軟件項目是發(fā)現(xiàn)與發(fā)明的過程。發(fā)現(xiàn)與發(fā)明融合為一的最佳方式是透過“階段性完成”的做法，將產(chǎn)品的功能分階段完成，而最重要的功能最早完成。當(dāng)項目進(jìn)行時，許多活動交互重疊，把產(chǎn)品有抽象概念轉(zhuǎn)化成具體成果。項目進(jìn)行中的源代碼傾向以S形曲線而非線性成長，而大部分的程序代碼都是在項目中間第三部分完成的。追蹤程序代碼的成長提供對項目狀態(tài)的洞悉力。執(zhí)行良好的項目也可以由一名上層主管選擇最有效的一組來進(jìn)行追蹤。

本文描述一個成功的項目由兩萬尺的高空鳥瞰時的樣子。它提供了通過不同的角度透視項目流程、人員、進(jìn)展活動、程序代碼成長與主要成效。

思考階段

在討論軟件項目依照規(guī)劃階段分期完成的方法之前，我認(rèn)為先對項目整個過程進(jìn)行通盤了解會有用處。

軟件項目如圖5-1，被切分成三個概念階段。在項目初期，焦點擺在“發(fā)現(xiàn)”，特別是發(fā)現(xiàn)使用者的真正需要。透過技術(shù)性調(diào)查、與使用者訪談和建立接口雛形，把不確定性的概念轉(zhuǎn)換成確定的觀念，這就是第一階段的特色。


在項目進(jìn)行中期，焦點移到了“發(fā)明”上。往大方向看，開發(fā)人員要發(fā)明軟件構(gòu)架與設(shè)計方式。細(xì)節(jié)的地方，如每個函數(shù)式或?qū)ο箢悇e也不能忽略。

如同發(fā)現(xiàn)階段般，發(fā)明階段的特征在于將不確定的概念轉(zhuǎn)換成確定的觀念。如果還有別的特征，就是發(fā)明階段的不確定性要高得多。在發(fā)現(xiàn)階段，開發(fā)人員可以確定答案“就在”某個地方?？墒窃诎l(fā)明階段，就不能以此類推。

在項目的最后部分，焦點又轉(zhuǎn)移了，這次擺在實作上。不同于發(fā)現(xiàn)與發(fā)明階段的是，實作階段的不確定性少多了，故可發(fā)掘出許多已確定的觀念并可實現(xiàn)成具體成果。

如圖5-1所描述的，發(fā)現(xiàn)、發(fā)明與實作在軟件項目中各自以一定程度進(jìn)行著。太嚴(yán)格分段規(guī)劃反而不能有效運作，好的項目計劃必須讓發(fā)現(xiàn)、發(fā)明與實作一起出現(xiàn)。

項目流程

在某些軟件開發(fā)方式中，項目團(tuán)隊幾乎是秘密完成開發(fā)的大部分工作。技術(shù)性項目常提供如“完成90%”之類的狀態(tài)報告。對顧客來說，如果完成項目的90%就花去了90%的時間，那剩下的10%可能會花去另一個“90%”的時間。

本文提供的項目規(guī)劃依循著“階段性完成”的輪廓進(jìn)行。由于她將項目中開發(fā)的軟件分階段完成，而不是到了項目結(jié)尾才一次完成，這種方式稱做“階段性完成”。圖5-2說明了這種方式。


如你從這圖所看到的，階段性完成強(qiáng)調(diào)項目規(guī)劃與風(fēng)險降低。項目團(tuán)隊先發(fā)展軟件概念，分析匯集需求；再完成構(gòu)架設(shè)計。這些工作透過積極的風(fēng)險管理與精心規(guī)劃，朝著消除風(fēng)險的目標(biāo)前進(jìn)。

在每個實作階段中，項目團(tuán)隊進(jìn)行細(xì)節(jié)設(shè)計、程序?qū)懽鳌⒊e與測試（以階段1到n表示），在每個階段都建立出可能推出的產(chǎn)品。這三個階段也描繪在圖中，不過你可能想隨心所欲的操控項目的完成，有些項目可以只用三或四個階段，而有些則有更充裕時間，使得每個星期都能推出新的軟件。

