大的開(kāi)發(fā)團(tuán)隊(duì) 可以按照實(shí)現(xiàn)不同的模塊分成很多小的項(xiàng)目小組，給個(gè)項(xiàng)目小組其實(shí)就是一個(gè)小團(tuán)隊(duì)。一般5、6個(gè)人最為合適，團(tuán)隊(duì)合作和溝通成本之間有一個(gè)很好的平衡。 

　　小版本發(fā)布是針對(duì)以前瀑布式開(kāi)發(fā)的缺點(diǎn)而提出的開(kāi)發(fā)方式。在以前的模式中，項(xiàng)目往往經(jīng)過(guò)一個(gè)漫長(zhǎng)的需求開(kāi)發(fā)、設(shè)計(jì)、編碼和測(cè)試階段后才能夠與客戶(hù)見(jiàn)面，而客戶(hù)在這個(gè)時(shí)間段上進(jìn)入了“盲區(qū)”，直到開(kāi)發(fā)團(tuán)隊(duì)“隆重推出”開(kāi)發(fā)成果。而恰恰這個(gè)時(shí)候是項(xiàng)目風(fēng)險(xiǎn)最大的時(shí)候，由于在過(guò)程中缺乏交流機(jī)會(huì)，客戶(hù)往往會(huì)發(fā)現(xiàn)這個(gè)產(chǎn)品與他們想象的很不一樣，因此很有可能導(dǎo)致項(xiàng)目拖延或者失敗。

　　小版本發(fā)布則不同，它將系統(tǒng)的實(shí)現(xiàn)分解為多個(gè)連續(xù)的版本，每一個(gè)都實(shí)現(xiàn)一部分的系統(tǒng)功能。當(dāng)每個(gè)小版本結(jié)束后，都會(huì)邀請(qǐng)客戶(hù)評(píng)估這一版本實(shí)現(xiàn)的狀況，并且根據(jù)用戶(hù)反饋制定和調(diào)整下一個(gè)小版本的目標(biāo)。這樣做的好處是顯而易見(jiàn)的：客戶(hù)越早看到產(chǎn)品，就能越早發(fā)現(xiàn)與開(kāi)發(fā)團(tuán)隊(duì)間就用戶(hù)需求方面的理解差異， 盡早調(diào)整需求，從而避免了在項(xiàng)目后期調(diào)整需求帶來(lái)的巨額代價(jià)。另一個(gè)潛在的好處是，這一部分產(chǎn)品功能經(jīng)過(guò)驗(yàn)收后就有可能投入使用，從而盡早為用戶(hù)提供價(jià)值。 當(dāng)然，小版本發(fā)布會(huì)不可避免地面臨較多的需求變更請(qǐng)求，因此需要仔細(xì)的管理需求變更。

　　以需求實(shí)現(xiàn)為單位規(guī)劃項(xiàng)目實(shí)施

　　小版本發(fā)布需要為每個(gè)版本制定實(shí)施目標(biāo)，確定在本次版本中需要實(shí)現(xiàn)的功能以及計(jì)劃修改的以前版本的缺陷。而用戶(hù)需求是功能的表達(dá)方式，因此使用用戶(hù)需求作為小版本是順理成章的。當(dāng)然根據(jù)粒度不同，也可以使用軟件需求做為小版本發(fā)布的內(nèi)容。 

　　在定下版本計(jì)劃的目標(biāo)后，就需要規(guī)劃實(shí)施。不過(guò)由于用戶(hù)需求描述的是客戶(hù)的業(yè)務(wù)和對(duì)系統(tǒng)的期望，因此直接采用用戶(hù)需求作為開(kāi)發(fā)任務(wù)安排的起點(diǎn)并不合適。從用戶(hù)需求導(dǎo)出的軟件需求則是以開(kāi)發(fā)團(tuán)隊(duì)能夠理解的語(yǔ)言和結(jié)構(gòu)描述的，很適合作為安排需求實(shí)現(xiàn)的基礎(chǔ)。需求追蹤矩陣可以幫助我們找到版本目標(biāo)中的那些用戶(hù)需求相關(guān)的軟件需求，項(xiàng)目經(jīng)理則為找到的這些軟件需求的實(shí)現(xiàn)制定開(kāi)發(fā)任務(wù)，從而形成開(kāi)發(fā)任務(wù)集的主線(xiàn)，再輔以集成測(cè)試和缺陷追蹤，就形成了完整的開(kāi)發(fā)計(jì)劃。這樣的分解方式自然而且清晰，易于上手。 


　　項(xiàng)目的進(jìn)度監(jiān)控

　　前文說(shuō)到用戶(hù)需求是客戶(hù)與開(kāi)發(fā)團(tuán)隊(duì)間的契約，因此用戶(hù)需求自然成為客戶(hù)參與項(xiàng)目時(shí)候關(guān)心的重點(diǎn)。但是，在實(shí)際項(xiàng)目過(guò)程中，當(dāng)客戶(hù)真正參與項(xiàng)目、試圖了解項(xiàng)目進(jìn)展?fàn)顩r時(shí)，卻發(fā)現(xiàn)除了用戶(hù)文檔外，再也找不到這些需求的影子，取而代之的是一堆花花綠綠的項(xiàng)目任務(wù)進(jìn)展報(bào)告、甘特圖、統(tǒng)計(jì)報(bào)告等。這些報(bào)表也許準(zhǔn)確地反映了現(xiàn)在項(xiàng)目中任務(wù)的分布和實(shí)現(xiàn)狀況，但是與用戶(hù)關(guān)心的需求實(shí)現(xiàn)狀態(tài)沒(méi)有什么直接聯(lián)系，因而與缺少了共同的語(yǔ)言。 

　　這個(gè)問(wèn)題來(lái)源于傳統(tǒng)項(xiàng)目管理過(guò)程中以任務(wù)為中心的理念和實(shí)踐。在這種理念下，項(xiàng)目被認(rèn)為是一個(gè)任務(wù)的集合，主要的工作就是任務(wù)的分解（WBS： Work Breakdown Structure）、分派、實(shí)現(xiàn)和審核。在一個(gè)項(xiàng)目組內(nèi)部，這的確是工作的主要內(nèi)容。但是，現(xiàn)代的軟件開(kāi)發(fā)過(guò)程都強(qiáng)調(diào)用戶(hù)的參與，項(xiàng)目進(jìn)展僅僅以任務(wù)為視角展現(xiàn)就不是很合適了。對(duì)于客戶(hù)而言，他們所熟悉的問(wèn)題描述，即用戶(hù)需求，已經(jīng)被分解成幾十甚至上百個(gè)大大小小的任務(wù)，再難看出它們之間的聯(lián)系，客戶(hù)自然會(huì)感到迷茫，更別說(shuō)從中看出需求實(shí)現(xiàn)的狀態(tài)了。 
　　而RDPM中提供的是需求實(shí)現(xiàn)狀態(tài)圖，需求變化趨勢(shì)，需求數(shù)量完成率，需求規(guī)模完成率，工時(shí)消耗率等指標(biāo)。這些指標(biāo)對(duì)于客戶(hù)來(lái)說(shuō)更有意義。 

　　需求的變更
　　“

    項(xiàng)目經(jīng)理勝任力免費(fèi)測(cè)評(píng)PMQ上線(xiàn)啦！快來(lái)測(cè)測(cè)你排多少名吧~

    http://m.opto-elec.com.cn/pmqhd/index.html