Что такое Agile, и зачем бизнесу гибкие методологии

Преподаватель Русской Школы Управления, бизнес-тренер Максим Якубович — о принципах и проблемах гибкой разработки продуктов. Основные тезисы прямого эфира.

Agile — это философия, система ценностей, которая помогает быстрее запускать новые продукты. Термин появился в 2001 году, когда практики, объединенные идеей разработки
ИТ-проектов, встретились для обсуждения рабочих подходов. Они создали Agile-манифест, содержащий 4 ценности и 12 принципов работы по Agile.  

Для чего нужен Agile 

В первую очередь Agile применяют при создании новых продуктов, в ситуации, когда их нужно выпустить на рынок как можно быстрее. Это касается не только ИТ, но и любого материального продукта — автомобиля, прибора. 

Второй случай — когда создается новый продукт, формируется новый рынок, и никто не знает, какие качества и функции потребуются, какие технологии нужно использовать.

Выгоды Agile

Участники исследования, проведенного среди представителей 1400 российских компаний, отметили три выгоды, которые дает гибкая методология разработки: 

1. Лучшее управление с меняющимися приоритетами по ходу проекта. Заказчик проекта может легко вносить изменения в требования к будущему продукту. 

2. Прозрачность ведения проектов.

3. Ускорение поставки и выход на рынок продукта (time to market). Agile позволяет сократить время от создания идеи до выпуска первой версии продукта на рынок. 

Ценности Agile

Люди и общение важнее, чем процесс и инструменты. Если вы подобрали мотивированных людей, профессионалов своего дела, создайте возможности быстрой коммуникации. И люди сами выберут, какие процессы в работе над проектом наладить и какими инструментами пользоваться, чтобы быстрее создать правильный продукт. 

Работающий продукт важнее, чем исчерпывающая документация. Важнее создать правильный продукт, который угадает тренд, поймет потребности потребителей. Описание принципов его работы можно составить уже после того, как продукт состоится, будет создан прототип. 

Сотрудничество с заказчиком важнее, чем составление контрактов. Если заказчик и команда исполнителей подпишут правильный контракт, это защит стороны от некорректного поведения, но не защитит проект от провала. Поэтому гораздо важнее создать атмосферу доверия, созидания и творчества для достижения общей цели. 

Готовность к изменениям важнее следования плану. Любому проекту нужен план, дорожная карта. Но команда должна быть готова к тому, что у заказчика могут регулярно меняться приоритеты и требования, поэтому план тоже будет меняться. 

Популярные подходы к разработке продуктов

Система ценностей Agile содержит различные методы и подходы к разработке. Более половины разработчиков в мире предпочитают метод Scrum. На втором месте по популярности — Scrumban, смесь Scrum и Kanban. Сам Kanban используют всего 7%. В России популярность Scrum падает. Если в 2018 его использовали 50% компаний, то в 2020 году — 41%. С Kanban ситуация обратная. В 2018 году этот подход применяли 10% компаний, в 2020 — уже 23%.

Среди известных компаний не из ИТ-сферы методологию Scrum использует производитель военных самолетов Lockheed Martin, BBC, John Deere, Zara. Последняя благодаря гибкой методологии смогла сократить показатель time to market до двух недель, в то время как большинство российских и белорусских производителей одежды тратят на этот процесс от трех до шести месяцев. Многие другие компании благодаря Agile научились быстро выпускать продукты. 

Scrum

Термин «Scrum» означает «драка за мяч» в регби. В 1986 году два японских профессора описали похожий на Scrum метод создания новых продуктов и провели аналогию между поведением регбистов на поле и команды бизнесменов. В 1995 году основатели подхода Кен Швабер и Джефф Сазерлэнд представили Scrum Guide, в котором указали, как этот подход можно использовать для разработки программного обеспечения. Но сейчас он используется далеко не только в этой сфере.

Суть подхода можно изложить на одной печатной странице. В нем есть три роли, два документа и пять событий (совещаний).

Роли в Scrum

Владелец продукта. Он отвечает за создание успешного продукта, достигающего поставленной цели, и за расход бюджета. Это всегда эксперт в предметной области, и чтобы принимать правильные решения, он должен расставлять приоритеты в списке своих идей — какие функции у продукта должны быть. 

Ключевые задачи владельца продукта:

1. Собирать все идеи о том, каким должен быть продукт, вести журнал продукта (Product backlog).

2. Расставлять приоритеты в этом журнале. Команда должна знать на несколько недель вперед, какими функциями продукта она будет заниматься. С этим часто возникают сложности, потому что расставить приоритеты в длинном списке идей непросто. Владельцу продукта нужно выбрать подход для этого и научиться его использовать. 

3. Принимать результаты работы команды, каждый спринт. Это отрезки времени длительностью от одной до четырех недель, на которые разделяется вся работа. Каждый спринт команда должна спланировать, а в конце его показать, что было сделано.  

