Паттерн «Ежедневный Скрам» из ScrumBook

Это перевод паттерна «Daily Scrum» из книги «A Scrum Book: The Spirit of the Game.» Если не указано [дополнительно], ссылки ведут на англоязычные разделы с паттернами из этой же книги.

Скрам-команда собралась вместе и готова начать или уже начала спринт. Команда разработки создала Бэклог спринта и работает над достижением Цели спринта. Однако,

никакой план действий не точен настолько, чтобы пережить хотя бы первое столкновение с противником,

фельдмаршал Хельмут фон Мольтке.

Короче говоря, созданные на Планировании спринта планы устаревают практически сразу же.

Проблема

Команда добивается прогресса в спринте, реализуя элементы Бэклога спринта, но из-за комплексного характера работы

свойства, размер и количество задач изменяются часто

— порой даже каждую минуту. Например,

  • альтернативные решения,
  • необходимые, но отсутствующие знания,
  • скрытые задачи, неверно понятые требования,
  • нуждающиеся в уточнениях требования,
  • зависимости между разработчиками,
  • проблемы в виде препятствий

— всё это может появиться в любой момент каждый день работы команды.

  • Существует 9 x 10157 [это 100!] вариантов упорядочить 100 задач, но только при нескольких вариантах команда окажется “в зоне”, где работа выполняется без усилий, и скорость значительно возрастает (см. Заметки о Velocity). Из-за изменчивой природы работы, чтобы быть выше среднего уровня, команде нужно адаптировать новый порядок хотя бы раз в день.
  • Дополнительно к изменчивости работы, команда может оказаться вынужденной пересмотреть свой план из-за отсутствия участника команды (например, по болезни).

Вопрос

Как справляться с этими трудностями каждый день наиболее эффективно?

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

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

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

Проблемы мешают прогрессу, пока команда не устранит их. Участнику команды нужно озвучить проблему всей команде. Но как это сделать?

Решение

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

  • Концентрируйтесь на работе на день, но держите в уме весь спринте.
  • Жестко следите за ограничением по времени, чтобы поддерживать фокус на плане на день и не отнимать время разработки. Проводите встречу за 15 минут или меньше.
    • Команда самостоятельно придерживается лимита времени, а Скрам-мастер помогает в этом при необходимости.
    • Многие команды во время встречи стоят, чтобы подчеркнуть малую длительность встречи.
    • После Ежедневного Скрама команда может продолжить обсуждение незавершённых тем, но если перепланирование занимает более 15 минут в день, это указывает на необходимость в Kaizen и Kaikaku [постоянное неустанное улучшение понемногу шаг за шагом локально или шире и больше].
  • Критически важно, чтобы все участники Команды разработки присутствовали. В редких случаях отсутствия разработчика по причине болезни или другой, вероятно, нецелесообразно направлять на встречу замену. Команда введёт его в курс дел самое позднее на следующем Ежедневном Скраме.

Формат 3 вопросов

Чтобы планировать, нужно знать, где ты сейчас и какие проблемы стоят на пути. Нужна полная картина. Популярная [но не единственная возможная] техника — каждому из Команды разработки ответить на 3 вопроса:

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

Обратите внимание, что как только разработчики озвучивают проблемы, возникает естественная склонность разобраться в деталях и исследовать возможные решения. Но эта встреча — для перепланирования и принятия решения, а не для решения проблем. Вместо этого несколько участников Команды разработки могут договориться встретиться в течение дня для работы над проблемой, и тем самым не тратить время остальных участников команды. На следующем Ежедневном Скраме они расскажут, что сделали [и как решили проблему].

В некотором смысле, Ежедневный Скрам — ежедневная версия ранее опубликованного паттерна, который рекомендует участникам команды сначала координировать проблемы широко, на более высоком уровне, и только потом погружаться в детали индивидуальных задач (см. Лицом к лицу перед удалённой работой [ссылка не работает]). Специальные действия, как Процедура ЧС, скорее всего станут следствием озвученных в ходе Ежедневного Скрама проблем.

Конечно же, из-за препятствий зачастую приходится изменять план — команда корректирует план на день, чтобы обойти их. Для этого и нужна эта встреча.

Кто участвует?

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

Результаты и преимущества встречи

Суть Ежедневного Скрама — в проверке реалистичности плана:

достигнем ли мы Цели спринта? 

Результат Ежедневного Скрама — обновлённый Бэклог спринта и связанные с ним информационные радиаторы. Однако, важно понимать, что Ежедневный Скрам — встреча по перепланированию, а не для отчётов о статусе. Обновлённая излучаемая информация — вторичный продукт, а не цель встречи.

