Agile Tour Taipei 2015 筆記與心得（五）| Scrum Estimation Model - Joey Chen (91)
在得到「欠筆記文欠過年」的成就之後，硬是擠出一個下午的時間，終於整理完 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 有多少。...