缺乏真正的風(fēng)險(xiǎn)管理與控制是導(dǎo)致軟件項(xiàng)目失敗的重要原因。實(shí)施有效的風(fēng)險(xiǎn)管理，做到真正風(fēng)險(xiǎn)驅(qū)動的迭代式開發(fā)，盡早排除架構(gòu)(性能上)的風(fēng)險(xiǎn)也是重要的。因此，風(fēng)險(xiǎn)管理是軟件項(xiàng)目管理的第一管理要點(diǎn)。

軟件項(xiàng)目失敗的種種問題

當(dāng)筆者三年前讀到《漫談企業(yè)應(yīng)用項(xiàng)目的軟件開發(fā)過程:一個PRM系統(tǒng)實(shí)施的經(jīng)驗(yàn)與教訓(xùn)》時，發(fā)現(xiàn)它是一篇非常難得的好文章。

國內(nèi)類似這樣的軟件工程案例分析太少了，很多人沒有時間寫或舍不得與旁人分享其中的美妙，何況這篇文章還是專門針對XP、RUP并涉及到敏捷統(tǒng)一過程實(shí)踐的。

除了這篇PRM(伙伴關(guān)系管理)案例外，Johnson其實(shí)早在2002年7 月還發(fā)表過一篇《從一個項(xiàng)目談XP在國內(nèi)的應(yīng)用》，該文在網(wǎng)絡(luò)上流傳甚廣。

這兩篇文章好像是國內(nèi)互聯(lián)網(wǎng)上早公開的XP(極限編程)實(shí)踐案例，還是嘗試XP、RUP整合的案例。姑且不論它們是否真正做到了敏捷，整合是否成功，但這兩個應(yīng)用案例的結(jié)果恰好一個成功，一個失敗，其價值在于真實(shí)性和典型性，具有很好的說服力和教育意義。

不管結(jié)果如何，PRM原文的篇幅不長，卻有很多值得我們借鑒和學(xué)習(xí)的地方。筆者認(rèn)為這個項(xiàng)目無論從商務(wù)角度，還是從工程技術(shù)的角度來看，都是比較失敗的。

PRM系統(tǒng)雖然通過2個月緊張的敏捷、迭代開發(fā)并準(zhǔn)時交付使用，但卻后來出現(xiàn)性能問題，大半年之后仍然沒有通過客戶驗(yàn)收，不但有幾十萬尾款沒有收到，而且還影響了開發(fā)商其它項(xiàng)目的投標(biāo)。

為什么一個曾一度成功按時交付的系統(tǒng)，在新舊系統(tǒng)數(shù)據(jù)集成、上線運(yùn)行的幾個月后會出現(xiàn)嚴(yán)重的性能問題，并暴露出系統(tǒng)架構(gòu)設(shè)計(jì)上的缺陷，導(dǎo)致遲遲無法獲得客戶的信任，讓項(xiàng)目各方都陷于被動和尷尬呢?是XP、RUP不行?還是敏捷過程、方法不行?有沒有可能事先避免這種典型的風(fēng)險(xiǎn)呢?以上所有這些有趣的問題，都值得我們深入探究。

迭代真正的目的是為了通過加速客戶反饋，顯著地消除開發(fā)風(fēng)險(xiǎn)，這要求每次迭代結(jié)束必須有一個可運(yùn)行、可演示的系統(tǒng)。這時的系統(tǒng)可能功能上還不完整，僅僅是一個骨架，但它總是系統(tǒng)開發(fā)中難、重要同時是風(fēng)險(xiǎn)大的部分。

RUP核心之一:風(fēng)險(xiǎn)驅(qū)動的迭代

風(fēng)險(xiǎn)驅(qū)動的迭代是RUP的核心特征之一，XP對此強(qiáng)調(diào)的不夠，在早期的XP項(xiàng)目中主要是客戶驅(qū)動的。所以，真正的迭代式開發(fā)在項(xiàng)目早期允許客戶對可運(yùn)行的系統(tǒng)進(jìn)行驗(yàn)證，從而使項(xiàng)目的風(fēng)險(xiǎn)減到小。

開發(fā)工作也應(yīng)該根據(jù)風(fēng)險(xiǎn)的大小來安排，通過迭代及時調(diào)整優(yōu)先級，風(fēng)險(xiǎn)越大的任務(wù)越應(yīng)該及早設(shè)計(jì)、實(shí)現(xiàn)、測試和反饋。

