Организация и планирование проекта по методологии разработки ПО Scrum,роль Developer, страница 2

Теперь у нас достаточно данных, чтобы наполнить резерв проекта.

Backlog item (элемент резерва проекта)	Очки (Story Points)
История 1-1 (1я история для 1й компоненты)	1
История 1-2	1
История 1-3	1
История 2-1	1
История 2-2	1
История 2-3	1
История 3-1	1
История 3-2	1
История 3-3	1
Объединение 1й компоненты со 2й	2
После объявления новых требований
История 1-4	4
История 2-4	4
Включение вызовов функций, реализующих 1-4 и 2-4, в объединяющий компонент	2
Подключение 3ей компоненты к общему интерфейсу	2
Тестирование 1й компоненты	4 очка
Тестирование 2й компоненты	4 очка
Тестирование 3й компоненты	4 очка

Стоит отметить, что создание данного артефакта – не только моя обязанность; фактически, резерв проекта создается всеми участниками скрам-процесса во время планирования первого спринта.

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

№ спринта	Задачи 1го разработчика	Задачи 2го разработчика	Задачи 3его разработчика
1	Истории 1-1, 1-2, 1-3. 3 очка	Истории 1-2, 1-3, 1-4. 3 очка	Объединение 1й и 2й компоненты. 2 очка
2	История 1-4. 4 очка	История 2-4. 4 очка	Дополнение объединяющей компоненты. 2 очка
3	Исправление возможных недочетов по 1й компоненте; История 3-1. 1-3 очка	Исправление возможных недочетов по 2й компоненте; История 3-1. 1-3 очка	Изучение результатов демонстрации и итогов работы коллег за время своего отсутствия 0 очков
4	Тестирование 1й компоненты 4 очка	Тестирование 2й компоненты 4 очка	История 3-3. Тестирование 3й компоненты. 5 очков
5	Исправление возможных недочетов по 1й компоненте 0-1 очко	Исправление возможных недочетов по 2й компоненте 0-1 очко	Исправление возможных недочетов по 3й компоненте 0-1 очко
Итого:	12-15 очков	12-15 очков	9-10 очков

Анализ моделирования спринтов

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

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

Мои обязанности и артефакты

Моими основными обязанностями являются разработка и тестирование 1й компоненты проекта. Также я должен готовить артефакт, называющийся «диаграмма сгорания задач (Burndown chart)».

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

Существуют разные виды диаграммы:

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

диаграмма сгорания работ для выпуска проекта — показывает, сколько уже задач сделано и сколько ещё остаётся сделать до выпуска продукта (обычно строится на базе нескольких спринтов).

Wikipedia.

Диаграмма сгорания – основное средство Scrum Master для контроля процесса разработки. Фактически, эта диаграмма и очки историй, на основании которых она строится, являются основными метриками для анализа Scrum-процесса.

Пример burndown chart по итогам окончания проекта.

Пример sprint backlog

Резерв спринта (sprint backlog) — содержит функциональность, выбранную владельцем проекта из резерва проекта. Все функции разбиты по задачам, каждая из которых оценивается скрам-командой. Каждый день команда оценивает объем работы, который нужно проделать для завершения спринта.

Wikipedia.

Характеристика	Состояние
Номер спринта	1
День	3
Выполненные задачи	История 1-1
Заработанные очки	1
Задачи к выполнению	История 1-2, История 1-3
Осталось заработать очков	2

Эта таблица должна обновляться каждый день и быть доступна всем участникам scrum-процесса.

Предложения по улучшению работы

·  Заказчик может участвовать в обсуждении во время планирования спринта посредством Skype-конференций. Это обеспечивает заказчика оперативной информацией о ходе разработки, и, естественно, избавляет от необходимости присутствовать лично;

·  Разработчики могут «меняться» разрабатываемыми компонентами: к примеру, 1й разработчик реализует 1ю компоненту, а тестирует 2ю. У этого подхода есть как положительные, так и отрицательные стороны: с одной стороны, разработчик начинает лучше понимать проект в целом, а также может найти те ошибки, которые не заметил первоначальный разработчик. С другой стороны, на вникание в «чужую» компоненту требуется дополнительное время.