Есть ли жизнеспособная альтернатива методологии гибкой разработки?


47

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

Но настоящие различия гораздо глубже в том, что эти практики исходят из философии.

Водопад говорит: « Перемены стоят дорого, поэтому их следует минимизировать.
Agile говорит: изменение неизбежно, поэтому сделайте его дешевым.

Мой вопрос: независимо от того, что вы думаете о TDD или функциональных характеристиках, действительно ли методология разработки водопада действительно жизнеспособна?

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


1
интересный вопрос. с нетерпением жду ответов.
DevSolo


3
@FarmBoy - Хороший вопрос. Я смотрю на гибкую философию немного по-другому. Я бы написал так: «Agile говорит: изменения неизбежны, поэтому удешевьте определение стоимости изменений». Изменения все еще могут быть очень дорогими, но в Agile вы можете понять это быстро и дешево, чтобы мы всегда знали стоимость изменений. Если сформулировать это по-другому, люди думают, что гибкие изменения будут дешевыми. Некоторые изменения стоят дорого, независимо от того, какой процесс.
Майк Два

1
@ Яннис Ризос: почему вы закрываете этот интересный вопрос в одиночку, без единого голосования сообщества?

1
@ Pierre303 из-за этого вопроса, который здесь обсуждался .
Ryathal

Ответы:


59

Конечно, водопад является жизнеспособным. Это привело нас на Луну!

И это ловкий тренер, говорящий здесь!

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

В качестве альтернативы методологии Agile и Waterfall я предложу ВАШУ методологию . Адаптированный к вашему конкретному бизнесу, вашей конкретной команде, вашим продуктам, вашему способу работы, культуре вашей компании ... Именно поэтому Scrum называют простой структурой, а не методологией.

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


10
+1 по ВАШЕЙ методологии, следующий Agile-тренер, который говорит мне, что SCRUM - единственный способ получить ботинок вверх по спине;)
Martijn Verburg

1
@karianna: Я делаю специально SCRUM, но иногда это просто не подходит. С другой стороны, я также видел команду, которая пыталась продать SCRUM своим боссам, думая, что это решит их проблему. Они потерпели неудачу, потому что проблема была не в их боссах или в их личном кабинете. Нет единого правила. У каждого случая свое решение. И да, большинство организационных проблем можно решить с помощью гибких методов, но гибкая - это не серебряная пуля.

5
Не только луна. Во встроенных системах космический челнок имел ~ 1 млн строк кода на языке Си. За ~ 30 лет у них было только 2 ошибки, превращающие их в производственные сборки.
Дэн Нили

2
Водопад также убил первых трех космонавтов. Эта настойчивость в использовании этой программы Apollo в качестве плаката для Waterfall в лучшем случае неосведомлена. Водопад также упоминается как ответственный за обе программы, являющиеся полными финансовыми проблемами, и Шаттл, являющийся сверхинженером, хрупким, дорогим «космическим феррари», когда оригинальная спецификация была для «космического грузовика». Я уверен, что SpaceX не согласится с Водопадом.

4
@DanNeely, высокое качество программного обеспечения космического челнока было недешевым. Видимо цена была в размере 1000 долларов за строку кода.

21

Во-первых, я собираюсь не согласиться с вашими утверждениями:

Водопад говорит: «Перемены стоят дорого, поэтому их следует минимизировать.
Agile говорит: изменение неизбежно, поэтому сделайте его дешевым.

Моя интерпретация:

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

Лучшей реализацией «водопада», который я когда-либо видел, был огромный интеграционный проект с очень крупным финансовым заказчиком, в котором участвовало более 40 подпроектов. Пакет для рабочего стола и веб-сайта, который мы поставили, был только одним из этих 40+ подпроектов. Хотя я думал, что они потратили слишком много денег других людей, они собрали свои вещи и держали более 40 различных кораблей, движущихся вместе в строю. Проект был запущен в установленный срок (цель перемещалась один раз во время проекта), и, хотя я думал, что они могли бы сделать это более экономно и ловко, это было сделано вовремя и в соответствии со спецификацией. Расписание ночного концерта длилось около 100 страниц, и около 40 из этих страниц были контактными данными экстренной паники всех вовлеченных людей. Я был очень впечатлен этим клиентом.

Или, вы можете сделать то, что мы делаем, то есть бегать и делать то, что является самым последним отчетом о жалобах / ошибках, и называть это гибким.


8
Согласно Agile Dilbert: is.gd/lDoQgb
Питер К.

11
Это больше похоже на «Водопад говорит: клиент не знает, чего он хочет, поэтому давайте сядем, поговорим об этом и договоримся о том, что они хотят, прежде чем мы начнем его взламывать» ...
scrwtp

