Планирование проекта на основе требований, путь RUP
RUP поддерживает двухуровневую схему планирования работ над проектом, разделяя план проекта и план итерации. Исходя из базовой концепции планирования итерационных проектов, план проекта разбивается на фазы:
- Начало,
- Уточнение,
- Конструирование,
- Переход.
Исходя из рекомендаций методологии по декомпозиции работ проекта в зависимости от степени сложности проекта и квалификации команды, в каждой фазе выделяется одна или более итераций.
Назначаются даты главных вех (окончания фаз):
- целей жизненного цикла (конец фазы начала, рамки проекта и его бюджет);
- архитектуры жизненного цикла (конец фазы уточнения, законченная архитектура);
- начальной работоспособности (конец фазы конструирования, бета-версия продукта);
- выпуска изделия (конец фазы перехода и полного цикла разработки).
Назначаются даты малых вех, приуроченные к окончанию итераций и их главные цели. Основные цели итераций - выпуск релизов, демонстрируемых, либо передаваемых Заказчику, однако не всякая итерация приводит к выпуску релиза.
План проекта создается как можно раньше в начальной фазе и модифицируется по мере необходимости.
Что это означает на практике:
- укрупненный план работ составляется "как можно раньше", например - через месяц после начала работ;
- бюджет появляется лишь к окончанию первой фазы (а она, в зависимости от сложности проекта может длиться месяц, а может и полгода);
- как план, так и бюджет проекта представляют собой лишь прогноз, который может корректироваться на протяжении работ над проектом;
- на момент появления плана и бюджета должно появиться подробное описание лишь 20% ключевой функциональности системы и "широкое, но неглубокое" [15.2] описание 80% функциональности.
Таким образом, концепция укрупненного планирования в RUP, как типичном представителе класса прогнозирующих методологий, предполагает базировать отношения между Заказчиком и Разработчиком на прогнозах, степень достоверности которых зависит от таких факторов, как качество проработки требований, квалификация команды Разработчика, сложность и новизна проекта.
Более конкретная информация представлена в плане итерации. Основные его особенности:
- План итерации базируется на функциональных требованиях. К моменту начала итерации совершенно точно известно, какие требования должны быть обработаны (детализированы, спроектированы, запрограммированы) в данной итерации.
План итерации составляется, исходя из сформулированных выше оценок требований - приоритетности, степени риска, трудоемкости.
- План итерации имеет жесткие сроки. В случае проявления незапланированных рисков удовлетворительным вариантом является достижение договоренности о реализации требований данной итерации не в полном объеме, либо переносе требований в следующую итерацию; переносить сроки текущей итерации не рекомендуется;
- Точный план составляется на одну, очередную итерацию. К моменту окончания текущей итерации должен быть сверстан план очередной итерации. Такой подход позволяет более гибко работать с рисками.
Таким образом, следует отметить, что требования являются решающим фактором в планировании итерационного проекта.