Две преобладающие методологии разработки программного обеспечения - водопад и проворный. При обсуждении этих двух вопросов часто большое внимание уделяется конкретным методам, которые их различают (парное программирование, TDD и т. Д. По сравнению с функциональными спецификациями, большим предварительным дизайном и т. Д.).
Но настоящие различия гораздо глубже в том, что эти практики исходят из философии.
Водопад говорит: « Перемены стоят дорого, поэтому их следует минимизировать.
Agile говорит: изменение неизбежно, поэтому сделайте его дешевым.
Мой вопрос: независимо от того, что вы думаете о TDD или функциональных характеристиках, действительно ли методология разработки водопада действительно жизнеспособна?
Кто-нибудь действительно думает, что минимизация изменений в программном обеспечении является жизнеспособным вариантом для тех, кто желает предоставить ценное программное обеспечение? Или действительно вопрос о том, какие методы лучше всего работают в наших ситуациях для управления неизбежными изменениями?
источник
Ответы:
Конечно, водопад является жизнеспособным. Это привело нас на Луну!
И это ловкий тренер, говорящий здесь!
Если вы не можете четко определить проблемы, связанные с управлением проектами, нет веских причин для изменения.
В качестве альтернативы методологии Agile и Waterfall я предложу ВАШУ методологию . Адаптированный к вашему конкретному бизнесу, вашей конкретной команде, вашим продуктам, вашему способу работы, культуре вашей компании ... Именно поэтому Scrum называют простой структурой, а не методологией.
Желание внедрить методологию, потому что кто-то в блоге, который вам нравится, говорил об этом, так же глупо, как разрешать проблемы, ничего не делая.
источник
Во-первых, я собираюсь не согласиться с вашими утверждениями:
Моя интерпретация:
Водопад говорит: клиент знает, чего хочет.
Agile говорит: заказчик не знает, чего он хочет, поэтому нам придется сделать несколько разных версий.
Лучшей реализацией «водопада», который я когда-либо видел, был огромный интеграционный проект с очень крупным финансовым заказчиком, в котором участвовало более 40 подпроектов. Пакет для рабочего стола и веб-сайта, который мы поставили, был только одним из этих 40+ подпроектов. Хотя я думал, что они потратили слишком много денег других людей, они собрали свои вещи и держали более 40 различных кораблей, движущихся вместе в строю. Проект был запущен в установленный срок (цель перемещалась один раз во время проекта), и, хотя я думал, что они могли бы сделать это более экономно и ловко, это было сделано вовремя и в соответствии со спецификацией. Расписание ночного концерта длилось около 100 страниц, и около 40 из этих страниц были контактными данными экстренной паники всех вовлеченных людей. Я был очень впечатлен этим клиентом.
Или, вы можете сделать то, что мы делаем, то есть бегать и делать то, что является самым последним отчетом о жалобах / ошибках, и называть это гибким.
источник
Вы начинаете с того, что говорите:
Это неверно Эта дихотомия была создана гибким сообществом, чтобы создать противника, против которого можно позиционировать себя. До того, как Agile был в моде, люди говорили о множестве различных подходов к созданию программного обеспечения. Они все еще существуют сегодня, но так или иначе они часто смешиваются в большой беспорядок, называемый проворными сторонниками «водопад».
Я использую OPEN / Metis и его варианты уже более 10 лет с большим успехом. Это определенно не проворный, и определенно не водопад. Тысячи разработчиков создают чрезвычайно сложное программное обеспечение для самолетов, жизненно важных систем, банковского дела и т. Д., Используя негибкие методы каждый день.
Так что да, конечно, существует жизнеспособная альтернатива гибкой.
источник
Да, различные методы разработки программного обеспечения являются жизнеспособными в зависимости от вашей проблемной области. Это «Лошади для курсов».
Например, вы пишете программное обеспечение для управления атомной электростанцией или для управления космическим кораблем НАСА. Этот тип проблемной области, вероятно, лучше подходит для подхода с использованием «водопада» (или даже более строгого подхода), если хотите, вы должны решить все проблемы заранее (или БУМ!).
Создание новейшего пользовательского интерфейса для веб 2.0 / 3.0 / маркетинговый термин? Agile - это гораздо лучший способ (вам нужна быстрая обратная связь и изменения).
Есть то, что я бы назвал принципами мастерства программного обеспечения, которые все еще могут применяться независимо от того, какая методология, например:
и более.
Что бы вы ни делали, не слушайте фанатиков по обе стороны уравнения, делайте то, что подходит вам, вашей команде и вашей проблемной области.
источник
Проблема связана со сложностью программного обеспечения. Водопад отлично подходит для строительства мостов и дорожных покрытий, потому что физика никогда не меняется. Конечно, в какой-то момент мы разработаем новый асфальт, но он не произведет революцию в строительстве дорог. Сталь в подвеске моста либо подходящего размера, либо нет. Вы не можете запутать или заглушить настоящий строительный проект, как вы можете с помощью программного обеспечения.
Изменения в программном обеспечении. Программное обеспечение быстро меняется. Закон Мура гласит, что число транзисторов на чипе удваивается каждые 18-24 месяца. В результате число строк кода в программе также удваивается. Сложность между этими строками кода, следовательно, возрастает с большим значением порядка 2 ^ (2t).
Программное обеспечение быстро меняется, и сложность увеличивается с ним в геометрической прогрессии.
Контролируя стоимость программного обеспечения, вы хотите контролировать экспоненциальные факторы, а не только мультипликативные или аддитивные. Изменение кода увеличивает сложность (и экспоненциально усложняется при продвижении проекта) экспоненциальным образом.
Изменение является неизбежным. Сама природа программирования расширяет язык с помощью классов и пользовательских методов, тем самым изменяя сам язык. Вы не можете сделать это в любой другой форме инженерной дисциплины (например, строительство дорог. Вы не изобретаете новый тротуар, чтобы проложить дорогу в Канзасе через Калифорнию).
Гибкий метод также дает вам платформу для обработки будущих выпусков и исправлений ошибок. У вас уже есть инструменты управления, процессы, обученные сотрудники для разработки программного обеспечения с поддержкой версий. При использовании метода водопада вам нужно будет переобучить свою команду, чтобы исправить даже незначительные ошибки.
во всяком случае, мои 2 цента.
источник
Чтобы ответить на вопрос, существует ли жизнеспособная альтернатива для программного обеспечения, возможно, нет - или еще нет, по крайней мере, в общем случае. Я думаю, что все сводится к природе программного обеспечения. Программное обеспечение, будучи информацией, может быть продублировано бесплатно. В отличие от моста или дома. Это означает, что с практикой я смог бы выстроить дом и работать в относительно простой области. В какой момент почему бы не использовать однократный подход?
Но поскольку программное обеспечение не требует затрат на дублирование, зачем вам делать одно и то же дважды? Программное обеспечение стремится от производства. Таким образом, если все программное обеспечение является созданием нового продукта, то мы всегда работаем в сложной области, в которой, в некоторой степени, мы не знаем, что делаем. Или это дорого, чтобы знать заранее, и дешевле узнать, делая. В сложной, рискованной области я хотел бы попробовать эксперименты, увеличивать и повторять.
Атомные электростанции и проводные системы часто приводятся в качестве примеров программного обеспечения, которое вы хотели бы использовать в качестве водопада. Но разве система челночного авионики не была разработана итеративно? Какими были канадские и американские системы управления воздушным движением?
И если OPEN / Metis является итеративным и инкрементным, то для меня это звучит так, будто у него гибкая философия, даже если она не ассоциируется с другими распространенными гибкими практиками.
источник
Метод «Водопад», безусловно, является жизнеспособным и столь же философски обоснованным, как и любой другой подход. Помните, что Waterfall существует намного дольше, чем Agile, но обратите внимание, что это не аргумент, чтобы утверждать, лучше ли одна методология, чем другая.
Вы используете метод «Водопад», когда имеете четкое представление обо всей проблемной области и о том, чего хочет достичь клиент в программном пакете. Возможно, вы указали фиксированную цену при заключении договора, и ваш клиент понимает, что он не может отклоняться от любых согласованных требований. Ваш процесс строго такой, который проходит через серию подписей между различными этапами разработки, и часто бывает так, что каждый этап завершается другой командой - иногда даже другой компанией - каждая из которых не обязательно может быть в связаться с остальными. Вы часто видите, что Водопад имеет хорошие результаты в военных и государственных проектах, когда они предлагаются внешним подрядчикам. Когда Waterfall и другие подобные подходы получают плохую репутацию, это когда разработчики сталкиваются с проблемами, такие как плохая оценка, графики, запланированные без непредвиденного времени, или плохое или неполное понимание проблемной области. Проблема никогда не является ошибкой методологии, а заключается в ее применении.
Сравнение Agile и любой методологии является ложным. Agile - это не методология, это философия, или, возможно, было бы лучше сказать, что это общий термин, который представляет другой взгляд на то, как вы занимаетесь разработкой программного обеспечения. Методология - это всего лишь инструмент, и поэтому ее ценность всегда будет меньше, чем у отдельных людей и взаимодействий, которые лежат в основе того, что значит быть гибким .
Любая возможность минимизировать изменения ценна как для разработчика, так и для заказчика. Изменения могут привести к сбою расписания или отсутствию функций для его соответствия. Именно как вы управляете последствиями изменений, которые влияют на стоимость ваших проектов.
Ваша практика может помочь в управлении изменениями, или они могут полностью игнорировать изменения. Важным является сочетание ваших методов разработки и управления вашими отношениями с клиентами, а также то, насколько эффективно эти вещи работают вместе для всех вовлеченных сторон.
Те из нас, кто для всех намерений и целей Agile, понимают, что вы выбираете метод, который работает для вас. Если вам нравится определенный подход, следуйте ему. Если это не совсем соответствует вашим потребностям, измените его. То, как вы занимаетесь созданием программного обеспечения, сводится к тому, чтобы максимально эффективно использовать имеющиеся у вас ресурсы и свести к минимуму те практики, которые могут привести ваш проект к провалу, и вы часто обнаруживаете, что вам нужно изменить свой метод в соответствии с конкретный проект под рукой.
Одно дело сказать: «Хорошо, теперь мы Agile», и совсем другое - жить и работать по философии Agile. Используете ли вы водопад, инкрементный, спиральный, SCRUM, XP, FDD или любой другой метод, вы в основном Agile, где вы цените:
и где вы объединяете свои инструменты, метод и ваш опыт для успешного применения этих ценностей.
источник
Да, модели Waterfall, Spiral, Iterative и другие гибридные процессы жизнеспособны, но изменения неизбежны. Процесс - это больше, чем просто обработка изменений, и (я утверждаю, что) главным определяющим фактором является то, насколько хорошо вы знаете / понимаете проблему и насколько точно вы можете планировать и прогнозировать.
Заявление о том, что «две преобладающие методологии разработки программного обеспечения - это водопад и гибкость», является неискренним, поскольку существует целый ряд процессов разработки программного обеспечения, и многие компании синтезируют свою собственную версию модели процесса, часто изменяющуюся для конкретного проекта. Существует более двух жизнеспособных подходов к разработке программного обеспечения. Хотя Водопад и Agile имеют тенденцию падать на противоположных концах спектра «изменений», разумно охарактеризовать эти конкурирующие методологии как
Водопад говорит: « Перемены стоят дорого, поэтому их следует минимизировать.
Agile говорит: изменение неизбежно, поэтому сделайте его дешевым.
Но это еще не все. Бизнес должен уметь планировать и прогнозировать, но программное обеспечение - это творческий процесс, а оценки часто ошибочны. Помните хороший - быстрый - дешевый треугольник? Добавьте четвертое измерение, процесс, и вы обнаружите, что сокращение усилий по процессу также может сжать график, когда оценки оказываются неверными и проект находится под угрозой задержки. Программное обеспечение является гибким (изменяемым) процессом, и Agile, Iterative, Spiral предлагают возможность предоставлять дополнительные функциональные возможности в более короткие промежутки времени.
Водопад и другие модели процессов, основанные на требованиях, имеют средства управления для обработки изменений, поэтому неточно сказать, что Водопад минимизирует изменения, точнее сказать, что Водопад распознает и управляет изменениями и сообщает о влиянии этих изменений (потому что изменение приводит к влиянию графика, когда вы есть требования и дизайн заранее). Когда вы создаете продукт или вам необходимо полностью определить требования (функциональность), вы переходите к одной из гибридных моделей.
И когда оценки неверны, часто процесс (четвертый этап железного треугольника) приносится в жертву, чтобы соответствовать графику.
источник
Зрелые гибкие и водопадные подходы неотличимы друг от друга. Ваше предположение о цели водопада неверно. Они оба имеют целью производство качественного программного обеспечения. Если у вас нет единого подхода к разработке для компании в целом, вам нужно посмотреть, какой подход обеспечит наименьшее количество трения для принятия. В конце короткие циклы разработки, сплоченная команда QA и бизнес, который управляет разработкой, являются тем, что является наиболее важным для производства программного обеспечения высшего качества
источник