Что такое 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)

Источник

Ещё раз про семь основных методологий разработки

Разработка программного продукта знает много достойных методологий — иначе говоря, устоявшихся best practices. Выбор зависит от специфики проекта, системы бюджетирования, субъективных предпочтений и даже темперамента руководителя. В статье описаны методологии, с которыми мы регулярно сталкиваемся в Эдисоне.

1. «Waterfall Model» (каскадная модель или «водопад»)

Одна из самых старых, подразумевает последовательное прохождение стадий, каждая из которых должна завершиться полностью до начала следующей. В модели Waterfall легко управлять проектом. Благодаря её жесткости, разработка проходит быстро, стоимость и срок заранее определены. Но это палка о двух концах. Каскадная модель будет давать отличный результат только в проектах с четко и заранее определенными требованиями и способами их реализации. Нет возможности сделать шаг назад, тестирование начинается только после того, как разработка завершена или почти завершена. Продукты, разработанные по данной модели без обоснованного ее выбора, могут иметь недочеты (список требований нельзя скорректировать в любой момент), о которых становится известно лишь в конце из-за строгой последовательности действий. Стоимость внесения изменений высока, так как для ее инициализации приходится ждать завершения всего проекта. Тем не менее, фиксированная стоимость часто перевешивает минусы подхода. Исправление осознанных в процессе создания недостатков возможно, и, по нашему опыту, требует от одного до трех дополнительных соглашений к контракту с небольшим ТЗ.

С помощью каскадной модели мы создали множество проектов «с нуля», включая разработку только ТЗ. Проекты, о которых написано на Хабре: средний — рентгеновский микротомограф, мелкий — автообновление службы Windows на AWS.

Когда использовать каскадную методологию?

2. «V-Model»

Унаследовала структуру «шаг за шагом» от каскадной модели. V-образная модель применима к системам, которым особенно важно бесперебойное функционирование. Например, прикладные программы в клиниках для наблюдения за пациентами, интегрированное ПО для механизмов управления аварийными подушками безопасности в транспортных средствах и так далее. Особенностью модели можно считать то, что она направлена на тщательную проверку и тестирование продукта, находящегося уже на первоначальных стадиях проектирования. Стадия тестирования проводится одновременно с соответствующей стадией разработки, например, во время кодирования пишутся модульные тесты.

Пример нашей работы на основе V-методологии — мобильное приложение для европейского сотового оператора, который экономит расходы на роуминг во время путешествий. Проект выполняется по четкому ТЗ, но в него включен значительный этап тестирования: удобства интерфейса, функционального, нагрузочного и в том числе интеграционного, которое должно подтверждать, что несколько компонентов от различных производителей вместе работают стабильно, невозможна кража денег и кредитов.

Когда использовать V-модель?

3. «Incremental Model» (инкрементная модель)

В инкрементной модели полные требования к системе делятся на различные сборки. Терминология часто используется для описания поэтапной сборки ПО. Имеют место несколько циклов разработки, и вместе они составляют жизненный цикл «мульти-водопад». Цикл разделен на более мелкие легко создаваемые модули. Каждый модуль проходит через фазы определения требований, проектирования, кодирования, внедрения и тестирования. Процедура разработки по инкрементной модели предполагает выпуск на первом большом этапе продукта в базовой функциональности, а затем уже последовательное добавление новых функций, так называемых «инкрементов». Процесс продолжается до тех пор, пока не будет создана полная система.

Инкрементные модели используются там, где отдельные запросы на изменение ясны, могут быть легко формализованы и реализованы. В наших проектах мы применяли ее для создания читалки DefView, а следом и сети электронных библиотек Vivaldi.

Как пример опишем cуть одного инкремента. Сеть электронных библиотек Vivaldi пришла на смену DefView. DefView подключалась к одному серверу документов, а теперь может подключаться ко многим. На площадку учреждения, желающего транслировать свой контент определенной аудитории, устанавливается сервер хранения, который напрямую обращается к документам и преобразует их в нужный формат. Появился корневой элемент архитектуры — центральный сервер Vivaldi, выступающий в роли единой поисковой системы по всем серверам хранения, установленным в различных учреждениях.

Когда использовать инкрементную модель?

4. «RAD Model» (rapid application development model или быстрая разработка приложений)

RAD-модель — разновидность инкрементной модели. В RAD-модели компоненты или функции разрабатываются несколькими высококвалифицированными командами параллельно, будто несколько мини-проектов. Временные рамки одного цикла жестко ограничены. Созданные модули затем интегрируются в один рабочий прототип. Синергия позволяет очень быстро предоставить клиенту для обозрения что-то рабочее с целью получения обратной связи и внесения изменений.

