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

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

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

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

Является ли Agile Software Development скорее гибким процессом, чем гибким продуктом?

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

Agile несовместим с разработкой программного обеспечения, которая определяется договором.

• Контракты должны быть Хард, вы платите X, мы делаем Y. Вы хотите X + M, вы платите нам Y + (M * N)
• Контракты ДОЛЖНЫ быть выполнимыми (т.е. не открытыми), иначе они не являются законными контактами. (Когда контакт задействован, вы должны пройти строгий процесс контроля изменений.)

Многие консалтинговые магазины претендуют на Agile, они лгут. Они просто говорят это, потому что Agile получил статус Buzz Word.

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

Если вы сосредоточены на выполнении (как вы считаете, в первую очередь) самого важного, то проект завершится, когда:

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

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

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

Никогда, и в этом вся прелесть.

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

Не часто упоминаемая деловая особенность этой технологии, не так ли?

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

Есть четыре фундаментальных ограничения для любого инженерного проекта; объем, стоимость, время и качество. Водопад предполагает, что они будут статичными. Это неверное предположение; один или несколько из них ВСЕГДА меняются. Ползучесть области, урезанные бюджеты и другие «неизвестные неизвестные» ВСЕГДА вмешиваются в проект, изменяя ограничения. Водопад не предвидит этого, поэтому, когда это происходит, проект меняется нежелательным образом; важные функции, которые еще не были добавлены, исчезают, или выполняются быстро, или нужно отодвигать релиз, или стоить надувные шары, поскольку премьер-министр подбрасывает деньги новым разработчикам, чтобы они помогли все сделать правильно.

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

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

Что касается определения конечных точек, вы правы; Agile проект МОЖЕТ продолжаться вечно. Однако, то же самое можно сказать и о традиционном SLDC; клиент часто возвращается с большим количеством денег и списком пожеланий обновлений. Разница в том, что нет четкой границы между «анализом», «дизайном», «разработкой» и «обслуживанием» при рассмотрении проекта в целом; все это происходит по кирпичику, спринт за спринтом. Если в какой-то момент владелец хочет назвать проект «выполнено», он может, и у него будет общая сумма «кирпичей», за которые он заплатил, в сплошной «стене»; он может быть не таким высоким или простираться так далеко, как планировалось изначально, но он прочно закреплен, выполняет свою работу и может быть добавлен позднее с минимальным сносом.

Он заканчивается, как только все функции реализованы и все ошибки исправлены.

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

Фиксированная цена часть 1, что в этом плохого?

Фиксированная цена, часть 2, исправьте это с гибкой!

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

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