http://blog.csdn.net/fuchunyi/archive/2006/10/22/1345708.aspx
這周去拜訪一個客戶，他們正在實施RUP，問及效果如何，聽到了一些關于迭代化開發的新問題。
這位客戶是一家集成商，主要為甲方開發應用軟件系統。實施迭代化開發的主要目的是控制項目風險，應用項目的最大風險一般都在于需求，采用迭代化可以通過迭代產生的原型系統來收集甲方客戶的反饋，從而及早修正對于客戶需求的誤解。但是開發團隊并沒有象預想中那樣收集到甲方的反饋，甲方還是習慣于用傳統的瀑布模型來評價、驗收系統，他們并沒有對項目過程中交付的原型系統進行認真的確認，所以也沒有太多的意見反饋給開發團隊，很多需求的變更還是要到系統正式驗收時才被提出來。因為在甲方的觀念中，他們還不太認可項目結束之前所提交的中間結果。
另外，項目的合同是按照瀑布模型的階段來簽的，需求分析、概要設計、詳細設計、編碼完成、驗收測試是項目回款的里程碑。采用迭代化開發之后，在原定的概要設計交付時間點上，可能需求分析和概要設計都只完成了部分的工作，比原定計劃要晚一些；而詳細設計和編碼工作都已經開始了一部分，比原定計劃要提前一些。這樣就不能按照原定時間點來要求甲方就需求分析和概要設計那部分工作量付款，對于中國的集成商而言，項目回款是比合同簽定都要重要的工作。
這些問題給我們的經驗教訓是應用項目開發采用迭代化開發流程，也需要讓客戶理解這一點，項目工作說明書中的工作單元內容也需要跟迭代化開發流程來符合。軟件開發流程關系到所有的涉眾(Stakeholder)，僅僅是開發團隊理解并實施這一流程是不夠的。
還有一個反饋來自于很多項目團隊，認為迭代化開發概念上聽起來很有道理，但在項目中實施后往往感覺不到采用這處方法后對項目有什么太大的幫助。迭代化開發的主要目的在于控制項目風險，常見的項目風險如技術架構、客戶需求等等。但是日常工作中的項目往往沒有太多的風險，我們開發的往往是重復性的項目，電信事業部做的就是不同運營商的BOSS項目，社保事業部就是為不同省份開發社保系統，雖然有特殊需求，但系統架構和基本需求完全一樣；更多的項目是對現有系統的維護性開發，實現客戶提出的變更請求和改正軟件缺陷，一般不會涉及到系統架構的改動。在這種類型的項目中，迭代化開發體現的不是對風險的控制，而是系統增量式開發而不斷給涉眾所帶來的信心和鼓舞，開發人員可以在較斷的時間周期內看到自己所開發的系統可以“跑”起來了，客戶則可以看到整個項目在不斷地往前推進。