5.6.1. Подготовка проекта

Перед запуском проекта необходимо выполнить следующие задачи:

• установить экономическое обоснование;

• собрать команду;

• настроить инфраструктуру команды.

Чтобы установить экономическое обоснование, необходимо выявить бизнес-потребности и обосновать их, определить концепцию проекта и получить финансирование.В книге Джеффри Мура (Geoffrey Moore) "Crossing the Chasm" представлено неплохое руководство по созданию концепций.Дополнительные сведения см. на следующем веб-ресурсе: Crossing the Chasm.

После установления экономического обоснования необходимо собрать команду и определить координатора Scrum и владельца продукта.Дополнительные сведения см. в разделе Роли.

И наконец, созданная команда должна настроить свою инфраструктуру.Например, необходимо установить сервер Visual Studio Team Foundation Server и систему Visual Studio Application Lifecycle Management (ALM), создать и, возможно, настроить командный проект и определить рекомендации по проектированию.Дополнительные сведения см. в разделах Начало работы с Visual Studio Application Lifecycle Management, Настройка командного проекта и Рекомендации по проектированию.

5.6.2. Планирование проекта

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

Построение списка невыполненных работ по продукту

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

	Создание описаний функциональности пользователей. В своей книге "User Stories Applied" Майк Кон (Mike Cohn) определяет описания функциональности пользователей следующим образом: "Описание функциональности пользователя определяет функции, которые будут полезны для пользователя или покупателя системы или программного обеспечения". Иными словами, описания функциональности пользователей создаются с точки зрения конечного пользователя.Примеры. "Мне, как постоянному клиенту, требуются блюда, которые я заказывал раньше". Дополнительные сведения см. в разделе Создание удобного описания требований пользователей к продукту.
	Определение приоритетов описаний функциональности пользователей. Приоритеты описаний функциональности пользователей определяются владельцем продукта в списке невыполненных работ по продукту. При этом владелец согласует с заказчиками цели и задачи проекта и вместе с командой выполняет анализ рисков и зависимостей.Владелец продукта указывает приоритеты путем назначения описаниям функциональности определенных рангов, определяющих порядок, в котором команда должна реализовывать описания. Для анализа и сравнения ценности описаний функциональности пользователей владелец продукта может использовать целый ряд методов.Если команда уже использует хорошо зарекомендовавший себя метод определения приоритетов, менять его не следует. Некоторые методы определения приоритетов тесно связаны с концепцией гибкого сообщества, например с моделью Кано удовлетворенности клиентов и принципом относительных весов Карла Вигерса (Karl Wiegers).(Дополнительные сведения об относительных весах см. в статье по адресу: First Things First: Prioritizing Requirements.) Другие методы определения приоритетов, такие как определение приоритетов затрат, чистая приведенная стоимость, расчетный период окупаемости и коэффициент окупаемости, широко применяются за пределами гибкого сообщества.Эти методы также вполне эффективны, и их можно использовать для определения приоритетов в списке невыполненных работ по продукту проекта Scrum.Дополнительные сведения см. в разделе "Part II: Estimating Size" книги на следующем веб-ресурсе: Agile Estimation and Planning.
	Оценка описаний функциональности пользователей. Каждое описание функциональности пользователя совместно оценивается участниками команды в баллах описаний функциональности.В своей книге "Agile Estimation and Planning" Майк Кон (Mike Cohn) определяет баллы описания функциональности следующим образом: "Баллы описания функциональности — это единицы измерения для выражения общего размера описания функциональности, компонента или другого элемента работы". Баллы описания функциональности представляют собой относительные значения, которые невозможно сразу перевести в определенное количество часов.Баллы описаний лишь помогают команде определить общий размер описания функциональности пользователя.Эти относительные оценки являются менее точными, поэтому для их определения требуется меньше усилий. Со временем оценки будут уточняться.Благодаря определению баллов описаний функциональности команда получает общий размер описаний функциональности пользователей на начальном этапе и в дальнейшем, когда участники команды приступают к реализации описаний, разрабатывает более детальную оценку трудозатрат.

Определение производительности команды

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

Если команда уже измерила свою скорость работы, собрав данные о числе описаний функциональности пользователей, реализованных командой за определенный период времени, можно использовать эти данные.Он предоставляет наиболее точную оценку производительности команды.Если такие данные отсутствуют, но команда начала выполнение проекта с помощью системы Visual Studio ALM и платформы MSF для гибкой разработки программного обеспечения версии 5.0, эти показатели будут собраны в ходе проекта.Дополнительные сведения см. в разделе Отчет "Состояние всех итераций" (гибкая разработка).

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

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

Создание плана выпуска

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

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

• Определение спринтов, на которых ожидается завершение реализации этих групп пользовательских описаний функциональности.

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

Дополнительные сведения см. в разделе Книга "Планирование продукта".

Подготовка к первому спринту

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

• Разбиение пользовательского описания функциональности на более мелкие описания функциональности.

• Предоставление подробных сведений о пользовательских описаниях функциональности, которые потребуются команде для разбиения описаний функциональности на задачи.

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

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

• "Могут ли критерии поиска задаваться в свободной форме или необходимо выбирать из списка доступных типов?"

• "Если блюда, соответствующие критерию поиска, можно получить у нескольких поставщиков, как должны сортироваться результаты?"

Дополнительные сведения см. в подразделе Подготовка к следующему спринту.