我們知道，RUP從風(fēng)險(xiǎn)驅(qū)動出發(fā)把一個軟件項(xiàng)目分為四個階段:起始階段、細(xì)化階段、構(gòu)造階段和移交階段，這四個階段分別對應(yīng)著項(xiàng)目的四個里程碑。起始階段主要消除項(xiàng)目的業(yè)務(wù)風(fēng)險(xiǎn)，細(xì)化階段應(yīng)該盡力消除項(xiàng)目的主要技術(shù)風(fēng)險(xiǎn):架構(gòu)風(fēng)險(xiǎn)(同時包括功能和非功能兩方面)。很遺憾，PRM項(xiàng)目是在到了項(xiàng)目后一個階段:移交階段。在系統(tǒng)運(yùn)行了幾個月、數(shù)據(jù)遷移完成之后才發(fā)現(xiàn)架構(gòu)設(shè)計(jì)上存在著嚴(yán)重的性能缺陷需要修補(bǔ)。重要的是:在項(xiàng)目之初的合同上其實(shí)已經(jīng)對數(shù)據(jù)遷移、上線運(yùn)行的要求作出了規(guī)定。

這導(dǎo)致了大架構(gòu)級風(fēng)險(xiǎn):系統(tǒng)性能滿足用戶的真實(shí)需要嗎?直到臨近項(xiàng)目結(jié)束也未能被消除。實(shí)際上PRM項(xiàng)目的“細(xì)化階段”并未真正完成，建立穩(wěn)定、可靠的系統(tǒng)架構(gòu)的里程碑目標(biāo)也從未達(dá)到。

在項(xiàng)目幾近成功、圓滿結(jié)束的時候，突然爆炸一顆碩大的“地雷”(嚴(yán)重的系統(tǒng)缺陷或問題)，導(dǎo)致項(xiàng)目進(jìn)度拖延甚至失控，人員失和，資金拖欠，這是軟件開發(fā)中糟糕的一種情況。

不幸的是，這種在各種經(jīng)典教材中都能大量看到的案例，再一次地在已經(jīng)(部分)采用了敏捷XP、RUP實(shí)踐的PRM項(xiàng)目上重演了。那么，我們有沒有可能事先防范PRM項(xiàng)目這顆延遲爆炸的“地雷”呢?

當(dāng)年P(guān)RM項(xiàng)目已經(jīng)花了10個月的時間，卻仍未能通過客戶驗(yàn)收。前期用了2個月完成功能開發(fā)，2個月部署和試運(yùn)行，從第5個月完成實(shí)際數(shù)據(jù)導(dǎo)入、開始正式運(yùn)行起，出現(xiàn)了嚴(yán)重的性能問題。

隨后的6個月基本上都用在了系統(tǒng)的性能優(yōu)化和改進(jìn)上�？傮w上項(xiàng)目開發(fā)給人一種手忙腳亂、進(jìn)度失控的感覺�，F(xiàn)在看來，PRM項(xiàng)目的進(jìn)度至少延誤了一倍時間。

軟件工程不相信眼淚

如果PRM團(tuán)隊(duì)和客戶從一開始意識到系統(tǒng)潛在的性能問題，明確了對系統(tǒng)容量的要求;如果PRM系統(tǒng)的架構(gòu)師擁有足夠的設(shè)計(jì)經(jīng)驗(yàn)，系統(tǒng)表示層、控制層和數(shù)據(jù)資源層在上線之前已經(jīng)得到優(yōu)化，提供了足夠的性能;如果架構(gòu)設(shè)計(jì)評審產(chǎn)生了真正的效用;如果 PRM 團(tuán)隊(duì)做到了完備的系統(tǒng)測試;如果時間能夠倒流……。

所有這些“如果”當(dāng)中，只要有一條靈驗(yàn)，那么那顆可惡的“地雷”可能不復(fù)存在了。

PRM項(xiàng)目可不可以做得更成功呢?答案是肯定的，我們不妨逆向思維:如果PRM團(tuán)隊(duì)能夠把這個項(xiàng)目重頭再做一遍，把吸取到的教訓(xùn)和學(xué)到的軟件工程“新”知識都用上，在5個月內(nèi)提供滿足客戶實(shí)際要求的系統(tǒng)應(yīng)該足夠了，至少PRM團(tuán)隊(duì)下次再遇到類似的項(xiàng)目他們成功的幾率肯定會大許多。

