Вотерфолл что это такое

Что такое Waterfall и чем он отличается от Agile

Что такое Waterfall и чем он отличается от Agile

Старший маркетолог ООО «Диалог Информационные Технологии»

Специалист-консультант ООО «Диалог ИТ»

Что такое водопадный подход

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

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

Минусы Waterfall

Но ни одна методология не обойдется без минусов, и в водопадном подходе есть, по меньшей мере, два существенных:

Некоторые из недостатков водопадной модели попытались исправить в одной из ее модификаций: Sashimi Waterfall (Сашими). В ней этапы, как и в оригинальной методике, идут друг за другом, но при этом перекрываются один другим во времени. Это позволяет начать разработку дизайна еще на этапе сбора информации, а значит, добавляет так сильно недостающую гибкость в процесс. Затраты при этом растут не сильно, а сама методология не превращается в Agile.

Waterfall или Agile: какой подход выбрать?

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

Доступность для заказчика

Заказчик дает комментарии по ходу разработки

Присутствие заказчика необходимо в начале и в конце разработки

В любой из методологий вовлеченность заказчика уменьшает риски

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

Хорошо подходит, когда концепция определена с самого начала, либо с заранее установленными ограничениями по времени и смете расходов

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

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

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

В условиях контрактов может быть отдельно прописано, что «частичный успех» неприменим

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

Координация и слаженность команды ограничена точками передачи ответственности (при переходе с этапа на этап)

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

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

Уменьшает риски при наличии фиксированной цены, так как договоренности установлены заранее

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

За отсутствием ограничений – Agile более предпочтителен

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

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

Источник

Методология разработки 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 такое бывает редко, поэтому команды добавляют к каскадной модели гибкие практики: например, проверяют продукт на соответствие требованиям после каждого этапа работы, а не в самом конце.

Источник

Не только Agile: как устроена модель 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 и не только. Уже через полгода вы сможете начать карьеру в топовой компании. Регистрируйтесь!

Получите карьерную поддержку

Если вы не знаете, с чего начать карьеру, зашли в тупик или считаете, что совершили какие-то ошибки, спросите совета у специалистов. Заполните заявку и консультанты Changellenge >> окажут вам помощь. Это отличный шанс вместе экспертом проработать проблемные вопросы и составить карьерный план.

Подписаться на карьерную рассылку

Подписывайтесь на рассылку и получайте карьерные советы — от выбора индустрии и компании до лайфхаков по самоорганизации и развитию коммуникативных навыков.

Источник

Методологии управления проектами: водопад, эджайл

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

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

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

В жизни я использовал и использую две, самые популярные методологии – Waterfall (“водопад”/“каскадная”) и Agile (и его ответвление – Scrum), о них и пойдет речь. Ради расширения кругозора читателя расскажу и о других известных мне вещах. Если читатель работает с диджитал, то “водопада” и “эджайла” хватит за глаза – можно будет использовать их в работе, жизни, рассказывать знакомым и незнакомым людям, на митапах, с умным видом попивая смузи.

Само собой, ничто ниоткуда не берется, и Петр Первый ничего не слышал про эджайл. Методологии придумываются всякими разными организациями и ассоциациями, где умные дядьки собирают свои проблемы в кучи, затем понимают, как их можно было избежать, и делятся после решениями с такими обывателями как я, например. Иногда продумывание методологий происходит на государственном уровне – там тоже решают проблемы и собирают best practices (в приличном обществе так не выражайся) в книги и руководства.

Речь сегодня пойдет в основном об этих двух зверятах. После прочтения этого раздела можешь смело идти и требовать себе самое классное место менеджера проектов в самой крупной подходящей организации города.

Водопад, каскадная методология – традиционная, самая популярная и логичная методология управления проектами. В чистом виде может сработать совсем в простых проектах. Допустим, тебе потребовалось посадить дерево. “По водопаду” выполнение проекта выглядит так:

