Прогнозирующий и реактивный дизайн программного обеспечения
Я знаю, что для себя я впервые начал следовать водопадному методу управления проектами, и вместе с этим я пошел на прогнозный подход к разработке программного обеспечения. В этом смысле я имею в виду огромные пакеты документации, UML, схемы баз данных, словари данных, рабочие процессы, диаграммы деятельности и т. Д.
Проработав в программном обеспечении более 10 лет, я считаю, что гораздо более реалистично подходить к разработке программного обеспечения с помощью подхода Reactive. Я часто следую скрам-подходу к управлению проектами, и при этом очень мало тяжелой документации. У нас очень мало спецификаций рабочего процесса (хотя они все еще там используются). Это гораздо более динамичный подход к созданию программного обеспечения. Конечно, наряду с этим часто происходит рефакторинг с течением времени, когда мы обнаруживаем новые функции с течением времени, которые мы планировали заранее, что-то кардинально изменило бы.
Для нас большая разница в том, что первый подход занимает больше времени, кажется, чаще всего терпит неудачу в мире разработки программного обеспечения, и не так гибок. Второй подход обеспечивает большую гибкость, позволяет нам быстрее осознавать ошибки (поэтому мы можем быстрее исправлять ошибки) и обеспечивает некоторую функциональность в конце каждой итерации.
Зная об опыте обеих сторон, я все же нахожу многих людей, которые ЛЮБЯТ водопадный подход по сравнению с гибким подходом к разработке программного обеспечения. Я не понимаю
вопрос: почему кто-то использовал бы водопад поверх какой-то формы agile со всеми исследованиями, поддерживающими agile? Каковы веские аргументы в пользу использования водопада над Agile?
15 ответов
Мой босс говорит мне
Я подозреваю, что у многих людей нет выбора, и старые боссы не учатся новым трюкам.
Когда я начал программировать (с COBOL не меньше), водопад был "новым" подходом. Сегодня я бы сказал вам, что я использую гибкую методологию. Я считаю, что для больших систем лучше всего подходит запуск типа водопад. Не создавать огромные документы (это пустая трата времени, IMO), а скорее предпринять некоторые шаги, такие как создание прототипа пользовательского интерфейса и / или сценариев использования, чтобы решить наши проблемы бизнеса. Как только мы почувствуем себя комфортно, мы решим проблему, и у нас будет твердое понимание, мы перейдем в режим гибкой разработки.
Чтобы ответить на ваш вопрос, я думаю, что главная причина, по которой водопад держится, заключается в том, что многим людям не нравятся перемены. Страшно меняться, и переход от водопада к ловкому - большое изменение.
Я думаю, что одна из причин, почему люди все еще часто цепляются за водопад, заключается в том, что он дает иллюзию контроля. В водопаде вы можете выполнить достаточно предварительную работу, чтобы составить прекрасный график, в котором удачно учтены все непредвиденные обстоятельства, о которых вы только можете подумать, а затем дать подробный план действий на будущее любому сотруднику, который спрашивает, когда появится функция X имеется в наличии.
Проблема в том, что вы почти никогда не будете следовать этому плану до буквы, и вы почти всегда опаздываете. Однако с самого начала он выглядит очень управляемым и управляемым.
Я большой поклонник Agile, но то, с чем я всегда боролся, это долгосрочные планы / прогнозы, которые часто запрашивают продавцы и маркетологи. Я думаю, что иллюзия уверенности водопада очень утешительна для менеджеров и деловых людей.
Не принимая сторону, но почти любое исследование было бы в лучшем случае ненаучным.
Вы говорите (акцент мой)
вопрос: почему кто-то использовал бы водопад поверх какой-то формы agile со всеми исследованиями, поддерживающими agile? Каковы веские аргументы в пользу использования водопада над Agile?
но не связывайтесь ни с какими исследованиями.
Это одна из тех вещей, которые, как известно, чрезвычайно сложно на самом деле проверить. Нельзя, чтобы две одинаковые команды работали над одним и тем же проектом одновременно, потому что не существует двух одинаковых команд. Нельзя, чтобы одна и та же команда выполняла одну и ту же задачу дважды подряд, используя две разные методологии, без первого прохода, портящего второй. Я никогда не слышал о том, чтобы кто-то разрабатывал экспериментальное (или даже статистическое) исследование, которое могло бы убедительно аргументировать любую методологию разработки программного обеспечения. Мне было бы интересно увидеть его, если у вас есть ссылка.
За исключением реальных доказательств, это сводится к личным предпочтениям. Каковы веские аргументы в пользу шоколада над ванилью?
Я сыграю адвоката дьявола и скажу, что ловкость несовершенна почти так же, как и метод водопада. Я не из тех, кто любит метод водопада, но я также не люблю проворный.
Мой опыт работы с Agile не был очень положительным. Чтобы быть справедливым, я использовал это в корпоративной среде, которая платила за слово "гибкой", все еще ожидая, что наш менеджер будет производить долгосрочные вехи и результаты заранее.
Тем не менее, я обнаружил, что гибкие (в частности, scrum) методологии часто скрывают серьезные проблемы с дизайном. В то время как водопад дает менеджерам иллюзию контроля, Agile, похоже, делает то же самое для команд разработчиков. Я видел команды, в которых поднимаются любые проблемы, которых нет в текущем спринте / итераторе, с надеждой, что они будут решены "вовремя". Требуется игнорировать лишь несколько важных проектных решений, чтобы в будущем проект не заработал, в то время как текущие итерации проходят гладко, и проект, похоже, будет на ходу.
Вы можете утверждать, что команда виновата в том, что не понимает духа agile, но я хотел бы увидеть лучшие методологии, включающие лучшие части agile.
Одной из предпосылок (по крайней мере) XP является то, что изменения дешевы. Модель водопада была построена на принципах, что изменение, любое изменение, является дорогостоящим. Предположение в модели водопада состоит в том, что после написания программного обеспечения его изменение обходится дороже, чем тратить время на то, чтобы прийти к "полному" пониманию проблемы.
Опыт показывает, что очень трудно прийти к полному пониманию проблемы и что, если принять некоторые меры предосторожности (например, модульное тестирование), изменение может стать намного дешевле. Поэтому, если вы столкнетесь с проблемой, когда некоторые гибкие условия не соответствуют действительности, другие подходы могут снова стать выполнимыми. Между Водопадом и Agile есть, по крайней мере, спиральное развитие, которое - своего рода - то, что мы практикуем.
Вы должны быть достаточно хищными, чтобы доставить товар. Вы должны быть достаточно реактивными, чтобы справиться с проблемами.
Однажды я застрял с шестью месяцами, чтобы завершить проект, который рассчитан на год, а исходя из прошлого опыта, потребуется два. Таким образом, я провел три месяца, исследуя методологии. Мы закончили вовремя (через три месяца), используя соответствующие части процесса водопада.
Несколько моментов, которые заставили методологию работать: - Создать стандарты использования, обновлять их при необходимости. - Сборка библиотек: сделайте это один раз, сделайте это хорошо, исправьте это, не нарушая существующий код. - Делайте достаточно документации. - Контроль версий все, что вы можете. - сломать вещи; метод должен либо управлять работой, либо выполнять работу. - Увеличьте сцепление, уменьшите сцепление, используйте повторно. - Покупайте или собирайте инструменты, которые вам нужны. - Отслеживайте свои проблемы и прогресс.
Другим проектом, в котором я участвовал, был шестимесячный проект. Я не вмешивался до тех пор, пока через полтора не началось. Начальник отдела развития был нанят с предельной наценкой, поскольку он оставлял карьеру в пенсионном плане. В начале проекта он спросил менеджера проекта: "Вы хотите, чтобы я сделал это правильно или реагировал?" Можете ли вы угадать ответ? На неделе, в которой я участвовал, такая же функция была реализована в понедельник, среду и пятницу. Угадай, что случилось во вторник и четверг?
Сила Agile заключается в том, что он делает акцент на достаточном количестве, как раз вовремя. Сила методологии водопада в том, что она охватывает все, что вам нужно подумать. Я еще не работал над проектом, который сделал или должен был сделать все шаги. Я работал над многими проектами, которые делали шаги, которые должны были быть выполнены на корпоративной основе.
Название говорит само за себя. (На самом деле: активный против реактивного). Почему выбрали реактивный путь и отказались от контроля, если нет необходимости? Водопад - не единственная альтернатива, вы можете иметь любой процесс разработки, какой захотите, когда захотите. Контроль это ключ.
Это спектр между прочим, водопад на одном конце и полностью реактивные, нулевые методы документирования на другом конце. Если вы работаете в сфере консультантов для влиятельных (и обычно нерешительных) клиентов, вам придется прибегнуть к реактивным методам. Если вы разрабатываете программное обеспечение для термоусадочной пленки, вы можете планировать заранее и управлять знаниями. В некоторых проектах также требуются тонны спецификаций и правил, где подход кода и исправления просто не сокращает его. Для меня разработка программного обеспечения - это, прежде всего, управление знаниями и дизайн, а кодирование - на втором месте.
Ps нет такой вещи как гибкая и фиксированная цена. Не классическим способом они обычно продают метод. См. http://martinfowler.com/bliki/FixedPrice.html
При разработке систем, которые будут использоваться конечными пользователями, Agile часто работает хорошо, потому что требования, вероятно, будут неправильными, и большая часть процесса получает обратную связь от пользователей в форме пригодной для использования версии.
Однако при создании программного обеспечения, которое взаимодействует с другим программным обеспечением, часто требования могут быть проработаны очень четко. В этом случае зачастую более продуктивно обеспечить наличие очень четкой и точной спецификации, модульных тестов. В этой модели вы также можете генерировать довольно хорошие оценки работы, и использование гибкой модели будет стоить намного дороже.
Когда вы предлагаете цену за контракт, довольно распространено, что одно из железных условий заключается в том, что вы следуете их "процессу", который при осмотре представляет собой водопад.
Если вы точно знаете требования, которые никогда не меняются, если вы знаете, сколько времени займет каждый шаг, и если вы знаете, что все ресурсы доступны в нужное время, вы можете сделать водопад, и он будет работать. Но на самом деле подобные проекты довольно редки, и я думаю, что никогда не буду частью этого.
Документация, сгенерированная во время процесса водопада, учитывает много CYA. Вы можете указывать пальцем, когда проект сходит с рельсов. Очень немногие руководители будут в порядке с "о, хорошо, я думаю, что проект ушел от нас! Ну, по крайней мере, мы узнали рано, никакого вреда, нет фола!"
Кроме того, проектные документы могут автоматически генерировать планы тестирования, что полезно для обеспечения качества.
Если у вас есть команда из нескольких десятков человек, которая в течение десятилетия доработала стратегию водопада до такой степени, что она хорошо работает для них, кто вы такой, чтобы прийти и сказать: "Вы делаете это неправильно..."? Действительно, если это работает для них, зачем что-то менять? Да, это просто переворачивает вопрос, но я думаю, что это может быть обоснованным аргументом.
В моей команде мы обнаружили, что с проектами обслуживания (что является основной частью того, что мы делаем), где мы настраиваем или заменяем что-то вроде того, что не всегда так много нужно для пользовательского ввода, кроме, возможно, некоторых прототипов пользовательского интерфейса.
В этом случае, особенно учитывая, что существуют коммерческие сделки, подход "водопад" на макроуровне может хорошо подойти. Даже тогда нам все еще нравятся инкрементные / гибкие подходы на уровне реализации.
Стоит отметить, что большинство наших клиентов - крупные неуклюжие организации, влюбленные в свои документы, что добавляет нам еще больше стимула, чтобы они хотя бы казались традиционными для них.