真的有「無痛軟體時程」這玩意兒嗎？
今天收到客戶正式確認的CR清單，包含了各階段期望的交付項目和交付日，接著就是我要開始做人力資源的分派，把原訂的時程重新整修。這一搞，竟然弄了四個多小時…
在過程中，忽然想到約耳趣談軟體中，有一篇「無痛軟體時程」，正好也當做感謝點部落贈書的自我修第一篇文章吧！
對了，其實我不認為有「無痛軟體時程」，因為實際上，就算依下述的方法執行，遇上了客戶喜歡玩急件中的急件，插件中的插件時，都一樣很痛啊！不過至少依下述的方式，的的確確可以讓我們在管理時程時，輕鬆許多，所以，可能要叫「有點痛軟體時程」比較好 XD
約耳是在2000/3/29寫的文章，當中列了十三個簡單無痛的方法，目的在訂出確實無誤的時程，我先列一下，再來說一下我的看法：
- 使用微軟Excel。
- 簡單就好。(欄位不用多，夠用就好)
- 每個功能應該包含多項任務。
- 只有實際要寫該程式的程式設計人員，才能排出該項目的時程。
- 要把任務分得很細。
- 記錄最初和目前的估計。
- 每天更新耗時欄。
- 加上國定假日、休假等項目。
- 把除錯時間排入時程。
- 把整合時間排入時程中。
- 在時程中上緩衝時間。
- 絕對不讓經理叫程式設計人員縮減估計時間。
- 時程就像積木。(積木太多時，只能找個大一點的箱子或拿掉一些積木)
大部分我都覺得很正確，除了上面我標綠色的項目，就是我不認同想法。
認同的想法大家很容易了解，我想講講不認同的部分。
「使用微軟Excel」：約耳認為，排時程不需要用到Project這種軟體，認為這是設計給建築業用的，原因有二：
- 要花費大量時間處理關連性，但是就軟體而言，相關連性很明顯，不用花工夫正式追蹤。
- 資源撫平，在軟體開發上完全行不通，因為程式設計人員是不能互換的。
我完全無法認同不處理關連性的部分。事實上，現今軟體功能強大，客戶要求的系統功能也多半有彼此關連性，而且開發人員也不是只有一、兩個，若不在安排時程階段，就把工作的關連性設定好，很容易發生重工或非自願性怠工的狀態。以我今天的例子來說，新增的CR項目涵括了三個專案，有維運需求也有新功能建置需求，而且項目高達二、三十個，我的人力資源有五位，每個人可投入的日期和可用期間都不同，如果用Excel，光是重新安排時程，我就想自殺了，而且客戶對於這些CR，也有要求交付的先後順序，透過關連性的設定，可能讓我很快的將新增需求插到原有的項目之間，而且Project會自動幫我調整後續關連項目之起始和預計完成日，加上視覺化的甘特圖關連，不會讓我把PG的時程給弄亂掉。
資源撫平我倒是覺得，真的不適合啊，或者我不會用。但是程式設計人員不能互換，我認為是專案團隊管理的一大風險。我在帶Team時，一定會讓同一個模組，至少有兩個人可以同時維護，這樣可有效避免人員異動（請假、外派、離職等等）時，臨時要找人接手卻無人可用的囧境。有人可能會疑惑，如何讓兩個人可以同時維護呢？其實很簡單啊，極限開發模式、建置新功能時分層開發但維運時不同層的人互換，這樣很快就會熟悉，不會浪費時間。
「要把任務分得很細」，約耳認為，分配好的任務應該是以「小時」計，而不是以「天」計。這點我覺得，有點天方夜譚了！我絕對認同要把任務分細一點，但就如同PMP課程中所說的，工作包，乃至於更底層的活動/任務，應該是能確實估計、配置資源即可。若要切到小時，所需要花費的規劃、分析時間，可能最後會比實際執行每個「超級細項」任務所需的時間還要多！
「每天更新耗時欄」，耗時欄也就是完成度。是的，開始執行某項任務以及結束任務時，應該要確實去更新耗時欄，這是有意義的行為，因為我們需要知道任務開始執行了沒，結束了沒！但是在開發一個功能的過程中，PG每天去填寫兩成、三成、五成，對於管理來說，有什麼用？再者，耗時欄評估基準為何？在軟體開發中，我們沒辦法預期建置一個功能會需要多少行程式碼，也沒辦法明確地定義目前完成的部分，佔了此任務的幾成，只能概估。那何必每天都去更新耗時欄呢？我認為，軟體開發，看的應該是每項任務開始做了沒，完成了沒，而不是完成多少了(註1)。
註1：如果我們的任務分的夠細（意思可明確估計，而非約耳說的小時計），那麼應該不會發生一個任務長達兩週以上的情況（我個人認為，任務最大長度應該要控制在5天內），那看完成多了少，其實是沒有意思的！
除了上述三點之外，其實我覺得這篇文章的可讀性很高，特別是第九項：把除錯時間排入時程中。很多開發人員，常常會低估任務的複雜度（或高估自己的能力？），結果時間到，的確如期交出程式碼，但是裡面卻充滿了地雷，導致除錯的時間過長，而延誤整體時程。
還有第十三點，很有哲理啊！
以上，一些心得分享囉~~
--------
沒什麼特別的~
不過是一些筆記而已