分階段完成的好處

階段性完成提供下述5種好處。

1．關(guān)鍵功能更早出現(xiàn)。

階段性完成的項目中各階段一般都先規(guī)劃產(chǎn)品最重要的功能。如果使用者期望特定功能，就表現(xiàn)出他們不想等到產(chǎn)品完工了才看到這些東西，他們只想在第一階段就先睹為快。比起一些倉促完工的冒失項目，階段性完成對一個有著時間壓力的項目可說是個寶貴的做法。

早期降低風(fēng)險這種做法強(qiáng)調(diào)項目的規(guī)劃與風(fēng)險管理。將產(chǎn)品分階段完成并隨時整合起來的方式，可降低項目末期才整合失敗的技術(shù)性風(fēng)險。同時將可用的軟件盡早提供給一般使用者參與，借著產(chǎn)生具體進(jìn)展成效來降低管理風(fēng)險。

2．早期預(yù)警問題

當(dāng)你及早計劃各完成版本的軟件時，你就會提早得到明白的進(jìn)度報告。無論各個版本是否如期推出，工作質(zhì)量可明顯從推出版本看出。當(dāng)開發(fā)團(tuán)隊碰上了麻煩，你也會先知先覺，不必等到項目“完成90%”了還摸不清頭緒。

3．減少報告負(fù)擔(dān)

階段性完成也提供一個長久有效辦法來消除開發(fā)人員花在建立臨時性進(jìn)度報告和傳統(tǒng)的固定性進(jìn)度報告。

=============================================
產(chǎn)品的動態(tài)比任何書面報告更能精確反映項目狀態(tài)。
=============================================

階段性完成能提供更多選擇。項目團(tuán)隊在每個階段末尾評估可推出產(chǎn)品并不代表產(chǎn)品非推出不可，不過如果真的有必要，產(chǎn)品可以隨時推出，而且將產(chǎn)品完成到待命狀態(tài)，所需的功能應(yīng)有盡有。如果你沒采用階段性完成的做法，你就沒有這種選擇。

4．階段性完成可降低估計失誤

階段性完成可通過對推出產(chǎn)品各部分功能逐步完成來避開估計錯誤的問題。與一次對整個項目做出大型評估相比，項目團(tuán)隊可以靈活地分別對幾個小版本做小型評估。在每個版本中，項目團(tuán)隊可以從評估中吸取教訓(xùn)，重新校正做法，并改善項目現(xiàn)況，使項目的未來預(yù)估更為精確。

5．階段性完成均衡了彈性與效率

分階段完成產(chǎn)品讓項目團(tuán)隊有精確的時間來決定軟件中該更改哪些東西，這些時間來自階段銜接的空擋。在空擋內(nèi)決定軟件規(guī)格的變更，讓開發(fā)團(tuán)隊不必一直考慮軟件改變，卻能保證讓項目不致遺漏該考慮變更的東西。

階段性完成的代價

從前述所列的好處中，階段性完成的做法聽來似乎毫無缺點，其實則不然。階段性完成的做法要付出相當(dāng)代價。因為項目團(tuán)隊需要時間準(zhǔn)備各種可推出的軟件，在每個階段重復(fù)測試已經(jīng)測試過的功能，推出軟件前進(jìn)行相關(guān)的版本管制工作，提供試用的不同版本軟件沒預(yù)料到的問題的解決方案（如果階段性完成的軟件真的拿出去給人使用），還有規(guī)劃階段性發(fā)行這種做法的好壞等等，都會提高項目的負(fù)擔(dān)。

其中的某些代價并不真的是額外多出來的它們不過是讓本來隱藏在項目末尾的一些成本提早顯現(xiàn)出來而已，找出缺陷并修正錯誤就是這類的隱藏成本。階段性完成項目的有些工作人員在一開始會抱怨他們把時間都花在修正錯誤上。實際上他們是在修理早晚都得修理的東西，而且這些在項目中先找出來的錯誤愈早修正，花費的成本就愈低廉。

