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