第一章 簡(jiǎn)介

1.1 研究背景

我之前曾在廈門一家中等規(guī)模（合計(jì)開(kāi)發(fā)人員50人）的軟件公司擔(dān)任項(xiàng)目經(jīng)理，開(kāi)始由于對(duì)軟件工程的不怎么重視，一些失敗的軟件項(xiàng)目給我留下了極深的映象。在失敗和困惑中，我們開(kāi)始反思，也總結(jié)了一些經(jīng)驗(yàn)教訓(xùn)。后來(lái)，我們?cè)陂_(kāi)發(fā)過(guò)程中引入了MSF（Microsoft Solutions Framework）軟件開(kāi)發(fā)模型，并結(jié)合公司的具體情況進(jìn)行了裁減。實(shí)踐證明，我們的軟件工程過(guò)程管理能力大為提高，軟件的質(zhì)量也有較大程度的提高，軟件的交付期也得到了基本保證，已經(jīng)沒(méi)有再發(fā)生那種“永遠(yuǎn)也完不成項(xiàng)目”的情況。

1.2 研究動(dòng)機(jī)

在這篇文章中，主要談?wù)摿嗽诋a(chǎn)品開(kāi)發(fā)中的項(xiàng)目管理問(wèn)題，此處的“產(chǎn)品開(kāi)發(fā)”是指做一個(gè)通用的軟件產(chǎn)品或者一些具體的領(lǐng)域性系統(tǒng)集成項(xiàng)目。下面我主要結(jié)合我們公司實(shí)施MSF的情況，談?wù)勛约簩?duì)軟件工程的一些初步看法。

第二章 MSF概要介紹

MSF主要由幾個(gè)模型構(gòu)成，其中包括：組隊(duì)模型、開(kāi)發(fā)過(guò)程模型、應(yīng)用模型、風(fēng)險(xiǎn)管理模型。下面只對(duì)組隊(duì)模型進(jìn)行較詳細(xì)的介紹，其他模型則簡(jiǎn)要說(shuō)明，更詳細(xì)的資料請(qǐng)查閱[2]。

2.1組隊(duì)模型

MSF把軟件開(kāi)發(fā)分成了六個(gè)小組，分別是：程序管理組、產(chǎn)品管理組、開(kāi)發(fā)組、用戶培訓(xùn)組、測(cè)試組、安裝管理組。組隊(duì)的原則是小隊(duì)（一般3－8人）、多側(cè)面；角色交叉、目標(biāo)一致；人員技術(shù)、業(yè)務(wù)精；關(guān)注能力和交貨期；對(duì)項(xiàng)目的前景認(rèn)識(shí)一致；人人參與設(shè)計(jì)；善于總結(jié)經(jīng)驗(yàn)；共同管理、共同決策，項(xiàng)目人員同地工作等。

程序管理組的工作是： ①推動(dòng)開(kāi)發(fā)過(guò)程；②負(fù)責(zé)產(chǎn)品規(guī)范說(shuō)明；③溝通和協(xié)調(diào)各組關(guān)系；④管理項(xiàng)目進(jìn)度，報(bào)告項(xiàng)目狀態(tài)；⑤把握總體決策。

產(chǎn)品管理組的工作是： ①代表客戶（customer）；②描述項(xiàng)目產(chǎn)品輪廓；③負(fù)責(zé)需求定義；④平衡功能和進(jìn)度要求；⑤負(fù)責(zé)市場(chǎng)、宣傳、公共關(guān)系等。

開(kāi)發(fā)組的工作是： ①概要、詳細(xì)設(shè)計(jì)；②完成產(chǎn)品開(kāi)發(fā)；③準(zhǔn)備安裝的產(chǎn)品。

測(cè)試組的工作是： ①制定測(cè)試策略和計(jì)劃；②盡可能發(fā)現(xiàn)問(wèn)題。

用戶培訓(xùn)組工作是： ①代表終端用戶（end user）；②負(fù)責(zé)用戶需求定義；③把握可用性和用戶性能指標(biāo)。

安裝管理組工作是： ①負(fù)責(zé)產(chǎn)品安裝；②把握可管理性和可支持性。

各組的地位同等，非領(lǐng)導(dǎo)關(guān)系，并充分授權(quán)，保證目標(biāo)清晰一致，由各組的負(fù)責(zé)人共同管理項(xiàng)目。

2.2過(guò)程模型

MSF過(guò)程模型主要確立了四個(gè)重要的里程碑：前景范圍確認(rèn)、項(xiàng)目規(guī)劃確認(rèn)、開(kāi)發(fā)完成、對(duì)外發(fā)布，通過(guò)控制這四個(gè)里程碑來(lái)分解管理項(xiàng)目過(guò)程。

2.3應(yīng)用模型
MSF應(yīng)用模型是分層次的應(yīng)用模型，大體可分為三層，用戶層、業(yè)務(wù)層和數(shù)據(jù)層，各層次通過(guò)標(biāo)準(zhǔn)組件進(jìn)行封裝，互相通訊調(diào)用來(lái)完成系統(tǒng)任務(wù)。

2.4風(fēng)險(xiǎn)模型
MSF風(fēng)險(xiǎn)管理過(guò)程主要包括：風(fēng)險(xiǎn)識(shí)別、風(fēng)險(xiǎn)表述，通過(guò)分析、計(jì)劃、跟蹤和控制過(guò)程，最終解除風(fēng)險(xiǎn)。

第三章 MSF在項(xiàng)目中的具體應(yīng)用

3.1組隊(duì)模型裁減

在中小軟件企業(yè)中，一般項(xiàng)目的規(guī)模不會(huì)太大，通常是十幾個(gè)人，少的只有幾個(gè)人，所以必須對(duì)MSF的組隊(duì)模型進(jìn)行簡(jiǎn)化。通常的做法是劃分成三個(gè)組，程序管理組：一般對(duì)應(yīng)于原來(lái)的項(xiàng)目經(jīng)理，通常就項(xiàng)目經(jīng)理一個(gè)人，如果需要還可以給他配個(gè)組手，通常稱為“項(xiàng)目秘書”；產(chǎn)品管理和測(cè)試組：一般包括MSF中的產(chǎn)品管理組，測(cè)試組、用戶培訓(xùn)和安裝管理，主要代表用戶確定軟件需求并測(cè)試產(chǎn)品是否滿足需求；開(kāi)發(fā)組：和MSF的開(kāi)發(fā)組相同。這樣的組隊(duì)，比較符合中小項(xiàng)目的需要，在實(shí)踐中也證明是比較合理的。

首先，確立項(xiàng)目經(jīng)理角色，符合一般公司的管理模式，比較容易被接受。如果有多人同時(shí)負(fù)責(zé)的話，容易產(chǎn)生責(zé)權(quán)理不清楚，互相扯皮的現(xiàn)象。有一個(gè)項(xiàng)目經(jīng)理對(duì)項(xiàng)目完全負(fù)責(zé)，遇到問(wèn)題容易很快得到解決；他作為項(xiàng)目組代表，負(fù)責(zé)向上級(jí)匯報(bào)工作，能使其他人全力投入到項(xiàng)目中，而不至于在日常的事務(wù)中耽誤太多時(shí)間，從而在某種程度上也提高了工作效率。

在原來(lái)的很多項(xiàng)目中，大多都沒(méi)有設(shè)置產(chǎn)品管理角色，他的工作一般由項(xiàng)目經(jīng)理兼任。這樣的做法已證明存在很多問(wèn)題，會(huì)使項(xiàng)目經(jīng)理精力分散，而且產(chǎn)品管理的任務(wù)和項(xiàng)目的日常管理工作也不大相同，如果叫一個(gè)人負(fù)責(zé)，怕兩頭都顧不上搞不好。在產(chǎn)品管理組中，根據(jù)項(xiàng)目的大小，可以設(shè)置兩個(gè)負(fù)責(zé)人，一個(gè)代表用戶確定需求，另一個(gè)主要負(fù)責(zé)測(cè)試，但由前一個(gè)負(fù)總責(zé)。因?yàn)橹挥杏脩舸碚J(rèn)可了的產(chǎn)品品質(zhì)，才是真正可以交付的品質(zhì)。

產(chǎn)品管理經(jīng)理（以下簡(jiǎn)稱產(chǎn)品經(jīng)理）是項(xiàng)目中非常重要的角色，他可以對(duì)技術(shù)不是很精通，但是必須對(duì)產(chǎn)品所服務(wù)的領(lǐng)域非常熟悉，最好是領(lǐng)域?qū)＜遥谒膸ьI(lǐng)下，項(xiàng)目才不至于偏離預(yù)先設(shè)定的前景范圍。他必須對(duì)產(chǎn)品的需求能作出很好的把握，在適當(dāng)?shù)臅r(shí)候能進(jìn)行流程重組，對(duì)產(chǎn)品的可用性和易用性有最終決定權(quán)。根據(jù)我們的經(jīng)驗(yàn)，通過(guò)設(shè)定產(chǎn)品經(jīng)理，主要的感覺(jué)是產(chǎn)品受用戶的歡迎程度增加了，無(wú)用的特性少了，因而也更容易成功。

開(kāi)發(fā)組主要負(fù)責(zé)產(chǎn)品的概要設(shè)計(jì)，詳細(xì)設(shè)計(jì)及代碼實(shí)現(xiàn)，這和一般項(xiàng)目中的開(kāi)發(fā)人員差不多，就不再贅述了。

根據(jù)我們的經(jīng)驗(yàn)，這樣組建的開(kāi)發(fā)團(tuán)隊(duì)既有助于提高工作效率，又能保證有良好的產(chǎn)品質(zhì)量。沒(méi)有設(shè)置產(chǎn)品管理角色的團(tuán)隊(duì)最容易產(chǎn)生的問(wèn)題是開(kāi)發(fā)人員往往喜歡憑他們的主觀臆想來(lái)設(shè)定產(chǎn)品的某些功能，最終導(dǎo)致產(chǎn)品易用性極差，不容易為用戶所接受。

3.2軟件過(guò)程管理
MSF開(kāi)發(fā)過(guò)程總的來(lái)說(shuō)是一個(gè)基于里程碑的，迭代的，風(fēng)險(xiǎn)驅(qū)動(dòng)的過(guò)程。一般遵循如下原則：①進(jìn)度計(jì)劃留有余地；②通過(guò)風(fēng)險(xiǎn)管理減少不確定性因素；③通過(guò)快速原型法盡可能使產(chǎn)品穩(wěn)定和可預(yù)測(cè)；④縮短生命周期；⑤重視創(chuàng)新使資源和性能效率最大化；⑥拆分大項(xiàng)目等。
在過(guò)程模型上，主要包括四個(gè)重要里程碑：①前景/范圍確認(rèn)；②項(xiàng)目規(guī)劃確認(rèn)；③開(kāi)發(fā)完成；④對(duì)外發(fā)布。

我們把MSF的各個(gè)階段對(duì)應(yīng)到傳統(tǒng)的項(xiàng)目開(kāi)發(fā)各階段，目的是使公司所有人員便于理解和使用。其中“前景范圍確認(rèn)”對(duì)應(yīng)傳統(tǒng)的“可行性分析”；“項(xiàng)目規(guī)劃確認(rèn)”對(duì)應(yīng)“需求分析”和“項(xiàng)目計(jì)劃”；“首次運(yùn)行”對(duì)應(yīng)“開(kāi)發(fā)完成”，“發(fā)布”的意思和傳統(tǒng)基本相同。同時(shí)，我們也根據(jù)公司的具體情況對(duì)流程進(jìn)行了相應(yīng)調(diào)整，把整個(gè)流程分為可行性分析、需求分析、開(kāi)發(fā)計(jì)劃、開(kāi)發(fā)過(guò)程和結(jié)項(xiàng)總結(jié)五個(gè)階段，下面分別進(jìn)行說(shuō)明。

3.2.1可行性分析

按照ISO9001的要求，在軟件開(kāi)發(fā)前有一個(gè)可行性分析報(bào)告，討論項(xiàng)目的可行性和風(fēng)險(xiǎn)，一般公司項(xiàng)目也都會(huì)經(jīng)歷這一階段。做可行性分析一般由未來(lái)的項(xiàng)目經(jīng)理和產(chǎn)品經(jīng)理共同完成，討論該項(xiàng)目的技術(shù)、經(jīng)濟(jì)可行性和潛在的風(fēng)險(xiǎn)等。很多小公司在做項(xiàng)目前都沒(méi)有這個(gè)過(guò)程，往往是不管自己的實(shí)際情況，匆忙上馬，遇到項(xiàng)目就接，結(jié)果是做一個(gè)死一個(gè)，成功的很少。

在做可行性分析的時(shí)候，要充分考慮公司以前的各種技術(shù)和市場(chǎng)積累，還有目前的資源可用性情況，特別是要做好風(fēng)險(xiǎn)分析。我以前就碰到過(guò)這種情況，一個(gè)項(xiàng)目的領(lǐng)域和公司以前的領(lǐng)域不盡相同，在立項(xiàng)前沒(méi)有充分考慮各種情況，認(rèn)為這個(gè)項(xiàng)目比較簡(jiǎn)單，應(yīng)該沒(méi)什么問(wèn)題，結(jié)果是沒(méi)有做得很成功，進(jìn)度上也拖了一段時(shí)間。在后來(lái)結(jié)項(xiàng)分析的時(shí)候，認(rèn)為主要的問(wèn)題就是領(lǐng)域的區(qū)別造成了公司內(nèi)部沒(méi)有人對(duì)該領(lǐng)域特別熟悉，缺乏領(lǐng)域?qū)＜?，并?duì)上述風(fēng)險(xiǎn)估計(jì)不足，也沒(méi)有對(duì)風(fēng)險(xiǎn)進(jìn)行較好的管理，所以造成了項(xiàng)目的不成功。

上面提到，可行性分析一般是由未來(lái)的項(xiàng)目經(jīng)理和產(chǎn)品經(jīng)理完成，必要時(shí)還需要市場(chǎng)人員的參與，項(xiàng)目經(jīng)理主要考慮技術(shù)可行性，包括項(xiàng)目最初估計(jì)的進(jìn)度表和資源需求情況；產(chǎn)品經(jīng)理主要考慮市場(chǎng)和經(jīng)濟(jì)上的可行性（主要是針對(duì)軟件產(chǎn)品而言）。只有預(yù)先對(duì)各種問(wèn)題進(jìn)行完備的分析后，才能得出正確的決策。不要到后來(lái)因?yàn)槟切┦孪葲](méi)考慮到的，但應(yīng)該想到的各種原因造成項(xiàng)目失?。换蛘唠m然完成了，但是沒(méi)有取得預(yù)期的效果，不能給公司帶來(lái)較好的收益。

只有在可行性分析通過(guò)評(píng)審，公司高層領(lǐng)導(dǎo)者認(rèn)可的情況下才能付諸實(shí)施。通過(guò)可行性分析，揭示了即將面臨的各種問(wèn)題及風(fēng)險(xiǎn)，使得公司內(nèi)部對(duì)該項(xiàng)目有了一致的認(rèn)識(shí)，在后來(lái)的資源申請(qǐng)上也更容易得到高層支持，更易于導(dǎo)致項(xiàng)目成功。那種只有一個(gè)想法，就開(kāi)始實(shí)施的做法是絕對(duì)不可取的，可以是單兵做戰(zhàn)，但決不是公司行為。

3.2.2需求分析

需求管理是軟件開(kāi)發(fā)中非常重要的部分，在一般的MIS型項(xiàng)目中，準(zhǔn)確的把握需求往往是項(xiàng)目成功的關(guān)鍵。但需求管理也是個(gè)困難的過(guò)程，據(jù)我所知，太多項(xiàng)目的需求都沒(méi)有良好的管理過(guò)程，往往導(dǎo)致項(xiàng)目后期的大量修改或者直接使項(xiàng)目失敗。

需求的管理主要由產(chǎn)品經(jīng)理負(fù)責(zé)，其中最終用戶（end user）的實(shí)時(shí)參與是一個(gè)非常重要的因素。在需求采集階段，我們主要采用了原型法，使用VB或者FrontPage建立最終產(chǎn)品的界面，然后把功能實(shí)現(xiàn)和界面一一對(duì)應(yīng)起來(lái)，和用戶進(jìn)行討論，并不斷的修改界面。最終在基本達(dá)成一致后，對(duì)應(yīng)原型寫出需求規(guī)格說(shuō)明書，在評(píng)審后納入基線管理。

