在得到「欠筆記文欠過年」的成就之後，硬是擠出一個下午的時間，終於整理完 Agile Tour Taipei 2015 最後一場議程的筆記，壓軸場當然是非同小可，是由絕無冷場的 91 哥為大家帶來「Scrum Estimation Model」這個題目。
同系列所有文章可以點此連結前往《Agile Tour Taipei 2015 筆記與心得》 因為欠筆記文欠太久，91 哥早已將他分享的內容整理成兩篇文章：
- Scrum Estimation - 如何估算專案時程
- Scrum Estimation - Scrum Estimation Model 既然講者都已經把內容寫成文章了，所以老實說我有沒有寫這篇筆記文好像也沒差，那本文就此結束吧。（揍飛）
筆記文由此開始，在一開場 91 哥就直接先用他自己今天的簡報總頁數當作範例，點出本場主題的三大關鍵重點「範圍」、「 時程」與「速率」。
- 範圍 = 簡報總頁數
- 時程 = 演講可用的時間
- 速率 = 每分鐘要講幾頁（才能不超時將內容講完）
基本上這是簡單的數學計算，由「範圍」除以「時程」可得出「速率」，反之你也可以由「範圍」除以「速率」得出「時程」，又或是由「時程」與「速率」得出「範圍」，總之這三個重點是彼此互相關聯的。
但實際上講者講話的速率有限，不可能提升至預期的速率，因此勢必只能延後結束時間或減少簡報頁數。這個開場白其實直接就比喻了專案執行的情況，因為專案執行時也同樣是在「範圍」、「 時程」與「速率」中不斷地協調。
透過開場白 91 哥很快的在聽眾們的心中埋下了「範圍」、「時程」與「速率」的基本概念，整場分享即是完全圍繞著這三大關鍵。
接著 91 哥繼續用「兩個人決定步行前往探視朋友的一段旅程」比喻說明了在專案執行中常見會導致「專案延誤」的意外狀況。
在這個小故事中一樣有「範圍」、「 時程」與「速率」：
- 範圍 = 交通距離
- 時程 = 與朋友約定的到達時間
- 速率 = 一天要移動多少距離 於是隨著小故事的發展，每一天都有不同的意外，但因為「範圍 = 交通距離」是無法變更的（但有可能會錯估），於是故事主角每天都在「 時程」與「速率」中不斷的協調與修正，嘗試要完成這趟旅程。旅程中就發生了各種突發狀況，例如：
- 錯估交通距離 = 錯估專案範圍
- 受傷導致行進速度變慢 = 開發速率下降
- 打電話通知朋友會晚幾天到達 = 嘗試延後 Due Time ⋯⋯等等 藉此案例 91哥再次強調這場分享就是一直圍繞在「範圍」、「時程」與「速率」這三個重點打轉，換句話說這場分享重點就是在講 Burn Down Chart 燃盡圖。
那「範圍」到底是啥？範圍就是專案要完成的工作項目有哪些，你的 product backlog 有多少，估算出來的 story point 有多少。
不過在問範圍有多少之前，首先要先問「該如何估算？」
關於估算，91 哥提到了幾個重點：
- 要SPA，也就是估算要「簡單」、「公開」且有「共識」。
- 相對估算比絕對估算簡單 （用小狗的大小當舉例，一隻狗很難描述大小，但問兩隻狗誰大，則很容易回答。）
- 粒度小比粒度大的精準 （用做飛機當舉例，做一台紙飛機與戰鬥機，哪一個能估算出比較精準答案） 91 哥也特別用了「一場 NBA 要打多久」當作範例說明「相對估算」。
一般來說 NBA 打一場的時間大約是 1.5 ~ 2 小時。如果要精確的計算，你大可以把每一節的時間、有可能的暫停時間、有可能出現的延長賽時間，全部加在一起嘗試算出精準的時間。但實際上每一場的狀況都不一樣，你很難在比賽結束之前精準地回答這一場比賽要打多久。可是即便沒有經過計算，你還是能根據過往的經驗回答出 1.5 ~ 2 小時這個該略的時間。
相對估算講完了，接著 91哥繼續講大家最在乎的「變化」，延續前面的範例，專案開發當中一定會發生變化，而變化就會影響「範圍」、「 時程」與「速率」。
而常見的變化有哪些？
- 插件
- 需求異動
- 做法異動
- 人員異動 那要如何面對「變化」，基本上就是「依據變化，時刻調整決策。」 （變化當下，最佳化決策；時時 review，調整決策；持續改善）
基本上老闆對於專案，他最關心的只有「範圍」與「時程」，因為他會優先在乎時間到了產品能不能交貨，畢竟能交貨才能賺錢。所以他通常不會第一時間管你目前的「速率」是多少。假設你跟他說這個 deadline 一定做不完，那他只會跟你說「那你需要多少人？我加給你！」（講到這 91 哥就吐嘲說，他就不相信上面那些人沒看過《人月神話》，真想把書砸到他們臉上。）
當專案發生變化時，PO 與 Developer 應該是在同一陣線，是互相幫助的夥伴；當 PO 估算了範圍與時程，若 Developer 覺得不妥，那 Developer 難道不用 support 更好的意見嗎？別忘了前面提到的 SPA「簡單」、「公開」且有「共識」。Developer 不幫忙 PO，Developer 不幫忙提出更好的解決辦法，那 PO 當然只好自己估算然後直接往上回報。
那在實際上在專案中到底要怎麼估算，91 哥說可以用三種 T-shirt size 來做相對估算。 例如：S = 10 story point、M = 20 story point、L = 40 story point。 因此當你將所有的項目都先分 size 之後即可得到「範圍」；由專案預定的 deadline 得到「時程」。如此就能計算出期望的「速率」（例如每週要完成多少 story point）。
有了「範圍」、「 時程」與「速率」的期望值，我們還需要知道團隊目前的「速率」基準。這裡 91 哥採用的方法是昨日天氣（yesterday weather），就是用過去的數據做加權平均，來當作下一次的基準。假設第一個月完成了 30 story point、第二個月完成 20 story point，那第三個月速率的基準就是 25。
搜集完這些數據後，不管是哪一種「變化」都能反映在 Burn Down Chart 上，就能由此看到變化帶來的影響。例如：
- 插件 = 影響範圍
- 需求異動 = 影響範圍或時程
- 做法異動 = 影響範圍或時程
- 人員異動 = 影響速率 看到變化帶來的影響之後，接著就要想辦法解決它，那有哪些方法呢？
首先關於「範圍」，它具備有 Queue 及 Priority 的概念，因此你會知道哪些項目要先做，哪些項目又可以無限延後。（友善提醒，不是不做，只是無限延後，晚一點做！）
在「時程」上則有很多方法，其中一個很常聽見的方法是「分階段上線」。
最後是「速率」，這也是 Developer 最能發揮的地方。
速率優化的治標方法有：
- 檢視 priority（很多東西真的沒這麼急。先做有價值的項目，有些東西可以無限延後。）
- 調整作法（人都快死了先做鋼鐵人一代就好，有錢有閒再來做二代、三代）
- 有計劃的欠債（欠債是要還的！）
- MVP（先求有，再求好）
- 如果是老闆，可以幫 Developer 提升硬體校能（也能提升人員士氣） 而治本的方法是老話一句「持續改善」，這也是王道，重點即是團隊有沒有一起變好！由團隊一起找到最適合團隊的實踐，那才是最佳實踐（best practice）。
所以老闆不要直白的跟團隊成員說我們來導入 Agile、Scrum 或其他東西，成員只會立即產生反彈。應該要先建立團隊的信任感及透明度，然後讓團隊彷彿是自己找到問題並自己提出解決方案（但其實你早已在團隊中安插 Spy 帶風向），等到最後團隊就會忽然發現，原來我們在 run Agile 或 run Scrum。
最後 91 哥有實際 DEMO 他們使用的工具，他在 excel 中將「範圍」、「 時程」與「速率」這些數據都互相關聯，只要輸入資料、調一下數字即可看出變化產生的影響，透過一個良好的工具確實的輔助面對變化該如何決策。
如此一來所有的決策都有數據在背後支持，不管是遇到要提前上線、有人離職、需求變更，只要將數據輸入 excel，就能看出影響層面，即可從中得到足夠的資訊來作出應變的決策。
例如：老闆要提前上線，你就可以跟他說，新的 deadline 我只能完成 200 story point（範圍），可以先調 Priority 優先作重要的，然後超過的部分先不做嗎？或可以改變做法，讓其中某幾個 L size 品質下降一點，但變成 M size 嗎？
但如果老闆堅持全部都要做完，那就只好調整速率，大家來加班，短期內衝刺讓速率變快。但要知道這一定有副作用，可能未來維護會更麻煩，可能下個月就一堆人請假或離職。
當有了足夠的資訊可以證明實際情況，老闆也比較能做出決策，也比較會被說服接受你提出的解決方案。
心得
之前一直聽見社群朋友們對 91 哥一再的讚不絕口，搞得我非常想要親身體驗一次，所以當初看到 Agile Tour Taipei 2015 的議程表中有 91 哥的場子，二話不說立刻搶票，等到活動當天還被朋友罵說有 91 哥的場子怎麼沒有找他一起來，由此可知 91 哥的魅力值有多高。
等到親身體驗之後，還真是驚為天人，整場分享非常順暢連貫且毫無冷場，分享的內容具備深度且實用，並有超多名言金句可以收錄。若用最近流行的話來形容，只能說這場分享的「含金量很高」。聽完後，對於 Burn Down Chart 有更明白的認識，更在聽完 91 哥分享了他們團隊是如何落實它，用它去面對「變化」並解決問題，讓人更能理解實務上該如何應用。
其他 91哥分享中包含的一些觀念也很受用，像是：
- 我們期待團隊能「依據變化，時刻調整決策」，但前提是你要有足夠的資訊來協助你作出決策。 延伸思考所以「記錄資訊 => 認識現況 => 看見問題」是很重要的。在 DevOps 中也有借用了這樣的觀念。
- 團隊轉型（成長）的精髓就是「自主管理」及「持續改善」。 持續改善的觀念不用說，不管是個人、團隊、工具，甚至是你的程式碼，都需要如此。
- Scrum、Agile 其實是讓你「面對現實」的照妖鏡。 「看見」很重要，不只讓你看見問題，還有足夠的資訊來真正的面對問題。
參加這一次的 Agile Tour Taipei 2015 ，真的收獲很多，讓我對於 Agile、Scrum 及 KanBan 有更多的認識與信心，我記得隔週團隊開例會的時候，我已經迫不及待的想跟夥伴分享所見所聞，希望這樣的好東西也能慢慢融入團隊裡，讓「持續改善」不只是落實在我們的「工具」層面，在「專案管理」在「團隊運作」也都能持續地向前邁進。
老實說這個筆記與心得文真的是拖了太久的時間了，有許多的細節已經遺忘，好在 91哥自己已經把文章寫出來，也有提供當天簡報的重點內容，不然能寫出的內容應該會再減少許多。所以一定要再推薦一次 91哥的這兩篇文章，含金量很高，務必要拜讀一下！
