Методология разработки программного обеспечения Waterfall все еще жизнеспособна?

14

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

Является ли методология разработки водопада все еще жизнеспособной для предоставления программных систем с точки зрения времени, стоимости и качества?

CFL_Jeff
источник
3
Итак, если вы не испытали это и не хотите испытать это, это делает его мертвым? Не то чтобы я защищал это, но это кажется странной предпосылкой.
Четверг
9
Это не мертвый. Это просто не текущее увлечение / тренд / "приемлемость"
Пол
2
@GrandmasterB Под «мертвым» я подразумевал «достаточно доказано, что это не лучший способ»
CFL_Jeff
3
@Rachel Пожалуйста, не продолжайте читать тег разработки программного обеспечения. Это метатег, который планируется использовать в будущем .
Томас Оуэнс
3
Это не мертвый, это просто отдых. Тоска по фьордам. ;)
FrustratedWithFormsDesigner

Ответы:

20

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

Из статьи Википедии:

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

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

Я верю в эту концепцию, но реализация, описанная выше, является рискованной и приводит к провалу.

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

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

Томас Оуэнс
источник
Во многих статьях о гибких методах употребления «традиционных методов» упоминается водопад, и этот подразумеваемый водопад использовался в 20 веке все время. Теперь я знаю, что я не прав.
Мин-Тан
@ThomasOwens Не могли бы вы привести пару таких other plan-driven methodologies that lie opposite of agile that can and do work on project?
Laiv
@Laiv. Спиральная модель, как правило, в большей степени основана на планах, чем гибкие подходы - вы делаете больше планирования и анализа, прежде чем разрабатывать рабочее программное обеспечение. Cap Gemini SDM - еще один пример, хотя более поздние пересмотры добавили в цикл «планируй-проверь-действуй», но опять-таки в него встроен приличный объем предварительного планирования и анализа. Многие из них, вероятно, представляют собой разновидность водопада, но со встроенным циклом обратной связи. Если у вас хорошее понимание предметной области и относительно стабильные требования, вам могут не понадобиться узкие циклы обратной связи гибких методов и вы сможете лучше планировать.
Томас Оуэнс
9

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

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

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

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

Для Agile Snobs (TM) все хорошо и хорошо, он смотрит свысока на «старомодных» разработчиков и их причудливую, неосуществимую методологию водопада, но факт в том, что Agile также не панацея. Некоторые проекты не могут быть построены с использованием Agile, и многие команды, которые думают, что они Agile, на самом деле просто небрежные и неорганизованные.

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

Джоэл Браун
источник
Вы, очевидно, имели совсем другой опыт "людей" для меня. За последние 30 лет я работал в ряде компаний, которые все использовали (и до сих пор используют) метод водопада из учебника. Неудивительно, что это не работает.
Дэвид Арно
@DavidArno Самым близким, что я когда-либо видел «в дикой природе» к учебнику «Водопад» в контексте программного обеспечения, было программное обеспечение компании, которое контролировало переключение поездов. Мотивация не заключалась в том, чтобы кто-то буквально умер в результате ошибки. Я полагаю, что это также может произойти в местах, где выполняется встроенное программирование, где вы не хотите создавать миллион чего-то, просто чтобы узнать, что это не получается из-за ошибки. Я склонен думать, что даже в этих случаях Водопад является скорее идеалом, чем практикой, которая достигается с совершенством. Как вы указываете - результаты неизбежно проваливаются на каком-то уровне.
Джоэл Браун
8

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

Ryathal
источник
5
Не уверен, в чем разница между «мифическим» процессом водопада и «реальным». Не могли бы вы объяснить это?
CFL_Jeff
6
Часто процесс «Водопад», описанный сторонниками Agile, представляет собой соломенного человека en.wikipedia.org/wiki/Straw_man
jfrankcarr
11
Это было бы лучшим ответом, если бы вы объяснили в своем ответе, как сторонники Agile создают соломенный процесс, который не будет работать, но не будет надлежащим образом Waterfall.
Роберт Харви
4
-1 за утверждение: «Они превосходны в доставке ...» Правда в том, что это мытье. Как и все программные методологии, иногда это работает, иногда нет. Я видел оба в случае с настоящим методом водопада.
riwalk
2
Я собираюсь сказать, [цитата нужна] на этот ответ. И -1, пока не будет предоставлено. Особенно «превосходная поставка в срок на бюджетном программном обеспечении, которое соответствует ожиданиям пользователей». Отчет CHAOS не согласен с вами.
Malfist
5

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

Есть ситуации, когда это так:

  • Когда требования не изменятся.

  • При выполнении новых требований это менее важно, чем попадание на 100% от первоначальных.

  • Когда все технологические компоненты являются зрелыми и понятными.

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

Очень немногие методы применимы везде. Очень немногие бесполезны.

MathAttack
источник
1
Что в мире является «менее мудрым» или «моренформальным»?
Aaronaught
1
@Aaronaught - «менее итеративный» и «более формальный», набранные жирными пальцами на iPhone. :-)
MathAttack
1
Я никогда не работал в проекте, который выполнил бы хотя бы одно из этих предварительных условий. :)
Теодор
3

Да, он очень живой, хотя сегодня используется более распространенная « модель V ».

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

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

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

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

gbjbaanb
источник
Agile может очень хорошо работать с фиксированной суммой денег или времени, при условии, что область действия также не фиксирована. Другой момент заключается в том, что заказчик / подрядчик может выбрать тип контракта (T & M, фиксированная стоимость или что-то среднее), чтобы он соответствовал конкретной методологии разработки (гибкая или водопадная) - он не предопределен.
ДНК
1

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

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

jwernerny
источник