在后面的開(kāi)發(fā)中，我們必須保證最終產(chǎn)品界面和原型基本一致，如有變更，則必須提交項(xiàng)目組和客戶討論。根據(jù)我們的經(jīng)驗(yàn)，優(yōu)秀的產(chǎn)品經(jīng)理＋用戶參與＋原型法＝良好的需求說(shuō)明。

在需求的制定過(guò)程中，產(chǎn)品經(jīng)理必須和項(xiàng)目經(jīng)理、開(kāi)發(fā)人員、測(cè)試人員進(jìn)行良好的溝通，使項(xiàng)目組全體都參與到需求分析中來(lái)，并共同確定需求的關(guān)鍵特性：

1．項(xiàng)目的范圍：在需求分析中，首先必須明確項(xiàng)目的范圍，去掉那些看似屬于該項(xiàng)目其實(shí)不該在項(xiàng)目中的需求特性。特別是在一些MIS項(xiàng)目中，客戶往往把一些屬于他們的日常工作但不屬于該項(xiàng)目的需求提交給項(xiàng)目組，這時(shí)就必須分清項(xiàng)目的范圍，不要在項(xiàng)目中加入太多不應(yīng)該做的東西，否則往往會(huì)導(dǎo)致項(xiàng)目范圍無(wú)限擴(kuò)大，最終只能是使項(xiàng)目失敗。

2．需求的優(yōu)先級(jí)：需求的優(yōu)先級(jí)是非常重要的特性，只有在準(zhǔn)確把握的需求優(yōu)先級(jí)的基礎(chǔ)上我們才可能規(guī)劃外部里程碑（產(chǎn)品版本）和內(nèi)部里程碑（開(kāi)發(fā)的階段性，后面會(huì)講到）。通常是用戶最關(guān)心，使用最頻繁的功能應(yīng)該屬于高優(yōu)先級(jí)，而那些不怎么重要或很少用到的功能應(yīng)該屬于低優(yōu)先級(jí)。我們必須在產(chǎn)品的開(kāi)始版本和項(xiàng)目的開(kāi)始就把重點(diǎn)放在高優(yōu)先級(jí)的需求上，而對(duì)于低優(yōu)先級(jí)的功能可以在項(xiàng)目后期根據(jù)需要進(jìn)行裁減或納入下一個(gè)版本規(guī)劃。

3．產(chǎn)品的易用性：產(chǎn)品的易用性反映在原型中，是原型法的一個(gè)非常重要的作用。很多產(chǎn)品的失敗其一個(gè)重要原因就是易用性比較差，雖然它在功能上滿足了用戶需求，甚至可以說(shuō)功能很強(qiáng)大。通過(guò)原型法，能讓用戶看到并模擬使用最終的產(chǎn)品界面，能在需求階段通過(guò)修正軟件界面來(lái)適應(yīng)用戶的偏好，從而在很大程度上提高了產(chǎn)品的易用性，使項(xiàng)目更容易成功。

4．其他需求特性：如性能要求、健壯性等。這些特性是產(chǎn)品的非功能性需求，也是項(xiàng)目成功的關(guān)鍵因素，特別是在一些大型的涉及重要領(lǐng)域的管理信息系統(tǒng)中。

需求分析是整個(gè)項(xiàng)目活動(dòng)中的非常關(guān)鍵的部分，它的好壞往往決定了項(xiàng)目的成敗。根據(jù)經(jīng)驗(yàn)，需求分析所需的時(shí)間往往占整個(gè)項(xiàng)目時(shí)間的12％[1]。在需求分析中，需要防止的一個(gè)錯(cuò)誤做法是太依靠一些所謂的分析方法，而使整個(gè)需求分析過(guò)程非常復(fù)雜，過(guò)多的圖表往往使人眼花繚亂，而不能準(zhǔn)確抓住問(wèn)題的本質(zhì)。一些分析人員往往對(duì)自己熟悉的簡(jiǎn)單的業(yè)務(wù)花大力氣，而對(duì)不熟悉的則一筆帶過(guò)，也是本末倒置的錯(cuò)誤行為。在分析過(guò)程中，我們必須始終把握需求分析的目的是把模糊的流程搞清晰，把復(fù)雜的業(yè)務(wù)盡量簡(jiǎn)化，而不是相反。

需求的管理也是非常重要的方面。對(duì)需求分析完后的形成的規(guī)格說(shuō)明需要進(jìn)行專門的評(píng)審，并且需要客戶和最終用戶的參與，在達(dá)成一致后形成最初的需求基線。以后對(duì)需求的更改都必須在基線的基礎(chǔ)上進(jìn)行，并需要項(xiàng)目組各成員的一致確認(rèn)，對(duì)需求進(jìn)行嚴(yán)格規(guī)劃評(píng)審的目的也在于在項(xiàng)目的后期能盡量減少對(duì)需求的更改，提高開(kāi)發(fā)的效率。

需求分析完成后，項(xiàng)目組需要對(duì)項(xiàng)目的初步計(jì)劃進(jìn)行重新審定，一般都需要變更項(xiàng)目時(shí)間表和資源需求。需求分析的完成也意味著項(xiàng)目其他部分可以齊頭并進(jìn)，如概要設(shè)計(jì)、測(cè)試計(jì)劃、用戶說(shuō)明書，這也在某個(gè)方面證明了需求分析的重要性－它是下面所有活動(dòng)的基礎(chǔ)和準(zhǔn)繩。

