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