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

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

Каковы же возможности руководителя проекта, который близок к за­вершению, но не укладывается в сроки, если проект разрабатывается по методу водопада?

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

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

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

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

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

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

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

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

Эволюционный метод

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

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

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

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

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