大的開發(fā)團隊 可以按照實現(xiàn)不同的模塊分成很多小的項目小組,給個項目小組其實就是一個小團隊。一般5、6個人最為合適,團隊合作和溝通成本之間有一個很好的平衡。
小版本發(fā)布是針對以前瀑布式開發(fā)的缺點而提出的開發(fā)方式。在以前的模式中,項目往往經(jīng)過一個漫長的需求開發(fā)、設(shè)計、編碼和測試階段后才能夠與客戶見面,而客戶在這個時間段上進入了“盲區(qū)”,直到開發(fā)團隊“隆重推出”開發(fā)成果。而恰恰這個時候是項目風(fēng)險最大的時候,由于在過程中缺乏交流機會,客戶往往會發(fā)現(xiàn)這個產(chǎn)品與他們想象的很不一樣,因此很有可能導(dǎo)致項目拖延或者失敗。
小版本發(fā)布則不同,它將系統(tǒng)的實現(xiàn)分解為多個連續(xù)的版本,每一個都實現(xiàn)一部分的系統(tǒng)功能。當(dāng)每個小版本結(jié)束后,都會邀請客戶評估這一版本實現(xiàn)的狀況,并且根據(jù)用戶反饋制定和調(diào)整下一個小版本的目標(biāo)。這樣做的好處是顯而易見的:客戶越早看到產(chǎn)品,就能越早發(fā)現(xiàn)與開發(fā)團隊間就用戶需求方面的理解差異, 盡早調(diào)整需求,從而避免了在項目后期調(diào)整需求帶來的巨額代價。另一個潛在的好處是,這一部分產(chǎn)品功能經(jīng)過驗收后就有可能投入使用,從而盡早為用戶提供價值。 當(dāng)然,小版本發(fā)布會不可避免地面臨較多的需求變更請求,因此需要仔細的管理需求變更。
以需求實現(xiàn)為單位規(guī)劃項目實施
小版本發(fā)布需要為每個版本制定實施目標(biāo),確定在本次版本中需要實現(xiàn)的功能以及計劃修改的以前版本的缺陷。而用戶需求是功能的表達方式,因此使用用戶需求作為小版本是順理成章的。當(dāng)然根據(jù)粒度不同,也可以使用軟件需求做為小版本發(fā)布的內(nèi)容。
在定下版本計劃的目標(biāo)后,就需要規(guī)劃實施。不過由于用戶需求描述的是客戶的業(yè)務(wù)和對系統(tǒng)的期望,因此直接采用用戶需求作為開發(fā)任務(wù)安排的起點并不合適。從用戶需求導(dǎo)出的軟件需求則是以開發(fā)團隊能夠理解的語言和結(jié)構(gòu)描述的,很適合作為安排需求實現(xiàn)的基礎(chǔ)。需求追蹤矩陣可以幫助我們找到版本目標(biāo)中的那些用戶需求相關(guān)的軟件需求,項目經(jīng)理則為找到的這些軟件需求的實現(xiàn)制定開發(fā)任務(wù),從而形成開發(fā)任務(wù)集的主線,再輔以集成測試和缺陷追蹤,就形成了完整的開發(fā)計劃。這樣的分解方式自然而且清晰,易于上手。
項目的進度監(jiān)控
前文說到用戶需求是客戶與開發(fā)團隊間的契約,因此用戶需求自然成為客戶參與項目時候關(guān)心的重點。但是,在實際項目過程中,當(dāng)客戶真正參與項目、試圖了解項目進展?fàn)顩r時,卻發(fā)現(xiàn)除了用戶文檔外,再也找不到這些需求的影子,取而代之的是一堆花花綠綠的項目任務(wù)進展報告、甘特圖、統(tǒng)計報告等。這些報表也許準(zhǔn)確地反映了現(xiàn)在項目中任務(wù)的分布和實現(xiàn)狀況,但是與用戶關(guān)心的需求實現(xiàn)狀態(tài)沒有什么直接聯(lián)系,因而與缺少了共同的語言。
這個問題來源于傳統(tǒng)項目管理過程中以任務(wù)為中心的理念和實踐。在這種理念下,項目被認(rèn)為是一個任務(wù)的集合,主要的工作就是任務(wù)的分解(WBS: Work Breakdown Structure)、分派、實現(xiàn)和審核。在一個項目組內(nèi)部,這的確是工作的主要內(nèi)容。但是,現(xiàn)代的軟件開發(fā)過程都強調(diào)用戶的參與,項目進展僅僅以任務(wù)為視角展現(xiàn)就不是很合適了。對于客戶而言,他們所熟悉的問題描述,即用戶需求,已經(jīng)被分解成幾十甚至上百個大大小小的任務(wù),再難看出它們之間的聯(lián)系,客戶自然會感到迷茫,更別說從中看出需求實現(xiàn)的狀態(tài)了。
而RDPM中提供的是需求實現(xiàn)狀態(tài)圖,需求變化趨勢,需求數(shù)量完成率,需求規(guī)模完成率,工時消耗率等指標(biāo)。這些指標(biāo)對于客戶來說更有意義。
需求的變更
“
項目經(jīng)理勝任力免費測評PMQ上線啦!快來測測你排多少名吧~
http://opto-elec.com.cn/pmqhd/index.html