Scrum-мастер, который отвечает за продвижение и поддержку Scrum внутри команды. Он внедряет подход, доносит ценности Agile-манифеста и подхода (для него тоже есть свои ценности). Причем стиль лидерства Scrum-мастера сильно отличается от стиля руководителя: Scrum-мастер не дает ответов на вопросы, как выполнять какие-то задачи. Он задает вопросы команде, просит участников брать ответственность за решение на себя — как выполнить какое-то требование из журнала продукта. Учит команду самоорганизации. 

Ключевые компетенции Scrum-мастера:

1. Он должен быть хорошим фасилитатором, потому что отвечает за грамотное проведение всех событий (совещаний) Scrum, укладываясь в ограниченное время и достигая цели. В фасилитации есть набор инструментов, позволяющих привести совещание к успешному завершению в отведенное время. И фасилитатор выбирает те инструменты, которые кажутся ему наиболее адекватными в данный момент. Собственно, Scrum-мастер должен быть или фасилитатором, или модератором. 

2. Он должен быть коучем, тренировать команду и помогать людям получить навыки, важные для командной работы в Scrum. 

Команда в Scrum небольшая — от трех до девяти человек. Она должна быть кросс-функциональной: участникам нужны все навыки, необходимые для создания продукта. То есть она автономна и не зависит от других людей в решении задач. Конечно, бывают ситуации, когда нужен сторонний эксперт, если компетенций членов команды не хватает, но это исключение.

Идеальный участник команды должен обладать тремя специализациями, быть так называемым T-shaped работником. Главное — профессионализм. Это его стержень (графически выраженный в ножке буквы Т). А две дополнительные специализации (отходящие от стержня Т прямые) позволяют ему работать в режиме взаимозаменяемости. Например, программист может быть дополнительно менеджером по продажам и хорошим дизайнером. С T-shape обычно возникают проблемы, потому что таких специалистов очень мало. 

Документы Scrum

Журнал продукта. В него записывают все идеи о том, каким должен быть продукт. Идеи могут быть зафиксированы в виде требований, тогда в Scrum их называют эпиками или историями:

• Эпик — большое требование, которое не помещается в один спринт. 

• История — небольшое требование, помещающееся в спринт. 

Обычно эпики делятся на истории. И один из навыков, которым должна обладать команда, это умение разделять большой эпик на маленькие истории. Если команда не умеет это делать, ее учит Scrum-мастер. 

Также в журнал заносятся ошибки, которые были допущены во время использования продукта. В целом это список того, что должна сделать команда, чтобы выпустить правильный продукт, и расставленных владельцем приоритетов в списке идей и пожеланий. 

Журнал спринта (Sprint backlog) — план работы на будущий спринт. Детализация в нем доведена до уровня задач, чтобы можно было определить, как какое-то требование, названное историей, можно разделить на эти задачи. Чтобы сформировать журнал спринта, команде нужен дополнительный навык оценки объемов и масштаба работ. Все должны знать, какие задачи они успеют сделать за следующий спринт.

События (совещания) в Scrum

Груминг (Product backlog refinement). На этом совещании происходит работа с журналом продукта. Его нужно проводить перед каждым совещанием по планированию спринта. Участвуют владелец продукта и команда, модерирует совещание Scrum-мастер. 

На груминге владелец продукта вместе с командой могут исключить какие-то элементы из журнала. Например, требование с самым низким приоритетом, которое «висит» полгода. Руководителю понятно, что до конца проекта это требование не будет реализовано, и он удаляет его из журнала. 

Также на этом совещании разбивают крупные требования на мелкие (эпики разбиваются на истории), определяют приоритеты в журнале продукта и присваивают оценки элементам журнала, чтобы потом не тратить время на планирование спринта. 

Планирование спринта. Команда берет приоритетный элемент из журнала продукта и делит его на задачи. Все пожелания в журнале рекомендуется разбивать на задачи длительностью не более 8 человеко-часов. Или на такой объем, чтобы сотрудник мог выполнить задачу за один день. 

Элементы из журнала продукта разбивают на задачи, оценивают объем работ по каждой из них. Оценка в Scrum может проводиться в идеальных человеко-часах (это час, когда исполнителя никто не трогает, он находится в потоке и выполняет только одну задачу). Или можно оценивать в каких-то условных единицах, например, в майках: эта задача размера XS, эта — M или L. Или иначе присваивать вес каждой задачи.

Накануне спринта определяется окончательный список задач для него. На этом совещании обязательно присутствует владелец продукта, который дает свое согласие. Scrum-мастер модерирует совещание, следит за временем и за тем, чтобы по окончании совещания появился четкий план работ, который называется журналом спринта. 

Когда список задач определен, владелец продукта с ним согласился, уже никто не решает за исполнителей, кто и чем будет заниматься. Каждый участник команды сам выбирает для себя задачу — так повышается мотивация исполнителей. 

