Прогнозирующий и Реактивный дизайн программного обеспечения [закрыт]

Question

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

Проработав в сфере программного обеспечения более 10 лет, я нахожу гораздо более реалистичным подходить к разработке программного обеспечения с точки зрения реактивного подхода.Я часто использую scrum-подход к управлению проектами, и при этом создается очень мало объемной документации.У нас очень мало спецификаций рабочего процесса (хотя они все еще используются).Это гораздо более динамичный подход к созданию программного обеспечения.Конечно, с течением времени происходит частый рефакторинг, поскольку мы обнаруживаем новые функции, которые, если бы мы планировали заранее, кардинально изменили бы ситуацию.

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

Зная обе стороны по опыту, я все еще нахожу много людей, которым НРАВИТСЯ водопадный подход, а не гибкий при разработке программного обеспечения.Я этого не понимаю.

вопрос: Зачем кому-то использовать waterfall поверх какой-либо формы agile со всеми исследованиями, поддерживающими agile?Каковы веские аргументы в пользу использования waterfall вместо agile?

Answer 1

Мой босс говорит мне.

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

Answer 2

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

Проблема в том, что вы почти никогда не будете следовать этому плану до буквы, и вы почти всегда опаздываете / отбрасываете функции. Однако с самого начала он выглядит очень управляемым и управляемым.

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

Answer 3

Когда я начал программировать (с использованием COBOL не меньше), водопад был "новым" подход. Сегодня я бы сказал вам, что я использую гибкую методологию. Я считаю, что для больших систем лучше всего подходит запуск типа водопад. Не создание огромных документов (это пустая трата времени, IMO), а скорее принятие некоторых шагов, таких как создание прототипа пользовательского интерфейса и / или сценариев использования, чтобы решить проблемы бизнеса. Как только мы почувствуем себя комфортно, мы решим проблему, и у нас будет четкое понимание, мы перейдем в режим гибкой разработки.

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

Answer 4

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

Вы говорите (акцент мой)

  

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

но не связывайтесь ни с какими исследованиями.

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

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

Answer 5

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

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

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

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

Answer 6

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

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

Answer 7

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

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

Несколько моментов, которые заставили методологию работать:  - Создать стандарты использования, обновлять их при необходимости.  - Сборка библиотек: сделайте это один раз, сделайте это хорошо, исправьте это, не нарушая существующий код.  - Делайте достаточно документов.  - Контроль версий все, что вы можете.  - сломать вещи; метод должен либо управлять работой, либо выполнять работу.  - Увеличьте сцепление, уменьшите сцепление, используйте повторно.  - Покупайте или собирайте инструменты, которые вам нужны.  - Отслеживайте свои проблемы и прогресс.

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

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

Answer 8

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

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

P.s.не существует такого понятия, как гибкость и фиксированная цена.Не классическим способом, которым они обычно продают этот метод.Видишь http://martinfowler.com/bliki/FixedPrice.html

Answer 9

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

Answer 10

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

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

Answer 11

ретроактивное поведение

Answer 12

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

Answer 13

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

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

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

Answer 14

Документация, сгенерированная во время процесса водопада, учитывает много CYA. Вы можете указывать пальцем, когда проект сходит с рельсов. Очень немногие руководители будут в порядке с "о, хорошо, я думаю, что проект ушел от нас! Ну, по крайней мере, мы узнали рано, без вреда, без фола! & Quot;

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

Answer 15

При заключении контракта довольно часто встречается одно из железных условий: вы следуете их «процессу». который на осмотре водопад.