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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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