缺乏真正的風險管理與控制是導致軟件項目失敗的重要原因。實施有效的風險管理，做到真正風險驅動的迭代式開發，盡早排除架構(性能上)的風險也是重要的。因此，風險管理是軟件項目管理的第一管理要點。
軟件項目失敗的種種問題
當筆者三年前讀到《漫談企業應用項目的軟件開發過程:一個PRM系統實施的經驗與教訓》時，發現它是一篇非常難得的好文章。
國內類似這樣的軟件工程案例分析太少了，很多人沒有時間寫或舍不得與旁人分享其中的美妙，何況這篇文章還是專門針對XP、RUP并涉及到敏捷統一過程實踐的。
除了這篇PRM(伙伴關系管理)案例外，Johnson其實早在2002年7 月還發表過一篇《從一個項目談XP在國內的應用》，該文在網絡上流傳甚廣。
這兩篇文章好像是國內互聯網上早公開的XP(極限編程)實踐案例，還是嘗試XP、RUP整合的案例。姑且不論它們是否真正做到了敏捷，整合是否成功，但這兩個應用案例的結果恰好一個成功，一個失敗，其價值在于真實性和典型性，具有很好的說服力和教育意義。
不管結果如何，PRM原文的篇幅不長，卻有很多值得我們借鑒和學習的地方。筆者認為這個項目無論從商務角度，還是從工程技術的角度來看，都是比較失敗的。
PRM系統雖然通過2個月緊張的敏捷、迭代開發并準時交付使用，但卻后來出現性能問題，大半年之后仍然沒有通過客戶驗收，不但有幾十萬尾款沒有收到，而且還影響了開發商其它項目的投標。
為什么一個曾一度成功按時交付的系統，在新舊系統數據集成、上線運行的幾個月后會出現嚴重的性能問題，并暴露出系統架構設計上的缺陷，導致遲遲無法獲得客戶的信任，讓項目各方都陷于被動和尷尬呢?是XP、RUP不行?還是敏捷過程、方法不行?有沒有可能事先避免這種典型的風險呢?以上所有這些有趣的問題，都值得我們深入探究。
迭代真正的目的是為了通過加速客戶反饋，顯著地消除開發風險，這要求每次迭代結束必須有一個可運行、可演示的系統。這時的系統可能功能上還不完整，僅僅是一個骨架，但它總是系統開發中難、重要同時是風險大的部分。
RUP核心之一:風險驅動的迭代
風險驅動的迭代是RUP的核心特征之一，XP對此強調的不夠，在早期的XP項目中主要是客戶驅動的。所以，真正的迭代式開發在項目早期允許客戶對可運行的系統進行驗證，從而使項目的風險減到小。
開發工作也應該根據風險的大小來安排，通過迭代及時調整優先級，風險越大的任務越應該及早設計、實現、測試和反饋。
我們知道，RUP從風險驅動出發把一個軟件項目分為四個階段:起始階段、細化階段、構造階段和移交階段，這四個階段分別對應著項目的四個里程碑。起始階段主要消除項目的業務風險，細化階段應該盡力消除項目的主要技術風險:架構風險(同時包括功能和非功能兩方面)。很遺憾，PRM項目是在到了項目后一個階段:移交階段。在系統運行了幾個月、數據遷移完成之后才發現架構設計上存在著嚴重的性能缺陷需要修補。重要的是:在項目之初的合同上其實已經對數據遷移、上線運行的要求作出了規定。
這導致了大架構級風險:系統性能滿足用戶的真實需要嗎?直到臨近項目結束也未能被消除。實際上PRM項目的“細化階段”并未真正完成，建立穩定、可靠的系統架構的里程碑目標也從未達到。
在項目幾近成功、圓滿結束的時候，突然爆炸一顆碩大的“地雷”(嚴重的系統缺陷或問題)，導致項目進度拖延甚至失控，人員失和，資金拖欠，這是軟件開發中糟糕的一種情況。
不幸的是，這種在各種經典教材中都能大量看到的案例，再一次地在已經(部分)采用了敏捷XP、RUP實踐的PRM項目上重演了。那么，我們有沒有可能事先防范PRM項目這顆延遲爆炸的“地雷”呢?
當年PRM項目已經花了10個月的時間，卻仍未能通過客戶驗收。前期用了2個月完成功能開發，2個月部署和試運行，從第5個月完成實際數據導入、開始正式運行起，出現了嚴重的性能問題。
隨后的6個月基本上都用在了系統的性能優化和改進上。總體上項目開發給人一種手忙腳亂、進度失控的感覺。現在看來，PRM項目的進度至少延誤了一倍時間。
軟件工程不相信眼淚
如果PRM團隊和客戶從一開始意識到系統潛在的性能問題，明確了對系統容量的要求;如果PRM系統的架構師擁有足夠的設計經驗，系統表示層、控制層和數據資源層在上線之前已經得到優化，提供了足夠的性能;如果架構設計評審產生了真正的效用;如果 PRM 團隊做到了完備的系統測試;如果時間能夠倒流……。
所有這些“如果”當中，只要有一條靈驗，那么那顆可惡的“地雷”可能不復存在了。
PRM項目可不可以做得更成功呢?答案是肯定的，我們不妨逆向思維:如果PRM團隊能夠把這個項目重頭再做一遍，把吸取到的教訓和學到的軟件工程“新”知識都用上，在5個月內提供滿足客戶實際要求的系統應該足夠了，至少PRM團隊下次再遇到類似的項目他們成功的幾率肯定會大許多。
規避風險，成熟的軟件工程可以設置幾道防線，采取許多措施。如果PRM項目按照RUP 風險驅動的迭代方式來做，那么從項目一開始我們應該對需求、架構進行更為細致、全面的分析，既包括功能，也包括非功能，還可以通過多次迭代反饋來確認分析的結果。
假設如果不知道有哪些風險，我們又如何來防范?所以，關鍵是要建立一張隨著迭代演進不斷被動態更新維護的風險清單(RUP工件叫Risk List)，制定出防范其中所有主要風險的預案。
PRM項目而言，一方面，功能開發不是一個重大風險，因為有舊的PHP系統、源代碼和現成的算法可以參考。另一方面，J2EE的應用架構設計得不好可能會存在性能問題。
因此，我們應該把注意力更多放到系統的非功能風險上(性能、可靠性、可維護性等)。具體表現為:客戶應用訪問的大并發用戶數到底是多少?我們交付到客戶手里的系統大容量又是多少?怎樣才能保證系統的性能?如果上線后性能達不到，不能滿足客戶要求怎么辦?等等。
明確了項目所面臨的重大風險，比如系統的性能問題，我們可以根據需求和設計方案制定出完善的、有針對性的測試計劃。包括在客戶可接受的響應時間要求下，系統大能夠支持多少個用戶的并發訪問(具體可細分為增、刪、改、查等多個操作類型)。
明確了項目的風險、需求還不行，作為風險預案的落實，我們還應該進行系統性能、可靠性等方面的設計，真正(通過編碼)做出一個符合要求的架構(框架)基礎，通過迭代開發、測試和評審對此進行驗證。
在開發階段，系統還未部署，如果我們無法獲得真實的用戶和使用環境怎么辦?用模擬測試!對，如果嚴格按照 RUP 風險驅動的迭代演進式開發進行管理，在半年多的時間里應該還是有機會盡早發現這個問題的。但是，這種方式可以消除局部的缺陷，但卻很難發現全局性的架構問題。對于軟件架構，“頭痛醫頭，腳痛醫腳”的做法往往是行不通的。
PR項目雖然模仿X迭代周期，甚至每天都開例會(這有點像Scrum)，很容易獲得真實的項目情況，像"掀開地毯下面的東西"，保證了初始版本的準時交付(在保證PRM前期進度方面，迭代還是有功勞的)，卻仍然沒有能夠防止較大風險的發生(交付系統幾個月后才逐漸暴露出性能和架構上的質量問題)。
可以說，這并沒有達到XP或RUP迭代開發的終目的。在項目初期，沒有把合同中已經提到的數據遷移視為一個關鍵風險，是前期分析工作或者說整個項目的一大失誤。