Другими словами, результат Ежедневного Скрама — новый план на день, приземлённый на реальную ситуацию. Он формирует команду, стремящуюся к кооперации; с более ясным общим видением и пониманием того, что они делают вместе. Команда лучше соответствует ландшафту препятствий, на котором работает.

Ритуал Ежедневного Скрама помогает группе людей развить чувство командной идентичности. Он объединяет участников для фокусировки на общих предназначении и идентичности. Он повышает моральный дух команды (см. Гордость команды [ссылка не работает]).

У Ежедневного Скрама есть и дополнительные преимущества:

  1. Снижает затрачиваемое время, потому что команда ежедневно подсвечивает препятствия.
  2. Помогает найти возможности для координации, потому что все знают, над чем работают все остальные.
  3. Укрепляет общее понимание Цели спринта.
  4. Способствует сплочению команды, обеспечивая как минимум одно глобальное взаимодействие каждый день.
  5. Способствует обмену знаниями и выявлению пробелов в знаниях.
  6. Повышает общее чувство срочности.
  7. Поощряет доверие и честность среди разработчиков посредством проверяемого ежедневного статуса.
  8. Повышает культуру Команды разработки через общие ритуалы и поощрение активного участия.

История стендапа и Daily Scrum

Термин «встреча стоя» (stand-up meeting) имеет давнюю историю. Согласно упоминаниям, он использовался на мероприятиях с участием английской королевы Виктории [правила 1837–1901]. Необходимо было стоять в присутствии королевы.

Практика Ежедневного Скрама уходит своими корнями в проведённый Джеймсом Коплиеном и опубликованный в 1994 году анализ проекта Borland Quattro Pro для Windows [см.1]. Проект показывал выдающиеся результаты в части быстрого создания ценности высокого качества. Руководивший этим проектом Боб Варфилд вспоминает:

Встреча была важной частью нашей продуктивности. Сегодня она является краеугольным камнем Agile/Scrum и называется встречей «Stand Up» или «Standing». [Примечание: на английском языке фраза «standing meeting» означает ещё и «постоянное совещание», регулярное.] Очевидно, некоторые люди поняли это буквально и начали проводить собрание без стульев. Это нормально, ведь они достаточно короткие, поэтому отсутствие стульев — не проблема. Думаю, на своих встречах стулья я оставлю. Раньше я говорил людям, чтобы они приходили вовремя, потому что стульев будет на два меньше, чем участников. Но это было всего лишь моей плоской шуткой, и даже не припомню, чтобы когда-либо делал так.

Боб Варфилд, руководитель проекта Borland Quattro Pro для Window в 1994 [см.2]

Первая Скрам-команда провела ежедневную встречу в феврале 1994 года в ходе проекта «Borland Quattro Pro для Windows». Команда пришла к выводу, что ежедневные встречи в Borland сыграли важную роль в достижении необычайной производительности. Команда начала проводить ежедневные встречи во время своего 2-го месячного спринта. В марте 1994 команда взяла в спринт столько же работы, сколько и в предыдущий, но завершила её уже в течение 1-ой недели. С тех пор эффективные ежедневные встречи значительно увеличили скорость Скрам-команд по всему миру.

И ещё кое-что

Непрофессионалы часто приравнивают “следование Скраму” и проведение Ежедневных Скрамов. Действительно, Ежедневный Скрам около Скрам-доски является одним из наиболее заметных событий в Скрам-организациях. Однако Скрам — гораздо больше, чем применение любого набора инструментов. Аналогично,

пинание мяча в парке может выглядеть как игра в футбол, но это не футбол.

Этот и многие другие паттерны представляют критически важные компоненты фреймворка Скрам. Но всё же они являются лишь отправной точкой.


Дополнительно читайте:

Ссылки от авторов оригинальной статьи:

  • [1] James Coplien and Jon Erickson. “Examining the Software Development Process.” In Dr. Dobbs Journal of Software Tools 19(11), October, 1994, pp. 88–97.
  • [2] Bob Warfield. “How I Helped Start the Agile/Scrum Movement 20 Years Ago.” Smoothspan Blog, 2 October 2014, https://smoothspan.com/2014/10/02/how-i-helped-start-the-agilescrum-movement-20-years-ago/ (accessed 14 February 2019).
  • Photograph by Walker Lewis, 1944, Library of Congress, Prints & Photographs Division, FSA/OWI Collection, LC-USW3-055963-D.

Оставить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *