Как готовое программное обеспечение сочетается с гибкой разработкой?[закрыто]

Question

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

---

Я вижу две ситуации, которые представляют для меня особый интерес:

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

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

---

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

Мои вопросы:

1. Как готовое программное обеспечение сочетается с гибкой разработкой?
2. Как гибкий менеджер и гибкий разработчик справляются с такими случаями?
3. Что говорят об этих случаях гибкие парадигмы?

Answer 1

Сценарий 1:

Это может произойти независимо от OTS-характера компонента.Гибкий не значит близорукий..вам нужно знать большие куски..части фреймворка и заранее потратьте время на обдумывание.Тем не менее, вы можете строить только на основе того, что знаете..Откладывайте только до последнего ответственного момента. Дальше нужно выбрать один из вариантов и приступить к нему.(Я бы избегал сторонних приложений, если только стоимость их собственной разработки невозможна.но это только я).Прототипируйте несколько решений, чтобы проверить осуществимость с помощью списка известных требований.Пусть все будет свободно связанным (заменяемым), легко заменяемым и полностью протестированным.Если вы дойдете до развилки, продолжая взламывать или переписывать, вам нужно будет подумать о том, что имеет большую ценность для бизнеса, и выбрать этот вариант.Все сводится к следующему: «Теперь, когда мы здесь, что лучше всего мы можем сделать сейчас?»

Сценарий 2:

Это может произойти, хотя шансы невелики по сравнению с тем, как команда потратит 2-3 месяца на то, чтобы «окончательно доработать» требования, а затем обнаружит, что потребности рынка или мнение клиентов изменились, и «Теперь мы хотим, чтобы все было именно так».Опять же, это вопрос о том, до какого момента вы готовы исследовать и исследовать, прежде чем вступить на путь действия.Принимайте мудрые решения, используя любую информацию, которая у вас есть на данный момент.Оглядываясь назад, всегда 20-20, но клиенты не будут ждать вечно.Вы не можете дождаться момента, когда требования объединятся, чтобы соответствовать известному компоненту OTS :)

Agile говорит: Делайте все, что имеет смысл, и исключите действия, не добавляющие ценности :) Agile — это не волшебное средство. просто мои 2 цента :)

Answer 2

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

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

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

Помните, что «открытость» — это важная часть, и поставщик часто рекламирует свое решение как открытое, хотя на самом деле это не так.

Answer 3

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

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

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

Answer 4

Обсуждение C2 вики: http://c2.com/cgi/wiki?BuyDontBuild