3.2.3開(kāi)發(fā)計(jì)劃
軟件開(kāi)發(fā)中的計(jì)劃性是非常重要的，一個(gè)沒(méi)有良好計(jì)劃的開(kāi)發(fā)項(xiàng)目能夠成功的機(jī)會(huì)非常小，除非有天才的程序員再加上好運(yùn)氣。開(kāi)發(fā)計(jì)劃的主要內(nèi)容包括：項(xiàng)目進(jìn)度安排、人力資源安排，風(fēng)險(xiǎn)管理策略等。

項(xiàng)目的進(jìn)度安排和人力資源安排可能是開(kāi)發(fā)計(jì)劃中最重要的部分，也是最難以估計(jì)的部分。一般國(guó)內(nèi)的中小軟件公司對(duì)項(xiàng)目工作量和開(kāi)發(fā)人員能力的量化程度不高，所以導(dǎo)致進(jìn)度和資源安排不確切，有時(shí)候甚至是相差很遠(yuǎn)。目前一個(gè)最實(shí)際的辦法就是根據(jù)以往項(xiàng)目的積累，但必須要求是同一領(lǐng)域的類似項(xiàng)目，這樣才有較強(qiáng)的可比性。由于這些計(jì)劃安排是預(yù)估粗略的，所以還必須在以后的項(xiàng)目各階段完成后進(jìn)行合理的變更，反應(yīng)項(xiàng)目的實(shí)際需求。微軟的辦法是把進(jìn)度估計(jì)的權(quán)限交給開(kāi)發(fā)人員，由開(kāi)發(fā)人員根據(jù)自己的經(jīng)驗(yàn)進(jìn)行估計(jì)，由于一般開(kāi)發(fā)人員往往會(huì)高估自己的能力，估計(jì)的進(jìn)度也會(huì)相應(yīng)偏短，最后再做適當(dāng)?shù)难娱L(zhǎng)[2]。這種辦法有它合理的地方，在中國(guó)還需進(jìn)行實(shí)踐摸索。

對(duì)于進(jìn)度的估計(jì)，我們有個(gè)經(jīng)驗(yàn)公式，即您最初預(yù)估的時(shí)間再乘以2.5，可能是最后的完成時(shí)間。因?yàn)樵S多人在估計(jì)進(jìn)度的時(shí)候，往往忽略了很多非開(kāi)發(fā)時(shí)間，如與客戶溝通的時(shí)間、項(xiàng)目組溝通時(shí)間、公司培訓(xùn)時(shí)間、假期等，所以我們?cè)诠烙?jì)進(jìn)度的時(shí)候，一定要全方位周全考慮，在盡可能的情況下寧愿把進(jìn)度估計(jì)的長(zhǎng)一點(diǎn)，免得在項(xiàng)目后期導(dǎo)致非常被動(dòng)的局面。后面我們將具體講到我們采取的階段性的開(kāi)發(fā)方法，這種方法的運(yùn)用反映在進(jìn)度估計(jì)時(shí)必須在各階段間預(yù)留緩沖時(shí)間，以解決那些我們事先沒(méi)有預(yù)料到的活動(dòng)。如果進(jìn)度表和要求的出貨時(shí)間有沖突，寧愿砍掉一些不重要的功能，也不要盲目增加人手，這種做法可能會(huì)導(dǎo)致產(chǎn)品質(zhì)量下降，最終得不償失，詳細(xì)說(shuō)明請(qǐng)參考[4]。
風(fēng)險(xiǎn)管理是項(xiàng)目管理中非常重要的部分，并且要貫穿項(xiàng)目的始終。一些軟件企業(yè)往往不是很重視風(fēng)險(xiǎn)管理，導(dǎo)致在項(xiàng)目的后期出現(xiàn)了很多預(yù)料之外的事情，使項(xiàng)目進(jìn)度一拖再拖，往往質(zhì)量也達(dá)不到預(yù)期要求。因此我們要特別重視風(fēng)險(xiǎn)的管理，具體方法留待后面專門詳述。

3.2.4開(kāi)發(fā)過(guò)程

在項(xiàng)目的開(kāi)發(fā)過(guò)程中，我們采用了階段式的開(kāi)發(fā)過(guò)程，這也是微軟公司所推薦的開(kāi)發(fā)過(guò)程。在開(kāi)發(fā)過(guò)程的初期，首要的活動(dòng)是概要設(shè)計(jì)。概要設(shè)計(jì)的目標(biāo)是簡(jiǎn)單、適用、能夠覆蓋所有的需求并能支持后面的階段式開(kāi)發(fā)。微軟的應(yīng)用方案解決模型是基于服務(wù)的三層（多層）架構(gòu)，包括用戶層，業(yè)務(wù)層和數(shù)據(jù)層，各層之間采用標(biāo)準(zhǔn)的接口進(jìn)行通訊，至于該方法的具體使用，請(qǐng)參看相關(guān)書籍，在此就不在贅述了。

階段開(kāi)發(fā)過(guò)程不是傳統(tǒng)的根據(jù)模塊劃分來(lái)依次完成各模塊，最后再進(jìn)行項(xiàng)目的整合，而是在每個(gè)階段完成后，項(xiàng)目都可以推出產(chǎn)品，只不過(guò)該產(chǎn)品的功能比最終產(chǎn)品的功能弱一些。

