Stand-up meeting, Daily Scrum Meeting или просто планёрки стали привычной практикой в IT. Я описывал различные нюансы стендапов ещё 5 лет назад в статье Stand-up meeting: лучшие и худшие практики. Казалось бы, техника проведения стендапов уже рассмотрена со всех сторон. Что в планёрке может быть сложного? Но совсем недавно наша компания начала практиковать несколько другой подход, с помощью которого мы ускорили выход задач в релиз.
Всё началось, когда летом 2014 года в Москве мы с Асхатом шли на тренинг и он обратил моё внимание на разницу между стендапами в Scrum и Kanban. До этого я не придавал особого значения таким нюансам. У нас в компании для части проектов используется Kanban, но стиль стендапов остался от Scrum'а.
Сейчас мы поменяли подход к стендапам, об этом я расскажу дальше, покажу разницу между тем, что было и тем, что стало. В конце статьи есть ссылки для более глубокого погружения в тему с описанием разных мнений и нюансов.
В Scrum стендап ориентирован на людей — каждый член команды по очереди рассказывает о результатах за прошлый день, даёт обещание на текущий день и делится проблемами. Дело в том, что в Scrum упор делается на выполнение обещания, которое команда даёт на итерацию во время планирования. Нужно сделать всё, чтобы выполнить обещание. Цель стендапа — отследить сможем ли мы выполнить все задачи итерации, если нет, то как можно раньше понять, в чем проблема и принять меры.
В Kanban преследуются другие цели — важно максимально сократить Lead Time, т.е. время работы над задачей на всех этапах. В связи с этим меняется и подход к стендапу. Он делается с ориентацией на доску, фокусировку на потоке задач и обнаружению бутылочных горлышек. Получается, что мы идем по колонкам с задачами справа налево, обсуждаем каким образом можно побыстрее перевести задачу на следующий этап. При обсуждении каждой задачи по ней может высказаться любой член команды.
Итого получаем, что Scrum meeting идет вокруг людей, которые рассказывают про задачи, а Канбан meeting идет вокруг задач. Если говорить другим языком, то в Scrum имеем связь Программист 1 <-> * User Story, а в Kanban связь User Story 1 <-> * Программист.
Давайте по шагам рассмотрим из чего состоит стендап в Kanban. Для примера будем рассматривать доску из статьи в Википедии.
Как можно заметить, в Kanban, в отличие от Scrum, обязательно нужна доска с визуализацией ситуации на проекте. Т.к. вы обсуждаете не конкретные действия людей, а текущее положение задач и их поток, очень важно видеть где эти задачи находятся. Как раз поэтому стендапы в стиле Kanban ещё называют Story-focused stand-up или Work Items Attend.
Кроме того, можно задавать 3 вопроса (а можно не задавать, это же Kanban), как это делается в Scrum, но эти вопросы будут возникать вокруг задач, а не вокруг членов команды:
После смены стиля стендапов со Scrum на Kanban результат появляется сразу. Для примера привожу Cumulative flow diagram с проекта, где мы применили новые стендапы. Мы сделали это 24 марта и вы можете увидеть, как поменялась ситуация — мы увеличили выход задач в релиз:
Важно понять, почему до этого задачи висели на последних стадиях и не уходили в релиз. Все в команде понимают процессы управления IT-проектами, заказчик в курсе текущей ситуации, но бывает, что задачи подолгу ждут. Мы выделил несколько причин:
Переход на стендапы в стиле 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
Всё началось, когда летом 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. Для примера будем рассматривать доску из статьи в Википедии.
- Вся команда собирается вокруг доски. Если команда распределенная и доска электронная, то все открывают эту доску и созваниваются.
- Желательно назначить того, кто будет ведущим. Это может быть кто-то из команды или любой другой человек, кто умеет проводить открытые обсуждения.
- Идем по колонкам справа налево и по задачам сверху вниз. Суть в том, что самая правая колонка означает завершение работы, поэтому задачи, которые стоят ближе всех к завершению, имеют высокую ценность. Чем быстрее мы переведем задачу в самую правую колонку, тем меньше будет Lead Time.
- В нашем примере самая правая User Story 754. Ведущий спрашивает: «Что мешает нам переместить задачу 754 в колонку Deployed?». Несколько человек могут сказать причину и объяснить, что мы ждем подтверждения от руководителя компании. В этом случае задача явно помечается стикером или комментарием, что она заблокирована по причине такой-то.
- Следующая User Story 75. Ведущий задает тот же вопрос. Например, один из членов команды, кто отвечает за тестирование на Pre-Production среде, говорит, что берет эту задачу себе в работу. Он берет карточку с задачей и «тянет» ее в колонку Test on Pre-Production System. На этой задаче отмечаем, кто взял ее в работу стикером.
- Дальше идем по всем задачам, которые есть на доске, пока ресурсы команды не закончатся. Каждый возьмет себе задачи в работу, чтобы на следующем стендапе перенести задачи в следующие колонки или рассказать, что блокирует работу.
Как можно заметить, в Kanban, в отличие от Scrum, обязательно нужна доска с визуализацией ситуации на проекте. Т.к. вы обсуждаете не конкретные действия людей, а текущее положение задач и их поток, очень важно видеть где эти задачи находятся. Как раз поэтому стендапы в стиле Kanban ещё называют Story-focused stand-up или Work Items Attend.
Кроме того, можно задавать 3 вопроса (а можно не задавать, это же Kanban), как это делается в Scrum, но эти вопросы будут возникать вокруг задач, а не вокруг членов команды:
- Что мешает движению задачи?
- Как задача двигается по потоку?
- Что можно улучшить?
Результаты перехода
После смены стиля стендапов со 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
Комментарии (7)
DeBovuar
14.05.2015 23:59+1Спасибо за статью, интересный подход, логично и похоже должно работать! Хотелось бы уточнить только один момент на следующем примере… Обычно крайние правые колонки — это валидации продактов\тестировщиков. Как разбираются задачи, в случае если в предпоследней колонке, которая, например, отвечает за подтверждение Product Owner'а (PO), задач больше, чем количество команды (разработчики и тестировщики)? Суть в том, что если фактически задачи «подвисли» в статусе, за который обычно отвечает определенная группа людей (например, тестировщики), и задач больше, чем участников этой группы, будут ли другие (разработчики?) брать на себя их решение (например, тестирование)?
AlexanderByndyu Автор
15.05.2015 09:22Ответ на этот вопрос, как на все остальные вопросы, которые касаются Kanban, лежит в принципе «Make Process Policies Explicit». Это означает, что как команда договорится, так и надо делать.
Если PO является бутылочным горлышком, то это нужно явно обозначить на стендапе и во время ретроспективы. Возможно PO отдаст часть полномочий аналитикам или еще кому-то, возможно PO станет не один человек, а несколько, например, кто-то из соинвесторов присоединится к этой работае.
Если выяснится, что PO просто не успевает разгребать задачи и расшить его полномочия не на кого, то тогда команде нет смысла работать с высокой скоростью. Возможно даже часть команды надо убрать на другой проект, потому что не имеет значение как быстро команда делает карточки, если PO не успевает их принимать.
Из своего опыта могу сказать, что довольно редко одни роли в команде, помогают другим. Кроссфункциональность есть, но с большими ограничениями. Бывает, что программисты помогают DevOps, аналитики помогают тестировщикам, но никогда не видел, например, чтобы программисты помогали тестировщикам или аналитики работали с DevOps.
imac
Изменилось ли как то время stand-up meeting?
Мне кажется если проходить по полному списку задач, а не по тем над которыми разработчик работал сегодня — время должно увеличиться.
AlexanderByndyu Автор
Время стендапов сначала увеличилось до 40 минут, а потом мы сбили его обратно до 15 минут. Дело было в том, что мы и заказчики привыкали. Много «залежалых» задач начали двигаться и время уходило на их обсуждение. Когда поток задач стал равномерным, обсуждение начали проходить быстро.
> Мне кажется если проходить по полному списку задач
Проходить по полному списку задач не нужно, нужно идти по задачам пока остались свободные ресурсы. Т.е. если все члены команды набрали себе работы на день, то дальше можно ничего не обсуждать.
imac
>Проходить по полному списку задач не нужно, нужно идти по задачам пока остались свободные ресурсы. Т.е. если все члены команды набрали себе работы на день, то дальше можно ничего не обсуждать.
Если идти от правого края, то в вашем случае столбцы Ready for Test, Ready for preprod, Ready for live должны разбираться полностью всегда, потому что только так можно выловить висячие задачи. Я правильно понимаю? Хотя Ready for test под вопросом, так как заивисит от организации процесса тестирования (могут или не могут там виснуть задачи).
AlexanderByndyu Автор
> должны разбираться полностью всегда
Я бы сказал, что они должны обсуждаться и по возможности задачи оттуда должны уходить правее.
Возможен вариант, что задачи из последних колонок не часто обсуждаются, например, если задача готова к заливке, а заливку на боевой можно делать только 1 раз в неделю в определенное время. Мы же не будем ежедневно обсудать эту задачу, проще пометить ее стикером и написать дату ее заливки, а во время стендапа пропускать.
> Хотя Ready for test под вопросом, так как заивисит от организации процесса тестирования (могут или не могут там виснуть задачи)
В Kanban как всегда всё решается принципом «Make Process Policies Explicit». Т.е. всё как вы договоритесь, как команде понятней и удобней.