Методология разработки ПО на основе водопада: иллюзия управления рисками

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

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

Предположение: Можно определить полный набор требований заранее

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

Предположение: Изначально определенные требования не изменятся

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

Предположение: Возможно выполнить оценки с высокой степенью точности

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

Предположение: Фаза разработки – это просто механический процесс преобразования архитектуры в код

Здесь разработка ПО страдает из-за попыток уподобить ее строительной отрасли. Фактически, в программировании есть много от искусства, что делает его куда менее предсказуемым, чем хотелось бы руководителям.

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