+1: очень хороший ответ. Я думаю, что у гибкого сообщества есть одна основная проблема: гибкость хороша в определенных контекстах для определенных классов проектов и клиентов, но они не видят, что есть проекты, в которых требования не меняются, поэтому быстрые и более структурированные подходы являются лучшим выбором , Я думаю, что гибкое сообщество должно попытаться реалистично определить области, в которых их подход является лучшим выбором (я думаю, что такие области существуют), а не пытаться выдвигать это как общее решение, потому что это не так.
Джорджио

6
@scrwtp - и Agile больше похож на «Мой клиент не знает, чего хочет, и не может / не хочет говорить и придумывать, и они меняют свое мнение каждые 5 минут. Я должен что-то толкнуть им в лицо чтобы получить какие-либо значимые ответы ". Ух ты. Это звучит очень печально, когда я записываю это.
Майкл Кохне

1
@scrwtp: Я думаю, что вопрос на миллион долларов: является ли это «вера» в то, что вы можете «сесть и обсудить это и согласиться» жизнеспособным? Ответ: это зависит, верно? Это зависит от ряда переменных: насколько велик проект? Мы даже ЗНАЕМ, насколько он большой? Сколько времени клиенты должны «сесть» с нами? Мы десятилетиями пытались связать разработку программного обеспечения со строительством, которое почти на 100% предписано. Разработка программного обеспечения находится где-то посередине между «полностью реакционным» и «100% предписывающим». В большинстве магазинов это ближе к "полностью реакционному", следовательно, гибкое принятие.
Calphool

21

Вы начинаете с того, что говорите:

Две основные философии разработки программного обеспечения - это водопад и ловкость.

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

Я использую OPEN / Metis и его варианты уже более 10 лет с большим успехом. Это определенно не проворный, и определенно не водопад. Тысячи разработчиков создают чрезвычайно сложное программное обеспечение для самолетов, жизненно важных систем, банковского дела и т. Д., Используя негибкие методы каждый день.

Так что да, конечно, существует жизнеспособная альтернатива гибкой.


6
Я не могу быстро понять, что такое OPEN / Metis по этой ссылке. (Обычно вам не нужно загружать методологию.) Мой вопрос: какова его философия, особенно в отношении изменений? Попытка минимизировать изменения или снизить стоимость изменений? Имейте в виду, что мой вопрос был о гибкой философии, а не о гибких практиках.
Эрик Уилсон

OPEN / Metis имеет итеративный жизненный цикл, который строит системы постепенно. Изменение признается как нечто, что не только происходит, но и замечательно, когда оно происходит, поскольку самой целью развития информационной системы является осуществление каких-то изменений. Однако стоимость изменений контролируется и управляется с помощью соответствующего жизненного цикла и соответствующих практик.
CesarGon

1
Что касается вашего замечания о «загрузке методологий», ну ... вы не загружаете методологии, я согласен. Вы загружаете документы, которые описывают методологии. Иначе как ты узнаешь о них? Посмотрите на множество книг, которые описывают XP, Scrum и т. Д.
CesarGon


10

Да, различные методы разработки программного обеспечения являются жизнеспособными в зависимости от вашей проблемной области. Это «Лошади для курсов».

Например, вы пишете программное обеспечение для управления атомной электростанцией или для управления космическим кораблем НАСА. Этот тип проблемной области, вероятно, лучше подходит для подхода с использованием «водопада» (или даже более строгого подхода), если хотите, вы должны решить все проблемы заранее (или БУМ!).

Создание новейшего пользовательского интерфейса для веб 2.0 / 3.0 / маркетинговый термин? Agile - это гораздо лучший способ (вам нужна быстрая обратная связь и изменения).

Есть то, что я бы назвал принципами мастерства программного обеспечения, которые все еще могут применяться независимо от того, какая методология, например:

  • Управления источником
  • построить и CI
  • парное программирование
  • TDD
  • Я даю ^% $$ &

и более.

Что бы вы ни делали, не слушайте фанатиков по обе стороны уравнения, делайте то, что подходит вам, вашей команде и вашей проблемной области.


Водопад работает, если вы можете себе это позволить. Кто-то из вышеупомянутых утверждал, что стоимость программного обеспечения проекта НАСА Луны составляла примерно 1000 долларов за строку кода. Большинству магазинов нужно что-то вроде 1–10 долларов за строку кода, и Agile лучше в таких ситуациях. Однако я не претендую на то, что Agile обеспечивает лучшее качество в целом. По сути, все сводится к тому, можете ли вы позволить себе много денег, чтобы быть уверенными в правильности программного обеспечения, или дешевле найти решение, если вы обнаружите, что программное обеспечение неверно.
Микко Ранталайнен,

2

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

Изменения в программном обеспечении. Программное обеспечение быстро меняется. Закон Мура гласит, что число транзисторов на чипе удваивается каждые 18-24 месяца. В результате число строк кода в программе также удваивается. Сложность между этими строками кода, следовательно, возрастает с большим значением порядка 2 ^ (2t).

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

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

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

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

