Тема 3. Жизненный цикл Sprint

Практические занятия

Тема 1. Знакомство с методологией Scrum

Целямиданного занятия является следующее.

  1. Разделить студентов на команды, определить и обсудить роли.
  2. Провести начальное знакомство с модельной задачей, которую предстоит реализовать.

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

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

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

 

Введение

одна из самых популярных методологий гибкой разработки. Одна из причин ее популярности - простота.

В методологии всего три роли.

  • Master
  • Product Owner
  • Team

Рис. 1 – Концепция Scrum

Скрам Мастер (Scrum Master)

Скрам Мастер (Scrum Master) - самая важная роль в методологии. Скрам Мастер отвечает за успех Scrum в проекте. По сути, Скрам Мастер является интерфейсом между менеджментом и командой. Как правило, эту роль в проекте играет менеджер проекта или Team Leader. Важно подчеркнуть, что Скрам Мастер не раздает задачи членам команды.

Основные обязанности Скрам Мастера таковы:

  • Создает атмосферу доверия
  • Участвует в митингах в качестве фасилитатора
  • Устраняет препятствия
  • Делает проблемы и открытые вопросы видимыми
  • Отвечает за соблюдение практик и процесса в команде

Скрам Мастер ведет Daily Scrum Meeting и отслеживает прогресс команды при помощи Sprint Backlog, отмечая статус всех задач в спринте (тема 3).

Sprint Backlog

Sprint Backlog содержит функциональность, выбранную Product Owner из Product Backlog. Все функции разбиты по задачам, каждая из которых оценивается командой. Каждый день команда оценивает объем работы, который нужно проделать для завершения задач.

ScrumMaster может также помогать Product Owner создавать Backlog для команды

Product Owner

Product Owner - это человек, отвечающий за разработку продукта. Как правило, это product manager для продуктовой разработки, менеджер проекта для внутренней разработки и представитель заказчика для заказной разработки. Product Owner - это единая точка принятия окончательных решений для команды в проекте, именно поэтому это всегда один человек, а не группа или комитет.

Обязанности Product Owner таковы:

  • Отвечает за формирование product vision
  • Управляет ожиданиями заказчиков и всех заинтересованных лиц
  • Координирует и приоритизирует Product backlog
  • Предоставляет понятные и тестируемые требования команде
  • Взаимодействует с командой и заказчиком
  • Отвечает за приемку кода в конце каждой итерации

Product Owner ставит задачи команде, но он не вправе ставить задачи конкретному члену проектной команды в течении спринта.

Команда (Team)

В методологии Scrum команда является самоорганизующейся и самоуправляемой. Команда берет на себя обязательства по выполнению объема работ на спринт перед Product Owner. Работа команды оценивается как работа единой группы. В Scrum вклад отдельных членов проектной команды не оценивается, так как это разваливает самоорганизацию команды.

Обязанности команды таковы:

  • Отвечает за оценку элементов backlog
  • Принимает решение по дизайну и имплементации
  • Разрабатывает софт и предоставляет его заказчику
  • Отслеживает собственный прогресс (вместе со Скрам Мастером).
  • Отвечает за результат перед Product Owner

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

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

Для облегчения коммуникаций команда должна находиться в одном месте (colocated). Предпочтительно размещать команду не в кубиках, а в одной общей комнате для того, чтобы уменьшить препятствия для свободного общения. Команде необходимо предоставить все необходимое для комфортной работы, обеспечить досками и флипчартами, предоставить все необходимые инструменты и среду для работы.

Тема 2. Создание проекта

Целямиданного занятия является следующее.

  1. Прояснить открытые вопросы по модельной задаче с Produсt Owner.
  2. Создать командный проект на TFS и добавить в него пользователей (при условии установки ПО).
  3. Составление Product Backlog.

Команды в течение 20-30 минут обсуждают задачу в рамках команды, готовя вопросы относительно реализуемого продукта. Затем, в течение 5-10 минут преподаватель отвечает на подготовленные командами вопросы.

Результатом является создание Product Backlog и определение суммы оценок оставшейся работы с помощью Sprint Burndown chart.

Product Backlog

Product Backlog - это приоритезированный список имеющихся на данный момент бизнес-требований и технических требований к системе.

Product Backlog включает в себя use cases, defects, technologies, stories, features, issues, и т.д. Product backlog также включает задачи, важные для команды, например "провести тренинг", "добить всем времени".

Рис. 2. Пример Product Backlog

Product Backlog постоянно пересматривается и дополняется - в него включаются новые требования, удаляются ненужные, пересматриваются приоритеты. За Product Backlog отвечает Product Owner. Он также работает совместно с командой для того, чтобы получить приближенную оценку на выполнение элементов Product Backlog для того, чтобы более точно расставлять приоритеты в соответствии с необходимым временем на выполнение.

Сумма оценок оставшейся работы может быть построена как график зависимости от времени. Такой график называется Sprint Burndown chart. Он демонстрирует прогресс команды по ходу спринта.

Рис. 3. Sprint Burndown chart

 

 

Тема 3. Жизненный цикл Sprint

 

Целямиданного занятия является следующее.

1. Реализация первичной функциональности.

2. Первичное представление заказчику Scope (границ задачи).

 

Результатом является составление Sprint Backlog и оценка времени.

 

В Scrum итерация называется Sprint. Ее длительность составляет 1 месяц (30 дней). Результатом Sprint является готовый продукт (build), который можно передавать (deliver) заказчику (по крайней мере, система должна быть готова к показу заказчику).

Короткие спринты обеспечивают быстрый feedback проектной команде от заказчика. Заказчик получает возможность гибко управлять scope системы, оценивая результат спринта и предлагая улучшения к созданной функциональности. Такие улучшения попадают в Product Backlog, приоритезируются наравне с прочими требованиями и могут быть запланированы на следующий (или на один из следующих) спринтов.

Каждый спринт представляет собой маленький "водопад". В течение спринта делаются все работы по сбору требований, дизайну, кодированию и тестированию продукта. Scope спринта должен быть фиксированным. Это позволяет команде давать обязательства на тот объем работ, который должен быть сделан в спринте. Это означает, что Sprint Backlog не может быть изменен никем, кроме команды.

Жизненный цикл спринта

Планирование спринта

В начале каждого спринта проводится планирование спринта. В планировании спринта участвуют заказчики, пользователи, менеджмент, Product Owner, Скрам Мастер и команда.

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

Планирование спринта, митинг первый

Участники: команда, Product Owner, Scrum Master, пользователи, менеджемент

Цель: Определить цель спринта (Sprint Goal) и Sprint Backlog - функциональность, которая будет разработана в течение следующего спринта для достижения цели спринта.

 

Рис. 4 - Sprint Backlog

Планирование спринта, митинг второй

Участники: Скрам Мастер, команда

Цель: определить, как именно будет разрабатываться определенная функциональность для того, чтобы достичь цели спринта. Для каждого элемента Sprint Backlog определяется список задач и оценивается их продолжительность.

Результат: в Sprint Backlog появляются задачи.

Если в ходе спринта выясняется, что команда не может успеть сделать запланированное на спринт, то Скрам Мастер, Product Owner и команда встречаются и выясняют, как можно сократить scope работ и при этом достичь цели спринта.