搞笑談軟工: 這不是整人遊戲之 time log 紀錄方式

6/14 22:35~22:57
6/14 23:07~ 6/15 00:20

Teddy 在 2005 年春天修了一門 PSP -- Personal Software Process 的研究所課程（個人軟體程序，聽起來就是無聊到爆的一門課。如果是 Sony 的 PSP 那該多好），沒記錯的話 PSP 這玩意兒（請捲舌）是 Watts S. Humphery 教授加博士所發明的，目的就是要利用『工程』的方法，來提昇軟體開發的品質。基本精神就是，『任何東西只要無法測量，就無法改善』。因此，為了要改善軟體開發的品質，出發點就要從『單兵作戰守則』開始，要求單兵（programmers）卯起來紀錄（測量）在開發過程中一些你從來也沒有想到需要去紀錄的資料，包含：

Time log: 詳細紀錄不同開發階段，例如 Plan，High-Level Design, High-Level Design Review, Design，Design Review, Compile, Code，Test, Project Manage 各花費多少『分鐘』。
Size: BASE PROGRAM LOC (基本的程式行數，就是說開發一個新的功能之前程式有幾行), LOC DELETED (此次開發刪除了幾行), LOC MODIFIED (此次開發修改了幾行)。
Defect: 紀錄 defect 的 date (哪一天被發現的), number (第幾個 defect), type (哪一種類型的，邏輯錯誤，打字錯誤，資料結構錯誤等等), inject (在哪一個階段所產生的，例如計畫階段，設計階段，寫程式階段等等), remove (在哪一個階段被修正，例如 Design Review 階段或是測試階段), fix time (花了多少時間來修正)。

剛剛去『批衣服』現在繼續。

除了這些以外，還要寫一堆資料，一個學期搞下來，雖然只寫了 10 支（1A~10A）總行數加起來可能不到 2000 行的小程式，整個人卻是累到走路必須要靠北邊走，有一種被掏空的感覺。今天要談的主題是 time log，因此看一下 Teddy 當初修課作業所紀錄的 time log 範例：

修完課之後，只有一個感想：『這是整人遊戲嗎？』Teddy 這一輩子應該不可能去寫戰鬥機，核電廠，或是太空梭所使用的程式，真實世界中的普羅大眾誰跟你紀錄這些。鄉民們信不信把這一套拿給你們老闆瞧一瞧，如果沒有被痛貶一頓的話，請注意你一下老闆的精神狀態是否正常。

但是，Humphery 教授加博士也不是省油的燈，PSP 或是進階版的 TSP (Team Software Process) 或是宇宙無敵世界無雙的 CMMI (Teddy 知道，CMMI 不是 process...不要太挑剔) 裡面提到的許多『觀念』（再次強調，觀念）出發點都十分正確，但是『落實』的方法卻『沒人性』。經過這麼多年，Teddy 已經了解到，反是『違反人性』的制度或是作法，最終大多以失敗收場（上有政策，下有對策。生命會自己找到出路滴）。紀錄 Time log 的想法，就像是減肥的人每天紀錄吃掉多少『卡路里』，或是想存錢的人每天紀錄『花了多少錢』是一樣的。立意良好，做到的沒幾個。但是一旦能夠作到，的確有其效果。因此，後來 Teddy 就自創（ㄟ，任何人都可以想到啦）一套簡化的紀錄 time log 格式，在唸書的這幾年當中，持續紀錄。請參考 Teddy 某幾天的 time log：

2006/11/21
1.    研究 Eclipse editor
    * 研究 syntax highlighting
    (09:30~12:10, 160 mins)
2.    研究 Eclipse editor
    * 研究 syntax highlighting
    (12:40~15:10, 150 mins)
3.    MAUT meeting
    (15:10~15:40, 30 mins)
4.    回答鄭老師中央演講投影片的一些問題
    (15:40~16:20, 40 mins)
5.    MAUT meeting
    (16:20~16:40, 20 mins)
6.    研究 Eclipse editor
    * 研究 syntax highlighting (完成雛型)
    (16:40~18:00, 80 mins)

2006/11/22
1.    研究 Eclipse editor
    * 研究 outline view
    (10:30~13:20, 170 mins)
2.    研究 Eclipse editor
    * 研究 outline view (完成雛型)
    (13:50~17:50, 240 mins)

2006/11/23
1.    研究 Eclipse editor
    * 將 nodes 改成支援 visitor pattern (未完)
    (10:30~13:10, 160 mins)
2.    和謝老師去吃飯
    (13:30~16:40, 190 mins)
3.    研究 Eclipse editor
    * 將 nodes 改成支援 visitor pattern (大致OK)
    (16:50~19:10, 140 mins)

2006/11/27
1.    Study Group
    (13:10~13:30, 20 mins)
