[31]). Они дополняют друг друга.
За спринт история проходит три этапа, представленных через метод лотков: готовая история, история в процессе и завершенная история.
Планирование переносит истории из лотка готово в лоток в процессе.
Говоря об историях в статусе в процессе, части, составляющие работу над ними, называются задачами. Они распределены по трем колонкам (к выполнению, в процессе, завершено).
Их совокупность называется план спринта.
Рисунок 9.3 – План спринта, в данном случае – с задачами к историям в процессе
Для изображения этого плана рекомендуется использовать доску.
А если не все участники команды находятся в одном офисе? В таком случае, для тех, кто далеко, можно делать фотографии или использовать какой-либо инструмент, чтобы процесс был наглядным для каждого участника команды.
9.4 Как спланировать спринт?
Есть несколько путей, ведущих к результату. Вот одна из цепочек действий и паттернов планирования спринта.
✓ Команда помещается в контекст спринта (введение).
✓ Участники команды вместе с РО уверяются в готовности бэклога к началу спринта.
✓ Участники становятся самоорганизованной командой и приступают к определению задач.
✓ После обозначения задач команда начинает двигаться к цели спринта.
✓ Спринт запущен (заключение).
• Корректировка
Если обзор и ретроспектива предыдущего спринта вдохновили Владельца продукта на новые истории, которые показались ему интересными в рамках начавшегося спринта, он может попросить команду доработать их, чтобы добавить в список готовых историй.
Такое случается редко.
• Предварительная цель
Владелец продукта дает предварительную цель на данный спринт, которую он представил заинтересованным сторонам в ходе обзора.
Цель будет консолидирована во время собрания.
Пример. «Цель, которую я вам предлагаю, – говорит Селин, – это реализовать функциональность, касающуюся персонализированного коучинга».
• Доступность
Команда смотрит, насколько все участники будут вовлечены в процесс. Если они работают неполный рабочий день в начавшемся спринте, полезно это знать и учитывать: это может повлиять на коллективную работу.
Нужно отметить дни, когда на помощь команде приходят эксперты. Для наглядности можно составить визуальный календарь.
Scrum-мастер бдительно следит за возможными зависимостями между участниками команды и/или экспертами. Сложности возникают, если навыки и знания не передаются. Чтобы не допустить этого, у команды есть возможность изменить порядок историй.
• Календарный вопрос
Владелец продукта напоминает остальным место этого спринта в текущем сезоне.
Пример. Мы сейчас в третьем спринте четвертого сезона, который завершится через два спринта.
Называется предполагаемая дата окончания спринта.
Так как длительность спринтов фиксирована во времени, речь, скорее, о простой установке конкретной даты и дня.
Команда может изменить продолжительность спринта. Например, из-за отпусков, которые пришлись как раз на время спринта. Подобное решение принимается в исключительном порядке во время сессии планирования. Учитывая предварительную цель и ожидаемую доступность каждого участника, команда выбирает новую продолжительность спринта, но только на этот раз.
Дата завершения выбирается однократно и меняться больше не может.
Итак, у нас есть цель, пока что предварительная, проверенная доступность команды и дата окончания спринта.
Команда уже обсудила готовые истории во время доработки. Теперь ее цель состоит в том, чтобы решить, будет ли она брать их в работу в данном спринте. Команда обсуждает каждую историю и рассматривает, насколько возможно ее реализовать в течение спринта.
Команда Peetic проверила доступность Лорана, специалиста по картографированию, в котором она нуждается для реализации истории добавить маршрут выгула собак. Да, он cможет присутствовать три дня в конце первой недели спринта.
Поскольку проверки сделаны ранее (в момент, когда команда сочла историю готовой), обсуждение и принятие решения займут буквально пару минут.
Но неожиданности случаются и, как правило, в последнюю минуту: команда имеет право отложить историю, если считает, что необходимые условия не выполнены. Это лучше, чем тратить половину собрания или не завершить историю в течение спринта.
Рисунок 9.4 – Готовые истории в плане спринта
Желательно, чтобы все истории, которые способствуют достижению цели спринта, были готовы.
В результате этого обсуждения команда и Владелец продукта получают упорядоченный список готовых историй.
Следует обратить внимание: наиболее приоритетные готовые истории переходят в статус «В процессе» сразу по окончании планирования спринта.
Команда уже определила правила, эксплицитные [32] или имплицитные [33], если они прошли этап прелюдии (см. главу 13). В этом спринте участники отказываются от правил в пользу их улучшения посредством самоорганизации команды.
В этом плане команда явно стремится ограничить многозадачность, а точнее многоисторичность, так как это замедляет ход спринта из-за задержки погружения.
Задержка погружения, вызванная остановкой одной незавершенной работы, чтобы начать другую, – это время, необходимое для того, чтобы окунуться в новый контекст.
Например, после запоздалого прохождения теста приходится внести изменение в код истории. Разработчику, который берется за это (после того, как в течение нескольких дней он не занимался этой историей), требуется хотя бы час времени, чтобы вникнуть в контекст. Это и есть задержка погружения.
Паттерн роения (пчелиного роя, или ролевого интеллекта) предлагает решение, вдохновленное социальным поведением насекомых. У пчел этот паттерн используется во время кормодобывания.
Роение (swarming) состоит во временном разделении команды. Созданная подгруппа собирается вокруг истории и работает над ней до ее завершения.
Как пчелиный рой добывает пищу во главе с первопроходцем, нашедшим нектар, так и у истории есть свой референт и свои участники.
Референт истории – участник команды, который хорошо знает эту историю. Он заинтересован в ней, начиная с сессии доработки. Он рассказывает контекст истории остальным (когда Владельца продукта нет) и обеспечивает ее быстрое завершение. Он привязан к истории, пока она не будет завершена.
Другой аспект паттерна касается количества историй, которые могут параллельно находиться в работе. В частности, ограничивает количество историй в процессе (это ограничение называется WIP [34]-лимитом в Kanban, см. главу 20). Количество может меняться в зависимости от размера команды и уровня специализации.
В идеале команда берется за работу последовательно и завершает одну историю, прежде чем перейти к следующей. Но для большинства команд невозможно работать в группах больше 3–4 человек над одной историей.
Группы самоорганизуются вокруг истории и сами решают, будет ли у нее референт или можно обойтись без него.
Когда первый круг историй завершен, команда переходит ко второму кругу – и так далее. Роение можно заранее обговорить во время доработки. Организация подгрупп меняется во время спринта, решения об изменениях принимаются в ходе ежедневных схваток.
Действия по реализации истории во время спринта, включая дизайн, выполняются в рамках временной группы. Как только история завершена, группа распадается, чтобы внутри Scrum-команды не было длительного существования подгрупп.
Не всегда легко определить, какие задачи команде нужно выполнить в рамках работы над историей. Паттерн работы облегчает коллективную организацию благодаря разбивке работы, необходимой для реализации каждой истории. Части, полученные в ходе этого разделения, называются задачами.
Задача – это работа, необходимая для реализации истории, но не несущая ценности сама по себе.
Задача описывается просто.
✓ Название и описание работы. Для обозначения задачи достаточно названия и текста, скомпанованного во время собрания и позволяющего понять, что необходимо сделать.
✓ Позднее можно к этому добавить, кто будет работать над этой задачей. Она может быть выполнена одним или несколькими участниками. Рекомендуется работа в паре (см. главу 19).
Самое важное – завершить историю. Задачи являются лишь способом достижения этой цели, без которого можно было бы и обойтись. Но большинство команд используют этот паттерн: он значительно упрощает разделение работы.
Паттерн работы побуждает команду к определению задач. Все, что связано с разработкой, происходит в ходе спринта, задачи формулируются на основе этих действий. Для каждой истории, содержащей код, задачи довольно похожи: дизайн, код GUI, код бизнес-уровня, приемочные тесты и т. д.
Критерии завершенности и список проверок не дают команде забыть о задачах.
Задачи определяются локально: если используется роение, то каждой подгруппой со своим референтом, после чего следует коллективная реституция