Каждый этап в таком проекте идет следом за предыдущим и не может быть выполнен раньше предыдущего – это и есть “водопад”. Еще это пересекается с “методом критического пути”, но о нем расскажу в отдельной статье – напомни мне.

Я работаю с проектами в сфере разработки сайтов и мобильных приложений. Этапы разработки таких проектов по водопаду примерно одинаковы:

Чтобы двигаться по водопаду, нужно иметь четкое техническое задание и понимание шагов, следующих друг за другом. Из практики скажу, что работать по чистому водопаду нереально – обязательно где-то выясняется, что что-то упустили, где-то нужно откатиться на предыдущий этап и делать это параллельно с текущим этапом. Тем не менее, чем четче техническое задание, тем меньше шансов на то, что проект уйдет в сторону. Для проектов, где “уход в сторону” приемлем, есть Agile.

“Эджайл” (или “агиль”, или “а жаль” – много у него прикольных названий) относится к типу гибкой методологии. Главное его отличие от водопада – рабочий продукт на каждом этапе работы и неясный финал проекта. В примере с тем же деревом, где каждый этап последователен, этот эджайл не покатит: ну купил ты саженец, а толку? У эджайла достаточно широкая область применения, однако более всего он прижился в IT. А его виды и подтипы толстой пленкой накрыли прилегающие сферы – бизнес-планирование, продуктовый менеджмент и так далее, и тому подобное.

Для примера работы “по агилю” представим проект посложнее. Пусть это будет проект из строительства. Задача: построить дом, где можно жить.

Этапы производства (представим, что каждый этап занимает ровно спринт):

Пусть в состоянии MVP (минимальный жизнеспособный продукт), но этим домом можно будет пользоваться примерно после первого этапа – не очень комфортно, но можно. Также “по эджайлу” этапы могут не следовать друг за другом, а идти параллельно или в разном порядке. Ключевой момент: на каждом этапе реализации продукта продуктом можно пользоваться.

Чтобы фиксировать этапы, умные дядьки придумали спринты, каждый из которого содержит набор операций и сроки (чаще равные) их реализации и планируются непосредственно перед спринтом. Задачи, прилетающие в процессе спринта складываются в бэклог – корзинку с тем, что при следующем планировании спринта кто-то будет разгребать. Ну и еще одна особенность эджайла: у проекта может не быть технического задания – вот думали вы строить одноэтажный таунхаус, а в процессе решили, что для вас окей построить шестиэтажный особняк и вы вот его строите, гибко меняя планы в процессе производства.

Agile используют в IT (“диджитале”) – лучше всего он живет в стартапах, когда финальный проект не ясен, нужно проверять гипотезы и делать это быстро и гибко. Эджайл удобно использовать в проектах стороннего клиента (не из компании), когда финал проекта не ясен и у клиента тысяча тысяч идей по ходу разработки. В таком случае определяешь, сколько времени команды в неделю можешь выделить, считаешь стоимость этого времени и выставляешь счета в финале каждого спринта.

Если ты работаешь со внешними клиентами, эджайл гораздо удобнее водопада в любых проектах – ты же знаешь, сколько комментариев клиент может выдать на каждом этапе проекта и как сложно объяснить клиенту, что его комментарии превышают заложенное время на разработку, а значит и бюджет проекта. Доплачивать-то он вряд ли будет – есть же смета, и ты вроде как профессионал, должен был сразу понять, что ему вообще нужно. Эджайл работает с понимающими клиентами, остальным будет крайне сложно объяснить, почему это окей.

Еще одна особенность методологии: в ней нет как такового менеджера проекта. Есть владелец продукта, скрам-мастер (в Scrum), члены команды. То есть, менеджер здесь выступает в роли владельца продукта и делает примерно то же самое, что делает при любой другой методологии. Внутри любой проектной команды продакт-оунером выступает менеджер проекта – он заказывает продукт у команды, а не тот человек, который брифует менеджера.

В одно семейство с эджайлом (“гибкие методологии”) входят Scrum, XP и Lean – хипстерские вещи из мира стартапов – читайте интернеты.