2.    研究 Eclipse editor
    * 測試 visitor
    * 完成在 outline 顯示每天總時數的功能 (尚未處裡四捨五入的問題)
    (13:40~15:30, 110 mins)
3.    研究 Eclipse editor
    * 修改產生 DLTree 的方法
    * 產生檢查 delta 的 marker (大致 ok)
    (15:30~19:50, 260 mins)

2006/11/28
1.    寫 Internet Computing review 結果
    (09:50~11:20, 90 mins)
2.    研究 Eclipse editor
    * 產生檢查 delta 的 marker 的 resolution (未完, 無法顯示)
    * 修改當讀取空白文件時, 文件 parser 程式無法結束 (無限迴圈) 的問題
    (12:20~14:10, 110 mins)
3.    和鄭老師討論 Internet Computing review
    (14:20~14:50, 30 mins)
4.    MAUT meeting
    (15:10~16:10, 60 mins)
5.    研究 Eclipse editor
    * 修改 (12:20~14:10, 20 mins) 若是在 end time 之後少一個 , (逗號) 程式的 bug
    (17:00~17:20, 20 mins)
6.    研究 Eclipse editor
    * 撰寫檢查日期是否重複的 visitor
    (17:20~17:40, 20 mins)
7.    Reading, Professional Java Interfaces with SWT/JFACE
    * chapter 8: Text Controls
    (17:40~18:10, 30 mins)
8.    Reading, Professional Java Interfaces with SWT/JFACE
    * chapter 20: Creating a Text Editor with JFace (未完)
    (18:10~18:40, 30 mins)
9.    研究 Eclipse editor
    * marker resolution (可在 problem view 按右鍵選 quick fix 來啟動)
    (23:00~24:00, 60 mins)

就這樣，格式很簡單，基本上實際紀錄都最小是以 5 分鐘（為了偷懶，Teddy 實際上通常最小是 10 分鐘為一個單位）來紀錄，只紀錄『有意義』的事情。太瑣碎與沒有意義的時間片段就忽略，例如，尿尿花了三分鐘，泡咖啡花了七分鐘這種就可以不用紀錄。

用紀錄流水帳的方式來紀錄 time log 的好處是『為了紀錄所額外花費的成本很低』。記得物理領域有一個叫做『測不準原理』的嗎，為了測量，觀測者其實已經改變了被觀測對象的行為。所以，越是輕量級的紀錄方式，看起來好像『不太精確』，但是卻是實際可行又具備參考意義的方法。

***

看到這邊，還沒閃人的鄉民們，可能會以為只有 Teddy 吃飽沒事幹才寫 time log。錯，Teddy 所屬的『X北科技大學資工系軟體系統實驗室』的所有博，碩士生，都在寫 time log，而且連續實施這個作法至少應該超過 6 年以上（Teddy 畢業之後不知道他們還有沒有繼續寫下去）。有什麼好處？主要的好處是協助時間的分配。例如，參考學長，學姊的 time log，可以知道修一門課，像是 OOP，平均需要花多少個小時。當有新生修課投入時間太少，老師馬上就可以看出來並提醒他要投入足夠的時間。如果投入時間太多也是問題，可能是其他課投入時間太少，或是遇到問題無法解決。這麼多年 run 下來，真的幫助了不少學生。

對於做研究也有幫助。例如，經過統計，出一篇好的 journal paper 從頭到尾大概需要 500 小時，寫一本碩士論文可能需要 200~250 小時。如果有研究生要求畢業，指導教授只要稍微看一下研究生投入的時間和產出物，就有一個比較客觀的基礎可以來決定能不能讓他畢業，研究生也不會不服氣覺的被教授ㄠ。Teddy 也利用 time log 來預估寫一份 proposal 需要多少時間（大概要 40 ~ 80 小時）。

最後要注意幾點，(1) 紀錄 time log 是『良心事業』，灌水是沒有意義的。(2) 所紀錄的時間是『實際工作時間』，例如 Teddy 紀錄寫一份 proposal 需要 40 小時，這是『實實在在』的 40 的小時，而不是說一個工作天算 8 小時，做了五天因此得出 40 小時。有什麼差別？如果是後者，雖然做了五個工作天，可是實際每天有效工作實數可能只有三小時，其他時間都在打B，聊天，噗浪。因此實際只有 3 * 5 = 15 小時。只要看了 proposal 內容，40 小時和 15 小時所做出來的東西是差很多的，很容易露出馬腳。(3) 每個人的能力與經驗不同，在參考別人的 time log 時必須考慮進去。例如，Teddy 寫一份 proposal 需要 40 小時，如果是找研二的學弟來寫出類似品質的 proposal，時間可能至少需要乘上 2 或 3。（PS：學弟，不要傻傻的直接參考學長的數據）。

***

友藏內心獨白：劉老師，PSP 的訓練還是滿有用的，要繼續開課喔。