網摘: The Joel on Software Translation Project:無痛軟體時程 - The Joel on Software Translation Project

網摘: The Joel on Software Translation Project:無痛軟體時程 - The Joel on Software Translation Project.

9)把除錯時間排入時程！除錯是最難估計的。回想一下你前一個專案。除錯所佔的時間很可能是把程式寫出來的一到兩倍。所以時程中一定要加這一項，而且這有可能是最大的一項。

實際的作法如下。讓我們假設一位開發人員正在做某件工作。Orig Est是16小時，不過到目前為止已經用了20小時，而且恐怕還要再做10小時。所以開發人員在Curr Est和耗時欄分別輸入30及20。

等到達里程碑(milestone)時，這所有的「落後」加總起來可能會有相當數量。理論上為了因應這些延誤，我們必須削減功能才能準時上市。幸運的是可以削減的第一項功能就是名為緩衝(buffer)的功能，而這個項目一開始就排了很多工時。

原則上，開發人員會在寫程式時除錯。程式員在應該除錯時絕對不該寫新程式。基於兩項原因，隨時都應該讓錯誤數目儘可能的少：

1)在寫出程式的同一天除錯會比較容易。如果一個月後當你忘記程式運作細節時再來除錯，就會變得非常困難而且要花很長的時間。

2)修正錯誤就像科學活動。不可能估計何時能有發現並解決問題。如果隨時都只有一兩個主要的問題，表示未來無法估計的項目不多，所以很容易估算產品推出的時間。反過來說，如果主要的問題有幾百幾千個，根本就不可能預測什麼時候才能把問題全部修好。

如果開發人員總會在寫程式時就把問題修好，為什麼還要加上除錯項目呢？有道理，不過即使在寫程式時儘量修好所有的問題，在到達里程牌時，測試人員(內部或外部)總還是會找到真正困難的錯誤，難免要有許多除錯的動作。

10)把整合時間排入時程中。如果你的程式員不只一位，難免會有兩人不一致的事情需要協調。他們會各自建立功能近似的對話框，這當然需要協調。必須有人細查所有功能表、鍵盤快速鍵、工具列工具等等，並且整理及組織所有大家不得不加的新功能表項目。另外只要有兩個人把程式登入就會出現編譯錯誤。這也得有人修正，而且應該列入時程。

11)在時程中加上緩衝時間。事物總是容易用完。你可能要考慮兩種重要的緩衝。第一種：預防工作耗時超過預期的緩衝。第二種：針對未預期但必要的工作的緩衝(這通常是因為管理階層決定某功能超級重要，絕對不能等到下一版)。

你可能會很驚訝地發現、休假、國定假日、除錯、整合還有緩衝時間加起來超過實際做事的時間。如果被嚇到表示你程式寫得還不夠久，不是嗎？你要忽略這些項目的話後果自行負責。

12)絕對不要讓經理叫程式員縮減估計時間。很多菜鳥軟體經理認為能用精細「緊密(短得不切實際)」的時程，「激勵」程式人員做得更快。我認為這種激勵根本是腦袋壞掉。當我進度落後時，我會覺得內疚消沈毫不積極。當我進度超前時，會非常快樂而且充滿生產力。時程可不是玩心理遊戲的地方。