Водопад против Agile

Разбираемся, откуда взялся Agile: что такое водопад, где именно он ломается, что на самом деле написано в манифесте 2001 года — и что там не написано, хотя многие уверены в обратном.

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

Обратите внимание на последние слова: в момент наименьшего знания. В этом весь сюжет. Любой план проекта пишется тогда, когда о проекте известно меньше всего — до первой строчки кода, до первого показа пользователю, до первого «ой, а мы не подумали про возвраты». И дальше начинается вопрос: что мы делаем с новым знанием, которое приходит по ходу дела? Водопад отвечает «стараемся не сойти с плана». Agile отвечает «переписываем план».

Как работал классический водопад

Waterfall («водопад») — модель разработки, где проект проходит фазы строго по очереди, и каждая следующая начинается после того, как предыдущая закрыта и подписана.

Требования (2 мес.)
   ↓  подписан документ требований
Проектирование (2 мес.)
   ↓  подписана архитектура и ТЗ
Разработка (6 мес.)
   ↓  код передан в тестирование
Тестирование (2 мес.)
   ↓  подписан акт приёмки
Внедрение и поддержка

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

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

Где он ломается на софте

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

1. Требования известны заранее

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

2. Ошибку можно поймать проверкой документа

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

3. Цена изменения постоянна

Она не постоянна — она растёт. Правка требования на этапе анализа стоит часа обсуждения. Та же правка после того, как под старое требование написаны схема базы, API, три экрана и сорок тестов, стоит недель. Классические оценки Барри Бёма (рост цены исправления от анализа к эксплуатации в десятки раз) сегодня справедливо критикуют: данные старые, из проектов, непохожих на современные, и в командах с хорошими тестами и CI кривая гораздо более пологая. Но знак производной верен: чем позже нашли — тем дороже. Именно на этом стоит вся аргументация в пользу коротких циклов, и честнее опираться на знак, чем размахивать красивыми цифрами «×100».

Итог: водопад не «плохой». Он оптимизирован под мир, где знание почти полное, а изменения дороги. В разработке софта знание неполное, а изменения дёшевы — если мы сами не сделали их дорогими.

Что реально говорит манифест

В феврале 2001 года семнадцать человек — авторы Scrum, XP, DSDM, Crystal и других подходов — собрались на лыжном курорте в Юте и вместо драки за то, чей метод правильнее, записали на одну страницу то, с чем все согласны. Получилось четыре ценности, каждая в форме «А важнее Б», и приписка: то, что справа, тоже ценно, просто левое мы ценим выше.

Важнее	Чем	Что это значит на практике
Люди и взаимодействие	процессы и инструменты	Проблема «команда не разговаривает» не решается покупкой Jira
Работающий продукт	исчерпывающая документация	Критерий готовности — работает у пользователя, а не «спека сдана»
Сотрудничество с заказчиком	согласование условий контракта	Когда всплывает новое, обсуждаем, а не ищем, кто виноват по пункту 4.2
Готовность к изменениям	следование первоначальному плану	Изменение требования — это новая информация, а не чей-то провал

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

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

Заметьте, чего здесь нет. Нет слов «спринт», «стендап», «story points», «velocity», «Scrum-мастер», «Jira». Ни одного. Всё это — инструменты конкретных фреймворков, придуманные до и после манифеста. Манифест — про приоритеты, а не про расписание встреч.

Чего манифест НЕ говорит

Не говорит, что документация не нужна. Он говорит, что «спека сдана» — не то же самое, что «работает».
Не говорит, что не нужно планировать. В принципах прямо сказано про регулярную поставку и устойчивый темп — это невозможно без планирования.
Не говорит, что заказчик может менять всё бесплатно. Приветствовать изменения — значит уметь их обсуждать и переприоритизировать, а не соглашаться на всё, не двигая сроки.
Не говорит, что Agile быстрее или дешевле. Ни слова про скорость команды. Он про то, чтобы не потратить год на ненужное.
Не говорит, что архитектура и качество вторичны. Наоборот: там прямым текстом про техническое совершенство.

Как это работает: итерации как страховка от ошибки

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

ВОДОПАД
  месяц 0   ошибка попала в ТЗ
  месяц 10  первый показ пользователю → ошибка обнаружена
  потеряно: до 10 месяцев работы, часть которой построена поверх ошибки

ИТЕРАЦИИ ПО 2 НЕДЕЛИ
  неделя 0  ошибка попала в план итерации
  неделя 2  демо пользователю → ошибка обнаружена
  потеряно: до 2 недель работы
  бонус: следующие 9,5 месяцев строятся уже на верной посылке

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

Отсюда же вытекает всё остальное, что покажется дальше в курсе. Демо в конце спринта — чтобы обратная связь пришла. Работающий инкремент вместо «80% готово» — чтобы обратная связь была настоящей, а не по слайдам. Ретроспектива — тот же цикл обратной связи, но применённый к самому процессу работы.

Частые ошибки

«Мы по Agile» = «мы без плана». Самая частая и самая дорогая подмена. Отсутствие плана — это не гибкость, это хаос; гибкость — способность быстро перестроить план.
Мини-водопад под видом спринтов. Неделя аналитики, неделя разработки, потом «спринт тестирования», потом «спринт багфикса». Ритуалы Scrum на месте, цикл обратной связи не замкнут: рабочего продукта в конце итерации нет.
Демо без пользователей. Показывать инкремент своему же менеджеру — не обратная связь. Нужен тот, кто будет этим пользоваться или платить.
Считать водопад глупостью. Он рационален там, где итерация физически дорога. Пренебрежение к нему — верный признак того, что человек читал не манифест, а посты про манифест.
Цитировать «×100» как доказательство. Аргумент за короткие циклы работает и без сомнительных цифр; ссылаясь на них, вы подставляетесь перед первым же скептиком в комнате.

Итоги

Водопад предполагает, что требования известны заранее, ошибки ловятся ревью документов, а цена изменения постоянна. В разработке софта не выполняется ни одно из трёх.
Ройс, которого считают отцом водопада, описывал линейную схему как антипример и предлагал итерации. Индустрия прочитала картинку.
Манифест — это четыре пары «важнее/чем» и двенадцать принципов. Ни спринтов, ни стендапов, ни story points там нет.
Правая часть каждой пары (документация, контракт, план) не отменяется — она просто проигрывает при конфликте приоритетов.
Работающий механизм Agile — короткий цикл обратной связи. Он не ускоряет команду, он ограничивает размер ошибки, которую можно совершить незаметно.