Роберт Мартин - Чистый Agile. Основы гибкости

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

И тогда случается новое чудо. Первого сентября мы внезапно завершаем проектирование. А почему так? Да потому что. Первое сентября. По графику работ мы должны были уже закончить. Незачем медлить.

Итак, еще одна вечеринка. Воздушные шары и речи. И мы прорываемся к следующему этапу — реализации.

Было бы замечательно провернуть такую схему еще разок. Эх, если бы точно так же можно было бы завершить этап реализации! Но так уже не выйдет. Потому что по завершении реализации требуется завершить и весь проект. Анализ и проектирование не приносят плодов в двоичном виде . У них нет однозначных критериев завершенности.

Нет объективного способа узнать, проведены ли они в реальности. Поэтому и получилось завершить эти этапы вовремя.

Этап реализации

А вот у реализации как раз есть отчетливые критерии завершенности. Тут уже не получится аккуратно схалтурить, выдав мнимый результат за действительный [23] Однако разработчики сайта healthcare.gov определенно пытались. .

На этапе реализации полностью отсутствует двусмысленность задач. Мы просто пишем код. И нам приходится писать код второпях, высунув язык, потому что четыре месяца просто выкинули на ветер.

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

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

Примерно 15 октября кто-то говорит: «Эй, а какое сегодня число? Когда сдавать?» И тут мы понимаем, что осталось всего две недели и к первому ноября мы ни за что не закончим. И вдруг впервые наши заказчики узнают, что с проектом возникают какие-то неувязочки.

Представьте их негодование. «А на этапе анализа нельзя было об этом сказать? Разве не тогда вы должны были оценить размер проекта и внимательно рассчитать график работ? А на этапе проектирования почему не сказали? Разве не тогда нужно было разбить проект на модули, распределить работу по всей команде и рассчитать человеческий ресурс? Почему мы узнаем обо всем за две недели до дедлайна?»

И ведь они правы, разве нет?

Марафон на выживание

И начинается марафон на выживание. Клиенты злятся. Заинтересованные стороны дошли до белого каления. Давление нарастает. Работаем сверхурочно. Кто-то уходит с проекта. Просто ад!

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

Я называю это раздуванием вышедшего из-под контроля процесса . Мы собираемся в следующий раз еще лучше работать по методу, который не работает.

Преувеличение?

Очевидно, что история утрирована. В ней собрано воедино все отрицательное, что вообще может быть во время работы над проектом по разработке программ. Большинство проектов, где применялась каскадная модель, не терпели такого краха. Действительно, по счастливой случайности некоторые проекты удавалось завершить даже относительно успешно. С другой стороны, на подобной встрече я бывал не раз, мне доводилось работать не над одним таким проектом, и такое случалось не только со мной. История гиперболизированная, но такое все равно бывает.

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