迭代化開發新問題

這周去拜訪一個客戶，他們正在實施RUP，問及效果如何，聽到了一些關於迭代化開發的新問題。

這位客戶是一家整合商，主要為甲方開發應用軟體系統。實施迭代化開發的主要目的是控制專案風險，應用專案的最大風險一般都在於需求，採用迭代化可以通過迭代產生的原型系統來收集甲方客戶的反饋，從而及早修正對於客戶需求的誤解。但是開發團隊並沒有象預想中那樣收集到甲方的反饋，甲方還是習慣於用傳統的瀑布模型來評價、驗收系統，他們並沒有對專案過程中交付的原型系統進行認真的確認，所以也沒有太多的意見反饋給開發團隊，很多需求的變更還是要到系統正式驗收時才被提出來。因為在甲方的觀念中，他們還不太認可專案結束之前所提交的中間結果。

另外，專案的合同是按照瀑布模型的階段來籤的，需求分析、概要設計、詳細設計、編碼完成、驗收測試是專案回款的里程碑。採用迭代化開發之後，在原定的概要設計交付時間點上，可能需求分析和概要設計都只完成了部分的工作，比原定計劃要晚一些；而詳細設計和編碼工作都已經開始了一部分，比原定計劃要提前一些。這樣就不能按照原定時間點來要求甲方就需求分析和概要設計那部分工作量付款，對於中國的整合商而言，專案回款是比合同簽定都要重要的工作。

這些問題給我們的經驗教訓是應用專案開發採用迭代化開發流程，也需要讓客戶理解這一點，專案工作說明書中的工作單元內容也需要跟迭代化開發流程來符合。軟體開發流程關係到所有的涉眾(Stakeholder)，僅僅是開發團隊理解並實施這一流程是不夠的。

還有一個反饋來自於很多專案團隊，認為迭代化開發概念上聽起來很有道理，但在專案中實施後往往感覺不到採用這處方法後對專案有什麼太大的幫助。迭代化開發的主要目的在於控制專案風險，常見的專案風險如技術架構、客戶需求等等。但是日常工作中的專案往往沒有太多的風險，我們開發的往往是重複性的專案，電信事業部做的就是不同運營商的BOSS專案，社保事業部就是為不同省份開發社保系統，雖然有特殊需求，但系統架構和基本需求完全一樣；更多的專案是對現有系統的維護性開發，實現客戶提出的變更請求和改正軟體缺陷，一般不會涉及到系統架構的改動。在這種型別的專案中，迭代化開發體現的不是對風險的控制，而是系統增量式開發而不斷給涉眾所帶來的信心和鼓舞，開發人員可以在較斷的時間週期內看到自己所開發的系統可以“跑”起來了，客戶則可以看到整個專案在不斷地往前推進。（傅純一）

================================================

其實也不算是新問題，這是作者06年的一篇博文，看後覺得有啟發。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/12231076/viewspace-1233/，如需轉載，請註明出處，否則將追究法律責任。