Модель быстрой разработки приложений включает следующие фазы:

Может использоваться только при наличии высококвалифицированных и узкоспециализированных архитекторов. Бюджет проекта большой, чтобы оплатить этих специалистов вместе со стоимостью готовых инструментов автоматизированной сборки. RAD-модель может быть выбрана при уверенном знании целевого бизнеса и необходимости срочного производства системы в течение 2-3 месяцев.

5. «Agile Model» (гибкая методология разработки)

В «гибкой» методологии разработки после каждой итерации заказчик может наблюдать результат и понимать, удовлетворяет он его или нет. Это одно из преимуществ гибкой модели. К ее недостаткам относят то, что из-за отсутствия конкретных формулировок результатов сложно оценить трудозатраты и стоимость, требуемые на разработку. Экстремальное программирование (XP) является одним из наиболее известных применений гибкой модели на практике.

В основе такого типа — непродолжительные ежедневные встречи — «Scrum» и регулярно повторяющиеся собрания (раз в неделю, раз в две недели или раз в месяц), которые называются «Sprint». На ежедневных совещаниях участники команды обсуждают:

Когда использовать Agile?

6. «Iterative Model» (итеративная или итерационная модель)

Итерационная модель жизненного цикла не требует для начала полной спецификации требований. Вместо этого, создание начинается с реализации части функционала, становящейся базой для определения дальнейших требований. Этот процесс повторяется. Версия может быть неидеальна, главное, чтобы она работала. Понимая конечную цель, мы стремимся к ней так, чтобы каждый шаг был результативен, а каждая версия — работоспособна.

На диаграмме показана итерационная «разработка» Мона Лизы. Как видно, в первой итерации есть лишь набросок Джоконды, во второй — появляются цвета, а третья итерация добавляет деталей, насыщенности и завершает процесс. В инкрементной же модели функционал продукта наращивается по кусочкам, продукт составляется из частей. В отличие от итерационной модели, каждый кусочек представляет собой целостный элемент.

Примером итерационной разработки может служить распознавание голоса. Первые исследования и подготовка научного аппарата начались давно, в начале — в мыслях, затем — на бумаге. С каждой новой итерацией качество распознавания улучшалось. Тем не менее, идеальное распознавание еще не достигнуто, следовательно, задача еще не решена полностью.

Когда оптимально использовать итеративную модель?

7. «Spiral Model» (спиральная модель)

«Спиральная модель» похожа на инкрементную, но с акцентом на анализ рисков. Она хорошо работает для решения критически важных бизнес-задач, когда неудача несовместима с деятельностью компании, в условиях выпуска новых продуктовых линеек, при необходимости научных исследований и практической апробации.

Спиральная модель предполагает 4 этапа для каждого витка:

Подытожим

На слайде продемонстрированы различия двух наиболее распространенных методологий.

В современной практике модели разработки программного обеспечения многовариантны. Нет единственно верной для всех проектов, стартовых условий и моделей оплаты. Даже столь любимая всеми нами Agile не может применяться повсеместно из-за неготовности некоторых заказчиков или невозможности гибкого финансирования. Методологии частично пересекаются в средствах и отчасти похожи друг на друга. Некоторые другие концепции использовались лишь для пропаганды собственных компиляторов и не привносили в практику ничего нового.

Источник

Agile или Waterfall? Сравнение методологий веб-разработки

При создании нового проекта, заказчик должен определиться не только с выбором подрядчика, но и подходящей методологией разработки проекта. На современном этапе развития технологий, нет универсального подхода в создании проекта, поэтому возникает логичный вопрос: какой подход выбрать и какие «подводные камни» существуют?

Waterfall – это четко запланированный и детализированный подход, где исполнитель придерживается плану. Agile – прямая противоположность, которая предполагает гибкость разработки с возможностью внесения изменений на каждом этапе проекта.

В этой статье постараемся определить, в чем особенности этих двух методологий, назовем положительные и отрицательные стороны, а также разберемся, какой способ реализации подойдет для выбранного вами проекта.

Гибкие методологии строятся на принципе итераций. Создание нового продукта делится на несколько циклов от одной недели до месяца. В зависимости от особенностей проекта, временные рамки оговариваются отдельно. Каждый цикл представляет собой завершенный мини-проект, в котором есть этапы анализа, планирования, тестирования и реализации. В итоге клиент получает продукт, который, при необходимости, корректируется.

Главные принципы Agile:

Наиболее популярные методики Agile:

Scrum – система гибкой разработки проектов, основанная на принципе спринта. От 1 недели до месяца должна быть готова рабочая версия продукта.

Экстремальное программирование (XP) – методика, при которой важно взаимодействие с клиентом на каждом этапе. Благодаря такому подходу, выявляются недостатки предыдущих этапов, определяется необходимый функционал продукта и другие параметры.

Lean – базируется на системе управления производством. Главное отличие – принцип постоянного совершенствования продукта на всех уровнях организации процесса.

Про гибкую модель управления можно сказать, что она универсальна, так как подойдет к любому проекту. Сложность выбора заключается только в ограничениях заказчика по времени и боязнью «дыр» в бюджете. Качество обратной связи при данном подходе поможет прийти к согласованному решению. Выбирая эту модель, заказчик может быть уверен, что его проект будет уникальным, интересным и проверенным до мелочей.

Waterfall (с англ. – «водопад») – предполагает последовательный переход к каждому этапу разработки и невозможностью вернуться на шаг назад. Внести какие-либо изменения будет возможно только после релиза проекта.

Выбирая данную модель для своего проекта, необходимо понимать, что конечный продукт будет иметь недочеты. Предусмотреть все на этапе анализа и планирования просто невозможно, в процессе разработки могут появится новые требования. Однако, в Waterfall сделать правки в течении проекта невозможно также, как и вернуться на шаг назад. Классический подход представляет из себя каскадную модель, которая базируется на последовательном создании проекта, разбитого на циклы.

Выделяют следующие стадии разработки в Waterfall:

Востребованные методики Waterfal:

Сашими – одна из самых популярных моделей Waterfal. Представляет собой наслаивающиеся друг на друга этапы, которые перекрываются по времени.

Waterfall с субпроектами – методика работы с тремя крупными стадиями: разработка концепции, проектирование и структурирование продукта. Каждый из этих блоков имеет свои этапы разработки. По окончании работ в каждой стадии проводится их интеграция.

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

Ключевая особенность Waterfall – невозможность сделать шаг назад или перепрыгнуть через итерацию, переход на следующую стадию возможен только после прекращения всех работ на предыдущей. Изменение функционала или исправление ошибок происходит только после релиза проекта. Работа по каскадной модели четко структурирована, определи точные сроки и конкретная стоимость разработки.

Waterfall подойдет, если:

Что из этого следует?

Каждая из моделей, рассмотренных нами выше, имеет определенный набор характеристик и подходит для реализации проектов разной направленности.

Как Agile, так и Waterfall помогут в создании практически любого продукта. Однако, в первую очередь выбирается та методология, которая может максимально эффективно и качественно реализовать проект. Быть может продукт универсален. Тогда необходимо отталкиваться от параметров, как время, бюджет, квалификация исполнителей и другие важные для вас критерии.

Гибкая модель требует высокого профессионализма от исполнителя и идеально подходит для стартапов и продвинутых нишах. Водопадная модель чаще всего используется в области строительства, инвестиций и т.д.

При выборе той или иной методологии заказчик должен внимательно изучить сильные и слабые стороны подходов, учесть советы специалистов, определить набор требований к проекту. И тогда выбор будет сделать гораздо легче. Некоторые разработчики считают, что в рамках одного проекта можно оптимально совместить Agile и Waterfall.

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

Ну вот какбэ да.
Выбирайте исполнителя, а с методологией уж пусть он сам пределяется. Если вы принципиально не хотите работать по предложенной методологии, а исполнитель не хочет ее менять, возможно, это не ваш исполнитель.

Ну и вопрос о месте работы автора.
Это ж каких размеров должна быть производственная махина, чтобы изменить продукт в процессе вотерфлоу было вот прям невозможно. Не дорого, не долго, не сложно, а вот прям невозможно?

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

** Преимущества Waterfall ** полный бред. Вы работали с реальными проектами?

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

Стоимость и сроки не понятны, они взяты из носа и размазаны по бумаге. По факту сроки и бюджеты всегда нарушаются.

Интуитивно понятная структура работы, как для опытных специалистов, так и для новичков.

Структура работ не понятно, а расписана из ПРЕДПОЛОЖЕНИЙ руководителя проекта или другого руководящего лица. Это мешает контактировать, мешает помогать, все заняты своим делом и не заботятся о благополучии команды.

Детально структурированный план работ и продуманная документация.

Документация, которую никто не читает. План работ, основанный на предположениях.

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

Постфактум в любом случае можно всё это отследить, если фиксировать во время работы.