規(guī)避風(fēng)險(xiǎn)，成熟的軟件工程可以設(shè)置幾道防線，采取許多措施。如果PRM項(xiàng)目按照RUP 風(fēng)險(xiǎn)驅(qū)動的迭代方式來做，那么從項(xiàng)目一開始我們應(yīng)該對需求、架構(gòu)進(jìn)行更為細(xì)致、全面的分析，既包括功能，也包括非功能，還可以通過多次迭代反饋來確認(rèn)分析的結(jié)果。

假設(shè)如果不知道有哪些風(fēng)險(xiǎn)，我們又如何來防范?所以，關(guān)鍵是要建立一張隨著迭代演進(jìn)不斷被動態(tài)更新維護(hù)的風(fēng)險(xiǎn)清單(RUP工件叫Risk List)，制定出防范其中所有主要風(fēng)險(xiǎn)的預(yù)案。

PRM項(xiàng)目而言，一方面，功能開發(fā)不是一個重大風(fēng)險(xiǎn)，因?yàn)橛信f的PHP系統(tǒng)、源代碼和現(xiàn)成的算法可以參考。另一方面，J2EE的應(yīng)用架構(gòu)設(shè)計(jì)得不好可能會存在性能問題。

因此，我們應(yīng)該把注意力更多放到系統(tǒng)的非功能風(fēng)險(xiǎn)上(性能、可靠性、可維護(hù)性等)。具體表現(xiàn)為:客戶應(yīng)用訪問的大并發(fā)用戶數(shù)到底是多少?我們交付到客戶手里的系統(tǒng)大容量又是多少?怎樣才能保證系統(tǒng)的性能?如果上線后性能達(dá)不到，不能滿足客戶要求怎么辦?等等。

明確了項(xiàng)目所面臨的重大風(fēng)險(xiǎn)，比如系統(tǒng)的性能問題，我們可以根據(jù)需求和設(shè)計(jì)方案制定出完善的、有針對性的測試計(jì)劃。包括在客戶可接受的響應(yīng)時間要求下，系統(tǒng)大能夠支持多少個用戶的并發(fā)訪問(具體可細(xì)分為增、刪、改、查等多個操作類型)。

明確了項(xiàng)目的風(fēng)險(xiǎn)、需求還不行，作為風(fēng)險(xiǎn)預(yù)案的落實(shí)，我們還應(yīng)該進(jìn)行系統(tǒng)性能、可靠性等方面的設(shè)計(jì)，真正(通過編碼)做出一個符合要求的架構(gòu)(框架)基礎(chǔ)，通過迭代開發(fā)、測試和評審對此進(jìn)行驗(yàn)證。

在開發(fā)階段，系統(tǒng)還未部署，如果我們無法獲得真實(shí)的用戶和使用環(huán)境怎么辦?用模擬測試!對，如果嚴(yán)格按照 RUP 風(fēng)險(xiǎn)驅(qū)動的迭代演進(jìn)式開發(fā)進(jìn)行管理，在半年多的時間里應(yīng)該還是有機(jī)會盡早發(fā)現(xiàn)這個問題的。但是，這種方式可以消除局部的缺陷，但卻很難發(fā)現(xiàn)全局性的架構(gòu)問題。對于軟件架構(gòu)，“頭痛醫(yī)頭，腳痛醫(yī)腳”的做法往往是行不通的。

PR項(xiàng)目雖然模仿X迭代周期，甚至每天都開例會(這有點(diǎn)像Scrum)，很容易獲得真實(shí)的項(xiàng)目情況，像"掀開地毯下面的東西"，保證了初始版本的準(zhǔn)時交付(在保證PRM前期進(jìn)度方面，迭代還是有功勞的)，卻仍然沒有能夠防止較大風(fēng)險(xiǎn)的發(fā)生(交付系統(tǒng)幾個月后才逐漸暴露出性能和架構(gòu)上的質(zhì)量問題)。

可以說，這并沒有達(dá)到XP或RUP迭代開發(fā)的終目的。在項(xiàng)目初期，沒有把合同中已經(jīng)提到的數(shù)據(jù)遷移視為一個關(guān)鍵風(fēng)險(xiǎn)，是前期分析工作或者說整個項(xiàng)目的一大失誤。