Среди множества вопросов, которые рано или поздно возникают в каждом проекте, есть один особенно важный: как лучше всего управлять процессом разработки продукта?
Один из проверенных годами вариантов — Waterfall, или каскадная модель управления разработкой программного обеспечения.
Сегодня эту методологию часто критикуют. Но действительно ли она настолько плоха? Или мы снова увидим, что история повторяется?
Жизненный цикл разработки программного обеспечения
Каждая команда разработчиков может создать собственную модель жизненного цикла программного обеспечения или использовать уже признанный подход. Один из таких вариантов — Waterfall.
Основателем этой модели считается американец Уинстон Ройс. Его работа была представлена в 1970 году. С тех пор метод, описанный Ройсом, используется во многих проектах как в первоначальном виде, так и в измененных версиях.
При этом некоторые IT-специалисты утверждают, что такой методологии фактически никогда не существовало в том виде, в котором ее часто описывают.
Интересно слышать такие утверждения о подходе, который десятилетиями применяли в разработке программного обеспечения, автомобильной отрасли, строительстве, финансах, медицине, электронике и других сферах.
Waterfall в IT
Главный принцип модели Waterfall в разработке программного обеспечения заключается в том, что каждый следующий этап нельзя начинать, пока полностью не завершен предыдущий.
При этом произвольные переходы вперед или назад не допускаются, а фазы не должны накладываться друг на друга.
Именно это отличает каскадную методологию от гибких подходов, таких как Agile, DSDM, Scrum или FDD.
Алгоритм действий в Waterfall
Чтобы понять идеи Ройса, которые лежат в основе модели, можно изучить его оригинальную работу:
Royce, Winston (1970), Managing the Development of Large Software Systems.
Каскадный рабочий процесс
Формирование и обсуждение идеи
На этом этапе разработка фактически еще не начинается. Есть только новая идея, которая заинтересовала одного или нескольких человек.
Анализ требований
Этот этап включает максимально детальное описание требований заказчика к проекту.
Нужно определить:
- способы достижения цели;
- сроки выполнения работ;
- финансовую часть;
- резерв времени и бюджета для каждого блока работ.
После завершения анализа требований у команды уже есть техническое задание для программистов и сформированный бюджет.
Проектирование программного обеспечения
На этом этапе команда определяет ключевые технические решения.
Обычно сюда входит:
- выбор платформы программирования, например Python, PHP, JavaScript и другие;
- уточнение технических деталей: взаимодействие сервиса или продукта с серверами, использование API, логика внешнего и внутреннего интерфейсов;
- решение вопросов безопасности: использование HTTPS, SSL-шифрования и других средств защиты;
- определение ролей пользователей продукта: администратор, клиент, менеджер и другие;
- финализация вопросов надежности, эффективности и дальнейшей технической поддержки продукта;
- формирование отдельной команды для реализации проекта.
Разработка программного обеспечения
На этом этапе команда пишет код в соответствии с документами, которые были подготовлены ранее.
Тестирование программного обеспечения
Специалисты тестируют финальную версию продукта в условиях, максимально приближенных к реальным, и фиксируют ошибки.
Самые критичные баги, которые влияют на работу продукта, исправляются. Менее важные могут остаться без исправления, если закончились время или бюджет.
Техническая поддержка программного обеспечения
Готовый работоспособный продукт запускают в использование по назначению и сопровождают.
Поддержка включает:
- контроль работоспособности продукта;
- исправление сбоев;
- планирование обновлений функционала на основе обратной связи пользователей.
Все эти фазы выполняются в строгой последовательности, а результаты каждого этапа фиксируются.
Чтобы понять эволюцию классической методологии Waterfall, можно изучить Project Management Body of Knowledge. Третья и четвертая версии имеют ряд различий, которые помогают понять каскадный путь.
Преимущества и недостатки каскадной модели разработки программного обеспечения
Как и любой подход, Waterfall имеет сильные и слабые стороны.
| Преимущества каскадной модели | Недостатки каскадной модели |
|---|---|
| Каждый этап работы максимально детализирован, а его ход фиксируется. | Поддержка детальной документации занимает много времени, а заказчику она не всегда понятна. |
| Требования прописаны максимально четко и не должны противоречить друг другу или меняться в процессе работы. | Нужны квалифицированные бизнес-аналитики, которые могут подготовить техническое задание для эффективной работы. |
| Можно заранее оценить, сколько времени и денег понадобится на проект. | Если во время разработки окажется, что продукт не соответствует требованиям рынка, пространства для маневра почти нет. |
| Методология понятна даже разработчикам с небольшим опытом. | Затраты времени и бюджета могут быть достаточно высокими. |
| Проект легко контролировать и при необходимости передать другой команде благодаря строгой системе отчетности. | Критические проблемы часто обнаруживаются на финальном этапе, а их исправление в готовом продукте стоит очень дорого. |
Как использовать каскадную модель разработки и в каких случаях?
На практике модель Waterfall в разработке программного обеспечения уместна в следующих случаях:
- заказчик участвует в проекте только на первом этапе, а затем принимает готовый продукт;
- требования к продукту не будут меняться;
- проект сложный, долгосрочный и дорогой;
- качество является главным приоритетом, даже если это влияет на сроки;
- у команды нет большого количества разработчиков высшего уровня;
- есть возможность привлечь внешних специалистов для реализации проекта.
Чтобы лучше понять возможные причины отказа от каскадной методологии, можно прочитать книгу Джеффа Сазерленда Scrum. The Revolutionary Method of Project Management.
Примеры использования Waterfall
В чистом виде каскадная модель в современной разработке встречается не так часто. Нередко Waterfall называют все, что нельзя отнести к Agile, поэтому определить реальное использование именно этой методологии не всегда просто.
По оценкам экспертов, значительная часть ERP-систем, программ для строительства, медицины, государственных контрактов, промышленного использования и других фундаментальных направлений создается с использованием модифицированных версий Waterfall.
Специфику работы с такими проектами можно лучше понять с помощью книги Сергея Зыкова Pattern-based Development of Enterprise Systems.
И это логично. Об этом также писал Чак Кобб, ментор, тренер и автор книг об Agile-методах в управлении проектами.
Если вы строите мост через реку, было бы странно сказать: “Сначала построим первый пролет, потом посмотрим, что получилось, и уже тогда решим, достраивать ли остальные пролеты”.
Среди компаний, где Waterfall используется или использовался, можно отметить следующие:
| Компания | Для чего использовали Waterfall | Используется ли сейчас | Комментарий представителя компании |
|---|---|---|---|
| Wüstenrot & Württembergische (W&W) | Разработка ERP-системы для финансового сектора | Нет данных | — |
| Cisco | Разработка систем безопасности | Да | — |
| EPAM | Разные продукты, решения или их части | Да | Agile не обязательно применять ко всему большому проекту. Гибкую разработку можно использовать на отдельных этапах или в отдельных процессах. |
| IBM | Разные продукты, решения или их части | Да | Waterfall-проекты все чаще требуют поддержки, а новые технологии постепенно заменяют старые подходы. |
| Microsoft IT | Разные продукты, решения или их части | Нет | Команды перешли на гибкие методологии, потому что традиционная модель Waterfall часто создавала проблемы из-за долгого предварительного планирования. |
| AT Consulting | Разработка систем с нуля | Да | Используют Agile, Waterfall или сочетание обоих подходов. |
| Parallels | Разные продукты, решения или их части | Да | В разных проектах применяют разные подходы: Agile со спринтами или квази-Waterfall с более длинными этапами. |
| SAP | Разные продукты, решения или их части | Да | На этапе создания продукта могут использоваться варианты Agile или сочетание Agile с Waterfall. |
| Toyota | Разные продукты, решения или их части | Нет | Компания изучает, как применять TPS, или Lean, к разработке программного обеспечения. |
Приложения и программы для управления разработкой на основе каскадной модели
Для работы с Waterfall можно использовать инструменты, которые помогают отслеживать время, планировать этапы и строить диаграммы Ганта.
Worksection
Worksection — украинский SaaS-сервис для управления проектами с удобной мобильной версией.
Он подходит для тщательного планирования благодаря таким возможностям:
- диаграмма Ганта со связями между задачами и дедлайнами;
- распределение обязанностей между исполнителями с разными правами доступа;
- система разных форм отчетности;
- сохранение комментариев, реакций и всей истории активности в рамках проекта;
- ограниченный доступ для заказчика или клиента для прозрачности процесса разработки;
- возможность указывать бюджеты и расходы;
- чек-листы для небольших этапов задач, чтобы выполнять работу точно по инструкции.
Подытожим
Waterfall — методология, которую используют уже давно. И, несмотря на критику, во многих случаях она остается эффективной.
В то же время в чистом виде этот подход не подходит для многих проектов, где нужно быстро реагировать на изменения рынка.
Из опыта крупных компаний можно сделать вывод: Waterfall имеет свое место в современных проектах. Но его использование оправдано там, где требования стабильны и точно не изменятся до завершения проекта.