Является ли частота выпуска единственной реальной разницей между Agile и Waterfall?

Ответ 1

Водопад

• вы разрабатываете продукт
• вы его создаете.
• вы проверяете его
• вы документируете его
• вы выпускаете его, когда вы разработали все требования

Agile:

• сначала вы создаете наиболее ценную функцию (или user story)
• вы тестируете его (TDD;))
• вы построили его
• вы документируете его
• вы повторяете процесс со следующей наиболее ценной функцией
• вы можете отправить его в любое время

(после каждой завершенной вами функции или после периода времени (обычно называемого sprint или iteration))

Разница для меня довольно понятна.

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

Ответ 2

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

• Команды водопада, как правило, строятся вокруг группы узких специализаций. Аналитики/архитекторы/дизайнеры/кодеры/тестеры, как правило, являются отдельными группами людей, работающих в одиночку. Гибкие команды работают вместе.

• Процессы водопада зависят от большого количества документации и передачи обслуживания. Гибкие команды ориентированы на рабочий код/​​продукты.

• Я бы не согласился с тем, что водопад фокусируется на сотрудничестве с клиентами. Существует одна точка контакта с небольшой группой общей команды разработчиков, часто только в начале процесса. Agile построен на непрерывном сотрудничестве на протяжении всего процесса разработки. Очень разные.

• Процессы водопада основаны на идее, что вы можете полностью определить продукт и архитектуру до начала разработки. Гибкие процессы основаны на идее, что вы обнаруживаете продукт/архитектуру, когда идете.

Ответ 3

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

Agile - это не единое целое, а зонт для многих различных методологий.

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

Фактически, в XP порядок больше или меньше:

• test (сначала TDD/тест)
• код
• дизайн (рефакторинг)
• повторить и в конечном итоге выпустить

какой тип инвертирует большую часть последовательности.

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

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

Но Водопад тоже делает это. Его просто так, что вместо обучения каждые 3-4 недели команда "Водопад" учится каждые 6 или 9 месяцев. Но дизайн Водопада все еще появляется. То есть, релиз 2 водопада будет отражать то, что было изучено в выпуске 1. Таким образом, процесс не отличается, его просто происходит с другой скоростью.

Это сильно зависит от практики. Как описано в DOD-STD-2167A, (раздел 4.1.1) модель водопада действительно позволяет фазам процесса разработки перекрываться и проходить (короче говоря, быть достаточно подвижным). Но большинство фактических практик пропустили это, и не было никакого обучения до конца проекта.

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

Снова зависит от практики. Я не вижу в упомянутой выше спецификации больше упоминания об ответственности клиента вообще, не говоря уже о непрерывности.

Как заметил Джерри Коффин в комментарии, "Водопад" действительно является соломенным, который спорил в пользу Agile (как и я сейчас использую его сейчас), но стоит посмотреть на этот документ и подумать о том, что он подразумевает и как оно было применено.

То, что показывает эта спецификация, - это интенсивное сосредоточение на контрактах, доставка и обслуживание планов и документов, а соблюдение плана. И я считаю, что , что переносится на практике.

Контраст с agile - это не время, а изменение значений.

Как Agile Manifesto объявляет:

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

Лица и взаимодействия над процессами и инструментами

Рабочее программное обеспечение по полной документации

Сотрудничество с клиентами по заключению контрактов

Ответ на изменение в соответствии с планом

То есть, хотя в элементах есть значение справа, мы больше ценим элементы слева.

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

Частая версия - это механизм для выполнения этих значений.

Если вы работали в "мини-водопадах", это было бы немного более гибким, чем водопад BDUF соломы. Но частота доставки, разумеется, не вся история.

Ответ 4

Одно из различий заключается в прозрачности: независимо от того, будут ли люди вне команды разработчиков во время цикла dev иметь какую-либо видимость в процессе, прогресс, препятствия и то, как будет выглядеть конечный результат.

Водопад не подразумевает прозрачность. Часто (хотя и не обязательно) это реализовано как "программисты входят в свою пещеру и появляются через несколько недель/месяцев с" готовым "продуктом". Бизнес-эксперты пишут спецификации вверх, и это может быть конец их участия - они могут быть недоступны, когда у программистов возникают вопросы во время реализации. Программисты могут не показывать каких-либо результатов никому до конца цикла.

Agile требует прозрачности - это часть основной ткани. Люди, не входящие в команду, будут (или, по крайней мере, могут) видеть, что делает команда. (Если нет, команда лжет о том, чтобы быть Agile.) Это могут быть ежедневные стендовые встречи Scrum или Big Visible Charts и информационные радиаторы, или демо в конце итерации. Требование XP состоит в том, чтобы Клиент принимал все бизнес-решения, вместо того чтобы оставлять программистов поцарапать свои головы и слепо выбирать вариант, когда требования не ясны. Это может быть тот факт, что тестеры - и Клиент - считаются частью команды, а не отдельными командами.

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

Ответ 5

Отметить,

Как вы указали, оба подхода разделяют "хорошие вещи", которые должны быть в каждом хорошем проекте. Например, возьмите эти два: ранняя обратная связь и прозрачность. Хотя это правда, что Agile имеет структуру, которая поощряет это, эти две "хорошие вещи" могут (и должны) быть в любом проекте водопада.

Однако я склонен (почтительно!) не соглашаться с идеей о том, что частота выпуска является единственной разницей. Одно существенное различие заключается в следующем:

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

Я так не думаю. В Agile вы пытаетесь сделать все это одновременно, с многодисциплинарной командой. Я говорю "попытка", потому что это не то, что можно легко сделать... но по крайней мере пытается помочь.

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

Только мои два цента...

Ответ 6

Мне очень нравится этот вопрос.

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

С Agile есть код. Долгосрочные разработчики считали, что это самодокументировано, потому что они были в курсе проекта, когда он был написан. (Вы когда-нибудь проверяли свои собственные заметки? Они всегда имеют смысл для автора.) Я попытаюсь разглядеть архитектуру, глядя на 1500-2000 модулей. Точно так же пытается выяснить дизайн на высоком уровне. Я возьму обильные заметки. Возможно, даже вяжущие заполнены. Глядя на "самодокументирующий" код, я расскажу, что делается (в этом модуле), но не почему. О да, сотрудники, которые сотрудничали с разработчиками, получили повышение (или испугались) и больше не доступны.

Плохая проворная не лучше плохих водопадов. На самом деле, плохой проворный может быть хуже, чем плохой водопад. Лучше ли лучше, чем хороший водопад?

В манифесте ничего не говорится о документации. Настоящая опасность здесь заключается в том, что "гибкий" означает для многих разработчиков и клиентов оправдание быстрой дешевой героической модели. Как вы думаете, покупателю понравилось читать три толстых трехкольцовых связующих на высоком уровне дизайна? Мы все слышали в Computer Science 100, что большая часть стоимости программного обеспечения - это обслуживание, а не развитие. Неужели я ошибаюсь, думая, что аспект обслуживания полностью игнорируется в этом обсуждении?

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