其他代價也許是多余的，如對外發(fā)出很多不同版本的軟件，會增加項目的整體負(fù)擔(dān)和總成本。

===============================================================
階段性完成并不是萬靈丹，不過總合起來，那些額外的負(fù)擔(dān)相對于明顯
改善了的狀態(tài)、質(zhì)量與時間的匹配、精確預(yù)估與降低風(fēng)險等來說，不過
是一點小小的付出而已。
===============================================================

規(guī)劃階段

圖5-2的階段性完成流程圖說明項目早期活動，如需求分析與構(gòu)架設(shè)計都是連續(xù)不斷進(jìn)行的。在投入構(gòu)架設(shè)計的階段之前先完成大部分需求分析工作，以及在進(jìn)行細(xì)節(jié)設(shè)計與實作之前先定好整體構(gòu)架，都是重要的事情。不過實際上，這些活動都是在同時間內(nèi)重疊進(jìn)行的，這是不可避免而且必然的事情。圖5-3所描繪的，就是這種重疊進(jìn)行的情形。


從本圖中，建立項目團(tuán)隊?wèi)?yīng)該在開始構(gòu)架設(shè)計前先做好大部分需求開發(fā)的工作。在開始細(xì)節(jié)設(shè)計以前，應(yīng)該先完成大致的構(gòu)架工作。這么做，是由于錯誤修正的成本會隨著時間的延后而提高。80/20比例的規(guī)則可以應(yīng)用到這上頭來：在開始進(jìn)行構(gòu)架工作前，先完成80%的需求開發(fā)工作，而在開始細(xì)節(jié)設(shè)計以前，先完成80%的構(gòu)架設(shè)計。80%并不是隨便選定的比例，知識基于一條良好的經(jīng)驗法則：這樣可以讓團(tuán)隊在明白表示不可能一次把這些工作完全做好時，還能在項目初期先滿足大部分需求。

細(xì)節(jié)設(shè)計、程序?qū)懽鳌⒄吓c測試差不多在同一時間內(nèi)完成，因為階段性完成的做法會在各階段中產(chǎn)生設(shè)計、實作、整合與測試的小循環(huán)。使用文件的撰寫會提早進(jìn)行，因為使用者需求先被開發(fā)好了（這在后面的文章會提到），而且這些工作會持續(xù)進(jìn)行，管理與規(guī)劃也會持續(xù)處理。這樣的復(fù)雜性也許會讓人以為這種做法只適用于大型項目，不過實際上幾乎任何項目都可以應(yīng)用這些法則，只是程度上多寡的問題而已。

匯聚人力

從人力觀點來看，在階段性完成項目中應(yīng)有兩個階段。在第一階段中，項目還在醞釀中，團(tuán)隊正在開發(fā)需求和建構(gòu)構(gòu)架。在這階段的整體努力程度一般被認(rèn)為要低于主要實作階段。前述項目完成10%～20%后決定要不要繼續(xù)進(jìn)行下去就是在這階段中處理的。這一階段的工作人員應(yīng)該是技巧高超的資深開發(fā)人員。

第二階段是階段性完成時期。在這階段中，項目團(tuán)隊處理細(xì)節(jié)設(shè)計、軟件構(gòu)件與測試。技巧高超的資深開發(fā)人員在這一階段也扮演重要地位，不過項目也需要質(zhì)量保證人員、技術(shù)文件寫作人員和資歷較淺的軟件開發(fā)人員。

在項目后半50%里，你可以看出質(zhì)量保證、細(xì)節(jié)設(shè)計、程序?qū)懽鞯娜藛T要求保持相對順暢。在一次做完所有事情的做法中，項目通常得花費更多人力，而且到了項目末期可用人力會變少。階段性完成的餓項目則在大部分時間里有著較流暢的人力比例，使資金流向、雇用、訓(xùn)練、測試和運算資源的使用跟著流暢起來。
圖5-3中所描繪的動態(tài)并沒有真正顯示出各項活動花費了多少時間，圖5-4說明了一個項目中的這些活動所需時間的分布情形。


