Что понимается под методом водопада waterfall
Agile или Waterfall — какой вариант соответствует вашему бизнесу?
Противостояние Agile и Waterfall не столько теоретическое, сколько практическое. Выбор методики, не подходящей под ваш проект, в лучшем случае существенно затормозит его развитие, в худшем — отправит в список «ТОП-провалов года».
Гибкая и каскадная модели разработки проекта (Agile и Waterfall соответственно) — одни из наиболее популярных среди прочих методологий управления. Изучив особенности конкретно вашего проекта, и вооружившись знаниями из этой статьи, вы сможете с полной уверенностью ответить на вопрос: «Что подойдёт моему бизнесу — Agile или Waterfall?»
Agile — система идей и принципов «гибкого» управления проектами, на основе которых разработаны популярные методы Scrum, Kanban и другие. Ключевой принцип — разработка через короткие итерации (циклы), в конце каждого из которых заказчик (пользователь) получает рабочий код или продукт.
Waterfall — методика управления проектами, которая подразумевает последовательный переход с одного этапа на другой без пропусков и возвращений на предыдущие стадии.
Что такое Agile
Как и другие популярные методологии разработки и управления проектами, Agile появился сравнительно недавно в США. В отличии от CPM и CCPM, за появление гибкой методологии разработки ответственна сразу целая группа людей — 17 американских IT-специалистов из штата Юта. Вместе с «Манифестом гибкой разработки ПО», в котором впервые прозвучал термин «Agile» они прописали 12 принципов Agile-разработки.
Их суть сводится к таким ключевым моментам, определяющим характер гибкой методики разработки:
Scrum — методология гибкой разработки на основе Agile, в основе которого лежит «спринт» — отрезок от 1 до 4 недель, по окончанию которого должна быть получена рабочая версия продукта.
Lean — метод, который вырос на основе системы управления производством Toyota Production System. В его основе — философия постоянного совершенствования на всех уровнях организации, где одно из ключевых понятий — ценность (то, за что готов платить заказчик).
Экстремальное программирование (XP) — одна из Agile-методик, где важная роль отводится периодической игре в планирование с привлечением заказчика. Она позволяет определить недостатки предыдущей итерации, приоритетность задач, желаемую функциональность продукта с учётом пожеланий заказчика.
Преимущества и недостатки метода Agile
К преимуществам метода относятся:
Не избежала методология и недостатков, которые органично «дополняют» её достоинства:
Что такое Waterfall
Методика Waterfall (водопадная система разработки) — детище Винстона Уолкера Ройса, директора Lockheed Software Technology Center в Остине (штат Техас, США), пионера в области разработки программного обеспечения.
Водопадная модель разработки подразумевает последовательное прохождение процесса, разбитого на стадии. Переход к новому этапу возможен только после завершения предыдущего.
В оригинальной работе Уолкера «Managing the development of large software systems» описаны 6 стадий разработки продукта, которые в 1985 году Департамент защиты США закрепил в стандартах работы с разработчиками программного обеспечения:
Преимущества и недостатки Waterfall
В число наибольших преимуществ методики Waterfall вошли:
Среди недостатков водопадного метода можно выделить:
Частично недостатки водопадной модели разработки исправлены в модификациях Waterfall: Сашими, Waterfall с субпроектами и водопадная модель разработки с снижением риска.
Сашими или водопадная модель с наслаивающимися фазами — cамая известная среди них. В ней этапы как и в оригинальной методике идут друг за другом, но при этом перекрываются одна другой во времени.
Waterfall с субпроектами — модель, в которой вы работаете с трёмя крупными блоками: концептуализацию, проектирование требований и архитектурная структура продукта. Затем для каждого из них вы проходите стадии (субпроекты) детального проектирования, кодирования и тестирования. В конце проводится интеграция всех компонентов на этапе тестирования системы.
Водопадная модель разработки с снижением риска — модификация классического Waterfall, в который добавлены спирали снижения риска, которые разделяют проект на мини-проекты и корреспондируют их одному или нескольким ключевым рискам.
Сравнительная таблица
Гибкая модель разработки, основанная на
итеративных принципах
Каскадная система разработки, основанная на жёсткой последовательности процесса разработки
1956 г., 1961 г., 1970 г.
Группа IT-специалистов (США)
Г. Беннингтон, Хозьер, В. Уолкер Ройс
Unilever, ряд банков (Альфа Банк, Home Credit, Райффайзен Банк и т.д.)
Cisco Ericsson AB, Toyota (до 2010)
Что такое Waterfall и чем он отличается от Agile
Что такое Waterfall и чем он отличается от Agile
Старший маркетолог ООО «Диалог Информационные Технологии»
Специалист-консультант ООО «Диалог ИТ»
Что такое водопадный подход
Водопадная или каскадная модель разработки программного обеспечения (waterfall, водопад) – это процесс разработки, в котором последовательно идут фазы сбора и анализа требований, проектирования и прототипирования, реализации, тестирования, интеграции и поддержки. Линейный подход к разработке программного обеспечения состоит из нескольких этапов:
В водопадном проекте каждый из этих этапов представляет собой отдельный, не связный с другими, период работы, и, как правило, каждый этап завершается до начала следующего. Часто между разными стадиями разработки есть «пропускной пункт», когда заказчик рассматривает и оценивает промежуточные результаты работы. Вот несколько важных плюсов такого подхода:
Минусы Waterfall
Но ни одна методология не обойдется без минусов, и в водопадном подходе есть, по меньшей мере, два существенных:
Некоторые из недостатков водопадной модели попытались исправить в одной из ее модификаций: Sashimi Waterfall (Сашими). В ней этапы, как и в оригинальной методике, идут друг за другом, но при этом перекрываются один другим во времени. Это позволяет начать разработку дизайна еще на этапе сбора информации, а значит, добавляет так сильно недостающую гибкость в процесс. Затраты при этом растут не сильно, а сама методология не превращается в Agile.
Waterfall или Agile: какой подход выбрать?
Возможно, перед менеджерами подразделений будет стоять вопрос, какая из методологий более предпочтительна при разработке IT продуктов. Данная таблица поможет расставить все на места.
Доступность для заказчика
Заказчик дает комментарии по ходу разработки
Присутствие заказчика необходимо в начале и в конце разработки
В любой из методологий вовлеченность заказчика уменьшает риски
Изменения по ходу разработки приветствуются, но требуют дополнительных затрат ресурсов и времени. Хорошо подходит для случаев, когда концепция финального продукта до конца не ясна
Хорошо подходит, когда концепция определена с самого начала, либо с заранее установленными ограничениями по времени и смете расходов
Перемен чаще всего не избежать, поэтому стоит прибегать к гибкости, если это возможно. Строгие условия контракта не позволяют этого достичь.
«Приоритет ценности» обеспечивает разработку самых нужных функций до всех остальных, что уменьшает риски получения нестабильного продукта, как только финансирование закончится. Эффективность финансирования максимальна. Уменьшает риск полного провала, так как возможен «частичный успех»
Необходимо выполнить все, что обговаривалось вначале. Такой подход позволяет клиенту получить именно тот продукт, который был запланирован. Подход «все или ничего» увеличивает риск провала
В условиях контрактов может быть отдельно прописано, что «частичный успех» неприменим
Предпочтительней небольшая, обособленная команда с высоким уровнем организованности и слаженности
Координация и слаженность команды ограничена точками передачи ответственности (при переходе с этапа на этап)
Лучше работать сообща, но, если задания выполняются разными командами, то слаженность не является ключевой характеристикой
Отлично работает в случаях, когда деньги и время не имеют жестких ограничений, но работа ухудшается при появлении рамок
Уменьшает риски при наличии фиксированной цены, так как договоренности установлены заранее
При отсутствии финальной концепции продукта, ограничения финансирования могут помешать команде закончить работу
За отсутствием ограничений – Agile более предпочтителен
Плановая работа обеспечивает более низкие риски в случаях, когда контракты заключаются с внешними заказчиками, например при работе с государственными компаниями
Каждый из перечисленных факторов не равнозначен, все определяется в зависимости от проектов и обстоятельств
Бессмертная классика Waterfall
Среди вопросов, неизбежно возникающих в каждом проекте, выделяется один: как целесообразнее управлять процессом разработки продукта? Один из вариантов ответа проверенных годами — Waterfall (или каскадная, водопадная модель управления разработкой ПО).
Правда, сейчас эта методика нещадно критикуется, но так ли все плохо на самом деле или мы в очередной раз придем к тому, что все новое — хорошо забытое старое?
Жизненный цикл разработки программного обеспечения
Практически каждая команда разработчиков может создавать свою модель жизненного цикла ПО или использовать что-то общепризнанное. Один из вариантов — Waterfall. «Родителем» такой модели считается американец В. У. Ройс, который, по слухам, многое позаимствовал у коллег, присвоив себе лавры. Случилось это в 1970 году. До сегодняшнего дня во многих проектах используется описанный им подход: в первоначальном варианте или с доработками.
Хотя некоторые участники IT говорят о том, что такой методологии «отродясь-то не бывало»:
Как IT-профессионал и преподаватель я в течение более чем 40 лет слышал много мифов об IT-индустрии. Но что продолжает удивлять меня, так это то, почему слово «Waterfall» до сих пор используется для описания методологии, которая не существует и почему создатели методов разработки систем используют его в качестве источника сравнения.
David Dischave,
профессор школы информационных технологий университета Сиракузы, США
Удивительно слышать такое о методологии, которая не один десяток лет используется в создании ПО для самых разных сфер деятельности, в том числе для автомобилестроения, строительства зданий и сооружений, финансового сектора, медицины и электроники.
Waterfall в сфере IT
Основной постулат Waterfall модели разработки ПО заключается в том, что следующий этап не может быть начат, пока не завершен предыдущий. При этом произвольные переходы вперед или назад не допускаются, а этапы не перекрывают друг друга. В этом и заключается основное отличие каскадной методологии от гибких собратьев (или конкурентов): Agile, DSDM, Scrum, FDD.
Чтобы понять мысли Ройса, заложенные в основу модели, можно изучить его труд в оригинале: Royce, Winston (1970), Managing the Development of Large Software Systems.
Процесс работы, основанный на каскаде
Возникновение идеи и ее обсуждение
На этом этапе о разработке как таковой речи не идет, просто рассматривается некая появившаяся идея, интересная одному или нескольким людям.
Анализ требований
Этап, на котором требования заказчика к проекту описываются в мельчайших деталях, также решается, какими способами будет достигнута цель, обозначаются сроки завершения работ и финансовая составляющая. При этом обычно закладывается некий запас времени и денег для каждого звена работы.
По окончании анализа требований в наличии имеется ТЗ для программистов и бюджет.
Проектирование программного обеспечения
На этом этапе делаются конкретные шаги:
Разработка программного обеспечения
Этап, на котором пишется код, соответствующий документации, разработанной ранее.
Тестирование программного обеспечения
Готовая версия продукта тестируется специалистами в условиях, приближенных к боевым, выявляются и фиксируются баги. Наиболее катастрофичные для работы ПО в целом — исправляются, менее критичные — могут быть не исправлены, если нет времени или исчерпан бюджет.
Техническая поддержка программного обеспечения
Пригодный к работе программный продукт начинают использовать по назначению и осуществлять его поддержку. То есть: следить за работоспособностью, устранять сбои в работе, планировать расширение функционала на основе фидбека от пользователей.
Все перечисленные выше этапы выполняются строго последовательно, полученные результаты документируются.
Чтобы понять эволюцию классической водопадной методологии, описанной выше, можно изучить PMBOK. Между 3-ей и 4-й версиями есть ряд различий, которые помогут понять путь «каскада«.
Плюсы и минусы каскадной модели разработки программного обеспечения
Ничего идеального в нашем мире, к сожалению, не существует, потому у каскадной методологии тоже есть сильные и слабые стороны.
Сильные стороны каскадной модели разработки ПО
Слабые стороны каскадной модели
разработки ПО
Как и когда использовать каскадную модель разработки?
Как показывает практика, Waterfall модель разработки ПО вполне уместна в следующих случаях:
Для понимания же мотивации отказа от каскадной методологии можно прочесть книгу «Scrum. Революционный метод управления проектами» Джеффа Сазерленда.
Примеры использования Waterfall
Каскадная модель в чистом виде в современной разработке не так уж распространена и, зачастую, то, что не подходит под определение Agile, нарекают Waterfall, поэтому достаточно сложно определить, где используется именно эта методология.
Понимание особенностей работы с такими проектами улучшает книга Сергея Зыкова «Основы проектирования корпоративных систем».
И это логично. Об этом говорит и Чак Кобб, автор книг, посвященных Аgile-методам в проектном менеджменте, наставник, инструктор:
Если бы вы строили мост через реку, было бы смешно сказать: «Мы построим первый пролет, посмотрим, как это выходит, а затем решим, как закончить оставшиеся пролеты!
Среди компаний, в которых использовали или используют Waterfall можно отметить:
Для чего использовалась модель Waterfall
Используется ли сейчас методология
Комментарий представителя компании
Wüstenrot & Württembergische (W&W)
Разработка ERP-системы для финансового сектора
Что понимается под методом водопада waterfall
Waterfall, или каскадная модель, ― это классика в мире разработки продуктов. Она существует уже больше полувека. За это время она доказала свою эффективность, но обзавелась мощными конкурентами. Главный из них ― гибкий Agile, которым активно пытаются заменить последовательный каскад. Пора ли отказаться от водопада или классика никогда не устареет? Разбираемся в плюсах и минусах Waterfall и говорим о проектах, в которых водопаду до сих пор нет равных.
Что такое Waterfall и кто его придумал
Waterfall (каскад или водопад) — классическая модель разработки продуктов. Американский ученый-информатик Уинстон Уокер Ройс придумал и описал ее еще в 1970 году, а в 1976 году ученые Томас Белл и Томас Тэйер дали ей название. Сначала Waterfall использовали в создании любого программного обеспечения, но потом появилась модель Agile и водопад засох. Теперь каскадную модель применяют в авиастроении, военной или космической отраслях, медицине и финансовом секторе. Там Waterfall самое место, потому что этим сферам нужны четко выстроенные процессы и сроки, а это суть каскада. Отсюда и сравнение с водопадом: каждый этап создания продукта, словно поток воды, продолжает предыдущий и не может начаться, пока прошлый не завершился.
Из каких этапов состоит Waterfall
Уокер Ройс придумал циклы водопада 50 лет назад, и с тех пор они не меняются. Кроме того, этапы создания проекта всегда идут в одинаковой последовательности и пропускать какой-то из них нельзя.
Основной инструмент водопада
Последовательность процессов, соблюдение сроков, выполнение задач в каскадной модели лучше всего отображает диаграмма Ганта (a Gantt Chart) или горизонтальная гистограмма. Она состоит из блоков, расположенных на двух осях. По горизонтали — задачи, по вертикали — время, затраченное на их выполнение. На диаграмме можно проследить, какие задачи входят в проект и кто за них отвечает, а также продолжительность каждого этапа.
Допустим, вы строите быстровозводимый дом ― дачу в Подмосковье, чтобы выбираться туда на лето. Времени мало, максимальный бюджет — три миллиона рублей. Земля в вашей собственности, все документы в порядке. Срок строительства двухэтажного коттеджа, как сообщает застройщик, — от 25 дней. Все этапы известны и определены, а материалы закуплены.
Для начала перечислим каждый этап, затем дату начала и завершения. Первые две задачи офисные специалисты делают только в рабочие дни, далее работа переходит к строительной бригаде, которая трудится каждый день. Срок проекта — 28 дней. Чтобы показать весь проект на нашей диаграмме, представим, что этап поддержки длится неделю. В жизни срок обнаружения ненадлежащего качества работ гораздо больше.
Затем построим диаграмму Ганта. Мы использовали smartsheet, но это можно делать в Excel или просто на бумаге.
По горизонтали перечисляем этапы строительства, по вертикали указываем начало и конец каждого. Теперь диаграмма иллюстрирует принцип Waterfall: этапы идут один за другим, следующий начинается только тогда, когда заканчивается предыдущий. Это логично: невозможно возвести хороший фундамент и покрыть крышу без инженерно-исследовательских работ и четкого плана дома. Мы также видим, из каких этапов состоит проект, какие задачи входят в каждый этап и сколько времени они занимают.
Плюсы и минусы Waterfall
Чек-лист, который подскажет, подойдет ли Waterfall вашему проекту
Подсказка. Вам точно подойдет каскадная модель, если вы делаете строительный проект, работает в авиастроении, медицине, финансовом секторе, военной или космической отрасли. Откажитесь от водопада в пользу Agile, если проект создается для стартапа или IT-компании.
Где искать дополнительную информацию по теме
Почитать
Посмотреть
Хотите научиться справляться со сложными вызовами современного бизнеса? Освойте самые эффективные методы на комплексной программе «Профессия бизнес-аналитика»! Вас прокачают эксперты-практики из McKinsey & Company, EY, «Газпрома», Unilever, KPMG и не только. Уже через полгода вы сможете начать карьеру в топовой компании. Регистрируйтесь!
Waterfall — итеративная методология разработки
Недавно открыл для себя интересный факт, что товарищ Винстон Ройс (Dr. Winston D. Royce), анонсируя свой знаменитый Waterfall говорил об итеративной модели разработки.
Наверняка, все, кто хоть как-то связаны с разработкой/тестированием ПО, знают о каскадной модели и об ее особенностях:
— высокий уровень формализации процессов;
— большое количество документации;
— и конечно же, жесткая последовательность этапов жизненного цикла без возможности возврата на предыдущий этап.
Ознакомившись с выдержкой из трудов Ройса, оказалось, что он предусматривал обратные связи между этапами на одном уровне (к примеру, дизайн-кодирование, кодирование-тестирование и т.д.).
Насколько я понимаю разницу, во втором варианте, в отличии от первого, речь идет о параллельных работах по двум последовательным этапам, что дает возможность на более ранних стадиях выявить ошибки предыдущего этапа жизненного цикла и решает один из весомых недостатков «классического» водопада — невозможность возврата на предыдущий этап.
К примеру, если рассмотреть параллельные работы по 2 последовательным фазам — Coding и Testing, становится очевидным, что часть программы выдается в тестирование, в то время как другая часть все еще находится на стадии разработки.
Т.е. получается, что речь действительно идет об итеративной методологии разработки ПО.
В таком случае остается вопросом, почему методология в широких кругах разработчиков и тестировщиков воспринимается ошибочно, как отображено на первом рисунке…