開發時程的預估（1）

在上一回中提到了不切實際的時程規劃表，大多數時程規劃表其之所以不切實際，主要是源自於兩種原因。第一種是「過度樂觀」的想法，低估了軟體開發的複雜度及高風險。第二種則是「過度侵略性」的態度，在這種態度底下，時程的訂定者多半認為訂一個高難度的時程目標，最後結果也是「雖不中亦不遠矣」，仍然可以壓縮時程，甚至提前完成。

不過過度樂觀、忽略眾多可能變因的想法，通常就是讓現實來證明專案終究會不那麼樂觀的結束。而「過度侵略性」的時程訂定態度，形同於壓榨開發者的生產，暗示著長期加班的可能性，但這運用於短期衝刺或許可用，但想要長期壓榨開發者，除非提供極好的待遇，否則很少開發者有辦法忍受，畢竟沒有人的身心皆是鐵打而成的。在長期的壓榨底下，開發者對於開發工作，很容易變得心灰意懶。研究也指出，長期加班，即使整體的工時提昇，但由於專注力下降，程式碼品質也容易驟降，導致整體生產力反而更低。

那麼，開發的時程又應如何預估呢？我們很容易可以找到許多評估的方法和技巧，例如有名的功能點（function point），便是透過將欲開發的系統拆解成若干個功能，再以各個功能所需的資料輸入個數、資料查詢個數、資料輸出個數、檔案個數、外部界面個數做為參數，帶入一個計算的公式裡，最終可以得到系統規模的評估值。理想的情況下，我們可以透過換算，知道需要多少工時，也就可以做為預估時程之用。

這類量化的方法看似迷人，因為開發時程的預估始終都是管理上讓人很頭痛的一件事情。人們通常對數字有一種近乎迷信的心理心素，時常認為計算得出來的總比隨口喊出來的來得可信賴。事實上，量化的方法的確有其可用之處，但倘若要提昇預估的準確程度，還是得倚賴開發歷史資料的收集。

在CMMI Level 2裡有個流程領域叫做度量與分析（MA，Measurement
and Analysis）其中便包含了要針對開發過程收集相關的度量值，並且進行分析、記錄以及溝通。

為什麼需要收集歷史的資料，是因為每個團隊所開發的系統類型不同（例如，商用的ERP系統和線上遊戲系統就有很大的不同）、開發團隊的成員組成方式及素質也不同（事實上是，每個程式設計者的能力都不同），而量化的估算方法裡，通常都有許多要代入的參數，而這些參數都必須從開發的歷史中去得到。事實上，我甚至認為歷史的記錄比起估算的式子本身更重要，因為它基本上是保留了過去的經驗值。平常我們所謂「空口估時程」，其實也是依據我們隱性的過去經驗來「開出價碼」的。當然，明確的將開發歷史記錄下來，更有助於日後新的開發專案預估時程的參考及類比之用。

此外，即使有了過去的經驗值做為參數，想要更準確的預估時程，必須降低各種風險。專案中會發生的風險有很多類型，其中技術風險時常會被低估。

開發專案中之所以會有技術風險，有一部份原因是因為有些技術上的不確定性存在，而充滿不確定性的開發項目，是很難從過去的經驗中知道究竟會需要多少時間來完成的。例如，在你的專案裡，需要一個影像處理的引擎，而這個引擎對於效能還有效果，都有一些必須達成的目標。因此，這個引擎有一些演算法上必須克服的困難在，你或許得持續嘗試、研究，才能得到符合需求的引擎。但究竟需要多少時間來嘗試及研究，沒人說得準的。或許你可以在時程裡估計一個時間，但實際上需要多少，都只有做了才知道。倘若這種高度不確定的工作項目成了你開發時程裡重要的工作時（例如深深影響到主時程時），那麼其實你對最終完成時間的估計，也是同時有著高度不確定性的。

對負責這種工作的程式設計者，事實上不能在時程上過於苛責。因為專案管理者所預估的時程，時常原本就是一種沒有根據的估算（或許是從期限倒推回來），既然是你估不準的，又怎麼能怪罪別人沒有實現一個沒估準的期限呢？

專案中的工作倘若技術上的不確定性低，那麼就容易從歷史上的經驗預估，發生出乎意料之外結果的機會也相對較低。因此，應當是盡量不要把不確定性高的工作擺入一個期限要求嚴格的專案中，針對不確定性高的工作項目，最好成為一個獨立的專案，令其帶有實驗性質，而不對其設定過度嚴格的完成期限。也就是說，會被擺入專案中的工作，盡量都是已經驗證過技術可行性的工作，那麼不確定性可以降低，對於時程的估計也就可以更準確些。

除了怎麼估計之外，另外究竟是由誰來預估專案中的每一項工作需要的時間同樣也是一個議題。最好的情況，應該是由專案經理和每一項工作的執行者一同討論進而決定下來。許多專案工作的時程安排，都缺少了執行者的承諾。這會造成一個問題，就是專案經理單方面的認定這個工作應當在某個時間點完成，但執行者卻沒有承諾他可以完成。在這種情況下，倘若不能如期完成工作，責任究竟是專案經理還是執行者呢？我想，恐怕不能片面的歸疚於執行者。雖然從傳統的管理觀點來看，管理者交代工作規定期限，執行者赴湯蹈火也應該要在這期限內完成，倘若工作不能如期完成，那自然是執行者的問題。可是，軟體專案的工作有其獨特之處，程式設計工作的時程許多時候充滿了不確定性，即使是執行者本身所預計的時程，都有可能發生不少誤差，何況或許不那麼了解工作本質的專案經理呢？因此，最好的方式，便是時程的訂定者（專案經理）和執行者一同討論，一方面讓執行者更清楚的明白工作的內容，另一方面則是同時了解執行者所預估的時間，判斷是否有必要調整對專案時程的安排。

在「過度樂觀」或「過度侵略性」的時程規劃之外，還有一種「過度保守」的時程規劃。為了面對充滿不確定性的開發，時程的訂定者，可能為每一項工作以及專案本身都加上了「緩衝時間」，也就是說，倘若一項工作預估需要十天，但緩衝的時間是百分之二十的話，就會將這個工作所需的時間拉長到十二天。加上了提供保護作用的緩衝時間，那麼看起來專案應該更有機會如期完成了吧？很可惜的，我看過的很多實例，緩衝時間都沒有如預期的發揮其作用。原因便在於所謂「自我實現的預言」的現象。你可以仔細回想你的經驗，專案中的工作是不是很少會提前完成呢？倘若時程比較寬裕，執行者會用比較鬆馳的心態來看待時程，即使是準時完成了工作項目，但最終還是耗光了時間。這麼一來，緩衝時間不僅不能保護每個工作項目，甚至還浪費了生產能力。

針對專案管理中緩衝時間的設置，「制約理論（Theory of Constraints，TOC）」主張不個別為每個工作項目局部地設置緩衝時間，而是將可用的緩衝時間全部留給專案本身。個別的工作項目可以將時程擬定的稍緊，甚至機率上允許發生延遲，但由於專案本身設有緩衝時間，可以為專案中發生延遲的工作項目提供保護作用。

Posted at 11:35下午 十月 05, 2009 by Chien-Hsing Wang in General  |  迴響[0]