注意，圖5-4的“發(fā)行”活動不像在圖5-3中是分開列舉的。它包含取得所有項目資助者同意發(fā)行的時間，建立項目的最后記錄，建立項目的歷程報告和其他項目結(jié)尾的活動。

圖表中的具體數(shù)據(jù)都是依照經(jīng)驗法則得來的，所以不是很嚴(yán)格的數(shù)字。不過它們還是提供了一些實際的概念。需求開發(fā)跟構(gòu)架的上游活動消耗了項目努力中相對較少的部分，而下游的構(gòu)建跟系統(tǒng)測試活動則消耗了太多的時間和精力。上游活動對下游活動起著極大的杠桿作用，兩者都需兼顧是很重要的。

圖5-5補(bǔ)足了上圖，說明項目活動間的典型時間分布圖。


從這些圖表中得到一個很重要的概念是，項目中進(jìn)行某一活動的時間比例不會跟耗用的精力成正比。需求開發(fā)工作一般會耗去項目12%的時間，可是只占用6%的努力。由于上游活動比較抽象而需要更多的深思熟慮，所以必須以較慢的步調(diào)進(jìn)行。

程序代碼增長曲線

前面的圖表應(yīng)該已經(jīng)說明在項目初期有許多不會產(chǎn)生任何程序代碼的工作要做。其實項目的頭三分之一是用來詳細(xì)了解需求與發(fā)展高質(zhì)量的構(gòu)架方式，好讓項目團(tuán)隊能夠好好檢測項目規(guī)格，然后一次把產(chǎn)品做好，程序代碼可能會教慢寫出來。項目中間的三分之一主要在建立項目軟件上，在這一階段程序碼會快速產(chǎn)生出來。項目的后面三分之一，則將焦點擺在檢查前面階段寫出來的程序代碼是否上得了臺面。這一階段著重錯誤修正和根本程序代碼的更動。如同開頭三分之一，程序代碼增加得很緩慢。圖5-6描述了一個執(zhí)行良好的項目中程序碼增長的方式。

黑線表示正常的程序代碼增長方式，陰影部分則表示正常變化量。在項目中期程序代碼增長的變化量仿照過渡版本提升現(xiàn)有程序代碼品質(zhì)而產(chǎn)生的。圖5-6中的項目在最后推出產(chǎn)品以前，推出兩個過渡版本。


一旦你了解了程序代碼增長的方式，你就能很精確的估計項目的現(xiàn)況。執(zhí)行良好的項目每周都會記錄項目的程序代碼。如果你認(rèn)為項目快到結(jié)尾，新程序碼幾乎也停止增加，這時項目就已經(jīng)可以準(zhǔn)備發(fā)行了。如果新的程序代碼還不停的加入項目中，那項目就還處于執(zhí)行中期的三分之一，還沒接近推出的成熟階段。

同樣的道理，如果開發(fā)人員在他們完成構(gòu)架設(shè)計前加入太多程序代碼，你幾乎可以保證會在系統(tǒng)測試階段停留許久，那是為了要讓開發(fā)人員修正他們在系統(tǒng)設(shè)計還不是很成熟時所造成的錯誤。

一些項目犯下的嚴(yán)重錯誤是將產(chǎn)品在只完成了85%左右時就發(fā)行出去。

如果項目主持人不了解圖中所說明的軟件開發(fā)方式，他們會假設(shè)新的程序代碼開發(fā)量開始降低時就可以立刻把程序推出去發(fā)行了，特別是項目執(zhí)行受到明顯的時間壓力時。這個將產(chǎn)品只有85%完成度就倉促發(fā)行的決定，表示軟件終究未臻完善，這樣的決定就像搬磚頭砸自己的腳。

主要完成點與推行點
有時候，前幾節(jié)中描述的一般軟件開發(fā)方式可縮減成以圖像表示詳細(xì)的完成時間點和推出時間點。主要完成點以極高水平來追蹤項目執(zhí)行進(jìn)度，圖5-7概述了本文中使用的高層次階段和完成點的劃分方式。