階段性完成項(xiàng)目比傳統(tǒng)的開(kāi)發(fā)方法最明顯的優(yōu)點(diǎn)是不必到項(xiàng)目的末期才開(kāi)始整合產(chǎn)品，使產(chǎn)品模塊之間協(xié)作產(chǎn)生的問(wèn)題及早產(chǎn)生，也及早修正，從而項(xiàng)目的風(fēng)險(xiǎn)也大大減小。傳統(tǒng)的開(kāi)發(fā)總是在項(xiàng)目的后期才開(kāi)始整合各模塊，使產(chǎn)生的問(wèn)題改正起來(lái)極為困難，成本也大大增加；前面累計(jì)的所有問(wèn)題全部都拖到了后面來(lái)解決，也使后面剩下的工作量大大增加。項(xiàng)目往往看起來(lái)已完成了90％——大部分的功能模塊都已完成，但剩下的10％總是完不成，項(xiàng)目進(jìn)度一拖再拖，很可能還要再花90％的時(shí)間來(lái)完成剩下的10％。當(dāng)然采用階段性開(kāi)發(fā)方法也有相應(yīng)的代價(jià)，最大的代價(jià)可能是反復(fù)的整合、測(cè)試已經(jīng)完成的模塊，但采用相應(yīng)的一些自動(dòng)化工具可以減小這個(gè)代價(jià)。

一般在開(kāi)始的階段進(jìn)行的是系統(tǒng)架構(gòu)和最重要的功能，后面的階段是相對(duì)不怎么重要的功能。這樣的分配有利于最終用戶在早期就能看到系統(tǒng)的大致模樣，便于他們及早的對(duì)產(chǎn)品提出意見(jiàn)，并對(duì)相應(yīng)的錯(cuò)誤進(jìn)行修改；也有利于項(xiàng)目組在項(xiàng)目后期時(shí)間很緊的情況下，去掉一些不重要的功能，把它們納入下一個(gè)版本處理，確保產(chǎn)品的推出時(shí)間。迭代的順利進(jìn)行依賴于良好的架構(gòu)設(shè)計(jì)，前面階段的設(shè)計(jì)應(yīng)該給后面要加入的功能預(yù)留出各種接口，并能使后面的工作在前面的基礎(chǔ)上繼續(xù)進(jìn)行下去。

這種在開(kāi)發(fā)階段的迭代方式不同于整個(gè)項(xiàng)目的完全迭代開(kāi)發(fā)，后者是項(xiàng)目的需求、概要設(shè)計(jì)、開(kāi)發(fā)等全部是迭代進(jìn)行，一次迭代要進(jìn)行所有的項(xiàng)目活動(dòng)。至于誰(shuí)優(yōu)誰(shuí)劣可能在不同的情況下有不同的說(shuō)法，需要根據(jù)項(xiàng)目和自身的情況合理采用。

還有就是迭代的次數(shù)也要根據(jù)項(xiàng)目的具體情況而定。不能太多，導(dǎo)致重復(fù)的工作量過(guò)大；也不能太少，使得該方法退化到傳統(tǒng)方法。我們的項(xiàng)目（項(xiàng)目小組在10人左右，開(kāi)發(fā)時(shí)間在5個(gè)月左右）一般分了四個(gè)階段：架構(gòu)完成、主要功能完成、其他功能完成、整合發(fā)行。實(shí)踐證明，這樣的實(shí)施比傳統(tǒng)方法確實(shí)在很大程度上減小了項(xiàng)目失敗的風(fēng)險(xiǎn)，再?zèng)]有產(chǎn)生那種“似乎永遠(yuǎn)也做不完的感覺(jué)”。

這里舉一個(gè)具體例子來(lái)更形象的說(shuō)明該方法的運(yùn)用。一個(gè)一般的MIS程序，第一階段可以構(gòu)建數(shù)據(jù)庫(kù)結(jié)構(gòu)和基于特定領(lǐng)域的核心平臺(tái)服務(wù)（包括一些基本服務(wù)類），并進(jìn)行初步整合；第二階段可并行同時(shí)開(kāi)發(fā)系統(tǒng)各大模塊的基本功能，并進(jìn)行第二次整合；第三階段可開(kāi)發(fā)其他增強(qiáng)功能，也需要相應(yīng)的功能整合；第四階段進(jìn)行整個(gè)系統(tǒng)的最后整合，并可進(jìn)行相應(yīng)的性能改進(jìn)，使產(chǎn)品進(jìn)入可發(fā)行狀態(tài)。

3.2.5結(jié)項(xiàng)總結(jié)

很多公司在項(xiàng)目完成后往往忽視了最后的總結(jié)，沒(méi)有把在上個(gè)項(xiàng)目中得到的經(jīng)驗(yàn)教訓(xùn)進(jìn)行分析，轉(zhuǎn)化成公司的巨大財(cái)富。我們認(rèn)為，項(xiàng)目的總結(jié)是整個(gè)項(xiàng)目的不可缺少的重要組成部分，只有通過(guò)詳盡的充分的項(xiàng)目總結(jié)，才能使項(xiàng)目組的所有成員對(duì)項(xiàng)目的歷程有一個(gè)清楚的了解，提高他們對(duì)軟件項(xiàng)目的認(rèn)識(shí)；才能真正地把以往的項(xiàng)目納入公司的資源庫(kù)，轉(zhuǎn)化成巨大的財(cái)富。

我們的做法是在項(xiàng)目完成后首先由各個(gè)項(xiàng)目成員寫出各自的總結(jié)報(bào)告，包括所從事的工作、任務(wù)的完成情況、遇到的問(wèn)題及解決方案、對(duì)項(xiàng)目過(guò)程的意見(jiàn)和自己的想法等內(nèi)容。項(xiàng)目負(fù)責(zé)人需要把整個(gè)的項(xiàng)目歷程整理成一份文件，其中包括項(xiàng)目的介紹、項(xiàng)目進(jìn)行的具體資料（如實(shí)際花費(fèi)時(shí)間、源代碼數(shù)、功能模塊數(shù)量等）、項(xiàng)目計(jì)劃與實(shí)際的比較等。

