程式者的胡言亂語
星期一 十月 05, 2009
開發時程的預估（2）
在上一回中我們探討了預估時程的量化方法，想要透過量化的估算方法來預估軟體的開發時程，那麼收集團隊開發的相關歷史資料就成了一個很重要的工作。依據過去的經驗累積，是我們得以估算新的開發工作究竟需要多少時間及資源來完成的重要參考。我們也提到了，技術上的風險是時程估算的不確定因素，應該要盡量的降低每個開發專案裡的技術風險。此外，我們也建議每個工作的估計時程，應由專案經理和每一項工作的執行者一同討論進而決定下來，並且藉此取得執行者對工作時程的承諾。而緩衝時間的設置，也是專案經理時常用來保護時程的一個技巧，但由於自我實現的預言所故，最好不要為個別的工作設置緩衝時間，而是將緩衝時間留給整個專案本身。
在軟體開發時程的規劃上，許多團隊時常會低估測試以及修正所需的時間。這也是導致產品延遲交付的常見原因之一。這或許是因為當完成了程式碼撰寫的工作後，系統看起來也像是能夠運作了，所以人們也就認為它距離可以交付的水平不遠了吧。許多專案經理甚至會在自己的時程表中，很樂觀的估計一個很短的測試時間。事實上，許多開發專案需要的測試時間，往往不是這麼樂觀。
測試時間是軟體開發時程中很難估計的一環，許多人看待測試時間的態度，就是設下一個期限，然後預期能在期限內測試完成。倘若你能夠列出或者估計出測試案例的約略數量，那麼你或許能夠估計執行這些測試案例所需的時間。但是，在規劃進行測試的時間內，不單要執行測試，更重要的是，程式員必須針對找出的臭蟲修正錯誤。軟體的臭蟲可以依據嚴重程度來分類，有一類的臭蟲相當嚴重，因為它們的存在，擋住了你，使得你無法繼續執行之後眾多的測試案例。像發生這樣子的情況時，測試員就必須等待程式員修正錯誤之後，才有機會繼續往下測試。也就是說，在程式員修正錯誤前，測試員便有可能陷入了空轉的狀態。而程式員修正一個錯誤需要多少時間，也是不易估計的一件事。有時候解決一個臭蟲很快，有時候，即使修正一個臭蟲的方法只需要修改一行程式碼，但卻可能耗去你數天甚至數週的時間在除錯。如果這類型的臭蟲一多，那麼連能不能在期限內執行完所有的測試案例都成了問題。
此外，測試時間內要做的工作，不單只是執行測試案例而已，更重要的是驅逐臭蟲、修正錯誤需要的時間。正如前一段中所提到的，修正錯誤的時間難以估計，究竟需要多少時間來修正錯誤，其實是很難說的。接著，在修正完錯誤後，還得重新測試。除了針對原先有問題的測試案例進行驗證，確定臭蟲的確被修正之外，還得對相關的測試案例重新測試一輪，即使它們原先是正常的。這是因為，許多對臭蟲的修正動作，往往衍生了副作用，反而引來更多的臭蟲，使得原先運作正常的功能反而出錯了。整個測試的時間，便在這來來返返的錯誤與驗證過程中耗去。
測試階段的結束與否，並不是以時程表上的期限做為判斷標準，而是以軟體品質是否已達可以接受為標準。但軟體品質何時才能達到可以接受的水平呢？相較於程式碼的撰寫而言，這又更難估計了。
另一方面，倘若開發時程過於緊湊，對程式員的壓力施加過大，程式員有可能試著先完成看起來功能完整，但內部卻暗藏許多地雷的系統，以求完成程式撰寫階段，先闖關進到測試階段卸下大部份的壓力再說。這或許是源自於一種「頭過身就過」的心態，但是，「出來跑的遲早要還」。這些問題，或許暫時被隱藏著，但是在測試階段「醜媳婦總是得見公婆」。更重要的是，這些暗藏的地雷，會使得測試階段不僅拉的更長，而且更不易預估究竟會需要多少時間，因為你不知道程式員究竟埋了多少地雷在系統裡面。而這些，都是造成低估所需測試時間的可能原因。
除了測試時間會被低估之外，整個開發過程中都有可能發生需求變更，而容忍需求變更的部份，也沒有被考量進來。同樣的，需求變更可能會對時程造成的衝擊可小可大，小則訊息、圖片的修改，大者可能影響到整體架構。不同的開發方法，允許改變需求的方式也不同，估量這部份時間的方式，也會跟著改變。但無論如何，當你在考慮時程時，不應該忽略需求變更肯定會發生，而且肯定會佔去開發時程。
另外，許多專案中都會有所謂的「共用資源」。像在軟體開發專案裡格外明顯。怎麼說呢？尤其在同一家公司裡，程式設計功力較高的幾個程式員，時常會被同時分派在多個開發專案裡，一人身兼多職，這種現象很普遍，但卻是對時程規劃的一大傷害。因為同時參與多個專案的程式員，很容易成為專案的瓶頸所在。一方面是專案經理時常會高估多工下的程式員的生產力，但事實上，倘若一名程式員平均工作在兩個專案裡，那麼可以為這兩個專案分別貢獻的生產力，通常不到全職生產力的一半。那麼，同時參與兩個以上的專案，就更不用說了。此外，當多個專案中的某個專案發生了意外，「咬住」了這名程式員，原先預計在另一個專案中登場的時間點就會延遲，那麼倘若這個工作又是落在該專案的要徑（critical path）上，整個專案便會一同發生延遲。身兼愈多專案的程式員，愈有可能成為各專案中愈不穩定的因素。
那麼，當無法趕上預計的開發時程時又該如何？或許許多團隊會選擇加班，但正如前文中所提的，加班適用於偶而為之的短期衝刺，但對於較長時間的時程延遲並不適合。另外，有些團隊可能也會考慮為專案加入更多的資源
－ 也就是加入更多的人力。不過，想要透過加入人力來解決時程問題，也不是全然的沒有負面效應。由於新加入的人力可能對這個已經開發到一半的專案不那麼熟悉，生力軍需要花一段時間才能上手，通常都不是即戰力。因此，在考量加入額外的人手時，也必須考慮到這批生力軍上手的時間。
因此，專案即將發生延遲，必須愈早偵測出來愈好。大多數人對專案時程的延遲，多半還是存在「拼拼看」的態度，於是，即使是發生了將要延遲的訊號了，仍然還是憑著一股拼勁，想要在最後一刻趕上。這固然是一種積極的心態，但也有可能造成到了期限的那一天，所有的人才發現原來時程趕不及了，而無法在其他方面進行配套的措施。事實上，專案中的每個人，在意識到自己的工作可能會有延遲時，都應該提出來討論，起碼做為一個示警的訊號，讓其他人－尤其是專案經理有更多的資訊來調整計畫，專案經理不應該是到了期限那一天才知道該工作會延遲完成。愈早查覺出工作可能會發生延遲，加入新人力的效果才會愈好，因為這麼一來便能夠保留愈多的上手時間。
除了上手時間之外，人力愈多，也會提高管理的複雜度，這是專案經理必須試著克服的另一點。
Posted at 11:35下午 十月 05, 2009 by Chien-Hsing Wang in General | 迴響[1]
「生力軍需要花一段時間才能上手，通常都不是即戰力。」這句話最近感觸很多啊~ 指導別人寫程式比自己寫程式真的要花費更多的時間和心力 .. 囧
由...發表 Genix on 十月 17, 2009 at 07:43 上午 CST #