Задачи, которые ставятся перед командой ясны и не меняются на протяжении всего проекта.

Для команды ясны, но в ходе проекта задачи меняются у заказчика и на выходе получается не жизнеспособный продукт, который не нужен заказчику.

Качество проекта занимает первоочередное место, а потраченное время и бюджет отходят на второй план.

А в Scrum и вообще в Agile продукт на последнем месте да?

С ** недостатками Agile ** тоже не согласен.

Рассчитать конечные затраты практически невозможно – требования могут постоянно меняться в зависимости от особенностей проекта. Сложность заключается в том, что они могут противоречить уже существующей структуре.

Требования могут меняться, но они не должны быть диаметрально противоположными. Требования могут дополняться, да. А чтобы вместо изначально запрошенного сарая, заказчик на выходе не требовал дворец, нужен грамотный Product Owner.

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

Любая задача требует полного погружения и воволеченности, иначе это будет халтура, а не работа.

Возможность частого внесения правок может обернуться риском в бесконечном совершенствовании проекта. Здесь также возможна и обратная сторона – снижение качества продукта.

Опять таки, есть конечные требования, поставленные изначально, а чтобы губу клиент не раскатывал есть договор и Product Owner.

Вообще по Agile в статье много ошибок. Либо автор не до конца разобрался в вопросе, либо просто не смог правильно преподнести информацию.

А вообще советую прочитать книгу Scrum (Джефф Сазерленд). Там всё по полочкам.

Источник

Методология разработки Waterfall: что это, как работает и чем отличается от Agile

Сейчас Waterfall не так часто используют, но без неё никто бы не придумал Agile. Рассказываем для менеджеров проектов и тех, кто хочет ими стать.

Бывает, что в теории методология ясна, а потом дело доходит до внедрения и начинаются вопросы. На курсе «Руководитель digital-проектов» преподаватели Skillbox разбирают инструменты управления на реальных кейсах, чтобы студенты легко и безошибочно применяли их в работе.

Что ещё за Waterfall?

Waterfall — модель «Водопад», водопадная или каскадная разработка продуктов. Она подобно потоку воды направляет команды решать задачи последовательно и строго по изначальному плану. Название появилось в 1970 году в статье Винстона Уолкера Ройса, директора Lockheed Software Technology Center, а структура позаимствована у диаграммы Ганта.

Пишет про управление в Skillbox. Работала координатором проектов в Русском музее, писала для блога агентства
CRM-маркетинга Out of Cloud.

Принципы водопадной модели разработки

Как работает Waterfall

Разработка при использовании каскадной модели — это пять строго последовательных этапов.

Команда собирает требования к будущему продукту. Потом пишет подробное техническое задание, планирует график работ и возможные риски. Переходит к следующему этапу, только когда все требования прописаны и есть план. А в плане — инструкции, что и когда делать.

Команда создаёт прототип и готовит дизайн-макеты. Когда это готово, подключаются разработчики.

На этом этапе пишут код продукта согласно плану, макетам и требованиям. Ни шагу в сторону, всё четко по ТЗ.

Код готов, начинается тестирование. Тут могут появиться проблемы. Например, команда обнаружит серьёзные ошибки в коде и потратит много времени, чтобы их исправить. Это главный минус каскадной модели разработки.

Эксплуатация и поддержка

Проект передают заказчику и следят заранее определённое время, чтобы всё работало.

Как отличить Waterfall от гибких методологий

Классическая методология Waterfall — это работа по заранее написанному и согласованному ТЗ. Гибкость здесь не приветствуется. В этом основное отличие водопадной модели от Agile.

Waterfall отличается от Agile и самими принципами работы, о которых мы говорили выше.

12 принципов Agile

Эти принципы появились из agile-манифеста.

Манифест гибкой разработки ПО

Если бы для Waterfall тоже написали манифест, он бы выглядел так:

Манифест водопадной модели разработки ПО

Чем Waterfall отличается от Scrum

Фреймворк Scrum — это часть Agile, поэтому он тоже отличается от водопадной модели разработки. В этой таблице мы собрали их основные отличия.

Если хотите разобраться подробнее:

Заключение

Waterfall — это методология, где всё изначально продумано и зафиксировано, и в этом есть свои плюсы. Бывают проекты, которым она подходит, — такие, в которых все требования известны заранее и не могут измениться по ходу работы и где нет риска ошибиться.

В Digital такое бывает редко, поэтому команды добавляют к каскадной модели гибкие практики: например, проверяют продукт на соответствие требованиям после каждого этапа работы, а не в самом конце.

Источник