在上述完成后，全體項(xiàng)目參與人員舉行項(xiàng)目結(jié)項(xiàng)工作會(huì)議，對(duì)各人所列舉的問(wèn)題及想法進(jìn)行討論，目的是得出好的經(jīng)驗(yàn)教訓(xùn)，從而指導(dǎo)后面項(xiàng)目過(guò)程。會(huì)議可由分別針對(duì)的問(wèn)題分為幾個(gè)部分，如項(xiàng)目過(guò)程方面的、質(zhì)量管理方面的、技術(shù)方面的等，整合后形成結(jié)項(xiàng)會(huì)議報(bào)告。

項(xiàng)目負(fù)責(zé)人最后把項(xiàng)目歷程、資料、在結(jié)項(xiàng)會(huì)議中總結(jié)的經(jīng)驗(yàn)教訓(xùn)等整理成一份總的項(xiàng)目過(guò)程文件，歸檔并分發(fā)到各成員和上層領(lǐng)導(dǎo)，并由項(xiàng)目經(jīng)理向上層領(lǐng)導(dǎo)匯報(bào)，這時(shí)，一個(gè)完整的項(xiàng)目才真正告一段落。這些項(xiàng)目資料給以后的項(xiàng)目提供很好的模板和借鑒意義，并可以作為以后項(xiàng)目預(yù)估的依據(jù)。

3.3風(fēng)險(xiǎn)管理

微軟公司認(rèn)為，軟件開(kāi)發(fā)是一個(gè)風(fēng)險(xiǎn)驅(qū)動(dòng)的過(guò)程，由此可看出風(fēng)險(xiǎn)管理在軟件項(xiàng)目中的重要性。一個(gè)項(xiàng)目的風(fēng)險(xiǎn)有許多來(lái)源，如客戶、進(jìn)度、開(kāi)發(fā)過(guò)程、人力資源等，忽視風(fēng)險(xiǎn)的后果可能是成本超支、進(jìn)度推后，最嚴(yán)重導(dǎo)致項(xiàng)目失敗。

MSF的風(fēng)險(xiǎn)管理原則是：
1．風(fēng)險(xiǎn)應(yīng)該在整個(gè)項(xiàng)目的進(jìn)程中一直被估計(jì)，并且作為項(xiàng)目決策的依據(jù)之一。
2．有效的風(fēng)險(xiǎn)管理過(guò)程覆蓋了所有關(guān)鍵的人力、過(guò)程、商務(wù)及技術(shù)領(lǐng)域。
3．風(fēng)險(xiǎn)在納入管理前必須被清晰的表述。
4．重要的風(fēng)險(xiǎn)必須優(yōu)先被處理。
MSF風(fēng)險(xiǎn)管理過(guò)程包括以下階段：風(fēng)險(xiǎn)識(shí)別、風(fēng)險(xiǎn)陳述、風(fēng)險(xiǎn)分析、處理計(jì)劃、風(fēng)險(xiǎn)跟蹤、風(fēng)險(xiǎn)控制、風(fēng)險(xiǎn)解除。

在中小企業(yè)的風(fēng)險(xiǎn)管理過(guò)程中，一般項(xiàng)目經(jīng)理?yè)?dān)任風(fēng)險(xiǎn)管理員的角色，但同時(shí)需要另外的資深開(kāi)發(fā)人員輔助，一起完成風(fēng)險(xiǎn)管理的任務(wù)。他們負(fù)責(zé)維護(hù)十大風(fēng)險(xiǎn)清單（不一定非要列出十個(gè)），并在項(xiàng)目進(jìn)程中隨時(shí)對(duì)風(fēng)險(xiǎn)清單進(jìn)行更新。對(duì)風(fēng)險(xiǎn)的評(píng)級(jí)MSF采用的方式是：風(fēng)險(xiǎn)影響程度＝風(fēng)險(xiǎn)的可能性×風(fēng)險(xiǎn)發(fā)生造成的損失，根據(jù)風(fēng)險(xiǎn)影響程度的大小對(duì)風(fēng)險(xiǎn)進(jìn)行評(píng)級(jí)。

在項(xiàng)目實(shí)施中，我們總結(jié)的一些高風(fēng)險(xiǎn)事件主要有：需求的不準(zhǔn)確、項(xiàng)目時(shí)間表過(guò)于短促、開(kāi)發(fā)一個(gè)從前沒(méi)進(jìn)入的領(lǐng)域軟件、開(kāi)發(fā)人員對(duì)工具的不熟悉、人員流動(dòng)頻繁、使用了外部軟件中間件等。如果對(duì)這些風(fēng)險(xiǎn)不提前作出計(jì)劃，可能會(huì)對(duì)項(xiàng)目的順利進(jìn)行造成極大的破壞，甚至直接導(dǎo)致項(xiàng)目失敗。針對(duì)每一個(gè)風(fēng)險(xiǎn)，我們需要列出who, when, how, how much等事項(xiàng)，并對(duì)風(fēng)險(xiǎn)處理的結(jié)果進(jìn)行追蹤，最后決定是否已經(jīng)解除風(fēng)險(xiǎn)或再進(jìn)入風(fēng)險(xiǎn)處理循環(huán)。

