Waterfall не существует

В смысле Waterfall не существует?

Просто нет такого подхода и никогда не было. Это как Эффект Манделы. Не существует описания или подробной методологии.

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

Я недавно была в Государственной экзаменационной комиссии в одном из ВУЗов, где в билетах были вопросы про тяжеловесные методологии разработки ПО. И правильный ответ был Водопад или Каскадная модель. (Спойлер, я бы к тяжеловесным отнесла RUP, но это другая история). Сама я училась на Прикладной информатике в 2007 году, и нам так же рассказывали про Waterfall.

Так значит все-таки существует?

Нет. Давай перенесемся в 1970 год. Dr. Winston W. Royce опубликовал статью «Managing the development of large software systems». Именно этот момент считается началом появления мифической Водопадной модели.

Получается все же автор есть и статья?

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

Так что же было в этой статье?

Ройс начал свой рассказ о том, что существует два основных этапа, общих для создания любого программного обеспечения, независимо от размера или сложности. Это были Analysis и Coding.

Он подчеркнул что эти этапы разработки, за которые большинство заказчиков готовы платить, так как оба этапа включают в себя действительно творческую работу, которая непосредственно вносит вклад в полезность конечного продукта.

Дай угадаю, следующая картинка была про Водопадную модель?

Да. Но с оговорочкой. Далее он показал, сколько на самом деле этапов в больших проектах. И вот тут он открыл портал в АД. Этапы анализа и кодирования по-прежнему присутствовали, но перед ними появились два уровня анализа требований, между ними находился этап проектирования системы, а после них — этап тестирования.

Ну вот, всеми известный Waterfall. Почему ж не существует то тогда?

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

А что же Ройс дальше писал в своей статье?

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

Но как же про реальные случаи, где делали всю разработку по Waterfall?

Сам Waterfall нигде не описан. Что значит по Waterfall? Что сначала делали Аналитику, а потом Разработку, а потом Тестировали? Ройс показал нам стандартный жизненный цикл создания ПО. А как иначе?

Иначе, например по Аджаил.

Ну это как сравнивать теплое с мягким. Аджаил это же культура, а не конкретная инструкция как разрабатывать. Это про здравый подход к разработке ориентированный на потребности заказчика. Если мы чуть сузим область, например выберем фреймворк Scrum, то там так же будет Анализ, Разработка, Ревью, Тестирование, возможно еще какие-то последовательные этапы.

Кстати, когда я была в Госкомиссии на экзамене, один студент отвечая на вопрос: "В чем отличие Аджаил от Waterfall?" Сказал:
В Аджаил нет строгих этапов, можно разрабатывать без требований.

Да, звучит правда нелепо. Всегда есть анализ, описание требований, иначе как разработчику понять, что именно делать?

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

Так это все родилось с той самой картинки: люди додумали, статьи написали, про свой опыт рассказали. Если честно, за 12 лет в разработке, я не видела, чтобы заказчик не мог внести новые требования.

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

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

Да и сейчас многие говорят, что Аджаил не работает, так как им нужно считать человеко-часы и подписывать акты о выполненных работах.

 В последнее время мне кажется, что Аджаил манифест написали потому, что разработчики потеряли главный свой фокус. Что они делают работу для заказчика, а не воюют против него через требования строгих ТЗ, DOR-ы и возмущения от очередной переделкой формы кнопки в интерфейсе...