во всяком случае, мои 2 цента.


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

И только дробовик несколько отверстий в ваших рассуждениях есть дорога конструкции проектируется прямо сейчас , что было бы целесообразно для дороги между Канзасом и Калифорнией, но не между Нью - Йорком и Бостоном. И новые методы обработки асфальта появляются постоянно.
Hounshell

2
И, наконец, вы говорите: «При использовании метода« водопад »вам потребуется переобучить свою команду, чтобы справиться даже с незначительными исправлениями ошибок». Это просто так неосведомлен о том, как работает процесс водопада. Вы должны попробовать хороший магазин водопад, прежде чем вы трибуны о том, как это не подходит для каждого сценария разработки программного обеспечения.
Hounshell

1
Привет Стефан, не все программные требования постоянно меняются.
Пол Натан

1
Бизнес всегда меняется ; бизнес, который не меняется и не адаптируется - это бизнес, который умирает. Время - это константа , которая плохо взаимодействует с переменами. Система, которая имеет философию, которая признает, что Изменения ожидаются, может приспосабливать изменения, в противном случае Время должно приспосабливаться к изменениям, и это постоянная постоянная величина!

2

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

Но поскольку программное обеспечение не требует затрат на дублирование, зачем вам делать одно и то же дважды? Программное обеспечение стремится от производства. Таким образом, если все программное обеспечение является созданием нового продукта, то мы всегда работаем в сложной области, в которой, в некоторой степени, мы не знаем, что делаем. Или это дорого, чтобы знать заранее, и дешевле узнать, делая. В сложной, рискованной области я хотел бы попробовать эксперименты, увеличивать и повторять.

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

И если OPEN / Metis является итеративным и инкрементным, то для меня это звучит так, будто у него гибкая философия, даже если она не ассоциируется с другими распространенными гибкими практиками.


2
Итак, теперь Agile пытается взять кредит за итеративный и поэтапный? Не берите в голову, что итеративные и последовательные были ОСНОВНЫМИ частями развития водопада, так как я начал разработку в '92
Данк

1

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

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

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

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

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

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

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

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

Одно дело сказать: «Хорошо, теперь мы Agile», и совсем другое - жить и работать по философии Agile. Используете ли вы водопад, инкрементный, спиральный, SCRUM, XP, FDD или любой другой метод, вы в основном Agile, где вы цените:

  • Индивидуумы и взаимодействия над процессами и инструментами
  • Рабочее программное обеспечение над всеобъемлющей документацией
  • Сотрудничество с заказчиком в процессе переговоров
  • Реагирование на изменения в соответствии с планом

и где вы объединяете свои инструменты, метод и ваш опыт для успешного применения этих ценностей.


2
Ух ты. Здесь так много странных вещей. Водопад является жизнеспособным на основе того, чтобы быть вокруг дольше? Водопад оправдан на основании использования в оборонных контрактах? Является ли каждая возможность минимизировать изменения на самом деле в интересах клиента, или это приводит к тому, что он доставляет то, что он хотел, а не то, что он на самом деле хотел? Так как вы, кажется, заботитесь об этом, я пытался понять, откуда вы, но я что-то упустил.
Эрик Уилсон

1
@EricWilson Waterfall существует дольше и успешно используется задолго до обсуждения философии Agile. Это жизнеспособно, потому что оно существует и при правильном применении работает для тех, кто хочет его использовать. Я не оправдывал его использование, а просто указал на пример, где у меня был личный опыт, когда я видел, как это работает, и да, я тоже видел несколько впечатляющих неудач. Вы не ищете возможности минимизировать изменения, вы хотите, чтобы возможности вносили изменения, но вы должны делать это разумно, иначе ваш клиент либо получит меньше, чем он хотел, либо уложится в срок.
С.Робинс

0

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

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

Водопад говорит: « Перемены стоят дорого, поэтому их следует минимизировать.

Agile говорит: изменение неизбежно, поэтому сделайте его дешевым.

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

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

И когда оценки неверны, часто процесс (четвертый этап железного треугольника) приносится в жертву, чтобы соответствовать графику.


Я не был нечестным. После пяти лет развития в различных компаниях я столкнулся только с двумя, и одна названа только как «оскорбительная». Спираль? Никогда не слышал об этом.
Эрик Уилсон


Я имел в виду, что я не сталкивался с ними в реальном мире. В Интернете есть все, что угодно, но я не собираюсь начинать охотиться на них сейчас, просто потому, что случайно задал вопрос еще в 2010 году.
Эрик Уилсон,

-1

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


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

4
Я могу сказать то же самое о гибкой. Младшие разработчики без руководства могут быстро и быстро создать беспорядок.
Чарльз Ламберт
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.