這里的通用項目要點幾乎可以應(yīng)用到任何規(guī)模的項目上。實際上每個階段的初步工作?？梢员葓D中所說的更早開始進(jìn)行，而后頭的工作可以比圖中所示的要晚結(jié)束。本圖說明了每段時間中主要強(qiáng)調(diào)的重點都放在個別的活動上（圖5-3已經(jīng)更完整的提到過各項活動重疊的情形了）。


上層主管與客戶有時對于軟件項目中的完成點模糊不清、無法依據(jù)而感到泄氣，不過如果你依循著本文建議的做法，以完成點的方式追蹤項目進(jìn)度，將可以對項目狀態(tài)得到良好的了解。表5-1列出這些完成點與圖5-7的高層次階段劃分方式相對應(yīng)的詳細(xì)活動。

表5-1 高層次完成點與推行點的劃分方式
◆ 項目初期
□ 找出項目關(guān)鍵決策者
□ 建立、檢視并按照前景敘述進(jìn)行項目
□ 建立軟件的業(yè)務(wù)狀況評估
□ 建立、檢視初步努力與時間目標(biāo)
□ 團(tuán)隊中擁有2～3名資深開發(fā)人員
□ 建立、檢視變更管制規(guī)劃，定案
□ 建立、檢視十大風(fēng)險清單，并以此避開已知風(fēng)險
□ 開始記錄軟件項目的過程
項目這時期所進(jìn)行的工作沒有的明顯終結(jié)點。這時期的工作是用來了解項目規(guī)模而進(jìn)行的。這時期耗用的時間和精力會隨著項目的不同而有極大變化
◆ 項目開啟/可行性研究完成

□ 質(zhì)量保證主導(dǎo)者就位
□ 文件說明主導(dǎo)者就位
□ 找出重要使用者，進(jìn)行訪談
□ 建立簡單的使用者接口雛形，由使用者審查直到能被接受后定案
□ 使用者接口格式簡介建立，經(jīng)過檢閱后作為日后說明文件的基礎(chǔ)
□ 建立第一次項目評估（精確度在-50%～范圍線+100%的范圍內(nèi)），檢視評估記結(jié)果后定案
□ 建立初步軟件開發(fā)規(guī)劃，經(jīng)過審查后，據(jù)以執(zhí)行項目過程
□ 更新十大風(fēng)險清單
□ 更新軟件項目記錄
項目在這部分的工作也是不受結(jié)尾限制的，而且依照項目性質(zhì)而決定

◆ 初步需求開發(fā)完成
在這時期，項目中開放性結(jié)尾的工作都已經(jīng)完成了，現(xiàn)在需要一些檢查來決定要不要繼續(xù)進(jìn)行項目
□ 建立細(xì)節(jié)使用者接口雛形，經(jīng)過檢視后定案
□ 建立使用說明/使用規(guī)格，經(jīng)過審查后定案
□ 建立軟件質(zhì)量保證計劃，經(jīng)過檢查后定案
□ 建立細(xì)節(jié)軟件開發(fā)規(guī)劃，經(jīng)過檢查后定案
□ 更新項目評估（精確度在-45%～+75%的范圍內(nèi)）
□ 更新十大風(fēng)險清單
□ 更新軟件項目記錄
到這一階段中約花費12%的項目時間跟6%的人手精力。這些比例不包括在項目開啟/可行性研究與初步需求開發(fā)上的工作時間跟努力成效的花費

◆ 細(xì)節(jié)需求開發(fā)完成
◆ 審查規(guī)劃，決定要不要繼續(xù)進(jìn)行項目

□ 開發(fā)團(tuán)隊大致就位
□ 管理人員大致就位
□ 完成使用說明/使用規(guī)格后撤除撰寫文件的人力（除非有別的文件產(chǎn)品要寫）
□ 建立軟件構(gòu)架文件，檢查后定案
□ 建立軟件整合程序，檢查后定案
□ 建立階段性完成規(guī)劃，檢查后定案
□ 建立第一階段的軟件測試項目，檢查后定案
□ 更新使用說明/使用規(guī)格
□ 更新項目評估（精確度在-30%～+40%）
□ 更新十大風(fēng)險清單
□ 更新軟件開發(fā)規(guī)劃
□ 更新軟件項目記錄
到這階段，約耗費20%的項目時間與14%的精力

