Stand-up meeting: лучшие и худшие практики

26 ноября 2010 г.

Вы не знаете, какую задачу делают коллеги? Бывает, что решаете проблему, которую уже решил ваш сосед неделю назад? Не можете найти время, чтобы поделиться с коллегами своими достижениями? Не знаете, когда можно озадачить коллег своей проблемой?

Все эти вопросы снимают ежедневные планерки. Ещё их называют летучки, собрание «на ногах», 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

InfoQ: What Makes a Good Stand Up Meeting?

Are daily stand-ups necessary?

12 комментариев:

  1. + Даже новички сразу учатся формулировать свои мысли, а это очень важный навык для программиста

    ОтветитьУдалить
  2. гы :)

    у нас еще есть практика за опоздание на стендап - штраф, плюшки на всех! :)

    ОтветитьУдалить
  3. @Раиль
    Кстати, у нас есть подобное за многочисленное использование местоимений.

    Например, "она должна там отображать его детали"

    ОтветитьУдалить
  4. >Трудно стоять, когда вчера ничего не делал. Лентяи становятся объектом внимания всей команды.

    Подкашиваются ноги? :) от страха.. :D

    ОтветитьУдалить
  5. Со скайпом всё несколько сложнее..

    ОтветитьУдалить
  6. Фактически все, что Вы Александр перечислили соответствует нашим stand up meeting -ам только вот иногда кажется, что это действительно отчет перед руководством. Комманда у нас 12 разработчиков и еще 3 человек, кажется что всеже комманда не очень сплоченая.

    ОтветитьУдалить
  7. С большинством согласен.

    > Обсуждение технических деталей.
    > Разговоры на отвлеченные темы.

    Если занимает пару минут, IMHO - почему бы и нет. Насчет ухода в *длительное* техническое обсуждение - конечно переносить на потом.

    > На стендапе рассказывают всей команде про проблему, с которой вчера столкнулись. Значит есть все шансы найти того, кто знает решение твоей проблемы, кто уже решал её или знает полезную статью по теме.

    У нас обычно рассказывается про *уже решенные* проблемы, или совсем уж "вечерние". Временами - про ожидаемые проблемы. День молчания при наличии проблем - нереально много, такое поведение может немного извинить разве что удаленная работа.

    ОтветитьУдалить
  8. У нас проходят примерно также.
    Столкнулись с проблемой: есть отдельные товарищи, которые используют большое количество вводных слов или начинают очень подробно описывать всё то, с чем столкнулись. Одним словом, надолго переключают на себя внимание...
    Поэтому мы ввели ограничитель времени, в качестве ограничителя используем песочные часы на три минуты. Говорящий сразу видит, что бесценное время утекает и старается излагать мысль яснее.

    ОтветитьУдалить
  9. > День молчания при наличии проблем - нереально много

    Кстати, да. Кто-нибудь решал такую проблему, или никто не сталкивался с таким? :)

    ОтветитьУдалить
  10. Очень плохая практика, с которой мне иногда приходилось сталкиваться - это проведение планерок в стиле "разбора полетов" и "публичной порки".

    Целесообразность ежедневного проведения планерок вызывает сомнение, поскольку реальная потребность в проведении коллективных обсуждений является переменной величиной, зависящей от многих факторов (прежде всего, от сложности проекта и от его фазы). Но планерки не должны проводиться реже 1 раза в неделю.

    Также непонятно, почему приглашенным на планерку (стендап) менеджерам, аналитикам и прочим участникам проекта не следует давать право голоса.

    Если планерка касается только программистов, то зачем присутствовать на ней указанным работникам? В противном случае, почему бы им не высказаться, в части их касающейся?

    ОтветитьУдалить
  11. @Павел Сандовин

    > Очень плохая практика, с которой мне иногда приходилось сталкиваться - это проведение планерок в стиле "разбора полетов" и "публичной порки".

    +1

    > Если планерка касается только программистов, то зачем присутствовать на ней указанным работникам? В противном случае, почему бы им не высказаться, в части их касающейся?

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

    ОтветитьУдалить

Моя книга «Антихрупкость в IT»

Как достигать результатов в IT-проектах в условиях неопределённости. Подробнее...