. Для каждой истории участники рассказывают, что было сделано, что будет сделано и какие препятствия мешают завершению. Команда корректирует распределение по историям.
• История рассказывает себя сама
При этом подходе три вопроса задаются не каждому участнику команды, а каждой истории, находящейся в процессе.
Участник, начавший работу над историей, представляет данные по прогрессу над ее реализацией. Он приводит условия приемки, проверенные после предыдущей схватки, и условия, которые должны быть проверены в следующий раз. С другими разработчиками, вовлеченными в работу над историей, он выявляет возможное препятствие и, в случае необходимости, планирует обсуждение, посвященное его устранению.
Затем команда переходит к следующей истории. Таким образом, обсуждаются все истории, которые находились в работе с момента последней схватки.
Рисунок 10.7 – Команда соблюдает порядок историй в соответствии с таблицей
• Распределение историй
Истории распределяются между участниками команды. Когда кто-то завершил задание, возникают вопросы, которые обсуждаются коллективно: останется он работать над этой историей, присоединится к завершению другой или, может, возьмется за новую историю?
Кроме того, необходимо определить, в какой момент рабочего дня вмешательство Владельца продукта (например, для проверки условий приемки) или Scrum-мастера (чтобы помочь устранить препятствие) будут наиболее релевантными для каждой истории.
Продолжение схватки совпадает с классическим подходом.
•Риски и преимущества
Поскольку важно завершить истории, преимущество этого подхода заключается в большей концентрации команды на их завершении. Однако не следует упускать из виду цель спринта.
И наоборот, существует риск, что участники не станут вмешиваться в обсуждение над конкретной историей, а будут отмалчиваться – если тот, кто начал работу над ней, не предоставит слово другим.
Схватка помогает определить зависимости между задачами и отслеживать их состояние. Если первичная цель состоит в том, чтобы завершить задачи, ключевая цель состоит в том, чтобы завершить истории. Для достижения этого все связанные с историей задачи должны быть выполнены. Это приводит к приоритизации свободных задач. Обсуждения во время схватки позволяют команде договориться о порядке выполнения задач.
10.6 Антипаттерны
Ситуация. Scrum-мастер следит за индикаторами и прогрессом команды, но в пылу работы команда совершенно забывает о цели спринта.
Последствия. Потеря фокуса команды, все сидят по углам и работают над чем-то своим.
Как сделать лучше? Обеспечить наглядность цели, написав ее на доске. Направлять команду к достижению цели при помощи трех вопросов.
Ситуация. Обсуждения идут хорошо. Когда кто-то поднимает проблему, участники команды находят решение. Но в связи с этим продолжительность схватки часто превышает четверть часа. Из-за поиска решения проблем команда пускается в дискуссии.
Последствия. Команда теряет время.
Как сделать лучше? Чтобы схватка не затягивалась, следует соблюдать правила: проводить схватку каждый день; не обсуждать, каким образом устранить то или иное препятствие; право голоса имеют только участники команды.
Можно использовать какой-то сигнал, когда команда пускается в ненужные обсуждения – например, колокольчик, оповещающий о том, что участники теряют время.
Ситуация. Команда отчитывается перед Scrum-мастером, как перед руководителем.
Последствия. Утрата инициативности. Во время схватки Scrum-мастер становится руководителем проекта.
Как сделать лучше? Участникам следует обращаться ко всей команде, а не только к Scrum-мастеру. Распределение задач – это дело всей самоорганизующейся команды, а не Scrum-мастера. В данном случае он – только для поддержки.
Если во время собраний команда использует технологии вместо настенной доски, участники рискуют еще сильнее: вероятнее всего, именно Scrum-мастер будет сидеть за клавиатурой и управлять процессом.
Ситуация. Для создания красивого burndown-графика каждый участник делится, сколько времени он провел над выполнением задач.
Последствия. Потерянное время.
Как сделать лучше? Измерение времени, проведенного над выполнением той или иной задачи, не имеет никакой ценности в Scrum, так как способствует развитию микроменеджмента и индивидуального мониторинга.
Не следует измерять и время, потраченное на историю. Важен только прогресс на пути к цели спринта. Оценка, безусловно, полезна, но еще полезнее думать о завершении задач и историй. Вот почему при Scrum-подходе потраченное время не так важно. Для некоторых команд – это кардинальная смена взглядов.
По словам одного из моих клиентов, его спросили, сколько еще времени ему необходимо на задачу. Он ознакомился со списком: накануне на эту задачу было запланировано 14 часов. После быстрых вычислений он ответил: «Я работал над этой задачей 2 часа. 14–2=12, так что мне осталось 12 часов».
Ситуация. Свобода, самоорганизация… Но некоторые участники остаются сидеть, переписываются в соцсетях, переговариваются, опаздывают или вовсе не приходят.
Последствия. Команда не заряжается необходимой энергией в начале рабочего дня. Работа превращается в рутину.
Как сделать лучше? Scrum-мастер (или любой участник группы) может предложить варианты проведения схватки.
✓ Все высказываются по очереди слева направо, справа налево и т. д.
✓ Каждый отвечает на три вопроса сразу, а на следующий день – на каждый вопрос по очереди.
Для сплочения команды можно использовать аксессуары:
✓ музыка, оповещающая участников о начале схватки;
✓ мяч для игры в регби, который участники передают друг другу, чтобы высказаться.
11Обмен результатами во время обзора
До участия в обзорах спринта я присутствовал на многих обзорах проектов. Они касались документов, которые нужно было отправлять за несколько дней до собрания, чтобы у участников было время их прочитать. Само собрание могло быть очень долгим.
Обзор окончательного этапа разработки наземной части космической системы занял несколько дней. Рассматривался каждый документ, на каждый комментарий был еще один комментарий.
Целью этих обзоров было узнать состояние проекта, чтобы принять решение о его продолжении. Scrum-обзоры преследуют ту же цель, но путь к ее достижению кардинально отличается.
Обзор спринта – в первую очередь, обмен результатами, достигнутыми командой.
Согласно Agile-манифесту, чтобы узнать о ходе разработки, лучше полагаться на операционное программное обеспечение, а не на документацию. При разработке ПО команда должна показать рабочий код.
Команда следует именно этому принципу во время обзора, демонстрируя достигнутое за прошедший спринт. Это важный момент в эмпирической теории Scrum: демонстрация позволяет увидеть продукт, обратная связь – учесть все потребности.
11.1 Обмен – больше, чем просто демонстрация
Обзор касается результатов работы команды во время спринта. Это двухсторонняя коммуникация между командой и заинтересованными сторонами.
В случае разработки программного обеспечения – это инкремент, включающий в себя завершенные истории и все, что необходимо для его работы (документация, тесты, скрипты и т. д.). Именно эта операционная версия рассматривается во время обзора. Затем она будет предоставлена заинтересованным сторонам для обратной связи – после чего, возможно, введена в эксплуатацию.
Обзор проходит в последний день спринта. За ним идет ретроспектива. Продолжительность обзора зависит от продолжительности спринта.
После двухнедельного спринта команда Peetic собирается на обзор, который длится менее двух часов. В среднем – один час.
Обычно довольно легко не выходить за рамки такой продолжительности, если во время демонстрации обсуждать исключительно новое в этом спринте. Демо занимает примерно двадцать минут.
Чтобы демонстрация была убедительной, требуется небольшая подготовка к обзору. Но она не займет много времени: в отличие от обзоров проектов, здесь слайды не нужны.
Вся Scrum-команда участвует в собрании. Модератором встречи выступает Владелец продукта. При этом настоятельно рекомендуется участие заинтересованных сторон.
В случае, если присутствуют заинтересованные стороны, это Scrum-событие является самым крупным по количеству участников. Обзор – событие для всех, входящих в экосистему. И это мероприятие является отличной возможностью вовлечь их в обсуждение и принятие решений о будущем продукта.
11.2 Результаты обзора
Главный результат – укрепление доверительных отношений между командой и заинтересованными сторонами.
Команда довольна, что показала качественный результат. Заинтересованные стороны убедились, что все работает, и обсудили продукт.
Бэклог дополнен обратной связью, собранной в ходе обзора. Были выдвинуты новые идеи – они нашли свое место в песочнице. При помощи демонстрации участники предложили свои результаты, получив взамен обратную связь, способствующую развитию продукта.