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

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

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

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

Фактически, в XP порядок примерно такой:

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

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

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

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

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

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

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

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

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

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

Отличие гибкости заключается не в ограничении времени, а в изменении ценностей.

Как Манифест Agile провозглашает:

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

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

Рабочее программное обеспечение важнее исчерпывающей документации

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

Реагирование на изменения вместо следования плану

То есть , в то время как предметы на справа мы ценим предметы слева больше.

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

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

Если бы вы работали в «мини-водопадах», он действительно был бы немного более проворным, чем водопад BDUF с соломинкой. Но частота доставки - это еще не все.

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

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

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

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

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

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

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

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

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

Марк,

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

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

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

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

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

Мои пять копеек...