План инкрементной поставки – это формальная взаимосвязь между частями трех других артефактов проекта:
•
•
•
Рабочий план обычно представлен в форме иерархии модулей или классов
(Здесь мы выдумали абстрактный черновик вместо того, чтобы отдать предпочтение какому-то определенному представлению плана).
Каждая версия, которую предстоит создать, может быть изображена как подмножество рабочего плана. Поскольку каждая версия содержит все предыдущие, эти подмножества напоминают своеобразную луковицу.
Процесс, вкратце, таков:
• Версия идентифицируется по рабочему плану.
• Задачи, связанные с этой версией, – это те задачи, завершение которых демонстрируется приемкой версии.
• Приемное испытание для каждой версии – это набор критериев, которым должен удовлетворять продукт, чтобы объявить, что версия завершена.
Завершенный план инкрементной поставки можно представлять как таблицу, в которой на каждую версию приходится по строке. Каждая строка будет содержать, как минимум, следующие записи:
• номер версии
• краткое описание включенных признаков и функций, и желательно, с ссылкой на основные компоненты требований, содержащихся в спецификации
• указатель на приемное испытание
• ожидаемая дата приемного испытания завершенной версии
• реальная дата приемного испытания завершенной версии (для заполнения позже)
• список всех работ в ИСР, которые считаются выполненными при завершении версии
• ООФ данной версии (будет рассмотрена в следующем разделе)
Нужно наложить два ограничения на план инкрементной поставки и связанные с ним артефакты: во-первых, этот метод обеспечивает возможность наложения времени при выполнении задач, связанных с различными версиями, но не предполагает такое наложение между задачей разработки самого плана (или предшествующего ему рабочего плана программного продукта) и разработкой версии. Чтобы этот подход работал, рабочий план и план инкрементной поставки должны быть завершены до того, как начнется наложение времени при выполнении задач.
Второе ограничение состоит в том, что рабочий план должен показывать
Освоенный объем – это мера запланированной стоимости работ, включенных в данное подмножество проекта (он измеряется в долларах или человеко-днях). Ваш проект называют освоившим этот объем, когда выполнены эти работы. В начале проекта вы ничего не освоили, а в конце освоено 100% всего, что отведено бюджетом. Конечно, вы можете потратить больше запланированного, тем не менее считается, что вы осваиваете именно запланированный бюджет, а не реально затраченные усилия или деньги.
Освоенный объем функционала (ООФ) – это стоимость тех работ, которые были завершены при создании текущей версии продукта. ООФ выражен в процентах от всего бюджета. Запланированные усилия для каждой задачи в ИСР также можно выразить в процентах от целого. ООФ для версии
Рассмотрим следующий простой пример: проект с 10 работами в ИСР, где есть 100 человеко-недель трудозатрат по графику и план инкрементной поставки n для пяти версий:
Проект целиком завершен, когда версия 5 проходит через приемные испытания ПИ5 (поскольку V5 – окончательная версия, то ПИ5 – приемное испытание для продукта целиком). В этой точке 100% объема освоено. ООФ, связанный с прохождением приемных испытаний отдельных версий, составляет:
ПИ1: 30%
ПИ2: 49%
ПИ3: 69%
ПИ4: 78%
ПИ5: 100%
Рисунок реального ООФ, показанною как функция от времени, выглядит так:
Значение завершенного ООФ в единицу времени дает плавную кривую для проекта. Эта плавная кривая – самый сильный из возможных показателей завершенности проекта. Отклонения этой кривой от ожидаемого вида являются безусловным признаком проявления риска и служат призывом к действиям по запуску запланированных стратегий сдерживания риска.