Тема 2. Создание проекта
Целями данного занятия является следующее.
Прояснить открытые вопросы по модельной задаче с Produсt Owner.
Создать командный проект на TFS и добавить в него пользователей (при условии установки ПО).
Составление 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
Целями данного занятия является следующее.
Реализация первичной функциональности.
Первичное представление заказчику Scope (границ задачи).
Результатом является составление Sprint Backlog и оценка времени.
В Scrum итерация называется Sprint. Ее длительность составляет 1 месяц (30 дней). Результатом Sprint является готовый продукт (build), который можно передавать (deliver) заказчику (по крайней мере, система должна быть готова к показу заказчику).
Короткие спринты обеспечивают быстрый feedback проектной команде от заказчика. Заказчик получает возможность гибко управлять scope системы, оценивая результат спринта и предлагая улучшения к созданной функциональности. Такие улучшения попадают в Product Backlog, приоритезируются наравне с прочими требованиями и могут быть запланированы на следующий (или на один из следующих) спринтов.
Каждый спринт представляет собой маленький "водопад". В течение спринта делаются все работы по сбору требований, дизайну, кодированию и тестированию продукта. Scope спринта должен быть фиксированным. Это позволяет команде давать обязательства на тот объем работ, который должен быть сделан в спринте. Это означает, что Sprint Backlog не может быть изменен никем, кроме команды.
Жизненный цикл спринта
Планирование спринта
В начале каждого спринта проводится планирование спринта. В планировании спринта участвуют заказчики, пользователи, менеджмент, Product Owner, Скрам Мастер и команда.
Планирование спринта состоит из двух последовательных митингов.