Никакая методология не панацея. Ближайшую аналогию могу провести с чеклистами – это такая классная штука (читай статью на моем медиуме @salakhmir), которая люто помогает в работе, но, почему-то, работает не у всех. Любой инструмент – всего лишь инструмент, и сам по себе работать не будет. Представь, что лопату положили на землю и ждут, когда что-то произойдет – так и тут, чтобы что-то сделалось, нужно что-то сделать.

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

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

Project Management Institute – наш друг. Питаю к этой организации особую привязанность – у них мощная комьюнити и хорошая база. Организация базируется в США, существует с 1969 года, а их стандарты управления проектами признаются ANSI.

Основной продукт PMI – свод знаний по управлению проектами PMBoK, осенью 2017 года вышла шестая часть. Свод знаний содержит канвы выполнения проектами в мелочах – от сбора требований стейкхолдеров до закрытия проекта. Рекомендую хотя бы ознакомиться с книгой – в ней же можно почитать и про ватерфолл с эджайлом, и про метод критического пути и метод быстрого прохода – темы одной из будущих моих статей.

Дополнительно к PMBoK у PMI есть такие основные вещи: стандарты управления портфелями (проектов) и программой, стандарты управления рисками и Scrum Guide. PMBoK – не IT-книга, методики из свода применимы фактически ко всем проектам (для некоторых типов есть отдельные расширения) – маст хэв, в общем.

У PMI куча куч видов сертификаций, со ступенями и наворотами. Сертификаты PMI известны и популярны. Например, PMP – профессионал управления проектами – типа подтверждает, что ты можешь руководить проектами. Получить сертификаты организации не имея опыта нельзя, потому они больше как подтверждение, нежели как этот твой университетский диплом, который ты получил, пока учился учиться.

Международная Ассоциация Управления Проектами – такая же организация, как PMI, только европейская (Швейцария), и о ней меньше слышно. Работает с 1965 года, и изначально называлась Internet (когда интернета в помине не было).

Что они там делают – понятно мало. Ну, сертифицируют менеджеров. Выпускают свои журналы – сами и под представительствами. Зарабатывают деньги. И слава Б-гу.

“Принц” (PRojects IN Controlled Environments). Появилась методология в 1989 году, в Великобритании (и тут отделились). Ключевой особенностью методологии является польза, которую принесут процессы внутри проекта проекту. Минимизация рисков, соблюдение качества проекта. Еще у проектов PRINCE2 сложная организационная структура с комитетом проекта. В остальном, такие проекты, как проекты по другим методологиям, имеют старт, этапы и завершения – все знакомо и привычно.

«A Guidebook of Project and Program Management for Enterprise Innovation». Японская методология управления проектами – на этот раз свежее, она 1999 года. Тентаклями тут является акцент на инновации и управление ожиданиями заинтересованных лиц. Близко не сталкивался, не изучал, оценки дать не могу.

“Частная” методология управления проектами, MSF, была придумана и введена в работу в 1994 году майкрософтом. Она особенна тем, что разрабатывалась непосредственно под разработку программного обеспечения, а не адаптировалась, что можно сказать о том же PMBoK. Внешне похожа на список внутренних рекомендаций (типа как у вас в интре) для менеджеров проектов. В чистом виде не используется даже Microsoft – добавляют тот же эджайл, например. В википедии есть познавательная статья об этом фреймворке, прошу пройти туда – там больше, чем могу рассказать я.

Ничто не панацея, но понимать принципы и брать из них лучшее можно и нужно. Пока писал статью, краем глаза наткнулся на статью о Стаханове – был такой чувак при Советах, его еще в советской пропаганде продуктивности использовали. Он тоже работал по методологии (уголь добывал), но однажды понял, что если чуток переставить людей и пустить некоторые процессы параллельно, можно работать лучше. Вот и заработал себе страницу в википедии. Так и здесь – тестируй, применяй и дорабатывай (потом делись). Все, с чем ты сталкиваешься, все советы – гипотеза, которую нужно проверить. Enjoy it!

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

Источник