在讀完無痛功能規格 – Part 4：提示之後，ㄚ琪要繼續讀無痛軟體時程，但是ㄚ琪先跑到約耳的網站去看時，發現他有一個重要的更新告知：「This article is obsolete.
Over the years, I’ve learned a lot more about schedules and estimates. A newer, far better method for producing accurate software schedules painlessly is Evidence-Based Scheduling. Read that instead.
This article remains here for archival purposes, but please don’t read it!」
他說這篇文章已經過時，並且教我們不要去讀，可是我中文版的已經讀完了啦！而且也是對ㄚ琪的工作很有影響，但是我也想看看，新的這篇Evidence-Based Scheduling會有時饃更新，所以我會兩篇合起看，並檢討一下自己的工作！
「睪丸素過剩的自大狂遊戲公司」有夠誇張吧，看是約耳要騙我們來看的！
記取蓮花的Lotus 123 3.0版、讓Jamie Zawinski有世界聞名之怒的Netscape的5.0版web瀏覽器及曾稱霸一時的資料庫軟體dBase的安信達(Ashton-Tate)的教訓，這三個古老的軟體ㄚ琪也都有碰過，不過都玩得沒有很多，想來也是設計不良吧，或跟台灣水土不服，還好沒有繼續用是對的，不然一定會哭說，怎麼會倒？
既然軟體界的魏徵約耳說，「所以說你一定得定時程。」身為唐太宗的你一定為聽這個勸的。
「那麼為什麼沒人要訂時程呢？主要原因有二。首先是執行起來很痛苦。其次是沒人認為值得做。」執行很痛苦，這個ㄚ琪深有體驗，特別是針對自己沒寫過的程式，真像是如履薄冰啊！一不小心就會身敗名裂，至於值不值得做就ㄚ琪來看是非常有必要的！
約耳就提供了一個簡單無痛的方法，可以訂出確實無誤的時程。
1)使用微軟Excel。不要用要花大量時間處理相關連性(dependency)的微軟Project，那是設計給建築辦公大樓用的，喔！原來如此，難怪我非常地討厭微軟這個東西，而且在ㄚ琪前任公司時代，資訊經理竟要導微軟Project 2007進入公司，哇！難怪就這樣倒了，當然這不是主因，但事出必有因。我覺得聰明的還是ㄚ琪前任處長的睿智，他想用專案管理，就叫ㄚ琪開發了一個比Excel好用，但又比微軟Project簡單的Web介面的專案管理，這一套程式弄到現在的公司一樣的得心應手地用。另外所謂相關連性是指有兩件工作，第一件工作必須在第二件工作開始前完成。
2)簡單就好。
（引用自無痛軟體時程)
只要七個欄位：Feature、Task、Priority、Orig Est、Curr Est、Elapsed、Remain，當然我想每個人可以視需要改變這個表格！
3)每個功能應該包含多項工作。
4)只有實際要寫該程式的程式員才能排出該項的時程。那是一定的，如果找不會寫程式的老闆定時程，等著鐵達尼號沉吧！
5)把工作分得很細。「當你必須訂出細項工作時，就得強迫自己實際地找出確實要進行的步驟。細分工作還有另一個理由，就是能逼你設計那些要命的功能。」這個ㄚ琪有很多話可以說的，我看過很多菜鳥對專案管理不懂，所以在用我的專案管理程式時，會變成只有一個工作項目，這意味著你不瞭解專案不懂細節，因此我很有理由地就可以知道你真是菜！另外不像一些小白臉似的業務個性能說會道，可以講得天花亂墜，相信我，我還是有能力去分辨業務的真假的！有些黝黑的大老粗，說是技術職嘛，也不像，只要我去看看，就可以看出是空心的還是實心的了，在福音的學習上也是如此，有些人常自栩福音生活化，但是當他上台分享的時候，他無法說出詳細的見證時，這就可以讓我們知道，這是空心的了，如果你真是福音生活化，你必定會有實務經驗，這個我們稱之為靈性的見證，你有去想有去做，才是福音生活化，也因為你有這樣的技術，你在分享見證時才不會空洞！
6)記錄最初和目前的估計。 「當你把某件工作第一次排進時程時，先估計所需時數並填入Orig[inal] Est[imate]以及Curr[ent] Est[imate]欄位中。」這是經驗的累積，別無他法，ㄚ琪也是這樣過來的！如何作到精準，做財務預算也是一樣的道理！
7)每天更新耗時(elapsed)欄。
8)加上國定假日，休假等等項目。記得將安息日算上，免得離棄了神，這樣程式會越寫越好！
9)把除錯時間排入時程！
10)把整合時間排入時程中。
11)在時程中加上緩衝時間。「考慮兩種重要的緩衝。第一種：預防工作耗時超過預期的緩衝。第二種：針對未預期但必要的工作的緩衝(這通常是因為管理階層決定某功能超級重要，絕對不能等到下一版)。」
12)絕對不要讓經理叫程式員縮減估計時間。『很多菜鳥軟體經理認為能用精細「緊密(短得不切實際)」的時程，「激勵」程式人員做得更快。我認為這種激勵根本是頭殼壞掉。』『不過你絕對絕對不可能由n變成3n，如果你自認有這種本事，請寫信告知貴公司的股票代碼好讓我放空。』其實我很想這麼做，不過繼然會讓公司倒，還是不幹得好！
13)時程就像積木。「如果你有一堆積木，積木太多塞不進箱子裡。這時候你只有兩個選擇：找個大點的箱子或拿掉一些積木。」這個比喻懂吧，我就不多說了！
另外你如果要用Excel做專案管理的話，你需要懂一些功能：
共用活頁簿
自動篩選
樞鈕分析表
WORKDAY函數
如果你還有問題，就看約耳的Q&A吧：Juggling Tasks in Excel
說到Evidence-Based Scheduling, or EBS（循證式軟體時程），當然前面騙人的屁話，如果你沒有看無痛軟體時程，你當然要看，如果看過了，就可以跳過！
你收集證據，當然主要是從歷史的時間表資料中來，然後回饋到你的時程中，你會因此會畫出像下圖類似的分佈曲線圖，曲線越陡，就越有證據顯示出貨的日期越真確！
（引用自Evidence-Based Scheduling）
以下是幾個要做的事：
1) Break ‘er down
把工作細分，工作時間不要超過16小時！內容有點跟前述的相似！
2) Track elapsed time
追蹤過去的時間，收集資料，做個統計圖表，像下圖：
因此你可以看看你的斜率是多少，斜率1表示精準，過與不及都不好，所以這個我想是要由經驗來累積的！
3) Simulate the future
這一節介紹Monte Carlo method（蒙地卡羅方法，也稱統計模擬方法，是二十世紀四十年代中期由於科學技術的發展和電子計算機的發明，而被提出的一種以機率統計理論為指導的一類非常重要的數值計算方法。），看起來這需要會點數學，更精準的說要會統計學，我不知道是不是很多人會，我自己有瞄過這個方法，但是我沒有用過跟做過這類的統計題目，所以可能有點難吧！但是本中大概是假設100種可能性，每一種就有1%的機率，你可以用前面的表，然後配上下表：
| Estimate: | 4 | 8 | 2 | 8 | 16 | |
| Random Velocity: | 0.6 | 0.5 | 0.6 | 0.6 | 0.5 | Total: |
| E/V: | 6.7 | 16 | 3.3 | 13.3 | 32 | 71.3 |
你可以依據這個表大概估出這個軟體出貨的時期！
這個計算可能是很累人的，所以相信電腦的使用是很需要的！
強迫症的毛病不需要，這裡在推薦EBS是多棒的方法，嗯！看起來是！
4) Manage your projects actively
這個工作的輕重緩急看來細分的很多，比我自己在用的還多！
從甘特圖裡找出哪些人的工作有問題一目了然！
Scope creep
這裡提到的就是ㄚ琪擔心的事，如果有些專案是新的點子，你沒碰過該怎麼辦？
- New feature ideas
- Responding to the competition
- Integration (getting everyone’s code to work together when it’s merged)
- Debugging time
- Usability testing (and incorporating the results of those tests into the product).
- Beta tests
你還是可以做出類似上圖來做規劃。
這裡有一些約耳學習關於時程表的經驗：
1) Only the programmer doing the work can create the estimate.只有程式設計師可以作估計的工作
2) Fix bugs as you find them, and charge the time back to the original task.當你發現錯誤時修正這些錯誤，把這些時間計到原來的工作上
3) Don’t let managers badger developers into shorter estimates.不要讓經理糾纏開發人員更短的估計時間，這跟前述類似，但是我發現3n的時間已經變成4n了，哇！
4) A schedule is a box of wood blocks.時程表是一個積木
感覺新舊文沒有差異很大，但是要更精準的估計時程，用新文的EBS會較妥，用一些簡單的數學工具來計算，算是很大的進步，但是如果你覺得數學差，那用前文的介紹，我是覺得沒什麼不好，那ㄚ琪算是個科技人嘛！是應該好好用新文去做的時候了！