◆ 構(gòu)架完成

□ 開發(fā)團(tuán)隊完全就位
□ 品管人員完全就位
□ 初步階段規(guī)劃完成
□ 建立第一階段的細(xì)節(jié)設(shè)計文件，檢查后定案
□ 建立包括小型完成點的第一階段的細(xì)節(jié)軟件構(gòu)建規(guī)劃，檢查后定案
□ 建立下一階段的軟件測試項目，檢查后定案
□ 更新第一階段軟件測試項目
□ 建立第一階段軟件建立指示（產(chǎn)生檔案）
□ 建立第一階段軟件源代碼，檢查后定案
□ 創(chuàng)造安裝程序，檢查后定案
□ 更新使用說明/使用規(guī)格
□ 第一階段“功能完成”產(chǎn)品
□ 更新項目評估（精確度在-20%～+30%）
□ 更新十大風(fēng)險清單
□ 更新軟件項目記錄
假設(shè)項目分三個階段，到這階段約耗用45%的項目時間與40%的努力成效

◆ 第一階段程序代碼完成
□ 各項活動同上
到這階段約花費65%的項目時間與65%的努力成效

◆第二階段源代碼完成
□ 建立最后階段細(xì)節(jié)設(shè)計文件，檢查后定案
□ 更新所有階段軟件測試項目
□ 更新所有階段軟件源代碼
□ 更新所有階段軟件建立指示（產(chǎn)生檔案）
□ 更新安裝程序
□ 如果軟件是個業(yè)務(wù)系統(tǒng)，完成使用文件（清楚的使用說明），完成使用者訓(xùn)練，使用團(tuán)隊準(zhǔn)備上路
□ 整合已完成的“功能完整”產(chǎn)品
□ 更新項目評估（精確度在-5%～+5%）
□ 更新十大風(fēng)險清單
□ 更新軟件項目記錄
到這階段，約花費85%的項目時間跟90%的努力成果

◆ 最后階段源代碼完成（如果分三個階段，這就是第三階段）

□ 建立發(fā)行檢查項目，檢查后定案
□ 所有成員同意發(fā)行產(chǎn)品，不再更議產(chǎn)品
□ 完成功能正確的產(chǎn)品
□ 完成功能正確的安裝程序
□ 完成最后測試項目
□ 完成軟件正本的復(fù)制
□ 項目成果媒介（源代碼、建立環(huán)境等）歸檔存放
□ 更新最后軟件項目記錄
□ 建立項目歷程文件，檢查后定案
到了這階段，用去100%的項目時間與努力成效

◆ 產(chǎn)品發(fā)行

有時人們會想，為何軟件項目要花那么久的時間。表5-1中的推進(jìn)項目清單有助于回答這個問題。每個推進(jìn)項目都代表一些必須完成才能讓項目有效推進(jìn)的重要工作。

大部分執(zhí)行成效糟糕的項目最后都得做同樣的事情，由于它們?nèi)狈芾?br> ，執(zhí)行起來也缺乏效率，最后花費代價更多卻沒得到什么好處。

人們抗拒“開發(fā)程序”的一個理由是開發(fā)程序?qū)虻捻椖吭谝婚_始就讓人們看到一張這樣的工作清單，使他們覺得“把這些事情都做完的話，項目就永遠(yuǎn)做不完了！”事實是如果項目中不做這些事，就得花更久時間才完成得了。即使小型的項目也得處理表5-1中列出來的絕大多數(shù)工作項目，雖然有些工作在小型項目中做起來不會花什么時間。我們也不希望做那么多工作，不過對軟件項目而言，忽視一定得做的事情恐怕會功虧一簣，而如果人們知道一個項目中從開頭就有哪些事情必須做的話，每個人都會好過得多。

=================================================================
求生檢查
項目采用階段性完成方式。
上層主管、顧客或兩者都依據(jù)程序代碼增長曲線盯緊項目進(jìn)度。
上層主管、顧客或兩者都留心著主要完成點和推行點的達(dá)成。
=================================================================

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