Недостатком для заказчика можно назвать то, что он сможет увидеть результат только waterfall это в конце проекта. До разработки и процесса тестирования клиент не допускается и не сможет прокомментировать макеты или прототипы. В итоге массовый потребитель на выходе рискует получить продукт, не отвечающий его требованиям. Методология “Водопад” (Waterfall) — это традиционная модель процесса разработки, где каждый этап последовательно следует за предыдущим. Подобный гибридный подход «выстреливает», если у ПО еще немного пользователей, но впереди большой объем работ по функциональности.
Направо пойдешь… или Как выбрать подходящую базовую методологию
Однако, Waterfall также имеет недостатки, включая отсутствие гибкости, высокие риски и ограниченное участие заказчика на промежуточных этапах. Методология «водопад» — это традиционный способ разработки программного обеспечения, при котором каждый последующий этап начинается только после завершения предыдущего. Основная идея этого подхода заключается в выполнении задач в линейной последовательности, что делает его подходящим для проектов, характеризующихся повторяемостью и предсказуемостью. Waterfall — технология разработки программного обеспечения, известная еще с 1970 года.
Чем «водопадный» подход отличается от аджайла
У каждого есть инструкция, за невыполнение которой можно получить по голове. Если разработкой занимаются профаны и просто бездари, руководство узнает об этом, когда будет слишком поздно. Если будут просто косяки, команде проще закрыть их заплатками, чем начинать разработку с нуля. Результат — плачевные последствия, плохой продукт и недовольный заказчик.
Встречают по обложке: в чем роль дизайна в бизнесе
Это ваш подход, если вы не знаете, где окажетесь завтра. Waterfall же подойдет для небольших проектов с высокой степенью определенности. Если вы точно знаете, какой проект нужен в итоге, либо вы уже делали аналогичный проект, вы сможете продумать четкую последовательность этапов. Основными шагами разработки Waterfall являются определение требований, проектирование, реализация, тестирование и поддержка. Принципиальным принципом Waterfall является последовательность выполнения этих шагов, при которой каждый последующий начинается только после окончания предшествующего.
Когда стоит применять каскадную модель
Вернемся к примеру с ремонтной бригадой «Уют», который мы рассмотрели в начале статьи. Если они будут ремонтировать квартиру по методологии Agile, сначала полностью отделают одну комнату и покажут результат заказчику. Он выскажет пожелания, например, что тон стен слишком холодный. Мастера перекрасят стены и учтут это пожелание при дальнейшем ремонте. Если клиент захочет, он сможет сразу жить в готовой комнате, а не ждать, когда закончится ремонт в остальной квартире. Еще один базовый принцип Agile — подрядчик выдает реальный результат как можно скорее.
Выходит, старый добрый Waterfall заметно отстал от жизни и современных реалий разработки. Если требования к продукту меняются после начала проекта, Waterfall не способен адаптироваться. Это может привести к риску завершения проекта, который уже устарел к моменту его завершения. Весь контроль за соблюдением сроков и бюджета лежит на исполнителе. Если, например, руководитель команды уходит или объем работ неправильно оценивается в начале проекта, исполнитель вынужден брать на себя ответственность за возможные срывы и дополнительные расходы. Если команда уже имеет опыт в реализации подобных проектов, то Waterfall может быть удобным выбором.
Заказчик не всегда готов сказать, чего он хочет — не всегда он это знает. На случай большой неопределенности и придумали гибкие методологии. Ее нужно постоянно держать в актуальном состоянии, из-за чего работа над проектом превращается в сплошную бюрократию. Пока не согласовать детали со всеми участниками процесса, не формализовать это в виде документа, проект не сдвинется с мертвой точки.
Но если заглянуть в оригинальный документ за авторством Ройса, выяснится, что он вполне предполагал возврат на предыдущие этапы для той же корректировки. Например, если надо создать медицинский прибор или систему экстренного торможения электропоезда. В таких работах цена ошибки — это человеческие жизни, поэтому надо проверить и перепроверить каждый шаг. Если все этапы пройдены последовательно и хорошо задокументированы, проверка упрощается. В этом случае заказчик компетентен в работе подрядчика и может точно описать в ТЗ, что он хочет получить в итоге.
Критика Waterfall часто заключается в неспособности методологии эффективно реагировать на меняющиеся требования в процессе разработки. Однако его сильные стороны — предсказуемость и чёткие рамки этапов — делают его идеальным для проектов с стабильными требованиями и хорошо понимаемыми рисками. Первую уже назвал — это участие в тендерах и стремление получить госконтракты. Обычно в таких проектах требования зафиксированы, а вероятность их изменения сравнительно мала.
Минусом является и большой объем документации, которую приходится постоянно поддерживать в актуальном состоянии. Невозможно начать работу над проектом, пока детали не согласованы со всеми участниками процесса и не формализованы в виде документа. Scrum также вводит дополнительную детализацию по ролям, которые играют члены команды разработки в рамках проекта.
- Если даже они появятся, ни на одном из семи этапов их вносить не будут.
- Более того, взаимозаменяемость членов команды невозможна.
- Наработки по чату отправились в морозильник, где лежат до сих пор.
- Традиционная методология разработки Waterfall, несмотря на критику, по-прежнему занимает важное место в сфере ИТ-проектов благодаря своей предсказуемости и структурированности.
Фреймворк Scrum — это часть Agile, поэтому он тоже отличается от водопадной модели разработки. Классическая методология Waterfall — это работа по заранее написанному и согласованному ТЗ. Потом пишет подробное техническое задание, планирует график работ и возможные риски. Переходит к следующему этапу, только когда все требования прописаны и есть план. Бывает, что в теории методология ясна, а потом дело доходит до внедрения и начинаются вопросы. На курсе «Управление проектами» преподаватели Skillbox разбирают инструменты управления на реальных кейсах, чтобы студенты легко и безошибочно применяли их в работе.
В 1970 году в своей статье Ройс описал в виде концепции то, что сейчас принято называть «каскадная модель», и обсуждал недостатки этой модели. Там же он показал, как эта модель может быть доработана до итеративной модели. Гибкие методологии помогают работать в полной неизвестности. В большинстве из них разработка ведется короткими циклами — итерациями по 2-3 недели. Каждая итерация позволяет сделать проект в миниатюре, протестировать и оценить его возможности. Agile поможет сделать продукт сильным, но нужно осознать, что гонка будет продолжаться очень долго.
При этом не возврат на предыдущие этапы, не перескакивание с этапа на этап не допускаются. При подходе Waterfall проект разработки программного обеспечения рассматривается как единый проект. Это резко контрастирует с методологией Agile, которая рассматривает разрабатываемый проект программного обеспечения как ряд различных подпроектов. Поскольку модель Waterfall следует строго последовательному порядку, группа разработчиков проекта может перейти к следующему этапу только тогда, когда предыдущий этап будет успешно завершен.
Waterfall — тот самый неплохой минимум, с которого можно начать. Мы привыкли мыслить последовательными категориями, поэтому каскадная методология кажется более близкой, в отличие от непоследовательности Agile. Продолжаю разбираться в теории управления проектами и изучать методологии, методики и методы. Теперь пришло время поговорить о её противоположности — каскадной методологии, которую также называют «водопадной моделью» или просто Waterfall.
Важно и то, что отхождение от изначального плана в Agile не нарушает рабочий процесс. В случае с Kanban все неожиданные задачи берутся в реализацию чуть ли не по щелчку пальцев, исполнители сменяются на лету, а приоритеты постоянно корректируются. Не нужно получать сотни согласований — достаточно переставить карточки на доске проекта. Одно из самых существенных преимуществ гибких методологий — прямая коммуникация между разработчиками и заказчиками. Последние могут непрерывно давать фидбек и реально влиять на рабочий процесс, а не только согласовывать требования и принимать конечный результат.
Допустим, локальный проект с крохотной командой может реализовываться по водопадной модели, если этого требует консервативный госзаказчик. Таким образом, свобода и гибкость Kanban отчасти уравновешивается правилами Scrum. Разработчики не распыляются между тасками и не берутся за все подряд. При этом в границах спринта можно гибко распределять задачи, корректировать загрузку по ситуации.
Результат важен, поскольку он дает возможность выходить на рынок, исследовать реакцию пользователей и тестировать новые идеи. Некоторые управленцы пытаются сгладить шероховатости традиционных методологий при помощи гибридных моделей. Эта тенденция началась с микширования Waterfall и Agile, но потом «селекционеры» отважились на скрещивание гибких подходов. У нас в Magnus Tech довольно высокую эффективность показала система с говорящим названием Scrumban. Гибкие методологии, напротив, подходят для динамичных отраслей, в которых технический прогресс мчится, как скоростной поезд. Удачный пример — машинное обучение, где идут постоянные исследования.
IT курсы онлайн от лучших специалистов в своей отросли https://deveducation.com/ .
