Когда использовать Waterfall, когда использовать Scrum?

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

Тогда было бы лучше обсудить тяжелые формальные подходы в сравнении с легкими гибкими подходами, а не водопад в сравнении со скрамом, поскольку это всего лишь частные случаи.

Вы можете захотеть использовать формальные подходы, когда:

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

• Вы работаете по контрактам с фиксированным объемом и фиксированной ценой, и клиент не ожидает (по каким-либо причинам) быстрого изменения объема.

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

Вы должны рассмотреть гибкий подход, когда:

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

• Вы работаете над проектом, объем которого быстро меняется (по какой-либо причине), и вы склонны принимать этот факт.

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

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

В качестве последнего совета: лучше использовать потенциально худшие методы (где худший означает тот, который не очень хорошо подходит для вашей конкретной среды проекта), но использовать его хорошо, чем использовать потенциально лучшие методы, но испортить их реализацию. См.: Хороший водопад лучше плохого аджайла

Используйте Agile (Scrum, XP, Kanban), когда:

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

Используйте Водопад, когда:

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

Отличный пост Дина Леффингуэлла на ту же тему — ПРОЙДИТЕ ВИКТОРИНУ — Выбор Agile против Waterfall «Проекты»: викторина из десяти пунктов.

Вы не должны использовать водопад ни для чего, кроме самых простых проектов, которые эффективно исключают около 90% всех программных проектов. Почему? Потому что программные проекты сложны по трем параметрам: требования, технологии и люди.

Чтобы проиллюстрировать это, это график Стейси, разработанный Ральфом Стейси из Университета Хартфордшира в 1980-х годах — он изучал сложность и человеческое поведение в организациях и предприятиях, а также то, как адаптировать методы управления, чтобы противодействовать их последствиям. Я адаптировал его на основе графика, который Кен Швабер использует в своих книгах и курсах по Scrum:

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

Однако типичные программные проекты, как правило, располагаются в сложной области в середине графика, где требования проходят по континууму, где они не полностью поняты или согласованы (поскольку их еще предстоит внедрить), а требуемые технологии идут по этому континууму. аналогичный континуум, где мы не уверены на 100% в том, как они работают.

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

В таких ситуациях (т. е. более 90 % времени) вам необходимо использовать итеративный/постепенный процесс, чтобы сдерживать сложность и снижать подверженность риску в течение определенного периода времени (итерации или спринта), чтобы вы могли постоянно проверять и адаптировать решение в соответствии с реалиями требований + технологии + люди.

У вас есть три фактора:

• Деньги
• Время
• Требования

Если деньги и время фиксированы, а требования могут меняться , тогда вам подойдет SCRUM .

Если требования фиксированы , вы бы выбрали водопад .

Изменится ли когда-нибудь программное обеспечение после его первого выпуска?

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

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

Вы должны ожидать и принимать перемены .

Я понимаю, что не все с этим согласны, но использование процесса Waterfall — это № 1 в моем посте о 5 основных ошибках управления программными проектами .

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

Водопад следует использовать, когда этого требует заказчик или регулирующие органы. Не то, чтобы я знал какие-либо регуляторы, которые требуют этого.

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

Необходимо учитывать ряд факторов.

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

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

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

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

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

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

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

Большинство компаний, которые официально практикуют водопад, за кулисами используют какой-то инкрементный или, что более реалистично, итеративный метод.

Вопросы таковы:

1. Используют ли они формальный итеративный метод, такой как UP, Scrum, Kanban и т. д., или они придумывают его по ходу дела.

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

Если неопределенность (в требованиях, технологиях, персонале и т. д.) велика, то гибкие методы могут привести к более эффективному процессу, чем более крупные итерации (например, UP).

Исходя из опыта использования обоих, честно говоря, нет никакого реального преимущества использования водопада, если только проект не настолько мал, что умещается в течение короткого периода времени, например. Один месяц. Скрам в любом случае повторяет этапы мини-водопада в каждом спринте. Ценность Scrum заключается в том, что вы не тратите время на предварительный анализ и проектирование, пока приоритеты и рыночные условия меняются. Обзор есть [здесь] ( http://www.pashunconsulting.co.uk/what_is_scrum_blog.html )

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

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

Для получения дополнительной информации посетите: http://www.scrumstudy.com/blog/advantages-of-using-scrum-listed-down-by-scrumstudy-2/

Я думаю, что ответ Павла великолепен, и я бы +1 вам, если бы мог!

Чтобы добавить в его список. Вы бы использовали водопад, где:

• У вас есть враждебно настроенный клиент или клиент, который отказывается взаимодействовать
  • Я говорю это только потому, что иногда это действительно случается. Клиент на самом деле не хочет изменений, и они навязываются ему владельцем или группой, но они владеют проектом. Это редко, но Agile требует участия.

Водопад сам по себе не является методологией. Водопад — это всего лишь модель жизненного цикла.

Scrum — это гибкая методология. Методология может описывать жизненный цикл и обеспечивать процесс поддержки этого жизненного цикла.