2009-04-16 2 views
1

В сценариях, где заказчик предлагает RFP для выбора поставщика на основе определенных технических и финансовых критериев, то есть в проектах с фиксированной областью/фиксированной ценой, существует ли какая-либо методология, кроме WATERFALL. То есть Может ли применяться инкрементный/итеративный подход?Имеет ли фиксированный объем/фиксированные цены проекты = WaterFall?

ответ

1

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

+0

Проект фиксированный объем/фиксированная цена. Фактически, он основан на тендере по RFP. и, таким образом, это означает, что перед тем, как я смогу начать разработку, необходимо сначала отложить подробные требования (SRS), я могу только увеличить dev и тестирование. – Shadi

+0

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

1

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

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

0

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

Водопад - это когда вы делаете все планирование, затем все кодирование, а затем все тестирование/отладка в этом порядке. Вместо этого вы можете сделать достаточно планирования, а затем повторить цикл планирования/кодирования/тестирования.

+0

Я предполагаю, что Итерации начнутся, как только клиент выйдет из SRS (подробные требования), чтобы любые будущие изменения попали под управление запросами на изменение. Правильно? – Shadi

+0

Да, это было бы моим предположением. –

0

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