366 Часть III: Управление проектами и группами

компания постоянно имеет полноценную и стабильную программу, даль­нейшее усовершенствование которой можно прекратить в любой момент, зная, что вся наиболее важная работа уже выполнена. Со временем про­грамма вырастает в надежный и полезный продукт с богатыми возможно­стями.

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

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

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

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

• Деньги. Вместо того чтобы отказаться от добавления новых функ­ций, можно реализовать их быстрее, подключив дополнительные ресурсы. Узким местом в этом случае станет проектирование про­дукта, поскольку подключить новых конструкторов гораздо сложнее, чем исполнителей.

• Дата выпуска. Главная мощь эволюционного подхода заключается в том, что он предоставляет руководству невероятные возможности контроля за графиком работ. Дата завершения проекта свободно может переноситься в ту или иную сторону в зависимости от требо­ваний момента. И нередко руководитель решает выпустить продукт вовремя, не добавляя в него оставшийся десяток функций. При этом, когда бы ни было принято решение о выпуске, сделать это можно буквально в течение нескольких недель, ведь продукт всегда стабилен.

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

Глава 13: Объединяющая 367

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

Затраты на тестирование продукта при эволюционном подходе довольно велики, поскольку оно начинается очень рано. Однако ближе к концу разработки объем тестирования гораздо меньше, чем при методе водопада, что несколько уравнивает расходы. К тому же не приходится тратить вре­мя на планирование тестов и тестирование тех функций, от реализации которых руководство откажется в случае цейтнота.

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

При выборе эволюционного подхода неопытным руководителем суще­ствует определенный риск. Руководителю может показаться, что, поскольку продукт развивается со временем, нет нужды проводить тщательное началь­ное планирование. Это огромная ошибка. Успех всей разработки зависит от гибкости ядра и продуманности основных концепций. А для достижения гибкости необходимо даже более тщательное планирование, чем при методе водопада, ведь должны быть предусмотрены все возможные способы и направления расширения продукта. Если же ядро разработано неудачно, при добавлении каждой новой функции программы его придется переде­лывать, а это сведет на нет все преимущества выбранного подхода. Кроме того, в конце разработки может оказаться, что не хватает одной из важней­ших функций, без которых продукт не будет полноценным, и придется добавлять ее, отодвигая дату выпуска.

Не всегда правильно понимают суть эволюционного метода сотрудни­ки группы маркетинга. Рекламируя продукт, они нередко анонсируют те его функции, которых в конечном варианте может не оказаться. Нет нужды говорить, что такого быть ни в коем случае не должно.