указующим размахиванием руками по поводу инкрементной поставки, но оставляет выбор подмножеств за программистами. Существуют версии, причем кумулятивные, но их формируют в отрыве от любых управленческих суждений о приоритетах. Обычно при этом нет обнародованного плана инкрементной поставки. Выбор версий делается в соответствии с удобством разработчиков: «Так, эти три штуки должны быть вместе, поэтому давайте включим их всей кучей и назовем это версией 1». Хотя есть версии и сборки, их не передают пользователю. Разработчики находят море причин хранить версии втайне, и (что более важно) версии, которые они выбирают, как правило, бесполезны для пользователей.
Все это изменяется, когда проект не укладывается в сроки. В этот момент руководство объявляет, что вместо поставки системы целиком в установленный срок, будет происходить поэтапная сдача. Результат первого этапа будет передан новым владельцам к первоначально запланированной дате сдачи, но полная система не будет закончена до четвертой, девятой или какой-то еще даты, спустя месяцы, а то и годы. Такое заявление направлено на то, что задержку будет легче пережить, если проект способен представить хотя бы что-то в первоначальный срок сдачи. Но что именно представляет собой это что-то?
Поскольку неоспоримое опоздание имеет обыкновение проявляться довольно поздно по отношению к первоначальному графику, то ясно, что выбор компонентов для первичной поставки также происходит поздно. В этот момент вопрос «Что включим в поставку на первой фазе?» выглядит несколько фальшивым, поскольку единственно возможен ответ: «При том, как близка дата поставки, первая фаза включит все, что будет к этому моменту готово».
Такой реактивный подход не имеет ни одного из тех преимуществ, на которые претендует инкрементный метод.
Проактивный подход требует очень тщательного плана, разработанного заблаговременно, где сказано, что будет представлять собой каждая версия. Выбор версий для ранних стадий поставки основан на двух критериях:
• ценность для заказчика
• подтверждение гипотез о возможных рисках
Это требует установления приоритетов компонентов системы.
Ранжирование всех функций и особенностей — лекарство от двух заболеваний проекта, первое из которых состоит в предположении, что все части продукта одинаково важны. Эта выдумка сохраняется во многих проектах, потому что обеспечивает, что никто не восстанет против участников проекта, добавивших свои любимые прибамбасы как плату за сотрудничество. Эта выдумка способствует второй болезни,
Установление приоритетов показывает ложность выдумки об одинаковой ценности. Оно облегчает инкрементный анализ выгод и затрат для оправдания раннего или позднего включения данного компонента в план.
Отметим, что ценность для участников проектов не является единственным основанием для раннего включения. Осознающий риски руководитель захочет заставить включить в ранние версии те функции продукта, с которыми связан наиболее серьезный технический риск. Это очень разумно, но у многих руководителей не лежит к этому душа, поскольку это в самом начале игры подвергает их риску выявить наиболее уязвимые точки проекта. Можно понять, почему такие руководители предпочтут утаивать эти щекотливые вопросы как можно дольше.
В работе над проектом тоже разумно пораньше понести неизбежные потери. Иначе вы теряете контроль над ситуацией, позволяя событиям распоряжаться вами как угодно (что делает это особенно тяжким). Но, столкнувшись с трудностями раньше, вы сохраняете силы, чтобы вновь вернуть контроль над ситуацией. Те части системы, которые зависят от создания технических чудес, следует втолкнуть в ранние версии. Таким образом, если чудес не получилось, у вас остаются максимальные шансы для перехода на «аварийный режим». Если это происходит достаточно рано, вам, может быть, удастся справиться с трудностями собственными силами, в то время как подобное поражение на более позднем этапе проекта коснется всех.
Есть проекты, где невозможны реальные инкрементные поставки (например, проект запуска космического корабля) или делать это неразумно. Есть мнение, что бессмысленно спорить с участниками проекта по поводу не очень впечатляющих характеристик ранних версий, потому что это может оказаться губительно для остальной части проекта. Наконец, есть проекты, где возможно осуществить поставку лишь части ранних версий. В любом из этих случаев мы настоятельно советуем относиться к частичной поставке точно так же, как если бы вы планировали сдавать конечному пользователю каждую из версий. Все равно имеет смысл распределять функции по версиям на основе ценности для пользователя и технического риска. Установление приоритетов в этой ситуации значит, что даже при прекращении вашего проекта, вы можете продемонстрировать, что к моменту прекращения ни один из подходов не обеспечил бы передачи в руки пользователя более ценных для него компонентов, чем этот.
Наш коллега Том Гилб смотрит на эту ситуацию с крайних позиций: «Как будто бы я как руководитель проекта не имел бы права знать срок сдачи проекта, пока этот срок не настанет. И у меня была бы единственная, полученная заранее инструкция: „быть готовым упаковать все, что окажется готовым на любое указанное утро, чтобы поставить это клиенту к концу того же дня“. Конечно, это вынудит меня создавать множество версий (поэтому время между версиями будет достаточно мало) и убеждаться, что все самое лучшее будет уже включено в самые ранние версии».
План инкрементной поставки — это формальная взаимосвязь между частями трех других артефактов проекта:
•
•
•
Рабочий план обычно представлен в форме иерархии модулей или классов
(Здесь мы выдумали абстрактный черновик вместо того, чтобы отдать предпочтение какому-то определенному представлению плана).
Каждая версия, которую предстоит создать, может быть изображена как подмножество рабочего плана. Поскольку каждая версия содержит все предыдущие, эти подмножества напоминают своеобразную луковицу.
