какие регулярные встречи существуют в agile
Ежедневные собрания в Agile разработке: 15 минут, без которых не видать релиза
Большинство IT-компаний привыкли к ежедневным внутренним митингам, статусным собраниям или коротким stand up, которые призваны оптимизировать процессы и синхронизировать работу всех членов команды. Оптимально, если такие встречи не будут превышать 15-20 минут.
В Agile-разработке сегодня без митингов никуда. Однако рабочие собрания у команд Scrum, Kanban или XP отличаются и имеют свои особенности. В этом материале разбираемся в том, что отличает stand up в Scrum и Kanban, а также приводим аргументы в поддержку необходимости ежедневных собраний, как важного стимулятора роста в компании.
Любое внутреннее собрание – это элемент культуры любой организации. Не важно, какова цель встречи: обсудить выпуск новых почтовых марок или статусы задач в итерациях перед релизом вашего продукта, — каждое собрание собирает команду и обеспечивает принцип прозрачности работы.
Важно не создавать видимость полезного эффекта и не проводить собрания ради «галочки». Статус-собрание команды должно приносить пользу, потому что, даже 15 минут впустую потраченного рабочего времени каждого участника митинга может вылиться для компании в приличную сумму.
По статистике, приведенной одной американской компанией, большинство ежедневных рабочих собраний планируется на 11 часов утра и 63% из них начинаются без подготовленной заранее повестки дня. 33% проводимых собраний считаются неэффективными самими сотрудниками.
К сожалению, последняя большая цифра может настичь любую компанию: от «древней» бюрократической корпорации до молодого стартапа, в которых роль подобных встреч одинаково важна.
В Agile-командах, по большому счету, глобальный смысл ежедневного собрания с командой сводится к тому, чтобы быстро, качественно и надежно привести задачи к их завершению. Такое статус-собрание часто называют stand up, что имеет смысл «короткая встреча».
Менеджерам проектов или менеджерам продукта, которые чаще всего организовывают такие митинги и заботятся о том, как избежать рутины в задачах, следует постоянно следить, чтобы во время stand up некоторые члены команд не превратились в бесполезных статистов. Вот несколько их примеров:
Ежедневные собрания в командах Scrum и Kanban: в чем разница?
Agile методологии разработки Scrum и Kanban отличаются не только своей сутью, но и проводимыми командой ежедневными митингами.
Главная цель в ежедневном митинге в Scrum-команде – отследить, смогут ли быть выполнены командой все итерации, либо как можно раньше выявить причины, почему они не могут быть выполнены. Stand up в Scrum ориентирован на людей. В течение непродолжительного митинга, каждый член команды по очереди озвучивает свои результаты прошедшего дня и актуальный статус задач, давая обещание команде выполнить конкретные задачи сегодня. Если есть какие-то проблемы – они также озвучиваются.
Цель митинга в Kanban — максимально сократить время работы над задачей на всех ее этапах. Kanban-собрания не являются обязательными, но носят рекомендательный характер, поскольку могут реально влиять на ход задач. Митинг ориентируется на конкретную доску и выявление тех самых узких мест (англ. bottlenecks).
Scrum митинг фокусируется на людях, Канбан митинг — на задачах
Классические вопросы собрания Scrum могут также задаваться по ходу Kanban встречи, но опять-таки с фокусировкой на задачи, а не на членов команды:
Сложно ли перейти с Daily Scrum на Daily Kanban?
Если принято решение перейти с Scrum на Kanban, то адаптация к новому формат встреч должна пройти гладко. Меняется формат обсуждения, но результат экономии времени очень скоро становится очевидным.
Как избежать «зависающих» задач?
Сперва важно понять, почему задачи «зависают» и предпринять действия по их эффективному ускорению. Причины «тормозящих» релиз задач могут быть следующими:
Как оптимизировать митинг. Или что мешает проведению эффективного stand up?
Каждый участник ежедневного stand up в любой Agile команде должен руководствоваться определенными правилами, которые помогут не превратить встречу в рутину, а в эффективное мероприятие:
Заключение
Любое продуктивное собрание должно заканчиваться свежими идеями, четкими решениями и краткосрочным планом действий. Менеджер продукта и все участники возвращаются на рабочие места с полным пониманием своего статуса и статуса проекта в целом, вносят необходимые изменения в своей платформе для управления проектами.
А вы уделяете достаточно внимания собраниям внутри команды? Как проходит ваш типичный stand up митинг? Делитесь в комментариях!
Мы знакомы?
Развеиваем мифы о четырех agile-собраниях
Просмотр тем
Собрания являются важной частью Agile-разработки. Но это лишь одна из многих важных составляющих, и она не может существовать в отрыве от остальных. (Конечно, есть соблазн включить собрания в проект, использующий каскадную модель, и назвать его Agile, но пользы от этого будет мало.)
Давайте рассмотрим каждое Agile-собрание и узнаем, какие возможности они дают команде и почему считаются движущей силой Agile-разработки.
Примечание. Некоторые из этих собраний сложились в результате применения Scrum — итеративного подхода к реализации Agile с проведением работы в рамках фиксированных промежутков времени. Идеи, лежащие в основе этих собраний, можно применить к другим формам Agile, например к Kanban или бережливому производству. Понятие «спринт» относится к Scrum. Обычно спринт представляет собой событие с фиксированной продолжительностью (месяц или меньше), которая позволяет сохранять единообразие. В других формах Agile для обозначения ограниченного по времени периода разработки используется более общее понятие «итерация». Длительность собраний часто зависит от продолжительности спринта или итерации.
Планирование спринтов
Состав участников: команда разработчиков, Scrum-мастер, владелец продукта.
Когда проходит: в начале спринта.
Продолжительность: обычно до двух часов на каждую неделю итерации. То есть двухнедельный спринт нужно начинать с четырехчасового собрания по планированию.
Agile-методика: Scrum. (Конечно, команды Kanban тоже занимаются планированием, но они не проводят формальное планирование спринта в соответствии с фиксированным графиком итераций.)
Назначение: на собрании по планированию закладывается основа для успешного спринта. На это собрание владелец продукта приносит бэклог продукта с расставленными приоритетами. Вместе с командой разработчиков он обсуждает каждую рабочую задачу, после чего группа совместными усилиями оценивает необходимые трудозатраты. Затем команда разработчиков дает прогноз на спринт, в котором указывает, какой объем работы из бэклога продукта она может выполнить. Этот объем работы становится бэклогом спринта.
На собрании по планированию спринта проработайте все мельчайшие детали работы, которую предстоит сделать. Пусть участники команды набросают примерные задания по всем историям, багам и задачам, которые входят в спринт. Поощряйте обсуждения и придите к единому взгляду на план действий. Эффективное планирование значительно повышает шансы команды успешно выполнить обязательства, которые она взяла на себя в рамках спринта.
Ежедневный стендап
Состав участников: команда разработчиков, Scrum-мастер, владелец продукта
Когда проходит: раз в день, как правило, утром.
Продолжительность: не более 15 минут. Не занимайте конференц-зал и не давайте участникам стендапа садиться. Если все будут стоять, собрание не займет много времени.
Agile-методика: Scrum и Kanban.
Назначение: стендап нужен для того, чтобы быстро сообщить всем о ситуации в команде. Это не полноценная планерка. Атмосфера должна быть легкой и непринужденной, но не бессодержательной. Пусть каждый участник команды ответит на следующие вопросы.
Когда отчитываешься о прогрессе за вчерашний день перед коллегами, проявляется личная ответственность. Никто не хочет оказаться участником команды, который постоянно делает одно и то же и не движется вперед.
В некоторых командах используют таймеры, чтобы не отставать от графика. Другие бросают друг другу мячик, чтобы все присутствующие сохраняли концентрацию. Многие распределенные команды используют видеоконференции или групповые чаты, чтобы преодолеть разрозненность. Ваша команда уникальна, и ваш стендап должен быть таким же!
Обзор итогов итерации
Состав участников:
Обязательно: команда разработчиков, Scrum-мастер, владелец продукта.
Необязательно: заинтересованные в проекте стороны.
Когда проходит: в конце спринта или по достижении контрольной точки.
Продолжительность: обычно 60 минут на каждую неделю итерации. То есть за двухнедельным спринтом должен следовать двухчасовой обзор итогов.
Agile-методика: Scrum и Kanban. Как и при планировании, Kanban-команды должны проводить обзор итогов в соответствии с контрольными точками, принятыми в команде, а не с фиксированным графиком.
Назначение: на собрании по обзору итогов итерации команда представляет результаты своей работы. Собрание может проходить как в свободной обстановке (по типу «пятничных демонстраций»), так и в более формальной. На нем команда отмечает свои успехи, демонстрирует результаты работы, выполненной за итерацию, и выслушивает мнение заинтересованных в проекте сторон из первых уст. Помните: результат работы можно считать окончательным и готовым к демонстрации в ходе обзора итогов, только если он может быть представлен полностью и отвечает критериям качества команды.
В компании Atlassian обзор итогов спринта проводится в неформальной обстановке. Мы пытаемся придать ему атмосферу праздника: собираемся вокруг стола участника команды и смотрим демонстрацию его новой возможности. У нас в офисе даже не скупятся на аплодисменты!
Ретроспектива
Состав участников: команда разработчиков, Scrum-мастер, владелец продукта.
Когда проходит: в конце итерации.
Продолжительность: обычно 45 минут на каждую неделю итерации. То есть после двухнедельного спринта нужно провести 90-минутную ретроспективу.
Agile-методика: Scrum и Kanban. Scrum-команды проводят ретроспективы спринта в соответствии с фиксированным графиком. Kanban-командам тоже может быть полезно время от времени проводить ретроспективы.
Назначение: суть Agile — в быстром получении отзывов для улучшения продукта и культуры разработки. С помощью ретроспектив команды понимают, что удалось, а что нет.
Ретроспективы — это не только время для накопленных жалоб. Ретроспективы помогают определить, что работает (и пусть команда продолжит сосредоточиваться на этих аспектах), а что нет (уделите время поиску нестандартных решений и разработке плана действий). Постоянное совершенствование — это опора и движущая сила развития в Agile-команде, и ретроспективы играют в этом ключевую роль.
Даже если у команды все складывается хорошо, не переставайте проводить ретроспективы. Через ретроспективы команда получает актуальные указания, которые помогут ей оставаться на верном пути.
Команда следует Agile, когда у нее сложились надежные практики разработки, подход к изменениям в краткосрочной и долгосрочной перспективе и отличный опыт командного взаимодействия. Agile-собрания всего лишь упрощают обмен информацией в команде.
Церемонии
Мы встречались?
Четыре Agile церемонии, проясненные
Встречи, или «церемонии», являются важной частью Agile разработки. Но они являются одним из многих важных элементов и не должны проводиться в вакууме. (Соблазнительно добавить несколько церемоний к проекту водопада (waterfall) и назвать его «гибким» «Agile «, но это ни к чему вас не приведет.)
Давайте посмотрим на каждую из Agile церемоний и поймем, как они расширяют возможности команды и способствуют Agile разработке.
Планирование спринта
Когда: в начале спринта.
Продолжительность: обычно час в неделю итерации, например двухнедельный спринт начинается с двухчасовой встречи по планированию.
Agile фреймворк (структура): Scrum. (Команды Kanban также планируют, конечно, но у них нет фиксированного графика итераций с формальным планированием спринта)
Цель (намерение): планирование спринта настраивает всю команду на успех на протяжении всего спринта. Приходя на встречу, владелец продукта будет иметь приоритетный бэклог (отставание) продукта.
Они обсуждают каждый пункт с командой разработчиков, и группа коллективно оценивает прилагаемые усилия. Затем команда разработчиков сделает прогноз спринта с указанием объема работы, которую команда может выполнить из списка необходимых требований (backlog). Этот объем работы становится списком необходимых требований (backlog) спринта.
PRO TIP: Используйте совещание по планированию спринта, чтобы конкретизировать конкретные детали работы, которая должна быть выполнена. Поощряйте членов команды наметить задачи для всех историй, ошибок (багов) и задач, которые входят в спринт. Стимулируйте дискуссии и собирайте консенсус по плану действий. Эффективное планирование значительно увеличивает шансы команды на успех, выполняя обязательства спринта.
Ежедневные летучки (stand up)
Участники: команда разработчиков, мастер Scrum, владелец продукта
Когда: один раз в день, обычно утром.
Продолжительность: не более 15 минут. Не бронируйте конференц-зал и не проводите stand up- ы сидя. Проводите стоя,что помогает сделать встречу короткой!
Agile подход : Scrum и Kanban.
Цель (Намерение): Летучка предназначена для быстрого информирования всех о том, что происходит в команде. Это не подробный статус встречи. Тон должен быть легким и веселым, но информативным. Пусть каждый член команды ответит на следующие вопросы:
В отчете о том, какую работу вы выполнили вчера перед своими сверстниками, существует неявная ответственность. Никто не хочет быть членом команды, который постоянно делает одно и то же и не прогрессирует.
PRO TIP:
Некоторые команды используют таймеры, чтобы держать всех на ходу. Другие бросают мяч в команду, чтобы все обращали внимание. Многие распределенные команды используют видеоконференции или групповые чаты, чтобы сократить расстояние. Ваша команда уникальна. Ваша летучка тоже должна быть такой!
Итерационное ревью
Присутствовавшие:
Необязательно: заинтересованные стороны проекта
Когда: в конце спринта или вехи.
Продолжительность: 30-60 минут.
Agile подход: Scrum и kanban. Как и при планировании, обзор для команд kanban должен быть согласован с основными этапами работы команды, а не с фиксированным ритмом.
PRO TIP:
В Atlassian мы применяем непринужденный подход к ревью спринтов и придаем им праздничный вид. Мы собираемся вокруг стола члена команды и смотрим, как они демонстрируют свою новую функцию. Нередко слышно, как хлопают по всему офису!
Ретроспектива
Участники: команда разработчиков, мастер Scrum, владелец продукта
Когда: в конце итерации.
Продолжительность: 60 минут.
Agile подход: Scrum и Kanban. Scrum-команды делают спринт-ретроспективу, основанную на фиксированном ритме. Kanban команды также могут извлечь выгоду из случайных ретроспектив.
PRO TIP:
Даже если дела в команде идут хорошо, не прекращайте делать ретроспективы. Ретроспективы обеспечивают постоянное руководство для команды, чтобы все шло хорошо.
ТВИИТ: Некоторые люди думают, что Agile церемонии магически делают команду гибкой (Agile ). Они не правы.
Гибкость команды основана на надежных инженерных практиках, тактическом и стратегическом подходе к изменениям и отличном командном сотрудничестве. Agile церемонии просто облегчают общение в команде.
По материалам Agile Coach «Ceremonies»
Agile в Сбере: как понять, что происходит?
В декабре 2020 мы провели Sbergile Talks (да, давно это было), нашу первую онлайн-конференцию про Agile в Сбере. Три потока, 31 доклад, спикеры из крупнейших отечественных и иностранных компаний, которые так или иначе связаны с Agile. Нас слушало порядка 10 тысяч человек. Я хочу пробежаться по основным моментам и рассказать, что же там было.
Давно не секрет, что Сбер провёл одно из самых масштабных Agile-преобразований в мире. Об этом неоднократно рассказывали топ-менеджеры в различных СМИ. Итак, что важного в Сбере произошло за эти четыре года? Мы радикально ускорились. А скорость — это один из ключевых факторов развития для Сбера. И он жизненно необходим технологическим компаниям для успешного достижения поставленных целей. Особенно таким крупным компаниям, как наша. И да, Agile действительно ускоряет разработку продукта и даёт возможность компании быть в целом гибче. Поэтому многие так или иначе пытаются внедрить похожие практики у себя, но не у всех получается успешно. Мы и другие игроки рынка каждый год открыто рассказываем о возможных ошибках, накопленном опыте и практических примерах изменений.
Так почему же Agile так интересен российскому рынку?
Agile в России
Ещё пять-семь лет назад в России следовали ценностям, озвученным в Agile-манифесте, в основном ИТ-компании. Перестраивать mindset, тем более в крупных организациях, как наша, никто не спешил.
Тогда решения в Сбербанке принимались медленно, а ИТ-архитектура была монолитной. Это абсолютно нормально для компаний такого размера. И это не российский подход или какие-то особенности менталитета: плюс-минус так выглядят крупные игроки в большинстве отраслей экономики во всём мире. При этом Сбербанк был коммерчески успешным банком.
Но, чтобы стать успешным ИТ-игроком и конкурировать не только с банками, но и с международными технологическими гигантами, необходимо было ускориться. Поиск инструментов и подходов, которые бы помогли достичь столь амбициозной цели, привёл нас к Agile.
По нашему мнению, Agile — это работающие практики, которые способны запустить процесс изменений в компании. А в бизнесе успешны те компании, которые готовы меняться и подстраиваться под запросы рынка.
Где смотреть доклады?
Какие доклады стоит посмотреть и почему?
В направлении «Организация» — взгляд бизнеса на управление в целом.
Как проводить стендап
В чем разница между статусным митингом и стендапом в Agile, и как его проводить с максимальной пользой.
Стендап (Stand Up, Daily Scrum, Kanban Meeting или просто дэйли) — регулярная короткая встреча Agile-команды, которая призвана синхронизировать всех участников, обеспечивать прозрачность рабочего процесса и таким образом поддерживать эффективность и производительность команды.
Традиционно стендап занимает 15 минут и проводится ежедневно в начале рабочего дня. Участники — продуктовая/проектная команда, владелец продукта, скрам-мастер — синхронизируются, кто чем занимался, чем будет заниматься до следующего стендапа и какие у кого есть трудности, мешающие работе над задачами.
Некоторые команды отказываются от стендапов, считая их лишней тратой времени. Мы с этим не согласны — это хороший инструмент для эффективного командного взаимодействия.
Если стендапы не работают, скорее всего, вы их неправильно проводите.
Ежедневный Stand Up:
Главное отличие стендапа от статусного митинга
Традиционный статусный митинг — это коммуникация «один к одному»: руководитель или проджект-менеджер задает вопрос по той или иной задаче, один сотрудник отвечает, остальные украдкой читают Телеграм.
Стендап подразумевает совместное обсуждение и обмен информацией, и в этом его главное отличие — и преимущество — перед статусным митингом. Один на один можно побеседовать в любое время, смысл в том, чтобы все сказанное в эти 15 минут было полезно всем участникам встречи.
Людям свойственно, отвечая на вопрос, обращаться к тому, кто его задал. И задача ведущего стендапа (владельца продукта или скрам-мастера) этого избегать:
В общем, модерировать, а не возглавлять.
Стендап в Scrum и Канбан
Kanban Meeting и Daily Scrum Meeting — близкие инструменты. Основное отличие в том, что в Scrum стендап фокусируется на людях, а в Kanban — на задачах.
Во время Daily Scrum Meeting участники делятся результатами предыдущего дня, планами на текущий рабочий день и проблемами, препятствующими движению вперед. В качестве визуализации, как правило, выступает доска задач.
Каждый участник отвечает на три вопроса:
В Канбан стендап призван минимизировать время на выполнение задач на всех этапах процесса. Обсуждение ведется вокруг доски и элементов на ней: участники проверяют каждую колонку справа налево (начиная с ближайших к «Готово») в поисках любых проблем потока — узких мест, блокировок, растущих очередей.
Идеальный стендап
Ежедневные стендапы станут эффективным инструментом команды, если придерживаться при их проведении нескольких правил.
1. Ограничить время
Обычно на стендап отводится 15 минут, это тот случай, когда быстрый равно эффективный. Команде важно обсудить все обновления и выявить факторы, которые блокируют выполнение задач. Подробности можно будет потом обсудить лично, в чате или назначить отдельную встречу.
Лучше всего стендап работает, когда становится частью рутины. В идеале его нужно проводить по фиксированному расписанию. Опоздавших не ждем: 15 минут есть 15 минут, и опыт показывает, что такой подход быстро дисциплинирует.
2. Определить цель
Важно, чтобы все понимали зачем и для чего собрались и были готовы к обсуждению темы. В конце каждого стендапа должна быть достигнута его цель: расставить приоритеты задач, принять решение и назначить следующие шаги, синхронизировать команду и тд. Это помогает исключить любые несвязанные темы и рационально использовать время.
3. Дать высказаться всем
Во время стендапа никто не доминирует и не отсиживается в углу с ноутбуком. Каждый участник коротко делится важной информацией, затем может следовать небольшое обсуждение. Главное — не выпадать из ритма встречи. За таймингом следит ведущий стендапа (обычно скрам-мастер).
4. Придерживаться структуры
Неформальный характер встречи не значит неорганизованный. За соблюдением структуры также следит модератор: важно не уходить в сторону, не закапываться в детальное обсуждение и ничего не пропустить.
Структура зависит от подхода (Scrum или Канбан) и характера проекта. Это может быть обсуждение: что сделано со времени последней встречи; кто над чем сейчас работает; блокаторы и трудности. А можно идти по задачам (проектам), в этом случае члены команды делятся обновлениями по задачам, в которых они участвуют.
Стендап позволяет за 15 минут, — время, которое тратится на утреннюю чашку кофе, — обсудить актуальные задачи, выявить блокеры, задерживающие их выполнение, в целом синхронизироваться по работе над проектом/сервисом.
Попробуйте провести в формате стендапа вашу следующую статусную встречу — даже если не все с первого раза пройдет гладко, встряхнете рутину и получите ценный опыт.
Чтобы отработать проведение встреч под руководством опытного Agile-коуча и фасилитатора, приходите на тренинг Advanced Scrum Master & Agile Coach.