что такое agile и scrum простыми словами
Как использовать Agile и Scrum для управления проектами
Agile и Scrum для руководителя проекта — основы гибких методологий, инструкция по ведению бэклога и спринтам, контроль процессов и организация работы.
Для чего внедрять гибкие методологии
Есть два подхода к разработке крупных проектов. Классический, или каскадный — это механика, в которой заранее готовится громадное техническое задание, учитываются все мелочи, предсказываются риски и затраты. И только потом начинается разработка. В digital такой метод работает неэффективно — когда команда разрабатывает большой проект, невозможно спрогнозировать все риски и проблемы.
Неожиданности появляются не только из-за бизнес-процессов, здесь работает и человеческий фактор. Например, представители заказчика могут намеренно затягивать внедрение ПО, преследуя личные цели. Сбор требований на этапе аналитики тоже не дает стопроцентной точности — заказчики не расскажут вам все сразу. Плюс сейчас ПО требует мгновенной реакции на отзывы пользователей — подход с долгой тщательной подготовкой не работает.
Управление проектами в стиле Agile и Scrum — иной подход. В основе — итерации, небольшие задачи с минимумом функций. Можно разработать основные функции, запустить ПО и постепенно дополнять его.
Agile — это подход к разработке большого проекта. Философия, которая позволяет создавать продукт с постоянно меняющимися требованиями.
Начните с бэклога
Scrum — это метод управления проектами, он входит в философию Agile. Ключевое отличие от классической, водопадной схемы создания ПО заметно сразу — для начала разработки не нужно техническое задание.
Вместо проектного задания используется бэклог — список функций, требований к системе, желаний заказчика. В Scrum они сортируются по приоритету. Это живой документ, добавляйте в него новые задачи по ходу работы.
Лайфхак — обратите внимание на столбец Приоритет на примере. Используйте не привычный список 1, 2, 3, 4. Попробуйте четырехзначные цифры — так вы сможете просто добавить строку между ними и выставить подходящий приоритет. Например, между 1 000 и 2 000 напишите 1 050.
Не нужно прорабатывать и продумывать полностью все функции сразу. Все «хотелки» и то, что появляется в процессе, добавляются в бэклог. Решайте, что делать сразу, а что стоит отложить на следующую версию.
Внедряйте спринты
Scrum создавался в первую очередь для гибкости и ускорения разработки. Для этого появилась механика спринтов — весь процесс делится на отрезки, обычно от одной до четырех недель.
Как это работает? Команда забирает из бэклога часть задач. Каждая разбивается на максимально мелкие тикеты. Теперь нужно оценить время на задачу, и вот здесь проявляется особенность Scrum.
Дело в том, что люди плохо считают процессы в абсолютных величинах. Сложно сказать, сколько часов что займет. Поэтому в Scrum используется относительная оценка. За основу берется простая функция, которую все оценивают одинаково — например, понятно, что ее сделают за час. Остальные тикеты вычисляются так — «это мы будем делать раз в пять дольше по времени».
Сделайте список версий продукта — от ПО с минимумом функций до полностью реализованного. Укажите к каждой версии прогноз по сроку выполнения.
Ключевая идея — до тех пор, пока команда не забрала задачи на спринт, их можно бесконечно видоизменять в бэклоге. В разработку уходит согласованная часть. Каждый спринт — это небольшой релиз, в конце которого команда показывает работающую функцию ПО.
Распределите роли в команде
В идеальном мире на ключевые роли в scrum-команде назначаются люди, выращенные на проекте. Такой человек будет знать процессы изнутри, лучше ориентироваться в оценках и понятнее ставить задачи.
Cвязующее звено между командой разработки и пользователями. Этот человек собирает общую концепцию продукта из мнений заказчиков и других заинтересованных в выпуске ПО людей. Он формирует задачи и расставляет приоритеты.
Член команды разработки, отвечающий за выполнение ежедневных процедур и за соблюдение интересов команды. Этот человек фиксирует дедлайны и начало спринта, добавляет оценки, отчитывается перед заинтересованными лицами об этапах проекта. Растите scrum-мастера внутри команды.
Люди, которые непосредственно создают и тестируют код.
К разработчикам есть несколько требований:
У такого принципа формирования команды есть минус — сложно заменить неожиданно выпавшего человека. Но скорость разработки на практике все равно выше, чем у других подходов.
Контролируйте процессы
Диаграмма сгорания — это наглядная демонстрация того, как команда «переваривает» все задачи проекта. Красная линия — план. Синяя — то, что делает команда. Диаграмма обновляется каждый день. Вы сразу видите, когда есть отклонения от плана: можно спокойно «крутить гайки» или менять приоритеты в бэклоге.
Контролируйте работу команды с помощью двух scrum-показателей:
Организуйте работу команды
В Scrum от сотрудников требуется минимальная отчетность. Каждый день человек должен ответить на три вопроса:
Задача руководителя — выяснить и устранить трудности, которые мешают разработчику добиться прогнозируемого результата. Для сотрудников это три-пять минут — ответили на вопросы, поставили оценки, разбежались работать дальше. Никаких решений или дискуссий.
В конце каждого спринта проводится ретроспектива. Команда встречается, озвучивает мнение, что в отрезке было хорошо, что плохо. Спросите у сотрудников идеи — что поможет им работать быстрее и эффективнее, что исправит проблемы. Запишите их в отдельный план — забирайте туда только те идеи, которые возможно сделать за следующий спринт.
Все идеи должны быть измеримы — например, «Ребята, давайте добавим серверов». Предложение просто работать лучше — не идея.
На следующей ретроспективе обсудите идеи из плана, отсортируйте их по категориям «плохо» и «хорошо». Повторите процесс — получается ретроспектива на ретроспективу.
Формируйте организацию процесса постепенно. Разбивайте день — например, шесть часов люди работают по спринтам, два часа остаются на срочные и случайные моменты. Если все пойдет без неожиданностей, ничего страшного, продолжайте спринт, сделайте больше тикетов.
Первый спринт команда всегда «факапит», потому что слишком оптимистично смотрит на дедлайны и задачи. Второй — берет очень мало задач и делает больше. Третий — снова плохая оценка, но уже чуточку лучше. Потом все выравнивается. Это рабочий процесс.
Демонстрируйте проект
Не затягивайте с первой версией продукта. Демонстрацию лучше проводить после каждого спринта — пусть даже релиз не пойдет к пользователям. Не копите внутри команды много функций — покажите их заинтересованным лицам и получите обратную связь. После — сразу измените бэклог.
В этом основное преимущество Scrum — гибко менять список задач во время разработки, не делать лишнего и не получать тысячи правок после завершения проекта, как в каскадной методологии разработки.
Изучите инструменты для контроля
Работать по системе можно даже на бумаге. Отлично подходит и таблица в Google Docs. Создайте свою рабочую область вручную или попробуйте специальные сервисы:
Чек-лист — как начать использовать Agile и Scrum на проекте
Теперь вы знаете основы Agile и Scrum и можете начать внедрять их в реальные проекты. Но для эффективной работы с командой этого мало — нужно уметь делать это осмысленно, знать тонкости методологий и не теряться в сложных моментах. Всему этому учат на курсе Skillbox. Одновременно с обучением сможете использовать полученные навыки в работе.
Делает из вебинаров статьи, пишет про все и даже немного больше.
Agile, scrum, kanban: в чем разница и для чего использовать?
Главный редактор RB.RU
Если раньше офисы модно было обустраивать «по фэн-шую», то теперь — исключительно «по эджайлу». Agile – это не только цветные стикеры, на которых удобно отмечать ход работы (стикеры, скорее, стоит относить конкретно к подходу kanban). А ведь есть еще и scrum – он тут при чем?
Специально для тех, кто запутался в терминах, мы кратко разобрали эти понятия и спросили экспертов, зачем компании переходить на новую систему.
Определение
Agile (agile software development, от англ. agile – проворный) – это семейство «гибких» подходов к разработке программного обеспечения. Такие подходы также иногда называют фреймворками или agile-методологиями.
Agile возник в IT-среде, но затем распространился и в другие сферы – от промышленной инженерии до искусственного интеллекта.
Смысл Agile сформулирован в Agile-манифесте разработки ПО: «Люди и взаимодействие важнее процессов и инструментов. Работающий продукт важнее исчерпывающей документации. Сотрудничество с заказчиком важнее согласования условий контракта. Готовность к изменениям важнее следования первоначальному плану».
Agile-манифест – главный документ всех «гибких» подходов к разработке. Он был создан в 2001 году группой энтузиастов-программистов, которые хотели понять, что именно лежит в основе разработки востребованного и полезного IT-продукта. Agile предполагает, что при реализации проекта не нужно опираться только на заранее созданные подробные планы. Важно ориентироваться на постоянно меняющиеся условия внешней и внутренней среды и учитывать обратную связь от заказчиков и пользователей. Это поощряет разработчиков и инженеров экспериментировать и искать новые решения, не ограничивая себя жесткими рамками и стандартами.
К отдельным agile-подходам относятся scrum и kanban.
Scrum – это «подход структуры». Над каждым проектом работает универсальная команда специалистов, к которой присоединяется еще два человека: владелец продукта и scrum-мастер. Первый соединяет команду с заказчиком и следит за развитием проекта; это не формальный руководитель команды, а скорее куратор. Второй помогает первому организовать бизнес-процесс: проводит общие собрания, решает бытовые проблемы, мотивирует команду и следит за соблюдением scrum-подхода.
Scrum-подход делит рабочий процесс на равные спринты – обычно это периоды от недели до месяца, в зависимости от проекта и команды. Перед спринтом формулируются задачи на данный спринт, в конце – обсуждаются результаты, а команда начинает новый спринт. Спринты очень удобно сравнивать между собой, что позволяет управлять эффективностью работы.
Kanban – это «подход баланса». Его задача – сбалансировать разных специалистов внутри команды и избежать ситуации, когда дизайнеры работают сутками, а разработчики жалуются на отсутствие новых задач.
Вся команда едина – в kanban нет ролей владельца продукта и scrum-мастера. Бизнес-процесс делится не на универсальные спринты, а на стадии выполнения конкретных задач: «Планируется», «Разрабатывается», «Тестируется», «Завершено» и др.
Главный показатель эффективности в kanban – это среднее время прохождения задачи по доске. Задача прошла быстро – команда работала продуктивно и слаженно. Задача затянулась – надо думать, на каком этапе и почему возникли задержки и чью работу надо оптимизировать.
Для визуализации agile-подходов используют доски: физические и электронные. Они позволяют сделать рабочий процесс открытым и понятным для всех специалистов, что важно, когда у команды нет одного формального руководителя.
Примеры употребления
Один из принципов Agile стоит на личной ответственности человека, а не на отлаживании внутренних процессов.
Когда в работе с профессиональными командами мы используем Scrum, чаще всего мы выбираем цикл длиной в 2–3 недели с ретроспективными собраниями, которые позволяют держать все под контролем.
(Из интервью «Ведомостей» с Фрэнком Сосьером, коучем компании Freestanding Agility)
Главная идея Kanban – визуализация рабочего процесса. Она заключается в создании физической панели, на которой можно наглядно отмечать прогресс.
Если говорить о том, что такое agile, я бы ограничился такой фразой – это набор ценностей, в рамках которых мы строим свою работу с продуктами, с процессами внутри организации.
(Управляющий партнер ScrumTrek Алексей Пименов в статье на Rusbase)
Слово экспертам
В зависимости от задач мы применяем разные методы в рамках философии – agile, scrum, kanban. Scrum позволяет развить в сотрудниках необходимые качества – проактивность, самостоятельность, организованность, коммуникабельность и дальновидность. Основной смысл метода – это выполнение задач в самоорганизующихся командах, где у каждого есть своя роль и каждый несет ответственность за свою часть работы. Используя scrum, мы проводим опросы персонала, составляем графики ожидаемой скорости выполнения задач. Agile мы используем во внутренних коммуникациях. Недавно провели очередной спринт по ликвидации опозданий сотрудников. Все начальники и специалисты, задействованные в проекте, провели целый день на совещании, обсуждая достижения, проблемы и предстоящие задачи в новом спринте. Сейчас мы активно внедряем в компании метод kanban. Цель внедрения kanban – повысить гибкость производства, лучше приспосабливаться к изменяющимся требованиям рынка. На практике метод помог нам добиться соответствия между складскими запасами и реально используемыми в производстве продуктами.
Важный момент: agile-методология – это общее направление, а kanban и scrum – уже ее разновидности. Мы используем связку scrum + waterfall, а также дорабатывали в течение года саму agile-доску. Главная причина использования: прозрачность и простота. По сути, это получается тот же самый конвейер Генри Форда: переход задачи от статуса к статусу со сменой исполнителя, поэтому основным принципом к самой agile-доске является уже простота. Мы используем agile как непосредственную часть нашего workflow, поэтому все проекты, от брендинга и разработки сайтов и вплоть до нашего стартапа по AI и нативной рекламе NativeOS, в бюро Chernika ведутся как раз по данному workflow. Работающий продукт важнее подробно прописанной документации. Это не говорит о том, что мы не ведем никакую документацию, нет. Это скорее взгляд в сторону эффективности с ударом по излишней бюрократии.
Scrum принес в нашу команду ритмичность и понимание — успеваем или не успеваем в срок. Мы видим скорость работы команды, нет ощущения постоянного факапа. Раньше были ситуации, что перед жесткими релизами scrum куда-то пропадал и все начинали просто фигачить — сейчас у нас это пропало, есть постоянное ощущение, что успеваем в срок. Если появляются риски, мы обсуждаем их с PD на ранних этапах, корректируем план или уменьшаем объем задач каким-то образом. Работа стала прозрачнее, рабочий день стал укладываться в 8-часовую норму и, по ощущениям, мы стали успевать больше. Мы понимаем, что когда у тебя есть ощущение, что ты не успеваешь, чувствуешь, что надо работать больше — это очень плохо влияет на продуктивность, от этого надо избавляться.
Для наглядности и открытости работы отдела разработки мы повесили специальную доску с пометками “to do”, “in progress”, ”review”, ”test”, “done”, где все члены команды наклеивают стикеры с задачами (в колонке “to do”), а по мере их выполнения перемещают в последующие пункты. И счастливый финал – конечный пункт “done”. Это помогает составить общую картину и дает возможность видеть, над чем работает каждый участник. Очень важный момент метода (и организации рабочего процесса): после утверждения всех задач (“to do”), список блокируется на внесение. Так новые поступающие задачи не отвлекают от процесса и не тормозят работу. Все участники также оценивают каждую задачу на предмет временных и материальных затрат, которые потребуются на выполнение. И вишенка на торте – ежедневные встречи в определенное время (Daily Scrum), где каждый член команды коротко рассказывает о том, что собирается сделать сегодня, что сделал вчера (и столкнулся ли с какими-то препятствиями). Это важно на пути к долгосрочным задачам – именно так можно вовремя понять, что пора сменить стратегию.
Scrum мы внедрили с двух попыток, потому что всем, от команды до пользователей, хочется иметь более прогнозируемый результат. В этом плюс методологии – четкие ритмы упорядочивают коллектив, повышают общий уровень знаний о проекте. Как следствие, результат становится более прогнозируемым, в том числе для наших «стейкхолдеров» – пользователей. Командная работа также повышает ответственность: все получают бонус, только если команда выполнила поставленные на определенном этапе задачи.
Agile – это философия, scrum – структура, waterfall – метод, kanban – система управления. Scrum и kanban – варианты agile, но у них есть некоторые явные различия. Методика scrum требует фиксированных ролей, тогда как у kanban нет необходимых ролей. Scrum основана на итерациях, объединяющих планирование, оптимизацию процессов и выпуск. В kanban это можно делать регулярно или каждый раз, когда вам нужно. Команда scrum требует оценки своей работы, тогда как команде kanban это не нужно.
Что почитать по теме?
RB.RU организует встречу проекта Founders’ Mondays для начинающих и опытных предпринимателей. Дважды в месяц по понедельникам.
Текст: Александр Петров.
Видео по теме:
Что такое Agile, как работает Scrum и почему от KPI пора отказываться?
«Гибкие методологии управления», Aglie – последние несколько лет эти термины не просто на слуху, они в абсолютном тренде. Даже мы, команда Kickidler используем методологию Agile в своей работе. Сегодня разберёмся в том, почему давно проверенные KPI уступают место новым подходам, а также поговорим о том, как контролировать сотрудников в Agile.
Что такое Agile?
Прежде всего, Agile – это не «ещё один метод управления компанией» и не какая-то конкретная практика. Agile представляет собой полноценную методологию: комплексное собрание инструментов, подходов и принципов, которые необходимы и достаточно для выстраивания любого бизнес-процесса в организации.
Главная идея Agile: контроль с сохранением максимальной гибкости в планировании и реализации проектов. Эта мысль появилась в Кремниевой Долине, где новые тренды возникали, развивались и гибли в течение считанных недель. Счёт шёл на часы: та мысль, которая ещё вчера могла родить нового титана рынка, сегодня уже никому не была интересна. Традиционный метод прямого управления, которого придерживались консерваторы, в таких условиях просто не работал – и так появился Agile.
В чём разница между Agile и Scrum?
Agile – это, собственно, методология, основные принципы которой вы найдёте чуть ниже. Можно назвать Agile фундаментальным базисом для выстраивания компании нового поколения. Scrum же – это «структурный подход»: один из инструментов Agile, который используется чаще всего.
Суть Scrum в создании универсальных проектных команд, внутри которых уже есть все необходимые специалисты: дизайнеры, разработчики, маркетологи. Исчезает сам формат сотрудничества между отделами: все, кто нужен, уже состоят в команде. Кроме того, к ней обязательно присоединяются «владелец продукта» (куратор проекта) и scrum-мастер, организатор работы.
Рабочий процесс в Scrum выстраивается спринтами – это периоды продолжительностью 7-30 дней, в зависимости от команды и проекта. На каждый спринт формируются свои задачи, по которым в конце подводятся результаты. А дальше следует новый спринт.
Манифест Agile и основные принципы
Всё строится на следующих ключевых правилах:
Это очень простые тезисы, но часть из них полностью противоречит привычным для консервативного бизнеса стратегиям прямого контроля и управления. Отсутствие бюрократии, самоорганизация внутри команд – новые нормы современного мира, что приводит нас к очевидному вопросу:
KPI устарели?
Система KPI хороша всем, кроме одного: чем дальше в 21-й век, тем хуже она работает. Чтобы понять, почему так происходит, нужно обратиться к истокам и посмотреть на 1954-й год. Именно тогда Питер Друкер, один из самых выдающихся теоретиков менеджмента в истории, представил свою концепцию «ключевых показателей эффективности».
Мысль была проста и элегантна: «Работодатель хочет, чтобы сотрудник выполнял определённый объём работ. Нужно определить для каждого работника – а в более широком понимании для каждого проекта или подразделения – некие ключевые показатели, которые позволят понять, справляется человек или нет».
KPI чаще всего очевидны: для маркетинга это количество лидов, для отдела продаж – собственно продажи. Для производства – объём выпускаемой продукции и процент брака. Для офиса – время, проведённое сотрудником за компьютером, в рабочем приложении. И так далее.
Однако у KPI есть ключевой недостаток: неповоротливость. Питер Друкер разрабатывал эту концепцию для рынка пятидесятых, стабильного и предсказуемого. Планирование на месяцы и годы вперёд было нормальным явлением, поэтому компания могла себе позволить вложиться в определение KPI, донесение их до сотрудников и контроль над соблюдением этих показателей.
Сегодня мы живём в совершенно другом мире: рынок меняется ежемесячно, ежедневно, а иногда и ежечасно. KPI устаревают раньше, чем вы их окончательно принимаете, становятся непоказательными. И здесь на сцену выходят новые методы организации работы.
Чего хочет современный работодатель?
Пользуясь KPI, мы устанавливаем жёсткие рамки конкретных показателей и загоняем в них сотрудника. Например, если для маркетолога ключевой параметр – количество лидов или заявок, он будет его повышать в ущерб их рентабельности в средне/долгосрочной перспективе. Работники на производстве могут увеличивать выработку, игнорируя рост расходов на обслуживание оборудования и замену инструментов. И так далее.
Современная практика показывает: KPI – это лишь промежуточный этап, который косвенно относится к настоящим требованиям работодателя. На самом же деле бизнес всегда стремится к выполнению вполне конкретных целей: росту выручки. Снижению расходов. Повышению конверсии рекламы. И так далее.
Методология Agile построена как раз на понимании этого принципа в сочетании с высокой динамикой рынка. Если упрощать, работает простое правило: ставите цель на короткий период – получаете результат – ставите новую цель. На первый план выходит не достижение каких-то абстрактных, численных показателей, а удовлетворённость конечного пользователя результатом вашей работы: клиента, руководителя, себя самого и т. д.
Как контролировать сотрудников без KPI?
Agile предполагает работу в проектных группах с контролем над достижением ценности. Вся деятельность ведётся короткими итерациями: 2-3 недели на выполнение одной цели – например, это может быть «снизить дебиторскую задолженность клиентов перед компанией на 40% и более». Команда работает, еженедельно проводятся общие совещания-планёрки с обсуждением результатов, по истечении срока подводятся итоги.
Такой подход работает, но при этом важно понимать: переход от привычных KPI к Agile-методологии, которая предполагает высокую вовлечённость сотрудника в процессы и определённую степень личной ответственности, не всегда проходит гладко. Более того, даже в процессе работы в agile-модели сотрудники могут время от времени пытаться снизить личный вклад в проект, «выехав на плечах других». Мир не стал идеальным, поэтому даже если ваша команда использует принципы agile, контроль за ней все равно нужен.
И здесь на помощь приходят методы непрямого контроля. Вам нужен способ проверять «уровень старательности» сотрудника, не привлекая его внимания – так вы не подорвёте доверие к принципам agile, но сможете держать руку на пульсе.
Мониторинг с помощью системы учета рабочего времени Kickidler даёт всю необходимую информацию: вы видите, сколько времени сотрудник проводит в рабочих приложениях, насколько он активен, какие ведёт переписки, чем вообще занимается на протяжении дня. При этом сам специалист даже не подозревает о вашем внимании.
Другой метод – дать сотрудникам возможность самим контролировать собственную продуктивность, без участия или с минимальным участием руководства. Для этой задачи идеально подходит новый инструмент программы Kickidler Автокик.
Автокик – это автоматические уведомления о нежелательных событиях и интерфейс самоконтроля сотрудника. Первая функция позволяет показывать сотруднику автоматическое уведопление, например, если он бездействовал в течение получаса, посещал непродуктивный для работы сайт или запускал нежелательную программу, например, игру. Интерфейс самоконтроля позволит сотруднику видеть собственную продуктивность за день, учитывая продуктивную, непродуктивную деятельность. Бездействие и общее количество отработанных часов. Специально для удаленных команд мы разработали возможность сотруднику самостоятельно включать и отключать граббер-агент программы, чтобы никто не имел доступ к компьютеру сотрудника в нерабочие часы.
В результате KPI как таковых нет, но вы сохраняете контроль над ситуацией. А в будущем можно использовать тот же Kickidler как платформу для самомодерирования отношения внутри команды – например, организовать открытый доступ к отчётам по активности работающей по проектам группы. «Все видят всех», полная прозрачность: такой подход увеличивает ответственность сотрудников и снижает вовлечённость руководителя, обеспечивая одновременный рост результатов.
Жёсткий прямой контроль уходит в прошлое. Сейчас наступило время гибких методологий и непрямого управления: попробуйте выстраивать работу по-новому, а наши инструменты вам в этом помогут.