Stand-up meeting, Daily Scrum Meeting или просто планёрки стали привычной практикой в IT. Я описывал различные нюансы стендапов ещё 5 лет назад в статье Stand-up meeting: лучшие и худшие практики. Казалось бы, техника проведения стендапов уже рассмотрена со всех сторон. Что в планёрке может быть сложного? Но совсем недавно наша компания начала практиковать несколько другой подход, с помощью которого мы ускорили выход задач в релиз.

Всё началось, когда летом 2014 года в Москве мы с Асхатом шли на тренинг и он обратил моё внимание на разницу между стендапами в Scrum и Kanban. До этого я не придавал особого значения таким нюансам. У нас в компании для части проектов используется Kanban, но стиль стендапов остался от Scrum’а.

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

Разница в стендапах между Scrum и Kanban

Если вы новичок в Scrum, то для начала рекомендую прочитать про Daily Scrum.

В Scrum стендап ориентирован на людей — каждый член команды по очереди рассказывает о результатах за прошлый день, даёт обещание на текущий день и делится проблемами. Дело в том, что в Scrum упор делается на выполнение обещания, которое команда даёт на итерацию во время планирования. Нужно сделать всё, чтобы выполнить обещание. Цель стендапа — отследить сможем ли мы выполнить все задачи итерации, если нет, то как можно раньше понять, в чем проблема и принять меры.

Дальше речь пойдет про Kanban. Если вы не использовали его, то рекомендую сначала прочитать бесплатную книгу Priming Kanban.

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

Вообще, стендап не является частью практик Канбан. В Канбан особо и практик-то нет, есть только несколько основных принципов. Стендап можно считать одним из способов реализации принципа improve continuously.

Итого получаем, что Scrum meeting идет вокруг людей, которые рассказывают про задачи, а Канбан meeting идет вокруг задач. Если говорить другим языком, то в Scrum имеем связь Программист 1 <-> * User Story, а в Kanban связь User Story 1 <-> * Программист.

Описание процесса

Давайте по шагам рассмотрим из чего состоит стендап в Kanban. Для примера будем рассматривать доску из статьи в Википедии.

1. Вся команда собирается вокруг доски. Если команда распределенная и доска электронная, то все открывают эту доску и созваниваются.
2. Желательно назначить того, кто будет ведущим. Это может быть кто-то из команды или любой другой человек, кто умеет проводить открытые обсуждения.
3. Идем по колонкам справа налево и по задачам сверху вниз. Суть в том, что самая правая колонка означает завершение работы, поэтому задачи, которые стоят ближе всех к завершению, имеют высокую ценность. Чем быстрее мы переведем задачу в самую правую колонку, тем меньше будет Lead Time.
4. В нашем примере самая правая User Story 754. Ведущий спрашивает: «Что мешает нам переместить задачу 754 в колонку Deployed?». Несколько человек могут сказать причину и объяснить, что мы ждем подтверждения от руководителя компании. В этом случае задача явно помечается стикером или комментарием, что она заблокирована по причине такой-то.
5. Следующая User Story 75. Ведущий задает тот же вопрос. Например, один из членов команды, кто отвечает за тестирование на Pre-Production среде, говорит, что берет эту задачу себе в работу. Он берет карточку с задачей и «тянет» ее в колонку Test on Pre-Production System. На этой задаче отмечаем, кто взял ее в работу стикером.
6. Дальше идем по всем задачам, которые есть на доске, пока ресурсы команды не закончатся. Каждый возьмет себе задачи в работу, чтобы на следующем стендапе перенести задачи в следующие колонки или рассказать, что блокирует работу.

Как можно заметить, в Kanban, в отличие от Scrum, обязательно нужна доска с визуализацией ситуации на проекте. Т.к. вы обсуждаете не конкретные действия людей, а текущее положение задач и их поток, очень важно видеть где эти задачи находятся. Как раз поэтому стендапы в стиле Kanban ещё называют Story-focused stand-up или Work Items Attend.

Кроме того, можно задавать 3 вопроса (а можно не задавать, это же Kanban), как это делается в Scrum, но эти вопросы будут возникать вокруг задач, а не вокруг членов команды:

1. Что мешает движению задачи?
2. Как задача двигается по потоку?
3. Что можно улучшить?

Результаты перехода

После смены стиля стендапов со Scrum на Kanban результат появляется сразу. Для примера привожу Cumulative flow diagram с проекта, где мы применили новые стендапы. Мы сделали это 24 марта и вы можете увидеть, как поменялась ситуация — мы увеличили выход задач в релиз:

Более подробно про Cumulative flow diagram рекомендую посмотреть в презентации Explaining Cumulative Flow Diagrams

Причины зависания задач

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

• Большое количество заблокированных задач. Например, задача дошла до предпоследней стадии и ждет подтверждения от Product Owner’а (PO) на заливку. При этом PO может быть занят, сменил фокус на другие задачи. Получается, что задача висит в одном шаге от релиза, в нее уже вложили много рабочего времени и остается сделать небольшое усилие. Если мы делаем стендапы в стиле Scrum, такие задачи некому тянуть в релиз, потому что этой задачей никто уже давно не занимается. Когда мы делаем стендап в стиле Kanban, такие задачи сразу становятся видны, кроме того каждый стендап мы к ним возвращаемся, т.к. идем справа налево.
• Приоритет у задач меняется. Задачи доходят до последних стадий, вдруг становятся не очень важными, команда переключается на новые задачи. Получается, что PO сменил приоритеты и не дал завершить работу. Изначально все мирились с таким положением вещей, потому что во время стендапов в стиле Scrum идет обсуждение задач, над которыми команда работает сейчас. Всё, что было до этого не так интересно.
• Работа заполняет время, отпущенное на неё.. Если итерация идет 3 недели, то все задачи будут висеть где-то на доске до завершения итерации. Даже, если какая-то задача может быть сделана раньше, то она может не дойти до последней стадии. В Scrum нет цели уменьшить Lead Time, тогда зачем релизить задачу раньше окончания итерации? Kanban подталкивает задачи в релиз, а стендапы в стиле Kanban этому способствуют.
• Много работы != много результата. На Scrum meeting команда может обсудить как много было сделано вчера. Но означает ли ударная работа, что команда дала много бизнес-результата? Возможно после ударной работы образовалось много бутылочных горлышек? Важным является поток задач и его нужно конролировать.

Заключение

Переход на стендапы в стиле Kanban очень прост. Использовать его можно с любого момента работы над проектом. Не важно какой у вас сейчас процесс: Scrum, Kanban, Scrumban или что-то ещё, если у вас есть доска и визуализация текущей ситуации на проекте, то описанный способ проведения стендапов вам подойдет.

Ссылки для погружения в тему:

The Daily Kanban Stand-up, Neel Lakshminarayan
Kanban – what is it and why should I care?, Landon Reese, Kathy Iberle
It’s Not Just Standing Up: Patterns for Daily Standup Meetings, Jason Yip
Kanban vs Scrum, Henrik Kniberg

Автор: AlexanderByndyu

Источник