Вы не знаете, какую задачу делают коллеги? Бывает, что решаете проблему, которую уже решил ваш сосед неделю назад? Не можете найти время, чтобы поделиться с коллегами своими достижениями? Не знаете, когда можно озадачить коллег своей проблемой?
Все эти вопросы снимают ежедневные планерки. Ещё их называют летучки, собрание «на ногах», stand-up meeting, стендапы, daily scrum. Эту практику настоятельно рекомендуют использовать в Scrum и eXtream Programming. Вы найдете утренние планерки в организациях любого направления, но в IT есть свои особенности.
Что такое stand-up meeting?
Это самая простая и очень эффективная практика, которую вы можете внедрить в своей команде. Ежедневно проводиться собрание всей командой, на котором каждый отвечает на вопросы:
- Что сделал вчера? (гордость)
- С какими проблемами столкнулся? (просьба помощи)
- Что сделаешь сегодня? (обещание)
В идеале, все должны знать, чем занимаются другие. Это минимизирует потери времени, связанные с недостаточной осведомленностью членов команды.
Как меняются стендапы, если мы используете Kanban, описано в статье Стендапы в стиле Kanban.
Собираем воедино
Я внимательно отслеживал проблемы и решения, которые касались использования стендапов в наших проектах и проектах коллег. Ниже я опишу то, что стоит делать на планерках, а чего делать не надо.
Условные обозначения
Полезная практика, ее стоит применять
Это знак для вредных и опасных практик. Они портят саму идею стендапа.
Просто позитивные замечания и наблюдения
Лучшие и худшие практики
Стендап - это практически бесплатно.
Есть человек, который зовет всех на стендап. Обычно это Scrum Master, руководитель проекта, менеджер, самый ответственный или заводной участник команды.
Стендапы проводятся утром, чтобы сразу скоординировать работу команды.
Стендап нельзя затягивать - это будет простой тратой времени. Идеальное время, за которое каждый может ответить на 3 вопроса - 15 минут. Маленькая хитрость - внешний стимул побыстрее закончить - всем стоять, а не сидеть. Не каждый захочет стоять больше 15 минут.
Обсуждение технических деталей.
Разговоры на отвлеченные темы.
Присутствует вся команда.
Стендап - это идеальное время, чтобы найти, с кем поработать в паре (парное программирование).
Иногда проводим стендапы, иногда не проводим. Надо понять, что стендапы - это не просто обмен информацией, а настрой на работу.
На стендапе рассказывают всей команде про проблему, с которой вчера столкнулись. Значит есть все шансы найти того, кто знает решение твоей проблемы, кто уже решал её или знает полезную статью по теме.
Каждый участник думает, как помочь коллеге, когда тот делится проблемами.
Кто следующий говорит? Это решает тот, кто ведет стендап, скрам-мастер, назначенный командой ответственный или разработчик, который закончил говорить.
После стендапа вы получаете тонус на день.
Приходите подготовленным.
Трудно стоять, когда вчера ничего не делал. Лентяи становятся объектом внимания всей команды.
Стоять в кругу. Так всех видно.
Во время стендапа стоять перед доской, на которой отражена текущая ситуация в проекте. Например, это может быть доска задачами или burn down chart.
Прервать человека, который ушел от темы или углубляется в детали.
Менеджер записывает все, что говорится на стендапе, чтобы потом сделать из этого план на день. В конце дня по этому плану проверяется, кто что сделал.
Привлекать на стендап менеджеров, аналитиков и вообще всех, кто участвует в проекте, но без права голоса.
Планерка неформальное мероприятие, можно и посмеяться.
Ежедневные стендапы меняют культуру команды. Они вносят больше общения и открытости.
Проводить в одно и тоже время. Опоздавших без уважительной причины не ждём.
Стендап превращается в формальный отчет перед руководством.
С помощью ежедневных коротких встреч вы держите коллег в курсе последних изменений в проекте.
Рассказывая о проблемах, вы даете возможность коллегам учится на ваших ошибках.
На стендапе (и не только) просить помощи в решении проблемы. Слабо просить помощи? А не слабо терять месяц на задачу, которую уже решил коллега за соседним столом?
Благодаря стендапам новые разработчики быстро вливаются в процесс разработки. Это схоже с эффектом от парного программирования.
Когда человек говорит, что он сделает сегодня, он дает обещание команде. Это увеличивает ответственность и повышает результативность.
Делитесь своими достижениями, получайте похвалы коллег.
Команда планирует и координирует действия на день, выносят на обсуждения препятствия, которые мешают достижению цели.
Это должен быть сбалансированный процесс. Говорите сами и давайте коллегам высказаться в полной мере.
Мои значки совпали с вашим собственным опытом? Поделитесь и , которые вы вынесли из своей практики проведения стендапов.
Углубитесь в эту тему ещё больше:
It's Not Just Standing Up: Patterns of Daily Stand-up Meetings
AgileGuru: Daily Scrum Meeting
“Вопрос дня” или зачем мы проводим Daily Scrum
Extreme Programming Explained: Embrace Change, Ken Auer, Roy Miller
10 Reasons We Have Daily Stand Up Meetings
+ Даже новички сразу учатся формулировать свои мысли, а это очень важный навык для программиста
ОтветитьУдалитьгы :)
ОтветитьУдалитьу нас еще есть практика за опоздание на стендап - штраф, плюшки на всех! :)
@Раиль
ОтветитьУдалитьКстати, у нас есть подобное за многочисленное использование местоимений.
Например, "она должна там отображать его детали"
>Трудно стоять, когда вчера ничего не делал. Лентяи становятся объектом внимания всей команды.
ОтветитьУдалитьПодкашиваются ноги? :) от страха.. :D
Со скайпом всё несколько сложнее..
ОтветитьУдалитьФактически все, что Вы Александр перечислили соответствует нашим stand up meeting -ам только вот иногда кажется, что это действительно отчет перед руководством. Комманда у нас 12 разработчиков и еще 3 человек, кажется что всеже комманда не очень сплоченая.
ОтветитьУдалитьС большинством согласен.
ОтветитьУдалить> Обсуждение технических деталей.
> Разговоры на отвлеченные темы.
Если занимает пару минут, IMHO - почему бы и нет. Насчет ухода в *длительное* техническое обсуждение - конечно переносить на потом.
> На стендапе рассказывают всей команде про проблему, с которой вчера столкнулись. Значит есть все шансы найти того, кто знает решение твоей проблемы, кто уже решал её или знает полезную статью по теме.
У нас обычно рассказывается про *уже решенные* проблемы, или совсем уж "вечерние". Временами - про ожидаемые проблемы. День молчания при наличии проблем - нереально много, такое поведение может немного извинить разве что удаленная работа.
У нас проходят примерно также.
ОтветитьУдалитьСтолкнулись с проблемой: есть отдельные товарищи, которые используют большое количество вводных слов или начинают очень подробно описывать всё то, с чем столкнулись. Одним словом, надолго переключают на себя внимание...
Поэтому мы ввели ограничитель времени, в качестве ограничителя используем песочные часы на три минуты. Говорящий сразу видит, что бесценное время утекает и старается излагать мысль яснее.
@Elena @Олег Аксенов
ОтветитьУдалитьСпасибо!
> День молчания при наличии проблем - нереально много
ОтветитьУдалитьКстати, да. Кто-нибудь решал такую проблему, или никто не сталкивался с таким? :)
Очень плохая практика, с которой мне иногда приходилось сталкиваться - это проведение планерок в стиле "разбора полетов" и "публичной порки".
ОтветитьУдалитьЦелесообразность ежедневного проведения планерок вызывает сомнение, поскольку реальная потребность в проведении коллективных обсуждений является переменной величиной, зависящей от многих факторов (прежде всего, от сложности проекта и от его фазы). Но планерки не должны проводиться реже 1 раза в неделю.
Также непонятно, почему приглашенным на планерку (стендап) менеджерам, аналитикам и прочим участникам проекта не следует давать право голоса.
Если планерка касается только программистов, то зачем присутствовать на ней указанным работникам? В противном случае, почему бы им не высказаться, в части их касающейся?
@Павел Сандовин
ОтветитьУдалить> Очень плохая практика, с которой мне иногда приходилось сталкиваться - это проведение планерок в стиле "разбора полетов" и "публичной порки".
+1
> Если планерка касается только программистов, то зачем присутствовать на ней указанным работникам? В противном случае, почему бы им не высказаться, в части их касающейся?
Как раз для того, чтобы не было разбора полетов. Часть, которая их касается обсуждается на планировании и ретроспективе. Естественно, что если ситуация требует их вмешательства, то они могу взять право голоса. Но это очень редкий случай.