greesha

Кто не знает, что такое каскадная модель разработки (aka водопад, он же waterfall)? Википедия учит: «модель водопада подразумевает, что переход от одной фазы разработки к другой происходит только после полного и успешного завершения предыдущей фазы, и что переходов назад либо вперёд или перекрытия фаз — не происходит».

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

Ну а стараниями Agile-евангелистов слово «водопад» в айтишной среде сейчас окончательно превратилось в ругательство. («Вы всё ещё используете водопад? Тогда мы идем к вам!»)

У меня есть некоторый опыт участия в проектах, разрабатываемых «по водопаду», и мне есть что сказать в его защиту. Но не в этот раз. Пока попробуем разобраться с первоисточниками. 


В большинстве книг при описании этой модели принято ссылаться на статью Уинстона Ройса, опубликованную в 1970 году. Спасибо интернетам вообще и Википедии в частности, теперь каждый может прочитать её в оригинале. Чем я и занялся, как только обнаружил эту ссылку.


Первое и самое главное. Статья называется «Управление разработкой больших программных систем». Или, в оригинале: Managing the Development of Large Software Systems. (Прошу прощения, я больше не буду захламлять текст повторением одного и того же на двух языках. Те, кто не доверяет моему переводу, могут самостоятельно свериться с оригиналом и при желании выразить своё возмущение в комментариях. Тем, кто доверяет, я всё равно рекомендую прочитать всю статью: это ведь уже классика из разряда must read!)

Для тех, кто пропустил ключевое слово, автор повторяет его в первой же фразе: «Я собираюсь поделиться своей точкой зрения на управление большими программными проектами». Чем сразу очерчивает границу применимости дальнейших рассуждений.

Можно, конечно, сразу задать вопрос: какие проекты считались большими сорок лет назад, и можно ли их считать таковыми сейчас? Моё мнение: за сорок лет мало что изменилось. Большие проекты — это такие проекты, на разных этапах которых задействованы разные, часто слабо связанные между собой организации (определение моё, на строгость не претендует).

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

Собственно, здесь и появляется хорошо знакомая всем картинка, благодаря которой и возникло название «каскадной» модели:

И что же, статья на этом заканчивается? Да нет, конечно, это только начало! Если быть точным, третий абзац, первая страница из десяти. Но именно здесь останавливаются теоретики не существующего в природе абстрактного, «чистого водопада».

Уже в следующем, четвёртом абзаце, появляется слово «итеративный». Каждый очередной шаг начинается не «после полного и успешного завершения» предыдущего, как гласит определение каскадной модели, а выполняются постоянные возвраты на предыдущий шаг. В процессе анализа уточняются требования, при кодировании уточняется архитектура и т. п. Здесь Ройс даже не «критикует недостатки» водопада, а просто описывает реальное положение дел с точки зрения практика. Критика начинается только с этой, уточнённой, и уже по сути итеративной модели:



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

Я думаю, на это есть несколько причин. И первая состоит в том, что водопадная модель очень изящна. Она проста, логична, доступна для понимания и неплохо согласуется с практикой (при значительном упрощении, конечно). Она в чистой, незамутнённой форме доводит главную идею: разработка ПО — это не только программирование!

Эта модель представляет прекрасную отправную точку для изучения реальных (как, впрочем, и абстрактных) моделей, чем и пользуются авторы учебников. «Кирпичики» водопадной модели в том или ином виде присутствуют в любой другой модели разработки (да-да, и в Agile тоже, кто со мной не согласен — вызываю на бой в комментариях!)

Другую причину нужно искать в стандартах, на долгое время зафиксировавших водопадную модель в качестве официально принятого способа разработки больших автоматизированных систем. Я не знаком со стандартами НАТО, которые часто упоминаются при описании этой модели, но, например, наш ГОСТ 34 тоже фактически описывает каскадную модель, хоть и с некоторыми оговорками.

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


Но вернёмся к статье. Главным недостатком описанного подхода Ройс считает (ждёте сюрприза? здесь его нет!) трудности с прогнозированием конечного результата на ранних стадиях проекта. Ну, по крайней мере, я его так понял. И предлагает пять шагов для преодоления основных рисков, порождаемых этим недостатком. Из этих пяти шагов я бы сейчас обратил особое внимание на третий и пятый.

Шаг 3: выполните работу дважды. «Сделайте так, чтобы финальная версия, переданная для использованию клиенту, была в действительности второй версией». Фактически здесь Ройс предлагает полноценный итеративный процесс, состоящий из двух итераций, охватывающих все шаги от конструирования до эксплуатации.

Это, конечно, ещё не короткие и частые итерации Agile, но следует помнить, что статья написана в 1970 году, когда машинное время продавалось поминутно, а естественным способом ввода программ в память ЭВМ считались перфокарты. Короткие итерации тогда были просто технологически невозможны.

Шаг 5: вовлекайте заказчика. «Важно привлекать заказчика к участию в проекте, так чтобы он принимал определённые обязательства на ранних стадиях проекта, до выпуска финальной версии.»

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


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

Мой ответ: да, и лично меня это ничуть не удивляет.

Конечно, технологии с тех пор сделали огромный скачок. Тогда программисты не могли даже мечтать о таких замечательных вещах, как непрерывная интеграция или разработка через тестирование. Собственно, даже основные принципы тестирования тогда ещё не были окончательно сформированы, а до выхода знаковой книги Майерса «Искусство тестирования программ» оставалось ещё девять лет.

Ну или попробуйте представить себе парное программирование на перфораторе и совместное владение кодом в виде колоды перфокарт.

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


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