軟體開發模型之一 萬祖歸宗是瀑布

案例

案例一

某公司承接了一個電子政務平台的項目，該項目主要分“政務辦公”與“政務公開” 兩大部分。甲方很配合，協助整理了國家電子政務管理規範與相當文檔。溝通擬定的開發週期也相對寬鬆。

甲方聘請了監理；三方各派代表成立項目控制委員會（CCB）。公司也在項目團隊中派了長駐QA小組，協助專案管理。

但是，電子政務並不是公司的主營業務，整個研發團隊是公司臨時招聘組建，約六人左右，大多是應屆畢業，除了專案經理之外，最有經驗的也不過兩三年開發經曆。

針對這種情況，作為專案經理，應該採用哪種開發模式比較合理？ 

 案例二

當項目剛開始不久，甲方接到通知，要在當年國慶前後參加全國電子政務網站評比，當地主管領導希望能在九月份先進行本地區評比。準備充足後，再備戰全國評比。而此時，剛過五一，總計用於研發時間也就四個月左右。

項目主管在瞭解情況後，向CCB提出項目變更申請，考慮先做前端功能，後端僅做現階段需要的模組。同時，向公司申請從其它項目組，抽調技術骨幹到該項目組協助。

經各方協商，以上方案得到支援，專案範圍、開發計劃的變更得到認可；公司抽調三名有多年協作經驗的老員工，到該團隊參與開發。

在這種情況下，作為專案經理，應該採用哪種開發模式？

 案例三

最終，該電子政務平台項目完滿成功。團隊成員覺得可以考慮將該項目轉化為產品，作為一項穩定業務看待，向公司建議後，得到公司高層支援，公司內部通過評審，確定以上思路。專案經理轉為產品研發經理，從事產品化工作。

在評審過程中，也顧慮到很多問題，具體如下：

研發經理考慮到在項目開發中，由於工期限制，程式架構不夠靈活，產品化後調整工作量會比較大，存在技術風險；

公司高層認為，市場定位依然不夠明晰，大幅投資不太現實，現階段僅限嘗試。

在這種情況下，該研發經理，應該採用哪種開發模式？

 分析

當然在實際開發中，情況各不相同，在同一個開發週期內，使用多個開發模型也是很正常的。在這裡，為了方便講解，我僅列舉主要的開發模型。

 案例一

第一種情況，首選瀑布模型

幾乎在所有軟體開發模型中（除了瀑布模型），都會說，“由於傳統的瀑布式開發……”，然後都是它的一堆問題。我們聽了它太多的不足，卻很少有人關注它的優勢了。幾乎在所有的軟體工程章節中，介紹軟體開發模型時，無一例外第一個就是“瀑布”，可見瀑布模型的重要性。我可以這麼說，軟體開發模型萬祖歸宗是“瀑布”。其它的開發模型都是為瞭解決瀑布模型的缺陷而產生的，沒有哪個可以顛覆瀑布模型。

我們看看上述項目情況，最大的不利之處是項目團隊不成熟，技術強弱先不說，新團隊溝通肯定存在障礙，而且成員穩定性有待考驗，越是新人離職率越高。

說一句名言，“新團隊，用新技術，開發新產品，成功率接近零”。而對一個新團隊來說，當務之急是正常化管理，瀑布模型是比較容易實施規範的。雖然它應對需求變化時不夠靈活，但在上述情況上，需求範圍相對明確，開發週期相對寬鬆，雖然細節還需要溝通，但可以用時間彌補變更影響。

另一方面，甲方聘請監理，監理會遵循成熟的項目過程管理的方法，CMMI將是他的首先理論依據。雖然程式員會認為文檔是形式化的東西，但是監理一定會要。

文檔驅動是瀑布模型的最大特點，是它的優勢，也是它的劣勢。

 案例二 

第二種情況 可以採用RUP模型

當研發周期被縮短後，並不代表監理將不再監管項目。他依然會按照項目過程管理的方法來監管，只是有可能要求的不那麼嚴格了。

新增加的三名老員工，不僅提升了技術力量，也有效彌補了溝通上的不足。在開發人力上，九名成員已經相當充沛了。雖然需求細節不明確，但需求範圍是比較明確的。所以，團隊成員面臨的最大問題是如何應對需求不明晰帶來的影響。

團隊成員決定，儘可能把各項工作提前。例如，哪些需求明確了，就開始設計哪些；哪些設計了，就開始開發哪些；哪些開發了，哪些開始測試……，整體仍然按瀑布式的方式走，但各個環節相互交疊，通過迭代 逐漸精化各個環節。總之，搞清楚哪些就先做哪些。這個理念是不是很像敏捷開發？不，它不是，這種開發模型是RUP（統一過程）。

敏捷開發與RUP還是有區別的，以後再說。

 案例三

第三種情況 建議採用螺旋模型

當項目轉為產品時，會面臨很多問題。首先是“技術債務”，快速開發會造成大量垃圾代碼，雖然公司提倡重構，但項目結束後，骨幹力量被抽走，個別成員離職，等等原因，很難會有機會、有人再對項目進行重構。只能在以後的工作日，逐漸改善。這其中就隱含了技術風險。

再加上產品化的市場定位問題，營銷的不確定性，經營風險也會被公司權衡。公司會考慮，先做一段試試，如果做得好，就繼續做，如果不行就另做打算。

在這種情況下，風險的控制是當前開發中的最大問題，而螺旋模型就是針對此類問題而生。

每個螺旋過程，首先是風險分析、需求確定、計劃、實施、評測；達到一個階段後，再進行風險分析，如果可行，就進入下一個螺旋。

要注意的是，每一個螺旋，就是一個小瀑布。 

後記：精義入神，以致用

上述案例只是為了方便大家理解開發模型的特點，還有很多細節未能涉及。關鍵是，理解了它，才能更加有效利用它。不同的開發模型，針對不同的問題有特效，我在前文中用粗體標識出了。在我看過的大多數軟體工程書中，這三種開發模型都是在列的，很具典型性。

除了上述三種開發模型，還有噴泉模型、V型、微軟開發模型等等，甚至還有原型開發模型，但我個人認為欠妥 ，原型開發不能算模型，它就像敏捷開發一樣，只能算開發方法。

“精義入神，以致用（引自《周易》）”