17 июля 2017   •   Елена Самойлова   •   14 min read

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

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

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

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

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

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

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

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

Waterfall в сфере IT

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

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

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

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

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

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

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

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

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

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

  1. выбирается платформа программирования (Python, PHP, JS и пр.)
  2. уточняются технические детали (например, как будут взаимодействовать сервис или продукт с серверами, станут ли использовать API, какой будет логика внешнего и внутреннего интерфейса и т.д.)
  3. решаются вопросы безопасности проекта (например, будет ли использоваться HTTPS, SSL-шифрование и пр.)
  4. описываются роли пользователей программного продукта (администратор, клиент, менеджер и пр.)
  5. финализируются вопросы надежности, производительности и дальнейшей техподдержки целевого продукта
  6. формируется конкретная команда.

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

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

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

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

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

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

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

Чтобы понять эволюцию классической водопадной методологии, описанной выше, можно изучить 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

Worksection

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

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

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

Вердикт

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

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

Опубликовать

Бизнес-кейсы
Искали инструмент, который интегрируем за пару месяцев, с приятным и понятным для команды интерфейсом. Пробовали разные таск-трекеры всей командой, и через время наткнулись на Worksection в интернете. Посмотрели видеоролики, создали аккаунт, закинули пару проектов и поразились насколько он удобен для нашей компании.
6 августа 2019   •   8 min read
Бизнес-кейсы
О компании: Консалтинговое агентство;120 сотрудников в СНГ секторе;Более 10 лет на рынке;Более 500 успешных проектов;Клиенты: Чех Post Print House, BogushTime, Water Energy, Global Security Technologies...
27 июня 2019   •   7 min read
Бизнес-кейсы
Worksection помогает настроить работу целого агенства. Если не фиксировать задачи, то есть очень большая вероятность что-то упустить.  
20 июня 2019   •   6 min read
Мы в соц-сетях
esc
Поделиться в
esc
Лучшая система управления проектами
Worksection
Попробовать бесплатно
уже есть аккаунт
Войти
Новинки Кейсы PM Книги
Найти
Видео Диаграмма Ганта Отчёт План Интеграции Уведомления Еще 48...
Видео Диаграмма Ганта Отчёт План Интеграции Уведомления Бизнес процесс Проектный менеджмент Roman.ua Теория Рецензия Artjoker Шесть Сигм Бережливое производство App Android IOS Задачи Календарь Связи Подзадачи UI Статусы Метки Отчёты Затраты Учёт времени Учёт финансов Горящие задачи Экспорт Фильтр Комментарии Сhecklist Таймер Документы Топ 10 Файлы Ответственный Поиск Безопасность Интервью Развитие команды Развитие лидера Саморазвитие Креативные команды Маркетинг команды IT команды Сервисные компании TOP 10 Рецензии Бизнес-процесс Акции Советы Партнерство Канбан
Лучшая система управления проектами
Worksection
Попробовать бесплатно
уже есть аккаунт
Войти