Этапы и мероприятия Scrum

7.1. Sprint

В Scrum итерация работы команды называется "спринт" (sprint). Ее длительность определяется конкретными условиями и требованиями к процессам разработки программного обеспечения и создаваемому продукту. Оптимальной длительностью спринта считается интервал 2 недели, максимально возможной - 6 недель. Не рекомендуется делать его более полутора месяцев, иначе могут возникнуть проблемы с создаваемым инкрементом.

увеличить изображение
Рис. 7.1. Диаграмма спринта

Результатом спринта является инкремент готового продукта (build), который можно передать заказчику для установки на продуктивный информационный ландшафт. Именно в реализации готового инкремента в короткие сроки и с минимальными трудозатратами, который заказчик может использовать и получать от этого определенную бизнес-ценность, заключается вся прелесть и уникальность Scrum в сравнении с альтернативными видами разработки программного обеспечения.

За счет коротких спринтов обеспечивается оперативный ответ Scrum-команде от заказчика. При этом заказчик получает возможность гибко управлять объемами работ и направлять разработку в нужном для себя направлении, оперативно оценивая результат спринта и предлагая улучшения создаваемого продукта.

Улучшения должны фиксироваться и попадать в бэклог продукта. После этого они оцениваются в соответствии с существующими бизнес-приоритетами во всем объеме существующих задач. В следующий спринт попадают задачи, которые имеют самый высокий приоритет.

Каждый спринт представляет собой маленький "водопад". На протяжении спринта делаются все работы по сбору требований, разработке и тестированию инкремента продукта. Объем работ, включенных в спринт (бэклог спринта), должен быть фиксированным. Это позволяет команде давать обязательства на тот объем работ, который должен быть сделан в спринте. Это означает, что бэклог спринта не может быть изменен никем, кроме команды.

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

1. Сначала выполняется комплексное планирование спринта в два этапа.

   В начале каждого спринта проводится его планирование. В этом мероприятии участвуют владелец продукта, ключевые пользователи, Scrum-мастер и команда разработки.

   Планирование спринта состоит из двух последовательных митингов:

   а)

   Первый митинг. Определение целей спринта. Участники: команда, владелец продукта, Scrum-мастер. Цель этой встречи - определить цель спринта и наполнить его бэклог.

   б)

   Второй митинг. Определение способа реализации задач, взятых в бэклог спринта. Участники: команда, Scrum-мастер. Цель этого митинга - определить, как именно будет разрабатываться функциональность для того, чтобы достичь цели спринта и синхронизировать понимание всех разработчиков о том, что именно будет сделано. Именно на этой встрече применяется техника Planning Poker для оценки трудоемкости и продолжительности задач. Если в ходе реализации задач выясняется, что члены команды могут не успеть сделать запланированное, отслеживаемое по диаграмме сгорания задач, то Scrum-мастер, владелец продукта и команда встречаются и выясняют, как можно сократить работы и при этом достичь поставленной цели спринта.

2. Разработка инкремента спринта.

   Активные участники: команда. Пассивные участники: Scrum-мастер, владелец продукта. Цель - разработка продукта силами команды. Это основной процесс, в рамках которого команда занимает активную позицию, от которой будет зависеть результат их деятельности. Scrum-мастер и владелец продукта готовы помогать и отвечать на вопросы при необходимости.

3. Остановка спринта.

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

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

В период проведения спринта каждый день необходимо проводить короткую встречу, называемую "дэйли", для того чтобы все члены команды понимали, кто и чем занимается в данное конкретное время. Продолжительность дэйли - максимум 15 минут. Его проведение предназначено для решения явных и потенциальных проблем. Ведущим этого митинга является Scrum-мастер, который по кругу задает каждому члену команды три вопроса:

• Что сделано c момента предыдущего дэйли?
• Что планируется делать сегодня?
• С какими проблемами вы столкнулись?

Все остальные вопросы и обсуждения должны быть вынесены за пределы митинга и обсуждаться между заинтересованными в его решении лицами.

Если команда достигла достаточного уровня самоорганизации, то участие в этом митинге Scrum-мастера не требуется.

После того как спринт достиг своего завершения, необходимо проводить демонстрацию реализованного функционала и последующий анализ спринта. Активность демонстрации называется "Обзор Спринта" (Sprint review), а анализ спринта - "ревью" или "Ретроспектива Спринта" (Sprint Retrospective).

В назначенное время на Обзор Спринта приходят команда, владелец продукта, ключевые пользователи. В процессе этой активности члены команда рассказывают о поставленных задачах, о том, как они были решены, какие препятствия возникали у них на пути, какие были приняты решения, какие проблемы остались нерешенными, и демонстрируют реализованный функционал, а владелец продукта и пользователи оценивают достигнутый результат.

На Ретроспективе Спринта команда и Scrum-мастер обсуждают ход выполнения процесса, отмечают его достоинства и недостатки, принимают решения о возможной корректировке процесса в целях его улучшения. Scrum-мастер является непосредственным организатором этих мероприятий и отвечает за общую подготовку к нему. Команда помогает ему составить адженду и запланировать расписание выступления. Подготовка к митингу не должна занимать у команды много времени (правило - не более двух часов). Для проведения демонстрации запрещено использовать инструменты типа Power Point. Функционал должен демонстрироваться непосредственно в рабочем программном продукте. Подготовка к митингу также не должна занимать у команды более 2 часов. В следующих главах мы продолжим обсуждение, связанное с рассмотрение отдельных этапов и мероприятий, более подробно. Здесь же необходимо акцентировать внимание на таком важном понятии процессов гибкой разработки программного обеспечения, как цель спринта.

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

Если какая-то история не сделана - вечный позор разработчикам, которые отвечали за нее, полный провал спринта, катастрофа вселенского масштаба и непрекращающаяся скорбь, инициированные заказчиками работ.

В ответ на это появляется экстремистская реакция самой Scrum-команды. Есть мнение, что в объем спринта нельзя вносить изменения после того, как спринт начался, а это, соответственно, ограничивает заказчика. Но если убрать рамки спринта по времени и объему задач, то мы "скатываемся" к классической, водопадной модели разработки информационных систем.

И первая, и вторая ситуации - это совсем не "гибко". Истина, как это часто бывает в 100% ситуаций, где-то посередине. Для достижения этой середины в Scrum появилось понятие - цель спринта. Это командная установка, определяющая, зачем мы собираемся потратить время и ресурсы спринта, чего хотим достичь с точки зрения инкремента ценности для заказчика. И это не просто набор разрозненных требований. Цель позволяет и предписывает нам быть более гибкими и толерантными, как к небольшому изменению объема спринта, так и к неожиданным причинам, не позволившим нам реализовать то или иное требование в спринте. Успешный спринт - спринт, достигший своей цели. Если мы реализовали ожидания заказчика, пришедшего на демо, то это успех.

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