Модель водопада: как работает методология Waterfall

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

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

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

Waterfall появился полвека (!) назад. В 1970 году этот подход описал американский ученый в области информатики Уинстон Уокер Ройс, директор Lockheed Software Technology Center. Не могу утверждать, что Ройс первопроходец. Появление каскадной модели стало скорее ошибкой. Ученый написал статью, в которой обсуждал недостатки каскадного подхода и предлагал его доработать — сам он использовал итеративную методологию.

Потоковый подход и до этого встречали в литературе. Как минимум, его структура практически полностью срисована с диаграммы Ганта. Но так вышло, что Ройс написал статью, в которой его не совсем правильно поняли. Сыграл случай: методология, как и сам ученый, приобрели всемирную известность.

Методология строится на 8 главных принципах. Внимательные заметят, что многие из них противоречат аджайлу. Вот они:

1. Документирование важно. Все этапы работы должны быть зафиксированы
2. Каждый этап последователен: следующий этап начинается после окончания предыдущего
3. Пропуск этапов плана запрещен
4. Если в процессе разработки требования к функционалу поменялись, вносим изменения в ТЗ
5. Откат на прошлый этап невозможен, ничего менять нельзя
6. Разработка происходит в рамках одного процесса. Итераций нет
7. Работа над ошибками — после окончания разработки
8. Участие клиента ограничивается этапом разработки ТЗ. Привлекать клиента к работе над продуктом нельзя

Waterfall много критикуют. За недостаточную гибкость, за громоздкость, за обязательную формализацию управления проектом в ущерб срокам, бюджету и даже качеству. Но для больших проектов как раз в формализации и есть большая ценность — она помогает минимизировать многие риски и делает работу над продуктом прозрачной. А с 2009 года в PMBOK внесен гибридный вариант, который сочетает преимущества каскадного подхода и итеративных методологий.

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

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

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

В описанной Ройсом модели можно было возвращаться на прошлые этапы работы над проектом — для корректировки.

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

Сбор требований

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

Проектирование

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

1. Обсуждают и согласуют с клиентом логику работы системы, детали готового продукта
2. Создают описание функционала — что и как должно работать
3. Готовят прототип и макеты дизайна, привлекают разработчиков
4. Согласуют бюджет, определяют объем человеко-часов, планируют штат команды разработки

Вопрос реализации по прежнему пока не затрагивается. Но подготовительный этап в самом разгаре.

Реализация

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

Этот этап занимает бОльшую часть времени проекта: разработчики пишут код, дизайнеры рисуют дизайн, редакторы пишут тексты. Все строго по техническому заданию, шаг в сторону — расстрел.

Проверка — тестирование

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

И это главный минус Waterfall: если бы использовали гибкие методологии, критические ошибки нашли бы сильно раньше. Это сократило бы время разработки и ресурсы команды, продукт обошелся бы дешевле, а проблемы не были бы столь существенными. А так получается, что бОльшая часть проекта уже пройдена, но к этому моменту работоспособного продукта моет и не быть.

Развертывание

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

Первое отличие. Метод водопада в управлении проектами — это работа по заранее спланированному и согласованному техническому заданию. Никакой гибкости, никаких изменений. Только четкий план и строгие инструкции. Это, наверное, главное отличие от аджайла, где гибкость лежит в основе самой концепции.

Второе отличие. Это принципы работы и положения манифеста. Помните как в аджайле? Никакой бюрократии, люди важнее документов, заказчик важнее ТЗ, изменения важнее плана… Тьфу, сопли. Каскадный метод — это хардкор, формальность и жесткие контрактные ограничения. Как будто водопадный подход придумал не разработчик программного обеспечения, а государство и крупные корпорации.

Давайте представим, как бы выглядел манифест Waterfall, если бы его кто-то составил.

Манифест водопадного подхода (по версии Oko)

1. Не нарушай правила. Иначе труба
2. Слушай начальника. Ему виднее
3. Работай строго по ТЗ. Без ТЗ — результат ХЗ
4. Давай без изменений. Нарушение плана от лукавого
5. Не контактируй с заказчиком. Потом посмотрит

Третье отличие. Как помните, аджайл — это итеративный подход. Работа ведется короткими фиксированными итерациям. Скажем, команда создает какой-то функционал в течение 2 недель, а потом смотрит на него и корректирует общий план. В методе водопада так нельзя. Тут всего одна итерация, и даже возможность вернутся назад для внесения кое-каких правок в продукт этого не изменит. Пересматривать этот подход нельзя.

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

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

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

Иллюзия безопасности и ложные впечатления. Смотрите, подробный план в больших корпорациях считается залогом успешной работы. В реальности громоздкая машина планирования лишь создает иллюзию работы над проектом. Менеджер может сказать: - «Все хорошо, работа идет. Мы реализовали уже 55% от проекта». На деле за этой цифрой может не быть никакого полезного результата.

Заказчик изолирован. Если что-то идет не так, клиент не узнает об этом до завершения проекта. А пользователь не сможет попробовать продукт. Никаких корректировок не предусмотрено, поэтому есть большой риск получить на выходе «фантик». Массовый потребитель на выходе может получить продукт, который не отвечает его требованиям.

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

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

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

Дисциплина. Строгий менеджмент, четкая последовательность работ, жесткие требования регламентов. Это исключает расхлябанность членов команды даже при отсутствии полной вовлеченности. У каждого есть инструкция, за невыполнение которой можно получить по голове.

Условная гибкость. Пока дело не дошло до разработки, изменения вполне допустимы. Суть подхода в том, чтобы заранее продумать все детали. В аджайле изменения приветствуются, потому что никто заранее не продумывает детали — в угоду скращению сроков и бюджетов. «Водопад» же заставляет сначала написать и согласовать требования, хоть в сколько подходов, а уже потом начинать разработку. Так делают, чтобы выпустить продукт с первого раза.

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

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

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

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

1. Waterfall — каскадный подход управления проектом. Он заточен на последовательную разработку продукта по заранее намеченному плану. В «Водопаде» всегда строгая документация, жесткие регламенты и определенность. Нельзя приступать к разработке, пока не известны основные моменты
   
2. Каскадную модель впервые описали в 1970 году. Разработчик описал концепцию и предложил для нее рекомендации. Но сообщество неправильно его поняло и восприняло описание как полноценную методологию. А потом она стала известна на весь мир
3. Каскадная модель строится на 5 обязательных и последовательных этапах. Обычно схему работы по ним изображают в виде каскада этапов, чем она напоминает водопад. Игнорировать эти этапы и перескакивать через них нельзя. Все строго и формально
4. В отличие от гибких методологий, Waterfall не терпит изменений, не включает в ход работ коммуникацию с заказчиком и обязательно работает по техническому заданию. Нет ТЗ — нет продукта. Сильная формализация делает методологию громоздкой и неповоротливой. Как раз то, что нужно крупным корпорациям
5. У Waterfall много минусов. Но это не мешает использовать ее при разработке сложных типовых продуктов, когда требования известны заранее, заказчик готов к полной передаче работ на аутсорс и ждет результат в срок