第7章 項目進度安排及跟蹤
在六十年代后期，一位熱情的青年工程師①受命為一個自動制造應(yīng)用軟件項目“編寫”計算機程序。選擇他的原因非常簡單，因為在整個技術(shù)小組中他是參加過計算機編程培訓(xùn)班的人。這位工程師對匯編語言的IN和OUT指令以及Fortran語言略知一二，但是卻根本不懂軟件工程，更不用說項目進度安排和跟蹤了。
他的老板給了他一大堆相關(guān)的手冊，以及需要做些什么的口頭描述。年輕人被告知該項目必須在兩個月之內(nèi)完成。
他閱讀了這些手冊，想好了解決方法，就開始編寫代碼。兩周之后，老板將他叫到辦公室詢問項目進展情況。
“非常好，”工程師以年輕人的熱情回答道，“這個項目遠比我想象的簡單。我差不多已經(jīng)完成了75％的任務(wù)?！?BR> 老板笑了，說道：“真是太棒了?！比缓笏麌诟滥贻p人繼續(xù)努力工作，準(zhǔn)備好一周后再匯報工作進度。
一周之后老板將年輕人叫到辦公室，問他說：“現(xiàn)在進度如何？”
“一切順利，”年輕人回答說，“但是我遇到了一些小麻煩。我會排除這些困難，很快就可以回到正軌上來。”
“你覺得在后期限之前能否完成？”老板問道。
“沒有問題，”工程師答道。“我差不多已經(jīng)完成了90％。”
如果讀者在軟件領(lǐng)域中工作過幾年，你一定可以將這個故事寫完。毫不奇怪，青年工程師在整個項目工期內(nèi)始終停留在90％的進度上，(在別人的幫助下)直到交付期限之后一個月才做完。
在過去的30年間，這樣的故事被不同的軟件開發(fā)者重復(fù)了成千上萬次。我們不禁要問：“為什么？”
7.1基本概念
雖然軟件延期交付的原因很多，但是大多數(shù)都可以追溯到下面列出的一個或多個根本原因上：
·一個不現(xiàn)實的截止期限，由軟件工程組以外的人所設(shè)立并強加給軟件工程組內(nèi)的管理者和項目開發(fā)者。
·客戶需求發(fā)生變化，而需求的變化沒有能夠反映在項目進度的變化上。
·對工作量和/或完成該工作所需的資源數(shù)量估計不足。
·在項目開始時，沒有將可以預(yù)測的和/或不可預(yù)測的風(fēng)險考慮在內(nèi)。
·事先無法預(yù)計的技術(shù)困難。
·事先無法預(yù)計的人力困難。
·由于項目組成員之間的交流不暢而導(dǎo)致的延期。
·項目管理者未能發(fā)現(xiàn)進度拖后，也未能采取行動解決這一問題。
在軟件行業(yè)中，人們對過于樂觀的(即“不現(xiàn)實的”)項目完成期限已經(jīng)司空見慣。有時候設(shè)定截止時間的人認為這樣的截止期限是合理的，但是常識告訴我們，合理與否還必須由完成工作的人來判斷。
7.1.1 關(guān)于“延遲”的評注
拿破侖曾經(jīng)說過：“任何同意執(zhí)行一個他本人都認為有缺點的計劃的指揮官都應(yīng)該受到指責(zé)；他必須提出自己的反對理由，堅持修改這一計劃，終甚至提出辭職而不是使自己的軍隊遭受慘敗?！边@句話擲地有聲，值得軟件項目管理者們深思。
在第5和第6章中討論的估算和風(fēng)險分析活動，以及本章中涉及的進度安排技術(shù)，通常都需要在一個定義好的截止期限的約束之下實現(xiàn)。如果樂觀的估算都表明截止期限是不現(xiàn)實的，一個勝任的項目管理者就應(yīng)該“保護其隊伍免受不適當(dāng)?shù)倪M度安排的壓力并將這種壓力反映給施加壓力的一方”［PAG85］。
不妨舉例說明，假定一個軟件開發(fā)小組的任務(wù)是構(gòu)造一個醫(yī)療診斷儀器的實時控制器，該控制器需要在9個月之內(nèi)推向市場。在進行了仔細的估算和風(fēng)險分析之后，軟件項目管理者得到的結(jié)論是在現(xiàn)有人員條件下，需要14個月的時間才能完成這一軟件。這位項目管理者下一步該怎么辦？
闖進客戶的辦公室(這里的客戶非常可能是市場或銷售人員)并要求修改交付日期似乎不太現(xiàn)實。外部市場壓力決定了交付日期，屆時必須發(fā)布產(chǎn)品。而(從事業(yè)前途的角度出發(fā))拒絕這一項目同樣是魯莽的。那么應(yīng)該怎么辦呢？
在這種情況下，推薦以下的處理步驟：
1.使用從以前的項目中得到的數(shù)據(jù)，進行詳細的估算。確定項目的估算工作量和持續(xù)時間。
2.使用增量過程模型(參見第2章)，制定一個軟件開發(fā)策略，以能夠在規(guī)定的交付日期提供關(guān)鍵功能，而將其他功能的實現(xiàn)推到以后。將這一計劃做成文檔。
3.與客戶會談并(用詳細估算結(jié)果)來解釋為什么規(guī)定的交付日期是不現(xiàn)實的，一定要指出所有這些估算都是基于以往的項目實踐，而且一定要指出為了在目前規(guī)定的交付期限完成項目，與以往相比在工作效率上必須提高的百分比①。做如下解釋將是恰如其分的：
“我認為在XYZ控制器軟件的交付日期方面存在一個問題，我已經(jīng)將一份以往項目中生產(chǎn)率的簡化明細分類表和以多種不同方式進行的項目估算提交給各位，你會注意到我已經(jīng)假設(shè)與以往的生產(chǎn)率相比有20％的提高，但是我們?nèi)匀恢荒艿玫?4個月而不是9個月的交付時間?！?BR> 4.將增量開發(fā)策略作為可選計劃提交給客戶。
“我們有幾個選擇，而我希望各位能夠在這些選擇的基礎(chǔ)上做出決策。首先，我們可以增加預(yù)算，并引入額外的資源，以便使我們能夠在9個月時間內(nèi)完成這一工作。但是應(yīng)該知道由于時間限制過于苛刻，這樣做將會增加質(zhì)量差的風(fēng)險②。第二個方案是，去掉一部分需求中所列出的軟件功能和特性。由此得到功能稍弱的產(chǎn)品的初版本，但是我們可以對外宣布全部功能，并在總共14個月的時間內(nèi)發(fā)布這些功能。第三種選擇是不顧現(xiàn)實條件的約束，而希望項目能夠在9個月時間內(nèi)完成。結(jié)果是我們竭盡全力，但是卻無法向用戶提供任何功能。我想你們會同意，第三種選擇是不可接受的。過去的歷史和我們樂觀的估算都表明這是不現(xiàn)實的，是在選擇一場災(zāi)難?！?BR> 盡管這樣做會有些抱怨，但如果你給出了基于準(zhǔn)確的歷史數(shù)據(jù)的可靠估算，那么終的談判結(jié)果將可能是選擇1或者選擇2。不現(xiàn)實的交付期限就不存在了。
7.1.2基本原則
曾經(jīng)有人請教的《神秘的人月》(The Mythical Man－Month，見文獻［BRO95］)一書的作者Fred Brooks，“軟件項目的進度是如何延遲的？”他的回答即簡單又深刻：“一天。”
技術(shù)性項目(不論它是涉及到水力發(fā)電廠建設(shè)，還是開發(fā)一個操作系統(tǒng))的現(xiàn)實情況是，在實現(xiàn)一個大目標(biāo)之前必須完成數(shù)以百計的小任務(wù)。這些任務(wù)中有些是處于主流之外，其實現(xiàn)不會影響到整個項目的完成時間；其他任務(wù)則位于“關(guān)鍵路徑”①之上，如果這些“關(guān)鍵”任務(wù)的進度拖后，則整個項目的完成日期就會受到威脅。
項目管理者的目標(biāo)是定義所有項目任務(wù)，識別關(guān)鍵任務(wù)，然后跟蹤關(guān)鍵任務(wù)的進展以保證“一天”的發(fā)現(xiàn)進度拖延情況。為了做到這一點，管理者必須建立一個具有一定詳細程度的進度表，使得項目管理者能夠監(jiān)督進度，并控制整個項目。
軟件項目進度安排是一種活動，它通過將工作量分配給特定的軟件工程任務(wù)，而將所估算的工作量分布于計劃好的項目持續(xù)時間內(nèi)。但是，進度是隨著時間的改變而不斷演化的，注意到這一點至關(guān)重要。在項目計劃的早期，首先建立一個宏觀的進度安排表。該進度表標(biāo)識所有主要的軟件工程活動和這些活動影響到的產(chǎn)品功能。隨著項目的進展，宏觀進度表中的每個條目都被精化成一個“詳細進度表”。于是(完成一個活動所必須實現(xiàn)的)特定軟件任務(wù)被標(biāo)識出來，并進行進度安排。
可以從兩個不同的視角考察軟件開發(fā)項目的進度安排。第一個視角，基于計算機的系統(tǒng)的終發(fā)布日期已經(jīng)確定(而且不能更改)。軟件開發(fā)組織在這一約束下將工作量分布在預(yù)先確定的時間框架內(nèi)。第二個視角，假定大致的時間界限已經(jīng)討論過，但是終發(fā)布日期是由軟件開發(fā)組設(shè)定的，工作量以一種能夠好地利用資源的方式加以分布，且在對軟件進行仔細分析之后才定義終發(fā)布日期。但不幸的是，第一種情況發(fā)生的頻率遠遠高于第二種情況。
同軟件工程的所有其他領(lǐng)域一樣，有一些基本原則能夠指導(dǎo)軟件項目的進度安排：
劃分：項目必須被劃分成若干可以管理的活動和任務(wù)。為了實現(xiàn)項目的劃分，對產(chǎn)品和過程都需要進行分解(參見第3章)。
相互依賴性：各個被劃分的活動或任務(wù)之間的相互關(guān)系必須是確定的。有些任務(wù)必須順序發(fā)生；而其他的則可以并發(fā)進行。有些活動只有在其他活動產(chǎn)生的工作產(chǎn)品完成時才能夠開始，而其他的則可以獨立進行。
時間分配：必須為每個被調(diào)度的任務(wù)分配一定數(shù)量的工作單位(例如，若干人天的工作量)。此外，必須為每個任務(wù)指定開始和結(jié)束日期，這些日期是與工作完成的方式相互依賴的(全職還是兼職)是工作方式的函數(shù)。
工作量確認：每個項目都有預(yù)定數(shù)量的人員參與。在進行時間分配時，項目管理者必須確保在任意時段中分配給任務(wù)的人員數(shù)量不會超過項目組中的人員數(shù)量。例如，一個項目分配了3名員工參加(即，每天可分配的工作量為3人天②)。在某一天中，需要完成7項并發(fā)的任務(wù)，每個任務(wù)需要0.50人天的工作量，在這種情況下，所分配的工作量就大于可用于分配的工作量。
定義責(zé)任：每個被調(diào)度的任務(wù)都應(yīng)該指定某個特定的小組成員來負責(zé)。
定義結(jié)果：每個被調(diào)度的任務(wù)都應(yīng)該有一個定義好的結(jié)果。對于軟件項目而言，結(jié)果通常是一個工作產(chǎn)品(例如一個模塊的設(shè)計)或某個工作產(chǎn)品的一部分。通常將多個工作產(chǎn)品組合成“可交付產(chǎn)品”。
定義里程碑：每個任務(wù)或任務(wù)組都應(yīng)該與一個項目里程碑相關(guān)聯(lián)。當(dāng)一個或多個工作產(chǎn)品經(jīng)過質(zhì)量復(fù)審(參見第8章)并且得到認可時，標(biāo)志著一個里程碑的完成。
隨著項目進度的發(fā)展，上述每一條原則都會被用到。
在六十年代后期，一位熱情的青年工程師①受命為一個自動制造應(yīng)用軟件項目“編寫”計算機程序。選擇他的原因非常簡單，因為在整個技術(shù)小組中他是參加過計算機編程培訓(xùn)班的人。這位工程師對匯編語言的IN和OUT指令以及Fortran語言略知一二，但是卻根本不懂軟件工程，更不用說項目進度安排和跟蹤了。
他的老板給了他一大堆相關(guān)的手冊，以及需要做些什么的口頭描述。年輕人被告知該項目必須在兩個月之內(nèi)完成。
他閱讀了這些手冊，想好了解決方法，就開始編寫代碼。兩周之后，老板將他叫到辦公室詢問項目進展情況。
“非常好，”工程師以年輕人的熱情回答道，“這個項目遠比我想象的簡單。我差不多已經(jīng)完成了75％的任務(wù)?！?BR> 老板笑了，說道：“真是太棒了?！比缓笏麌诟滥贻p人繼續(xù)努力工作，準(zhǔn)備好一周后再匯報工作進度。
一周之后老板將年輕人叫到辦公室，問他說：“現(xiàn)在進度如何？”
“一切順利，”年輕人回答說，“但是我遇到了一些小麻煩。我會排除這些困難，很快就可以回到正軌上來。”
“你覺得在后期限之前能否完成？”老板問道。
“沒有問題，”工程師答道。“我差不多已經(jīng)完成了90％。”
如果讀者在軟件領(lǐng)域中工作過幾年，你一定可以將這個故事寫完。毫不奇怪，青年工程師在整個項目工期內(nèi)始終停留在90％的進度上，(在別人的幫助下)直到交付期限之后一個月才做完。
在過去的30年間，這樣的故事被不同的軟件開發(fā)者重復(fù)了成千上萬次。我們不禁要問：“為什么？”
7.1基本概念
雖然軟件延期交付的原因很多，但是大多數(shù)都可以追溯到下面列出的一個或多個根本原因上：
·一個不現(xiàn)實的截止期限，由軟件工程組以外的人所設(shè)立并強加給軟件工程組內(nèi)的管理者和項目開發(fā)者。
·客戶需求發(fā)生變化，而需求的變化沒有能夠反映在項目進度的變化上。
·對工作量和/或完成該工作所需的資源數(shù)量估計不足。
·在項目開始時，沒有將可以預(yù)測的和/或不可預(yù)測的風(fēng)險考慮在內(nèi)。
·事先無法預(yù)計的技術(shù)困難。
·事先無法預(yù)計的人力困難。
·由于項目組成員之間的交流不暢而導(dǎo)致的延期。
·項目管理者未能發(fā)現(xiàn)進度拖后，也未能采取行動解決這一問題。
在軟件行業(yè)中，人們對過于樂觀的(即“不現(xiàn)實的”)項目完成期限已經(jīng)司空見慣。有時候設(shè)定截止時間的人認為這樣的截止期限是合理的，但是常識告訴我們，合理與否還必須由完成工作的人來判斷。
7.1.1 關(guān)于“延遲”的評注
拿破侖曾經(jīng)說過：“任何同意執(zhí)行一個他本人都認為有缺點的計劃的指揮官都應(yīng)該受到指責(zé)；他必須提出自己的反對理由，堅持修改這一計劃，終甚至提出辭職而不是使自己的軍隊遭受慘敗?！边@句話擲地有聲，值得軟件項目管理者們深思。
在第5和第6章中討論的估算和風(fēng)險分析活動，以及本章中涉及的進度安排技術(shù)，通常都需要在一個定義好的截止期限的約束之下實現(xiàn)。如果樂觀的估算都表明截止期限是不現(xiàn)實的，一個勝任的項目管理者就應(yīng)該“保護其隊伍免受不適當(dāng)?shù)倪M度安排的壓力并將這種壓力反映給施加壓力的一方”［PAG85］。
不妨舉例說明，假定一個軟件開發(fā)小組的任務(wù)是構(gòu)造一個醫(yī)療診斷儀器的實時控制器，該控制器需要在9個月之內(nèi)推向市場。在進行了仔細的估算和風(fēng)險分析之后，軟件項目管理者得到的結(jié)論是在現(xiàn)有人員條件下，需要14個月的時間才能完成這一軟件。這位項目管理者下一步該怎么辦？
闖進客戶的辦公室(這里的客戶非常可能是市場或銷售人員)并要求修改交付日期似乎不太現(xiàn)實。外部市場壓力決定了交付日期，屆時必須發(fā)布產(chǎn)品。而(從事業(yè)前途的角度出發(fā))拒絕這一項目同樣是魯莽的。那么應(yīng)該怎么辦呢？
在這種情況下，推薦以下的處理步驟：
1.使用從以前的項目中得到的數(shù)據(jù)，進行詳細的估算。確定項目的估算工作量和持續(xù)時間。
2.使用增量過程模型(參見第2章)，制定一個軟件開發(fā)策略，以能夠在規(guī)定的交付日期提供關(guān)鍵功能，而將其他功能的實現(xiàn)推到以后。將這一計劃做成文檔。
3.與客戶會談并(用詳細估算結(jié)果)來解釋為什么規(guī)定的交付日期是不現(xiàn)實的，一定要指出所有這些估算都是基于以往的項目實踐，而且一定要指出為了在目前規(guī)定的交付期限完成項目，與以往相比在工作效率上必須提高的百分比①。做如下解釋將是恰如其分的：
“我認為在XYZ控制器軟件的交付日期方面存在一個問題，我已經(jīng)將一份以往項目中生產(chǎn)率的簡化明細分類表和以多種不同方式進行的項目估算提交給各位，你會注意到我已經(jīng)假設(shè)與以往的生產(chǎn)率相比有20％的提高，但是我們?nèi)匀恢荒艿玫?4個月而不是9個月的交付時間?！?BR> 4.將增量開發(fā)策略作為可選計劃提交給客戶。
“我們有幾個選擇，而我希望各位能夠在這些選擇的基礎(chǔ)上做出決策。首先，我們可以增加預(yù)算，并引入額外的資源，以便使我們能夠在9個月時間內(nèi)完成這一工作。但是應(yīng)該知道由于時間限制過于苛刻，這樣做將會增加質(zhì)量差的風(fēng)險②。第二個方案是，去掉一部分需求中所列出的軟件功能和特性。由此得到功能稍弱的產(chǎn)品的初版本，但是我們可以對外宣布全部功能，并在總共14個月的時間內(nèi)發(fā)布這些功能。第三種選擇是不顧現(xiàn)實條件的約束，而希望項目能夠在9個月時間內(nèi)完成。結(jié)果是我們竭盡全力，但是卻無法向用戶提供任何功能。我想你們會同意，第三種選擇是不可接受的。過去的歷史和我們樂觀的估算都表明這是不現(xiàn)實的，是在選擇一場災(zāi)難?！?BR> 盡管這樣做會有些抱怨，但如果你給出了基于準(zhǔn)確的歷史數(shù)據(jù)的可靠估算，那么終的談判結(jié)果將可能是選擇1或者選擇2。不現(xiàn)實的交付期限就不存在了。
7.1.2基本原則
曾經(jīng)有人請教的《神秘的人月》(The Mythical Man－Month，見文獻［BRO95］)一書的作者Fred Brooks，“軟件項目的進度是如何延遲的？”他的回答即簡單又深刻：“一天。”
技術(shù)性項目(不論它是涉及到水力發(fā)電廠建設(shè)，還是開發(fā)一個操作系統(tǒng))的現(xiàn)實情況是，在實現(xiàn)一個大目標(biāo)之前必須完成數(shù)以百計的小任務(wù)。這些任務(wù)中有些是處于主流之外，其實現(xiàn)不會影響到整個項目的完成時間；其他任務(wù)則位于“關(guān)鍵路徑”①之上，如果這些“關(guān)鍵”任務(wù)的進度拖后，則整個項目的完成日期就會受到威脅。
項目管理者的目標(biāo)是定義所有項目任務(wù)，識別關(guān)鍵任務(wù)，然后跟蹤關(guān)鍵任務(wù)的進展以保證“一天”的發(fā)現(xiàn)進度拖延情況。為了做到這一點，管理者必須建立一個具有一定詳細程度的進度表，使得項目管理者能夠監(jiān)督進度，并控制整個項目。
軟件項目進度安排是一種活動，它通過將工作量分配給特定的軟件工程任務(wù)，而將所估算的工作量分布于計劃好的項目持續(xù)時間內(nèi)。但是，進度是隨著時間的改變而不斷演化的，注意到這一點至關(guān)重要。在項目計劃的早期，首先建立一個宏觀的進度安排表。該進度表標(biāo)識所有主要的軟件工程活動和這些活動影響到的產(chǎn)品功能。隨著項目的進展，宏觀進度表中的每個條目都被精化成一個“詳細進度表”。于是(完成一個活動所必須實現(xiàn)的)特定軟件任務(wù)被標(biāo)識出來，并進行進度安排。
可以從兩個不同的視角考察軟件開發(fā)項目的進度安排。第一個視角，基于計算機的系統(tǒng)的終發(fā)布日期已經(jīng)確定(而且不能更改)。軟件開發(fā)組織在這一約束下將工作量分布在預(yù)先確定的時間框架內(nèi)。第二個視角，假定大致的時間界限已經(jīng)討論過，但是終發(fā)布日期是由軟件開發(fā)組設(shè)定的，工作量以一種能夠好地利用資源的方式加以分布，且在對軟件進行仔細分析之后才定義終發(fā)布日期。但不幸的是，第一種情況發(fā)生的頻率遠遠高于第二種情況。
同軟件工程的所有其他領(lǐng)域一樣，有一些基本原則能夠指導(dǎo)軟件項目的進度安排：
劃分：項目必須被劃分成若干可以管理的活動和任務(wù)。為了實現(xiàn)項目的劃分，對產(chǎn)品和過程都需要進行分解(參見第3章)。
相互依賴性：各個被劃分的活動或任務(wù)之間的相互關(guān)系必須是確定的。有些任務(wù)必須順序發(fā)生；而其他的則可以并發(fā)進行。有些活動只有在其他活動產(chǎn)生的工作產(chǎn)品完成時才能夠開始，而其他的則可以獨立進行。
時間分配：必須為每個被調(diào)度的任務(wù)分配一定數(shù)量的工作單位(例如，若干人天的工作量)。此外，必須為每個任務(wù)指定開始和結(jié)束日期，這些日期是與工作完成的方式相互依賴的(全職還是兼職)是工作方式的函數(shù)。
工作量確認：每個項目都有預(yù)定數(shù)量的人員參與。在進行時間分配時，項目管理者必須確保在任意時段中分配給任務(wù)的人員數(shù)量不會超過項目組中的人員數(shù)量。例如，一個項目分配了3名員工參加(即，每天可分配的工作量為3人天②)。在某一天中，需要完成7項并發(fā)的任務(wù)，每個任務(wù)需要0.50人天的工作量，在這種情況下，所分配的工作量就大于可用于分配的工作量。
定義責(zé)任：每個被調(diào)度的任務(wù)都應(yīng)該指定某個特定的小組成員來負責(zé)。
定義結(jié)果：每個被調(diào)度的任務(wù)都應(yīng)該有一個定義好的結(jié)果。對于軟件項目而言，結(jié)果通常是一個工作產(chǎn)品(例如一個模塊的設(shè)計)或某個工作產(chǎn)品的一部分。通常將多個工作產(chǎn)品組合成“可交付產(chǎn)品”。
定義里程碑：每個任務(wù)或任務(wù)組都應(yīng)該與一個項目里程碑相關(guān)聯(lián)。當(dāng)一個或多個工作產(chǎn)品經(jīng)過質(zhì)量復(fù)審(參見第8章)并且得到認可時，標(biāo)志著一個里程碑的完成。
隨著項目進度的發(fā)展，上述每一條原則都會被用到。