Waterfall — это методология, где всё изначально продумано и зафиксировано, и в этом есть свои плюсы. Бывают проекты, которым она подходит, — такие, в которых все требования известны заранее и не могут измениться по ходу работы и где нет риска ошибиться. Фреймворк Scrum — это часть Agile, поэтому он тоже отличается от водопадной модели разработки. Разработка при использовании каскадной модели — это пять строго последовательных этапов.
Противостояние Agile и Waterfall не столько теоретическое, сколько практическое. Выбор методики, не подходящей под ваш проект, в лучшем случае существенно затормозит его развитие, в худшем — отправит в список «ТОП-провалов года». Однако Agile отлично работает в тех случаях, когда деньги и время не имеют жестких ограничений и в разработке задействована небольшая, обособленная команда, имеющая высокий уровень организованности и слаженности.
Преимущества И Недостатки Каскадной Методологии
Разберем, что значит каждый этап, на примере компании «Уют», которая занимается отделкой квартиры под ключ. CustDev (Customer Development) — это процесс, который помогает предприятиям разрабатывать продукты и услуги, отвечающие потребностям их клиентов. Сейчас Waterfall не так часто используют, но без неё никто бы не придумал Agile. Рассказываем для менеджеров проектов и тех, кто хочет ими стать.
На этом этапе QA, бета- и все другие тестеры обнаруживают и сообщают о проблемах в приложении. Данный этап чаще всего вызывает необходимый повтор предыдущей фазы кодирования, чтобы устранить критические неполадки. Если результатом тестирования становятся частые доработки кода, это вызывает возврат к этапу конструирования. Понимание особенностей работы с такими проектами улучшает книга Сергея Зыкова «Основы проектирования корпоративных систем». Разработчики, которые практикуют методологию Agile, вывели четыре основополагающих принципа гибкого подхода.
Проект И Документация
В 1970 году в своей статье Ройс описал в виде концепции то, что сейчас принято называть «каскадная модель», и обсуждал недостатки этой модели. Там же он показал, как эта модель может быть доработана до итеративной модели. Главная, в отличие от других методологий, особенность Waterfall — в ней отсутствует какая-либо гибкость. У тех же Agile или Scrum этапы могут идти параллельно, возможны почти любые изменение и возвраты на предыдущие ступени. Например, устанавливаться и тестироваться могут части продукта задолго до того, как начнет вырисовываться общая картина.
Самым сложным и ответственным этапом выступает период планирования, на протяжении которого формируются требования. В ходе данного этапа может появиться необходимость в методологии разработки Waterfall специализированных программных решениях. Последующие же этапы более просты, поскольку их выполнение будет осуществляться в регламенте ранее утверждённого плана задач.
Водопадная модель разработки подразумевает последовательное прохождение процесса, разбитого на стадии. Переход к новому этапу возможен только после завершения предыдущего. Именно поэтому часто ошибочно за каскадную модель принимается процесс разработки, в котором взаимодействие между этапами в обратном порядке исключено без директивных причин. Да и сами этапы часто дробятся в угоду многочисленным контролирующим органам, или объединяются из-за смежных профессий разработчиков.
Тем не менее, при управлении большими проектами формализация часто являлась очень большой ценностью, так как могла кардинально снизить многие риски проекта и сделать его более прозрачным. Поэтому даже в PMBOK 3-й версии формально была закреплена только методика «каскадной модели» и не были предложены альтернативные варианты, известные как итеративное ведение проектов. Ну и вообще, как бы все ни хотели «быть Agile», человеческая любовь к последовательности и порядку слишком сильна. Поэтому Waterfall ещё долгое время будет доминировать в сфере управления проектами. Взять хотя бы требование к жёсткой последовательности этапов и невозможности возвращаться назад. Говорят, в этом и состоит основное отличие Waterfall от Agile, Scrum и т.
Несмотря на то, что эти three пункта всё реже встречаются в реальной практике, каскадная модель ещё долго будет популярна и востребована из-за чёткой организации. А значит любой профессиональный разработчик должен понимать её основные принципы и быть готовым существовать в рамках этой схемы. В последние годы модель водопада уступает свои лидирующие позиции более гибким методологиям. Это связано с общей динамикой в IT, когда за разработку ПО отвечают команды из 5-9 человек, а дедлайн может быть легко сдвинут из-за наращивания функциональности.
Благодаря высокому уровню формализации, управлять таким проектом значительно проще. Принято считать, что каскадная модель разработки снижает риски и вносит ясность в процесс разработки, когда над проектом работает несколько десятком человек. Разработка ПО в рамках этой модели позволяет строго зафиксировать бюджет и сроки. Однако, работа по этой модели может быть эффективна только в том случае, если Заказчик весьма детально понимает цели и задачи разрабатываемого продукта, а также способен их сформулировать.
- Последующие же этапы более просты, поскольку их выполнение будет осуществляться в регламенте ранее утверждённого плана задач.
- Каскадная модель проста и понятна, но не так практична как раньше.
- Лучше всего подходит для длительных, долгоживущих проектов, в которых очень важен ранний запуск и постоянное усовершенствование (например, стартапы).
- Если кто-то зафакапил, переделывается один участок, что дешевле и быстрее.
- На выходе разработчики уже представляют, сколько по времени и кадровому составу может занять проект.
Но если заглянуть в оригинальный документ за авторством Ройса, выяснится, что он вполне предполагал возврат на предыдущие этапы для той же корректировки. Вопреки расхожему мнению, методология «водопад» подходит не только для проектов малой ответственности или несложной структуры. Определяющим фактором в данной ситуации являются чёткие исходные требования к конечному результату.