一般國(guó)內(nèi)公司的風(fēng)險(xiǎn)意識(shí)不強(qiáng)，沒(méi)有很好的去規(guī)劃處理風(fēng)險(xiǎn)。我們當(dāng)時(shí)也是這樣，往往要等到風(fēng)險(xiǎn)已經(jīng)發(fā)生了，才意識(shí)到原來(lái)沒(méi)有注意到這些問(wèn)題。在風(fēng)險(xiǎn)的管理上，還需要更多的實(shí)踐探索，首先應(yīng)該從加強(qiáng)風(fēng)險(xiǎn)意識(shí)開(kāi)始。

3.4質(zhì)量管理

關(guān)于軟件質(zhì)量管理，現(xiàn)在已經(jīng)得到了很多公司的重視，這里我想針對(duì)性地強(qiáng)調(diào)幾個(gè)問(wèn)題：
1．質(zhì)量管理不單單是測(cè)試。一個(gè)容易犯的錯(cuò)誤是把質(zhì)量管理和測(cè)試等同起來(lái)，如果軟件有問(wèn)題就是測(cè)試沒(méi)做好。其實(shí)質(zhì)量管理包括很多內(nèi)容，如技術(shù)檢查、缺陷追蹤、源代碼追蹤、單元測(cè)試、系統(tǒng)測(cè)試等。
2．質(zhì)量管理不是在代碼完成后才開(kāi)始，質(zhì)量管理應(yīng)該貫穿整個(gè)項(xiàng)目始終，從需求、設(shè)計(jì)到編碼、測(cè)試。我們往往只重視了后期對(duì)代碼的測(cè)試，而忽略了對(duì)需求、設(shè)計(jì)的質(zhì)量管理，而前者比較起來(lái)可能更為重要。因?yàn)樘幚硪粋€(gè)在后期才發(fā)現(xiàn)的錯(cuò)誤比處理一個(gè)前期發(fā)現(xiàn)的錯(cuò)誤的成本要高幾十倍。
3．使用缺陷追蹤管理工具。我們的實(shí)踐證明：使用缺陷追蹤管理工具比以前單純的使用文檔傳送方式的效率提高幾倍，并在管理諸如優(yōu)先級(jí)、防止遺漏等方面有更大的優(yōu)勢(shì)。

3.5其他

這里談一些沒(méi)有包括在上述內(nèi)容里的經(jīng)驗(yàn)教訓(xùn)，供大家參考：
1．項(xiàng)目管理工具。我們使用的是MS Project來(lái)管理項(xiàng)目過(guò)程，Project一個(gè)很好的優(yōu)點(diǎn)是能把項(xiàng)目管理的內(nèi)容自動(dòng)發(fā)布到網(wǎng)站上去，這極大地方便了各階層人員對(duì)項(xiàng)目狀態(tài)的了解，有助于及時(shí)發(fā)現(xiàn)問(wèn)題解決問(wèn)題，對(duì)項(xiàng)目組成員也是個(gè)很好的激勵(lì)方法。
2．項(xiàng)目團(tuán)隊(duì)中需要資深開(kāi)發(fā)人員。我曾經(jīng)經(jīng)歷過(guò)一個(gè)項(xiàng)目，項(xiàng)目負(fù)責(zé)人堅(jiān)持用C++ Builder開(kāi)發(fā)（可能是為了學(xué)習(xí)的原因），但是公司沒(méi)有任何一個(gè)人對(duì)這個(gè)工具非常熟悉，也沒(méi)有進(jìn)行相應(yīng)的風(fēng)險(xiǎn)管理。結(jié)果在項(xiàng)目的過(guò)程中出了太多問(wèn)題，使項(xiàng)目一直延期，在交付的時(shí)候都還存在很多問(wèn)題。所以在項(xiàng)目團(tuán)隊(duì)中一定需要資深開(kāi)發(fā)人員，特別是在項(xiàng)目的前期更是如此。
3．再次強(qiáng)調(diào)產(chǎn)品經(jīng)理角色。必須牢牢記?。阂粋€(gè)不管使用了什么先進(jìn)技術(shù)、開(kāi)發(fā)方法的產(chǎn)品，如果不能滿足用戶的需要，就是一個(gè)失敗的產(chǎn)品。而產(chǎn)品經(jīng)理角色的設(shè)立能較好滿足這一要求。
4．在領(lǐng)域性較強(qiáng)的項(xiàng)目中，最好在基本的軟件架構(gòu)上（如COM或J2EE）實(shí)現(xiàn)一個(gè)該領(lǐng)域的基礎(chǔ)開(kāi)發(fā)平臺(tái)，這樣在以后的擴(kuò)展上，在具體項(xiàng)目的實(shí)施上，都會(huì)極大的節(jié)省成本，軟件的質(zhì)量也有良好的保證。

第四章 結(jié)束語(yǔ)

上述簡(jiǎn)單介紹了我們項(xiàng)目管理的經(jīng)驗(yàn)教訓(xùn)，在引入MSF管理思想后，項(xiàng)目的成功率比原來(lái)增大了很多。我們碰到最棘手的問(wèn)題就是項(xiàng)目的度量（Metrics），怎么更合理估算項(xiàng)目的大小，估算軟件開(kāi)發(fā)人員的生產(chǎn)率，更合理的項(xiàng)目計(jì)劃等，這也是CMM4所要求的內(nèi)容。需要在不斷項(xiàng)目積累的同時(shí)，逐步細(xì)化量化指標(biāo)，在實(shí)踐中不斷學(xué)習(xí)、提高。

【?發(fā)表評(píng)論?0條?】