Слушай аудиоверсию этой статьи в нашем подкасте:
Продолжаю разбираться в теории управления проектами и изучать методологии, методики и методы. Про Agile, гибкую методологию, я уже рассказывал. Теперь пришло время поговорить о её противоположности — каскадной методологии, которую также называют «водопадной моделью» или просто Waterfall.
В чём идея
Говорят, без знания хотя бы одной методологии разработки бессмысленно лезть в управление проектами — всё начнёт разваливаться. Waterfall — тот самый неплохой минимум, с которого можно начать. Мы привыкли мыслить последовательными категориями, поэтому каскадная методология кажется более близкой, в отличие от непоследовательности Agile.
Впервые Waterfall представил в 1970 году Уинстон Ройс, директор Lockheed Software Technology Center, в своей статье. Но не сказать, чтоб до него про такой подход никто не знал — всё-таки структура каскадной методологии во многом заимствована у диаграммы Ганта, а она, как я уже рассказывал, уходит корнями далеко в прошлое. Просто так вышло, что славу за Waterfall Ройс (намеренно или случайно — не известно) присвоил себе.
Согласно Waterfall работа над проектом должна идти в несколько этапов, следующих друг за другом, от первого и до последнего. Их количество от проекта к проекту, от схемы к схеме может меняться, но суть одна.
- Требования. Самый первый этап, во время которого определяют и анализируют требования проекта: системные требования, требования к ПО, пожелания заказчика и т. д. и т. п. На основе всей этой информации создают входную документацию, где описывают, что должно получиться в итоге (не важно, что это будет — софт или авианосец), но не то, как именно это всё нужно будет делать. Короче, на этом этапе пишут первую, обобщённую, версию ТЗ.
- Проектирование. Когда первая версия ТЗ готова и есть общее понимание, что нужно сделать, команда приступает к проектированию — детализирует ТЗ, согласует с заказчиком логику работы системы, описывает, что и как будет работать. На выходе этого этапа всё ещё не проясняется вопрос реализации, но уже становится примерно понятно, сколько нужно людей и часов на работу.
- Реализация. Затем команда окончательно проясняет, как именно будет происходить разработка проекта, с помощью каких инструментов (языков программирования, оборудования, сервисов и т. д.). Каркас, который проработали на предыдущих этапах, становится более целостным, потихоньку формируется облик продукта. На этот этап приходится большая часть работы над проектом.
- Проверка. На этом этапе проводят полноценное тестирование продукта, чтобы найти и исправить критические (и не очень) проблемы.
- Развёртывание. И, наконец, когда всё протестировано и отлажено, переходят к последнему этапу, в рамках которого сдают проект заказчику, устанавливают, внедряют — в общем, вводят продукт в эксплуатацию. Кроме того, сюда может входить и последующее сопровождение, и поддержка, в том числе техническая.
Получается идеальная схема: продумали и согласовали ТЗ, сделали всё в точности по нему, протестировали, отдали клиенту — все довольны. А большой-пребольшой детализированный план, который создаёшь в самом начале, и которому все должны неотрывно следовать, создаёт иллюзию безопасности
У нас есть чёткий план. Что может пойти не так?
А пойти не так может всё.
Постулаты каскадной методологии
Как и у Agile, у Waterfall есть свои принципы, на которых всё строится:
- документы и инструкции очень важны;
- следующий этап должен начинаться только после окончания предыдущего;
- перескакивать через этапы нельзя;
- возвращаться на предыдущие этапы, чтобы что-то изменить, нельзя;
- если изменились требования — переделываем ТЗ;
- ошибки выявляют и исправляют только во время тестирования;
- клиент не участвует в работе над проектом после создания ТЗ.
Но не всё так однозначно. Взять хотя бы требование к жёсткой последовательности этапов и невозможности возвращаться назад. Говорят, в этом и состоит основное отличие Waterfall от Agile, Scrum и т. д. Но если заглянуть в оригинальный документ за авторством Ройса, выяснится, что он вполне предполагал возврат на предыдущие этапы для той же корректировки.
Думаю, ключевое отличие Waterfall от гибких методологий и методик в том, что, как ни крути, итерация здесь всего одна. И никакая возможности вернуться на этап назад, чтобы что-то поправить, этого не изменит. Но и сказать, что тот же Agile однозначно лучше каскадной методологии тоже нельзя.
Чем плох Waterfall
Сейчас Waterfall всё ещё популярен, но для того же IT подходит всё меньше по ряду причин.
- Очень много документов, который нужно постоянно актуализировать. Из-за этого работа над проектом часто превращается в сущую бюрократию — пока всё со всеми не согласуешь, в документах всё не пропишешь, с места ничто не сдвинется.
- Подробнейший план может создать не только иллюзию безопасности, но и ложные впечатления о работе над проектом. За фразами типа «60% проекта выполнено» может не быть никакого полезного результата. Это всего лишь манипуляция. Всё-таки «делать» — не значит «сделать».
- Пользователя и заказчика полностью изолируют от процесса разработки. В итоге первый не может постепенно привыкать к продукту, а второй — вносить корректировки, если что-то идёт не так. Поэтому продукты, сделанные по каскадной методологии, оказываются не ориентированы на массового пользователя.
- Все требования должны быть сразу известны. Сделать это очень сложно, потому что заказчик часто и сам не знает, чего он хочет. В таких ситуациях гибкие методологии сподручнее.
- Из-за того, что в Waterfall тестирование происходит только в самом конце, проектом могут заниматься некомпетентные специалисты, и этого никто не заметит, пока не станет поздно. А когда на этапе тестирования находят вагон и маленькую тележку проблем, их начинают просто закрывать заплатками, ведь иного выбора нет. На первых этапах модель может быть более-менее гибкой, но масса проблем на этапе тестирования влечёт плачевные последствия.
Чем хорош Waterfall
В IT всё больше команд переходит на гибкие методологии по двум причинам: команды разработчиков небольшие, а дедлайны можно легко подвинуть. Но для крупных проектов каскадная методология всё ещё актуальна, потому что:
- Устойчива к обновлению кадров. Благодаря очень подробному документированию каждого этапа, участники могут приходить и уходить, но на сроки работы это никак не повлияет.
- Дисциплинирует, благодаря плану и чёткой последовательности этапов и строгому менеджменту.
- Гибкая на ранних этапах. До этапа разработки можно вполне легко вносить изменения в предыдущие этапы.
- Прозрачна. Заранее понятно, на каком этапе что будет происходить, поэтому становится проще прогнозировать бюджеты и набирать команду.
Где лучше применять
Перечисленные плюсы и минусы не исключают использование каскадной методологии (она в некоторых случаях всё ещё уместнее Agile), но сужают пространство для применения. Waterfall подойдёт, если:
- Заказчик хорошо понимает, что хочет. У него есть проработанная концепция, которая не изменится.
- Заказчик не планирует участвовать в проекте после принятия ТЗ, а полностью отдаёт его на аутсорс.
- Заказчик хочет заранее знать точные сроки и результаты каждого этапа.
- Заранее понятно, что, как и с помощью каких инструментов нужно будет делать.
- Это сложный продукт, который требует очень много затрат, и у которого есть очень чёткая последовательность разработки (сомнительно, что подводные лодки когда-нибудь будут делать по Agile).
- Команда уже делала аналогичный проект.
Ну и вообще, как бы все ни хотели «быть Agile», человеческая любовь к последовательности и порядку слишком сильна. Особенно у разработчиков. Поэтому Waterfall ещё долгое время будет доминировать в сфере управления проектами.
Подписаться