如何讓 scrum 團隊透過 t-shirt size 來對專案範圍進行相對估算，使用 yesterday's weather 來評估團隊速率，進而估算出推估時程與預計的 deadline 之間落差有多大。
當專案面臨「插件」、「時程調整」、「priority調整」、「需求異動」、「作法異動」、「人員異動」時，就能以 estimation model 當基底來評估影響範圍，讓團隊能在在變化當下擬定眼前最佳化的決策，並提供相對客觀的資訊給 PO 與 stakeholder 溝通。
前言
在上一篇文章《Scrum Estimation－如何估算專案時程》，介紹了在 Scrum 中推估專案時程的其中一種方式。在大家有了推估時程的基礎知識後，本篇文章將以上一篇的內容為基底，介紹一下 Scrum Estimation Model 可以怎麼幫助團隊在變化的當下，做出最佳化的決策。
Burn Down Chart
在 Scrum 中要瞭解團隊進度是否符合預期時，最常使用的就是燃盡圖（Burn Down Chart）。燃盡圖其實就是由一條 x 軸（代表專案時程）、一條y軸（代表專案大小範圍），以及一條斜線（斜率代表消化 Product Backlog 的速度）組成。預期專案的進展，如下圖所示：
當團隊紀錄實務上每天消化的 story point 並相連成線，就可以得到實務的燃燒線的趨勢，如 wiki 上圖示的紅線：
這有什麼好講的？不就是兩點連成一直線而已，有什麼狗屁學問呢？在實務上如何使用燃盡圖來觀察團隊目前開發的狀況可能潛藏著什麼問題，本篇文章暫時先不深入探討。這篇文章的重點在如何透過這個最簡單的燃盡圖的元素，就可以用來說明如何用 Scrum 來觀察變化，進而擁抱變化。
接下來為各位說明燃盡圖的三個元素能有什麼樣的變化，以及該變化在實務上的意義。
Burn Down Chart－Y軸
PBI 代表了專案有哪一些 story 需要完成與交付，同時也定義了這一些 story 的優先開發順序。PBI 如下表所示：
在經過了 spike 試驗後，定義 L 為 40 ， M 為 20 ， S 為 10 ，所以專案的大小就等於 2*40 + 3*20 + 4*10 = 180 story points 。有了這個資訊，就擁有了專案的粗略大小、範圍以及 story 的優先序，如下圖所示：
Burn Down Chart－X軸
如上篇文章所提，每一個專案都一定有預期的 deadline ，不會因為使用 Scrum 來進行開發就沒有時程的壓力或目標。唯一比較不一樣的是，Scrum 的 iteration timebox 是以 sprint 為單位。倘若這個團隊一個 sprint 是 2 週，且 sprint 1 的起始日期為 5/4 ，預計的 deadline 為 6/15 ，換算結果為 3 個 sprints ，那麼燃盡圖的 x 軸就代表了專案的時程，如下圖所示：
Burn Down Chart－斜率
燃盡圖有了 X 軸代表「專案時程」， Y 軸代表「專案的範圍大小」，而這兩個端點所劃下來的斜線，其斜率即代表「在預期的 deadline 要完成這些 story ，團隊在每個 sprint 需要完成的速率」，如下圖所示：
所以以上述的例子，專案大小為 180 story points ，預期開發時程有 3 個 sprints ，所以如果團隊從 5/4 開始進行開發，想要在 6/15 完成 180 story points 的話，每個 sprint 團隊需要消化 60 story points 才有機會準時結案。
這篇文章如果只寫到這，那就只是依據上篇文章改成圖解說明而已。別忘了，這篇文章的重點在於變化，因為所有預估的東西，通常都不是這麼美好的。
專案範圍不變，團隊開發速率不變 ► 專案時程的變化
當 spike 試驗後團隊預期的開發速率（或是之前團隊的平均開發速率），也就是 velocity 為 50 story points/sprint，那就代表實務與預期之間有所落差。
倘若專案每一個 story 都很重要，一定都要交付才行，也就是專案大小不允許改變。而團隊的開發速率也不變的情況下，專案的 deadline 就會因此改變。如下圖所示：
因為團隊每個 sprint 只能消化 50 story points ，而專案推估總共有 180 story points ，所以團隊需要 3.6 個 sprints 方能把所有 story 完成。這樣推估與預期的 deadline 6/15 差了 0.6 個 sprint ，也就是預期團隊完成這個專案，實際上需要到 6/24 方能完成。
時程不變，團隊開發速率不變 ► 專案範圍的變化
如果時程才是專案最重要的關鍵，不允許異動。而團隊開發速率仍維持線性不變的情況下，那在 deadline 時，預期團隊能完成哪一些項目，又有哪些項目無法被完成呢？透過燃盡圖的移動，可以一目了然。
首先來看，當 X 軸的 deadline 不變，斜率也不改變的情況，燃盡圖的變化如下所示：
當斜率不變，團隊開發的斜線平行往預期的 deadline 移動時，也就是 X 軸從 6/24 移動到 6/15 時，可以看到 Y 軸從原本 180 降到了 150 。這代表團隊在預期的 deadline 6/15 時，只能消化掉 150 story points 的 PBI ，這樣代表什麼？代表了如果按照順序消化 PBI 時，我們能馬上推算出哪一些 story 無法在 6/15 被完成。如下圖所示：
當為 PBI 加上每一個 story 累計的 story points 時，就能簡單且清楚的推算，最後兩個 story 並無法在 6/15 前完成。而這樣的資訊有什麼用處？當然有用！對 PO 來說，可以馬上知道 PBI 有沒有需要調整一些順序，甚至調整作法來縮小 story size，或是不能如期交付的項目中，有哪一些是必要交付的，如果只額外完成必要的項目，則 deadline 會需要增加幾天。
PO 所掌握的資訊越多，就越能替團隊向 stakeholders 與 users 爭取更多的資源、時程與作法的調整。
斜率的優化－提升消化速率
可惜的是，很多團隊一開始所面臨的情況似乎都是「專案範圍不變、專案時程不變」，只一味地強迫團隊需要有斜率的優化。但為什麼我把斜率的優化擺在最後面呢？原因很簡單，這是實務上最不容易達成的變化。
技術債的由來
當時程與專案範圍無法割捨與讓步，而一味強求斜率優化時，就會使得團隊不得以而欠下技術債，如下圖紅色三角形所示：
技術債是會產生利息的，如果沒有有效且清楚瞭解副作用的訂好欠下與償還技術債的策略，往往專案後期光還利息就把團隊的生產力全部消耗殆盡，最後就是以債養債，然後看誰倒楣接手這個專案。
當所有資訊都透明公開地呈現出來，PO 與團隊可以很清楚地知道，現在因為什麼樣的限制與需求，使得我們需要制訂欠債還債的策略，會影響哪些，該怎麼欠，該怎麼還，該在什麼時候內要還清。一切都有資訊來佐證跟調整策略，在欠債的同時也瞭解了副作用的影響範圍，只有 PO 與團隊都清楚且有共識的一同下決定，團隊衝刺的方向才會一致，團隊才會一心。
再強調一次，不欠技術債，是理想化、烏托邦、甚至不切實際、不負責任的說法，真正的價值是在最剛好的時間、用最剛好的方式欠下技術債，並在合適的時間用合適的方式還債。這樣的價值在需求很容易急速變化的情況下，很有可能達到事半功倍的效果。
加人的問題
加人的部分，我想到人月神話上的一個笑話：”Nine women can’t make a baby in one month.“。
增加人員到一個已經延誤的專案裡，等於是火上加油。除非你可以把工作區分，讓新進人員可在不影響他人工作的狀況下有所貢獻。
欲增加軟體專案的人手，總共必須付出的代價可分為三方面：
- 工作重新切分本身所造成的混亂與額外工作量
- 新進人員的訓練
- 新增加的相互交流。
每個管理者都知道這個道理，卻只是得到他的表面，往往總是挑這個最糟糕的決策來試圖解決問題，並擺出一副「你提出了你的問題，我給了你我的解決方案。你可以選擇不接受，但就不要再來跟我爭論你的問題」的模樣。
加班的問題
加班的部分，大家也都知道，加班有幾個重點：
- 要有目的性
- 要短期衝刺，而不是長期慣性
- 要大家主動與心甘情願
上面這幾點若無法滿足，加班的效果就只是做做樣子，展現出「我們都很努力，但還是無法滿足時程」的模樣。糟糕的加班反而會帶來了許多負面的效果：
- 士氣低落
- 工作 12 小時仍只有 8 個小時的產出（多出來的 4 小時只是被轉換成其他形式的浪費而已）
- 公司付出了額外的成本：電費、加班費、員工的健康、員工後續的請假
- 品質低落、便宜行事、疊床架屋、破窗的開始
但還是許多管理者會選擇，讓自己的團隊做出那副可憐兮兮的模樣，來展現自己鐵腕的管理能力以及鞠躬盡瘁的假象。
斜率優化的建議方式
斜率優化有很多方式要比加人、加班來得有用，但這幾個方式往往需要相輔相成，例如：
- 自主管理
- 持續改善
- 對症下藥
實際上斜率優化為團隊本身（不是專案，而是團隊本身）帶來的價值是最高的，因為這就是大家常掛在嘴邊講的「敏捷開發的文化」。
就如人月神話中提到的《沒有銀彈》一樣，在軟體開發中其實沒有所謂的 best practice ，最適合你們團隊的方式，就是你們的 best practice 。
每個團隊最好的運作方式，只有每個團隊自己能決定。什麼方式是團隊成員都認同的，什麼問題是大家觀察、體會後，共同認定的問題。針對這些大家自己提出來的問題，大家自己提出看法，覺得以什麼樣的方式是我們團隊能接受並嘗試改善的。
只有問題是大家自己提的，方法是大家自己想的，大家才會心甘情願地去落實、體會，這是團隊要能持續改善的最重要前提，也是團隊自主管理的基本元素，更是對症下藥的不二法門。
有很多時候，很多團隊其實提升 velocity 的最有效方式，並不是 run Agile, Scrum, Kanban, XP …，而是提升開發團隊的硬體設備，例如有個讓眼睛舒適一點的大螢幕、讓編譯建置可以更快的 SSD 或電腦，讓大家能自主管理有效率的工作時段，更甚至讓大家不要開無意義的會議，就能戲劇化地提高所有人的生產力。
這也是為什麼，在 Scrum 中 retrospective 會議相當重要。事實上是不是 run Scrum 都不要緊，要緊的是有沒有持續改善、避免浪費、自主管理並從回饋中學習成長。
把團隊中大家共同認為的問題挑出來，大家集思廣益地找出適合自己團隊的解決方案，大家方向一致的替自己的流程進行改善，大家的問題獲得改善時，就是 velocity 提升的時候。所創造出來的盈餘時間，也就是正向循環的動力來源，發現問題並試圖解決，問題就是養分的來源。
魚幫水、水幫魚，團隊中的每個角色互補、互相支援跟協助，讓每個人都擠出盈餘時間，就可以做更多改善或是對彼此的支援，這才叫 1+1 > 2。而每個人都擁有盈餘時間，這才是整個團隊可以持續改善的彈藥、動力來源。
如果一個團隊裡面，每個角色都自顧不暇，要他們互相支援、互補，根本就是笑話，要他們改變、改善、甚至創新，根本也是強人所難。
所以一個團隊成不成功（成功很難定義，順不順利可能比較貼近一點），看大家的表情就知道、看每個角色的盈餘時間就知道、看他們彼此的互動跟支援程度就知道。
Estimation Model 的 MVP 雛形
- T-shirt size 的加權平均
- PBI 的推估範圍
- Yesterday weather 概念所產生平均的 velocity
- 三個維度的變化
- 預計時程內無法完成的 PBI 項目
結論
透過「專案時程」與「專案範圍」與「團隊開發速率」三個元素所組成一個簡單的燃盡圖，用它來表現出專案管理的三個維度。不管異動了哪一個關鍵因素，所帶來的沙盤推演的變化，上述 estimation model 所提供的資訊，都能讓 PO 在當下這個時間點來進行最適合的決策。
- 時程不變、開發速度不變
PO 要如何決定哪一些 story 可以不做，可以晚一點做，可以暫時換個方式做。該怎麼說服 stakeholders ，有哪些充足的資訊與證據來說明團隊真實的現況與當下的決策，而不是信口開河、坐地起價的討價還價。 - 專案範圍不變、開發速度不變
PO 要怎麼說服使用者還需要花費多少時間才能滿足他們所有需求。如果使用者願意體會、理解，對使用者來說，是否認同現在 PBI 的順序，是否有哪一些是使用者覺得不是 must have, priority 卻被排在很前面的呢？ - 專案範圍不變、時程不變
這就只能提升開發速度。是否有足夠的資訊瞭解現在困擾團隊的是哪些關鍵的問題？這些問題排除，是否就能讓團隊的 velocity 獲得改善呢？就算 PO 想要團隊透過加班來提升 velocity ，也能有足夠的資訊與目標來說服 Scrum 團隊，一起衝刺同一個目標，而不是越到後面逼近時程時，才漫無目的地透過加班來「展現出自己與團隊的盡心盡力」。如果團隊不想加班，也能請團隊在每個 sprint 中提出哪些改善斜率的方式，讓專案能在時程內滿足必要的交付項目。
持續地改善，讓團隊持續地進化，目標明確，沒有任何角色吃虧，沒有任何角色之間的敵對，一切都是透明、公開、自主。讓使用者、stakeholders、PO、Scrum team 每個角色都是朝向共同的目的去努力，而不是像傳統開發團隊碰到的那種互相推諉、只做表面、只管結案、凍結變化，最後在這個專案中每個人都輸了的局面。
blog 與課程更新內容，請前往新站位置：http://tdd.best/
