Процесс, вкратце, таков:
• Версия идентифицируется по рабочему плану.
• Задачи, связанные с этой версией, — это те задачи, завершение которых демонстрируется приемкой версии.
• Приемное испытание для каждой версии — это набор критериев, которым должен удовлетворять продукт, чтобы объявить, что версия завершена.
Завершенный план инкрементной поставки можно представлять как таблицу, в которой на каждую версию приходится по строке. Каждая строка будет содержать, как минимум, следующие записи:
• номер версии
• краткое описание включенных признаков и функций, и желательно, с ссылкой на основные компоненты требований, содержащихся в спецификации
• указатель на приемное испытание
• ожидаемая дата приемного испытания завершенной версии
• реальная дата приемного испытания завершенной версии (для заполнения позже)
• список всех работ в ИСР, которые считаются выполненными при завершении версии
• ООФ данной версии (будет рассмотрена в следующем разделе)
Нужно наложить два ограничения на план инкрементной поставки и связанные с ним артефакты: во-первых, этот метод обеспечивает возможность наложения времени при выполнении задач, связанных с различными версиями, но не предполагает такое наложение между задачей разработки самого плана (или предшествующего ему рабочего плана программного продукта) и разработкой версии. Чтобы этот подход работал, рабочий план и план инкрементной поставки должны быть завершены до того, как начнется наложение времени при выполнении задач.
Второе ограничение состоит в том, что рабочий план должен показывать
Освоенный объем — это мера запланированной стоимости работ, включенных в данное подмножество проекта (он измеряется в долларах или человеко-днях). Ваш проект называют освоившим этот объем, когда выполнены эти работы. В начале проекта вы ничего не освоили, а в конце освоено 100% всего, что отведено бюджетом. Конечно, вы можете потратить больше запланированного, тем не менее считается, что вы осваиваете именно запланированный бюджет, а не реально затраченные усилия или деньги.
Освоенный объем функционала (ООФ) — это стоимость тех работ, которые были завершены при создании текущей версии продукта. ООФ выражен в процентах от всего бюджета. Запланированные усилия для каждой задачи в ИСР также можно выразить в процентах от целого. ООФ для версии
Рассмотрим следующий простой пример: проект с 10 работами в ИСР, где есть 100 человеко-недель трудозатрат по графику и план инкрементной поставки n для пяти версий:
Проект целиком завершен, когда версия 5 проходит через приемные испытания ПИ5 (поскольку V5 — окончательная версия, то ПИ5 — приемное испытание для продукта целиком). В этой точке 100% объема освоено. ООФ, связанный с прохождением приемных испытаний отдельных версий, составляет:
ПИ1: 30%
ПИ2: 49%
ПИ3: 69%
ПИ4: 78%
ПИ5: 100%
Рисунок реального ООФ, показанною как функция от времени, выглядит так:
Значение завершенного ООФ в единицу времени дает плавную кривую для проекта. Эта плавная кривая — самый сильный из возможных показателей завершенности проекта. Отклонения этой кривой от ожидаемого вида являются безусловным признаком проявления риска и служат призывом к действиям по запуску запланированных стратегий сдерживания риска.
Инкрементный метод в процессе разработки продукта — главный источник показателей завершения, а показатели завершения — пульс проекта. Осуществляя мониторинг ООФ и отслеживание реальной производительности в терминах ООФ, вы используете показатель «голоса продукта». Сам продукт говорит вам: «Я на столько-то % готов и могу доказать это». Доказательством, конечно, служит прохождение приемного испытания версии, которая включает указанный процент освоенного объема всего проекта.
Отслеживание ООФ — основной источник обратной связи по поводу рисков от середины проекта (или даже чуть раньше) до самого конца. ООФ дает показатель «голоса продукта», причем добавляет совсем мало затрат к проекту.
Пока мы говорили только о преимуществах этого подхода, относящихся к рискам. Для справки сообщим, что есть и другие преимущества, включая:
1. больше возможностей для мотивации персонала проекта
2. большая прозрачность
3. большее привлечение пользователя в проекте с середины до конца
4. возможность отмены заключительной части проекта в силу понимания, что она в основном состоит из малополезных частей продукта
Инкрементный метод хорош для всех проектов… и является обязательным, когда риски высоки.
Глава 17
Стратегия максимального ослабления рисков
Позвольте предложить вам небольшой мысленный эксперимент. Вам понравится. Представьте, что вы работаете на территории своего клиента в Чикаго. Среда, вторая половина дня. Вы узнаете, что очень важное совещание назначено в Сан-Франциско на полдень пятницы. Обстоятельства требуют вашего присутствия там, а сложные характеры некоторых участников превращают опоздание в катастрофу. Вам просто необходимо быть там вовремя.
Вы ныряете в Интернет и обнаруживаете рейс American Airlines в 8:40 из аэропорта O'Hara, на который еще есть билеты, он прибывает в Сан-Франциско в 11:21. Прикинем: с собой только ручная кладь, в это время очереди на такси быть не должно и пробки на шоссе не такие уж страшные. Если повезет там и здесь со своевременным взлетом и посадкой, не будет никаких задержек при входе или выходе, никаких пробок и заторов на дорогах, то, возможно, вам повезет добраться до офиса в Сан-Франциско минут за