Том ДеМарко - Вальсируя с медведями

В работе над проектом тоже разумно пораньше понести неизбежные потери. Иначе вы теряете контроль над ситуацией, позволяя событиям распоряжаться вами как угодно (что делает это особенно тяжким). Но, столкнувшись с трудностями раньше, вы сохраняете силы, чтобы вновь вернуть контроль над ситуацией. Те части системы, которые зависят от создания технических чудес, следует втолкнуть в ранние версии. Таким образом, если чудес не получилось, у вас остаются максимальные шансы для перехода на «аварийный режим». Если это происходит достаточно рано, вам, может быть, удастся справиться с трудностями собственными силами, в то время как подобное поражение на более позднем этапе проекта коснется всех.

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

Наш коллега Том Гилб смотрит на эту ситуацию с крайних позиций: «Как будто бы я как руководитель проекта не имел бы права знать срок сдачи проекта, пока этот срок не настанет. И у меня была бы единственная, полученная заранее инструкция: „быть готовым упаковать все, что окажется готовым на любое указанное утро, чтобы поставить это клиенту к концу того же дня“. Конечно, это вынудит меня создавать множество версий (поэтому время между версиями будет достаточно мало) и убеждаться, что все самое лучшее будет уже включено в самые ранние версии».

План инкрементной поставки — это формальная взаимосвязь между частями трех других артефактов проекта:

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

• иерархическая структура работ (ИСР): сеть задач, которые должны быть выполнены, и их взаимозависимости

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

Рабочий план обычно представлен в форме иерархии модулей или классов

(Здесь мы выдумали абстрактный черновик вместо того, чтобы отдать предпочтение какому-то определенному представлению плана).

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

Процесс, вкратце, таков:

• Версия идентифицируется по рабочему плану.

• Задачи, связанные с этой версией, — это те задачи, завершение которых демонстрируется приемкой версии.

• Приемное испытание для каждой версии — это набор критериев, которым должен удовлетворять продукт, чтобы объявить, что версия завершена.

Завершенный план инкрементной поставки можно представлять как таблицу, в которой на каждую версию приходится по строке. Каждая строка будет содержать, как минимум, следующие записи:

• номер версии

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

• указатель на приемное испытание

• ожидаемая дата приемного испытания завершенной версии