close
| 程式設計工作的時程充滿不確定性，除了科學化的評估方法和技巧，過去的開發經驗也要考慮在內。 |
| 大多數的專案時程規畫表，之所以不切實際，主要是源自於兩種原因。第一種是「過度樂觀」的想法，低估了軟體開發的複雜度及高風險。第二種則是「過度侵略性」的態度，在這種態度之下，時程的訂定者，多半認為訂一個高難度的時程目標，最後結果「雖不中亦不遠矣」，因此仍然可以壓縮時程，甚至提前完成。 不過過度樂觀、忽略眾多可能變因的想法，通常就是讓現實證明，專案終究不會那麼樂觀地結束。而「過度侵略性」的時程訂定態度，形同於壓榨開發者的生產，暗示著長期加班的可能性，但這運用於短期衝刺或許可用，想要長期壓榨開發者，除非提供極好的待遇，否則很少開發者有辦法忍受，畢竟沒有人的身心是鐵打的。 在這樣的情況之下，開發者對於工作，很容易變得心灰意懶。研究也指出，長期加班，即使整體的工時提升，但由於專注力下降，程式碼品質也容易驟降，導致整體生產力反而更低。 科學化的計算之餘，仍需參考過去的經驗值 那麼，開發的時程又應如何預估呢？我們很容易可以找到許多評估的方法和技巧，例如有名的功能點（Function Point），便是透過將欲開發的系統拆解成若干個功能，再以各個功能所需的資料輸入個數、資料查詢個數、資料輸出個數、檔案個數、外部介面個數做為參數，帶入一個計算的公式裡，最終可以得到系統規模的評估值。 理想的情況下，我們可以透過換算，知道需要多少工時，也就可以做為預估時程之用。 這類量化的方法看似迷人，因為開發時程的預估，始終是管理上讓人頭痛的一件事情。人們通常對數字有一種近乎迷信的心理因素，時常認為計算得出來的，總比隨口喊的來得可信。事實上，量化的方法的確有可用之處，但倘若要提升預估的準確程度，還是得倚賴開發歷史資料的收集。 在CMMI Level 2裡有個流程領域，叫做「度量與分析（Measurement and Analysis，MA）」便包含了要針對開發過程收集相關的度量值，並且進行分析、記錄以及溝通。 為什麼需要收集歷史的資料？因為每個團隊所開發的系統類型不同（例如，商用的ERP系統和線上遊戲就有很大的不同）、開發團隊的成員組成方式及素質也不同（事實上，每個程式人的能力都不同），而量化的估算方法裡，通常都有許多要帶入的參數，而這些項目都必須從開發的歷史中取得。 事實上我甚至認為，歷史的記錄比估算的式子本身更重要，因為它基本上是保留了過去的經驗值。平常我們所謂「空口估時程」，其實也是依據我們隱性的過去經驗來「開出價碼」的。當然，明確地記錄開發歷史，更有助於日後新的開發專案，作為預估時程的參考及類比之用。 將技術不確定性高的專案獨立出來，降低變數 此外，即使有了過去的經驗值做為參數，想要更準確的預估時程，仍必須降低各種風險。專案中的風險有很多類型，其中技術風險時常會被低估。 開發專案中之所以會有技術風險，有一部分原因，是因為有些充滿不確定性的開發項目，它們是很難從過去的經驗知道究竟會需要多少時間完成。 例如，在專案裡，需要一個影像處理的引擎，而對於這個引擎的效能和效果，專案都有規定必須達成的目標。因此，這個引擎有一些演算法上必須克服的困難，你或許得持續嘗試、研究，才能符合需求。但究竟需要多少時間嘗試及研究，沒人說得準。或許可以在時程裡估計一個時間，但實際上需要多少，都只有做了才知道。 倘若這種高度不確定的工作項目，成了開發時程裡的重要工作時（例如深深影響到主時程的情況），那麼其實對於專案最終完成時間的估計，也是同時有著高度不確定性。 對於負責這種工作的程式人，事實上不能在時程上過於苛責。因為專案管理者所預估的時程，時常是沒有根據的估算（或許是從期限倒推回來），既然如此，又怎麼能怪罪別人沒有實現一個沒估準的期限呢？ 管理者與執行者共同討論時程，避免爭議 倘若專案工作的技術上不確定性低，那麼就很容易從歷史上的經驗預估，結果出乎意料之外的機會也相對較低。因此，專案管理者應當盡量避免把不確定性高的工作，擺入一個期限要求嚴格的專案中。針對這類型的工作項目，最好成立一個獨立的專案，因為帶有實驗性質，所以不用設定過度嚴格的完成期限。 也就是說，會被擺入專案中的工作，盡量都是驗證過技術可行性的工作，那麼不確定性就可以降低，對於時程的估計，也就可以更準確些。 除了怎麼估計之外，另外究竟是由誰來預估專案中的每一項工作需要的時間，同樣也是一個議題。 最好的情況，應該是由專案經理和每項工作的執行者一同討論，進而決定下來。許多專案工作的時程安排，都缺少了執行者的承諾。這會造成一個問題，就是由專案經理單方面地認定，這個工作應當在某個時間點完成，然而執行者卻沒有承諾可以如期完成。 在這種情況下，倘若不能如期完成工作，責任究竟是專案經理還是執行者呢？我想，恐怕不能片面地歸究於執行者。雖然從傳統的管理觀點來看，管理者交代工作時程，執行者赴湯蹈火也應該要在期限內完成，倘若工作不能如期完成，那自然是執行者的問題。 可是，軟體專案的工作有其獨特之處，程式設計工作的時程，很多時候是充滿了不確定性，即使是執行者本身所預計的時程，都有可能發生很多誤差，更何況是不那麼了解工作本質的專案經理呢？ 因此，最好的方式，便是時程的訂定者和執行者一同討論，一方面讓執行者更清楚地明白工作的內容，另一方面則是同時了解執行者所預估的時間，判斷是否有必要調整專案時程的安排。 針對整個專案擬定緩衝時間，兼顧生產力與保護作用 在「過度樂觀」或「過度侵略性」的時程規畫之外，還有一種「過度保守」的時程規畫。為了面對充滿不確定性的開發，時程的訂定者，可能為每一項工作以及專案本身都加上了「緩衝時間」，也就是說，倘若一項工作預估需要10天，但緩衝的時間是百分之二十的話，就會將這個工作所需的時間拉長到12天。 加上了提供保護作用的緩衝時間，那麼看起來專案應該更有機會如期完成了吧？很可惜的，我看過很多實例，緩衝時間都沒有如預期的發揮作用。原因便在於所謂「自我實現的預言」現象。 你可以仔細回想自身的經驗，專案是不是很少會提前完成呢？倘若時程比較寬裕，執行者會用比較鬆馳的心態看待時程，即使是準時完成了工作項目，但最終還是耗光了時間。這麼一來，緩衝時間不僅沒有保護工作項目，甚至浪費了生產能力。 針對專案管理中緩衝時間的設置，「制約理論（Theory of Constraints，TOC）」主張，不為每個工作項目局部地設置緩衝時間，而是將可用的緩衝時間全部留給專案本身。個別的工作項目可以將時程擬定得稍緊，甚至機率上允許發生延遲，但由於專案本身設有緩衝時間，可以用它來為專案中發生延遲的工作項目，提供保護作用。 |
全站熱搜
留言列表
