О сервисе

О WEEEK

УЗНАТЬ ПОДРОБНЕЕ

Решения

Chevron

Возможности

Chevron

Режим Календаря

Контролируй загрузку с помощью календаря на день и неделю.

Режим Досок

Следи за рабочими процессами через полностью кастомизируемые канбан-доски.

Подзадачи

Создавай подзадачи до 6 уровней вложенности. Используй их, как чек-лист или как полноценные задачи.

Уровни важности

Расставляй приоритеты между задачами с помощью четырёх уровней важности.

Тёмная тема

Пощади свои глаза и эффективно работай даже в тёмное время суток.

Умные уведомления

Настраивай, какие уведомления и где ты хочешь получать. Хоть на емейл, хоть в Телеграм.

Горячие клавиши

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

О сервисе

← Назад

О WEEEK

УЗНАТЬ ПОДРОБНЕЕ

Возможности

Chevron
← Назад

Режим Календаря

Контролируй загрузку с помощью календаря на день и неделю.

Режим Досок

Следи за рабочими процессами через полностью кастомизируемые канбан-доски.

Подзадачи

Создавай подзадачи до 6 уровней вложенности. Используй их, как чек-лист или как полноценные задачи.

Уровни важности

Расставляй приоритеты между задачами с помощью четырёх уровней важности.

Тёмная тема

Пощади свои глаза и эффективно работай даже в тёмное время суток.

Умные уведомления

Настраивай, какие уведомления и где ты хочешь получать. Хоть на емейл, хоть в Телеграм.

Горячие клавиши

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

Ресурсы

← Назад

Ресурсы

Модель водопада: плюсы, минусы, подводные камни

Александр Машков

Александр Машков

Calendar

12 марта

Time

5 мин.

Eye

221

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

Продолжаю разбираться в теории управления проектами и изучать методологии, методики и методы. Про 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 ещё долгое время будет доминировать в сфере управления проектами.

logo

Полезные статьи у тебя в почте раз в неделю

Скрыть

Article Другие статьи

Также советуем почитать

Читать другие статьи →