Обзор спринта, демонстрация. Участники команды показывают результаты своего труда за время спринта (например, за две недели) и получают обратную связь от владельца продукта. Один из участников записывает все замечания и по окончании совещания предоставляет их владельцу продукта, чтобы впоследствии включить какие-то из них в журнал продукта. Так команда сможет в следующем спринте быстро исправить что-то неверно сделанное.

Ретроспектива спринта. Это событие посвящено ответам на вопросы: 

• Что мы делаем хорошо? 

• Что мы могли бы улучшить в нашей командной работе? 

• Что мы возьмемся изменить во взаимодействии между участниками проекта? 

Собрав все идеи, Scrum-мастер подводит итоги, определяет исполнителей и сроки внедрения улучшений. Часть задач по улучшению взаимодействия командной работы попадают в план работ на следующий спринт. Таким образом, ретроспектива как бы замыкает цикл непрерывного совершенствования команды. Каждый раз, проводя ее по завершении спринта, команда решает, что улучшить.

Ежедневный Scrum (daily meeting, standup-meeting). Предназначен для того, чтобы каждый послушал команду, узнал, у кого какие проблемы и планы на следующий день. Это не статусный отчет Scrum-мастеру, а синхронизирующее совещание между участниками проекта. Обычно на этом совещании все отвечают на три вопроса: 

• Что ты сделал вчера? 

• Что помешало выполнить план на день, какие есть сложности при выполнении задачи? 

• Чем ты будешь заниматься сегодня? 

Какие проблемы возникают у участников команды при реализации задач?  

1. Студенческий синдром. Большинство людей откладывают исполнение задач до последнего момента. 

2. Сталкиваясь со сложностями, многие молчат и не говорят коллегам о возникших проблемах. Пытаясь решить их самостоятельно, теряют много времени, и по окончании спринта выясняется, что задача не выполнена. 

Kanban

Kanban — это не метод разработки программного обеспечения, не подход к управлению проектами, не жизненный цикл проекта. Это подход, позволяющий улучшить любой существующий процесс работы с его проектами и задачами. Его применяют в тех сферах бизнеса, где используется интеллектуальный труд. То есть его не стоит брать для производства, а вот для творческого труда он очень хорош. 

Принципы Kanban

• Начните с того, что есть сейчас. Kanban-метод можно применить к любому текущему подходу. Изучите, как сейчас работает конкретная команда, и начните с этого. 

• Договоритесь об эволюционном развитии. В отличие от Scrum, который использует революционный подход, где обязательно есть три роли, два документа, пять совещаний, в Kanban применяют текущий подход к совместной работе, его изучают и эволюционно меняют. 

• Поощряйте правильное лидерство на всех уровнях. 

• Выясните потребности и ожидания заказчика. 

• Управляйте потоком работ, дайте людям организоваться вокруг работы. 

• Развивайте правила, чтобы улучшить показатели. 

В Kanban также есть практики: визуализируй, ограничивай, используй wip-лимиты, управляй потоком, делай правила работы явными, внедряй циклы обратной связи и улучшай, эволюционируй.

Метрики Kanban

Lead time, время управления заданиями. Это время от начала работы по запросу до появления результатов у заказчика. 

Пропускная способность команды. Это количество запросов, которые команда реализует в единицу времени. 

Touch time, или время контакта, касания. Это суммарное время, которое кто-то из участников команды потратил на работу над запросом. 

Effectiveness, эффективность потока — процент времени, когда кто-то работал над запросом. 

Ресурсная эффективность — процент рабочего времени, в которое ресурсы реально работали. 

Work in progress (wip) — количество одновременно выполняемых командой запросов. Одна из важнейших метрик, используемых в Kanban. Специальную доску делят на стадии, для каждой из которых устанавливают wip-лимит. Он ограничивает количество задач, которое выполняется на этой стадии. То есть в Kanban используется «вытягивающий» процесс выполнения работ: мы можем вытянуть дополнительную задачу на доску только тогда, когда у нас освободилось место. Лозунг Kanban: давайте перестанем начинать что-то новое и начнем заканчивать то, что уже есть в работе.

Запомнить

• Agile придумали для сокращения времени выхода продуктов на рынок. Он очень хорош для проектов по созданию новых продуктов, требования к которым пока непонятны.

• Agile — это философия, а не методология, но внутри нее есть конкретные подходы. И самые популярные — фреймворк Scrum и Kanban-метод. Сторонники Kanban говорят, что тот является не Agile-подходом, а альтернативным способом стать гибкими. То есть Kanban разделяет ценности Agile, но выступает альтернативным способом стать Agile. Scrum использует революционный подход («Мы внедрим в организации новые три роли, два документа и пять совещаний!») и для некоторых проектов он будет работать очень хорошо. Kanban использует эволюционный подход: «Мы изучаем процесс совместной работы сегодня, внедряем метрики, ценности и практики Kanban и потихоньку улучшаем текущий процесс». 

• И еще существует подход Scrumban, который предполагает, что команда уже умеет работать по Scrum. Далее просто добавляется Kanban-метод. Его используют около 5% компаний.