開發時程規畫大剖析第2回─測試時程易低估，及早預警較保險

想要透過量化的方法，預估軟體的開發時程，那麼收集團隊開發的相關歷史資料，就成了一個很重要的工作。過去的經驗，是我們得以估算新開發工作的重要參考，了解究竟需要多少時間及資源來完成。

之前也提到了，技術上的風險是時程估算的不確定因素，應該要盡量降低每個開發專案裡的這類變因。此外，也建議每個工作的估計時程，應由專案經理和每一項工作的執行者一同討論，進而決定下來，並且藉此取得執行者對工作時程的承諾。

而緩衝時間的設置，也是專案經理時常用來保護時程的一個技巧，但由於自我實現的預言之故，最好不要為個別的工作設置緩衝時間，而是將緩衝時間留給整個專案本身。

在軟體開發時程的規畫上，許多團隊時常會低估測試以及修正所需的時間。這也是導致產品延遲交付的常見原因之一。這或許是因為當完成了程式碼撰寫的工作後，系統看起來也像是能夠運作，所以人們也就認為它距離可以交付的水平不遠了。

許多專案經理甚至會在自己的時程表中，很樂觀地估計一個很短的測試時間。事實上，許多開發專案需要的測試時間，往往不這麼樂觀。

測試時程還必須包括修正臭蟲所需的時間
測試時間是軟體開發時程中很難估計的一環，許多人看待測試時間的態度，就是設下一個期限，然後預期能在時段內測試完成。

倘若你能夠列出或者估計出測試案例的約略數量，那麼或許能夠估計執行這些測試案例所需的時間。但是，在規畫測試的時間內，不單要執行測試，更重要的是，程式人還必須針對找出來的臭蟲，修正錯誤。

軟體的臭蟲可以依據嚴重程度來分類，但有一類相當嚴重，因為它們的存在，擋住了你的進度，使得無法繼續執行之後眾多的測試案例。像這樣子的情況時，測試人員就必須等待程式人修正錯誤之後，才有機會繼續往下測試。

也就是說，在程式人修正錯誤之前，測試人員便陷入空轉的狀態。而程式人修正一個錯誤需要的時間，也是不易估計的。有時候解決一個臭蟲很快，有時候，即使修正一個臭蟲的方法，只需要修改一行程式碼，卻可能耗去你數天甚至數周的時間。如果這類型的臭蟲一多，那麼連能不能在期限內執行完所有的測試案例，都成了問題。

測試時間內要做的工作，不單只是執行測試案例而已，更重要的是驅逐臭蟲、修正錯誤需要的時間。正如前一段中所提到的，修正錯誤的時間難以估計，究竟需要多少時間來修正錯誤，其實是很難說的。接著，在修正完錯誤後，還得重新測試。除了驗證原先有問題的測試案例，確定臭蟲的確被修正之外，還得對相關的測試案例重新執行一輪，即使它們原先是正常的，這是因為許多修正臭蟲的動作，往往衍生了副作用，引來更多的臭蟲，使得原先運作正常的功能反而出錯。整個測試的時間，便在這來來返返的錯誤與驗證過程中耗去了。

測試階段的結束與否，並不是以時程表上的期限做為判斷標準，而是以軟體品質是否已達可以接受為標準。但軟體品質何時才能達到這樣的水平呢？相較於程式碼的撰寫，這又更難估計了。

頭過身就過的交差心態，導致測試時程拉得更長
另一方面，倘若開發時程過於緊湊，對程式人的壓力施加過大，程式人有可能試著先完成看起來功能完整，內部卻暗藏許多地雷的系統，以求完成程式撰寫階段，先闖關進到測試階段，以卸下大部分的壓力再說。

這或許是源自於一種「頭過身就過」的心態，但是，「出來混，遲早要還的」。這些問題，或許暫時隱藏著，但是到了測試階段「醜媳婦總是得見公婆」的。更重要的是，這些暗藏的地雷，會使得測試階段不僅拉得更長，而且更不易預估究竟會需要多少時間，因為你不知道程式人究竟埋了多少地雷在系統裡面。而這些，都是造成低估所需測試時間的可能原因。

同時參與多個專案的人，最容易成為專案的瓶頸
除了測試時間會被低估之外，整個開發過程中都有可能發生需求變更，而容忍需求變更的部分，也沒有考量進來。同樣的，需求變更可能會對時程造成的衝擊可小可大，小則僅是訊息、圖片的修改，大者可能影響到整體架構。

不同的開發方法，影響允許改變需求的方式，估量這部分時間的方式，也會跟著改變。但無論如何，當你考慮時程時，不應該忽略需求變更時肯定會發生的事實，而且「肯定」會占去開發時程。

另外，許多專案中都會有所謂的「共用資源」。像在軟體開發專案裡格外明顯。怎麼說呢？尤其在同一家公司裡，程式設計功力較高的幾個程式人，時常會被同時分派在多個開發專案裡，一人身兼多職，這種現象很普遍，卻是對時程規畫的一大傷害。同時參與多個專案的程式人，很容易成為專案的瓶頸所在。

一方面是專案經理時常會高估多工下的程式人的生產力，事實上，倘若一名程式人的工作分攤在兩個專案裡，那麼可以為這兩個專案分別貢獻的生產力，通常不到全職生產力的一半。那麼，同時參與兩個以上的專案，就更不用說了。

此外，當多個專案的其中一個發生了意外，「咬住」了這名程式人，原先預計在另一個專案中登場的時間點就會延遲，那麼倘若這個工作又是落在該專案的要徑（Critical Path）上，整個專案便會一同發生延遲。所以身兼越多專案的程式人，越有可能成為各專案中的不穩定因素。

越早偵測出專案可能延遲，越容易挽救
那麼，當無法趕上預計的開發時程又該如何是好？許多團隊會選擇加班，其實加班適用於偶而為之的短期衝刺，但是對於較長時間的時程延遲並不適合。

另外，有些團隊可能也會考慮為專案加入更多的資源──也就是加入更多的人力。不過，想要透過加入人力來解決時程問題，也不是全然沒有負面效應。由於新加入的人力，可能對這個已經開發到一半的專案不那麼熟悉，生力軍需要花一段時間才能上手，通常都不是即戰力。因此，在考量加入額外的人手時，也必須考慮到這批生力軍上手的時間。

因此，專案即將發生延遲，必須越早偵測出來越好。大多數人對專案時程的延遲，多半還是存在「拼拼看」的態度，於是，即使是發生了將要延遲的各種訊號，仍然憑著一股拼勁，想要在最後一刻趕上進度。

這固然是一種積極的心態，但也有可能造成到了期限的那一天，所有的人才發現原來時程趕不及，而無法在其他方面採取配套的措施。事實上，專案中的每個人，在意識到自己的工作可能會有延遲時，都應該提出來討論，起碼發出一個示警的訊號，讓其他人（尤其是專案經理）有更多的資源來調整計畫，專案經理不應該是到了期限那一天，才知道該工作會延遲完成。

越早查覺出工作可能會發生延遲，加入新人力的效果才會越好，因為這麼一來，便能夠保留越多的上手時間。

除了上手時間之外，人力越多，也會提高管理的複雜度，這是專案經理必須試著克服的另一點。

作者簡介─王建興
	清華大學資訊工程系的博士研究生，研究興趣包括電腦網路、點對點網路、分散式網路管理、以及行動式代理人，專長則是Internet應用系統的開發。曾參與過的開發專案性質十分廣泛而且不同，從ERP、PC Game到P2P網路電話都在他的涉獵範圍之內。