Бессмертная классика Waterfall

Среди вопросов, неизбежно возникающих в каждом проекте, выделяется один: как целесообразнее управлять процессом разработки продукта? Один из вариантов ответа проверенных годами — Waterfall (или каскадная, водопадная модель управления разработкой ПО).

Правда, сейчас эта методика нещадно критикуется, но так ли все плохо на самом деле или мы в очередной раз придем к тому, что все новое — хорошо забытое старое?

Жизненный цикл разработки программного обеспечения

Практически каждая команда разработчиков может создавать свою модель жизненного цикла ПО или использовать что-то общепризнанное. Один из вариантов — Waterfall. «Родителем» такой модели считается американец В. У. Ройс, который, по слухам, многое позаимствовал у коллег, присвоив себе лавры. Случилось это в 1970 году. До сегодняшнего дня во многих проектах используется описанный им подход: в первоначальном варианте или с доработками.

Хотя некоторые участники IT говорят о том, что такой методологии «отродясь-то не бывало»:

Как IT-профессионал и преподаватель я в течение более чем 40 лет слышал много мифов об IT-индустрии. Но что продолжает удивлять меня, так это то, почему слово «Waterfall» до сих пор используется для описания методологии, которая не существует и почему создатели методов разработки систем используют его в качестве источника сравнения.
David Dischave,
профессор школы информационных технологий университета Сиракузы, США

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

Waterfall в сфере IT

Основной постулат Waterfall модели разработки ПО заключается в том, что следующий этап не может быть начат, пока не завершен предыдущий. При этом произвольные переходы вперед или назад не допускаются, а этапы не перекрывают друг друга. В этом и заключается основное отличие каскадной методологии от гибких собратьев (или конкурентов): Agile, DSDM, Scrum, FDD.

Чтобы понять мысли Ройса, заложенные в основу модели, можно изучить его труд в оригинале: Royce, Winston (1970), Managing the Development of Large Software Systems.

Процесс работы, основанный на каскаде

Возникновение идеи и ее обсуждение

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

Анализ требований

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

По окончании анализа требований в наличии имеется ТЗ для программистов и бюджет.

Проектирование программного обеспечения

На этом этапе делаются конкретные шаги:

Разработка программного обеспечения

Этап, на котором пишется код, соответствующий документации, разработанной ранее.

Тестирование программного обеспечения

Готовая версия продукта тестируется специалистами в условиях, приближенных к боевым, выявляются и фиксируются баги. Наиболее катастрофичные для работы ПО в целом — исправляются, менее критичные — могут быть не исправлены, если нет времени или исчерпан бюджет.

Техническая поддержка программного обеспечения

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

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

Чтобы понять эволюцию классической водопадной методологии, описанной выше, можно изучить PMBOK. Между 3-ей и 4-й версиями есть ряд различий, которые помогут понять путь "каскада«.

Плюсы и минусы каскадной модели разработки программного обеспечения

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

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

Как и когда использовать каскадную модель разработки?

Как показывает практика, Waterfall модель разработки ПО вполне уместна в следующих случаях:

1. заказчик участвует в проекте только на первом этапе и принимает готовый продукт;
2. изменять требования к продукту не планируется;
3. проект отличается высокой сложностью, длительностью и дороговизной;
4. основной приоритет — качество, даже в ущерб времени;
5. отсутствие команды разработчиков экстра-класса;
6. допускается возможность выполнения проекта на аутсорсе.

Для понимания же мотивации отказа от каскадной методологии можно прочесть книгу «Scrum. Революционный метод управления проектами» Джеффа Сазерленда.

Примеры использования Waterfall

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

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

Понимание особенностей работы с такими проектами улучшает книга Сергея Зыкова «Основы проектирования корпоративных систем».

И это логично. Об этом говорит и Чак Кобб, автор книг, посвященных Аgile-методам в проектном менеджменте, наставник, инструктор:

Если бы вы строили мост через реку, было бы смешно сказать: «Мы построим первый пролет, посмотрим, как это выходит, а затем решим, как закончить оставшиеся пролеты!

Среди компаний, в которых использовали или используют Waterfall можно отметить:

Название компании	Для чего использовалась модель Waterfall	Используется ли сейчас методология	Комментарий представителя компании
Wüstenrot & Württembergische (W&W)	Разработка ERP-системы для финансового сектора	Нет данных	_
Cisco	Разработка систем безопасности	Да	_
EPAM	Разнообразные продукты и решения или их части	Да	Алексей Ионов: «...не обязательно весь большой проект делать по Agile — можно использовать гибкую разработку в рамках отдельных фаз или потоков работ...»
IBM	Разнообразные продукты и решения или их части	Да	Розалинда Рэдклифф: «Настало время, когда команды разработчиков, занимающиеся водопадом, не в силах выполнить требования бизнеса, поэтому эти проекты и продукты получают больше работ по техническому обслуживанию... Водопад будет постепенно заменен новыми технологиями и новыми командами, заинтересованными во внедрении новых бизнес-практик».
Microsoft IT	Разнообразные продукты и решения или их части	Нет	«За последние несколько лет... все наши команды приняли гибкую методологию. Мы обнаружили, что она решила многие проблемы, связанные с традиционной моделью водопада, где проекты планируются заблаговременно и могут занять месяцы или даже годы. В рамках этой модели продукт может быть устаревшем, как только мы его выпустили».
AT Consulting	Разнообразные продукты и решения или их части	Да	Василий Кораблев: «Для разработки систем с нуля мы используем один из подходов гибкой (Agile) или водопадной (waterfall) разработки, либо их комбинации».
Parallels	Разнообразные продукты и решения или их части	Да	Николай Добровольский: «В разных проектах у нас используются различные подходы — где-то Agile с одно-двухнедельными спринтами, а где-то — почти что Waterfall с майлстоунами по несколько месяцев. За многие годы работы у нас сложилось ощущение, что чем больше проект и команда, работающая над ним, тем сложнее и менее эффективно стараться запихнуть разработку в agile-процесс».
SAP	Разнообразные продукты и решения или их части	Да	Евгений Арнаутов: «На этапе создания продукта часто можно видеть варианты Agile, причем иногда совмещенные с Waterfall-подходом».
Toyota	Разнообразные продукты и решения или их части	Нет	Сатоши Ишии: "...мы пытаемся научиться применять TPS (Lean на западе) к разработке программного обеспечения«.

Приложения и программы для управления разработкой по каскадной модели

Для работы с «водопадом» можно использовать ряд сервисов для постановки задач. Ключевые критерии — наличие тайм-трекера, канбан-досок и диаграммы Ганта.

Worksection

Привлекательный украинский saas-сервис с удобной мобильной версией.

Подходит для четкого планирования, потому что есть:

• диаграмма Ганта со связями между задачами и дедлайнами
• распределение обязанностей по исполнителям с разными правами
• система разных типов отчетов
• комментарии, емоции и вся история действий по проекту сохраняется
• ограниченный доступ заказчика/клиента для прозрачности процесса разработки
• возможность внесения бюджета и расходов
• чек-листы для мелких этапов задач, что облегчает исполнение в точности по инструкции.

Вердикт

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

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