估算需求複雜度（4）Scrum 專案金三角

估算需求複雜度（3）如何評估專案時程 << 前情

前言

相信大家一定都對傳統的專案管理金三角不陌生，如下圖所示：

（出處：http://www.projectup.net/blog/images/stories/1001_thumb.jpg）

在上一篇文章估算需求複雜度（3）如何評估專案時程中，介紹了在 Scrum 中推估專案時程的其中一種方式。在大家有了推估時程的基礎知識後，接下來就要來介紹一下 Scrum 中的專案金三角有什麼不一樣的地方。

Burn Down Chart

在 Scrum 中要瞭解團隊進度是否符合預期時，最常使用的就是燃盡圖（Burn Down Chart）。燃盡圖其實就是由一條 x 軸（代表專案時程）、一條y軸（代表專案大小範圍），以及一條斜線（斜率代表消化 Product Backlog 的速度）組成。如下圖所示：

這有什麼好講的？不就是兩點連成一直線而已，有什麼狗屁學問呢？本篇文章暫時先不探討，在實務上如何使用燃盡圖來觀察團隊目前開發的狀況可能潛藏著什麼問題。而用這一個最簡單的燃盡圖，就可以用來說明如何用 Scrum 來觀察變化，進而擁抱變化。

接下來為各位說明燃盡圖的三個元素能有什麼樣的變化，以及該變化在實務上的意義。

這篇文章所使用的例子，為估算需求複雜度（3）如何評估專案時程文章中的「考考你」的 PBI 來當例子。

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 都應該讀過人月神話，而且從內心相信裡面的核心價值觀。但當他們碰到專案金三角的問題時，卻總是不加思索地選擇斜率的優化來解決專案的矛盾問題，往往要嘛加人，要嘛加班。

加人的問題

加人的部分，我想到人月神話上的一個笑話：”Nine women can’t make a baby in one month.“。

Brooks’s Law:

增加人員到一個已經延誤的專案裡，等於是火上加油。除非你可以把工作區分，讓新進人員可在不影響他人工作的狀況下有所貢獻。

欲增加軟體專案的人手，總共必須付出的代價可分為三方面：工作重新切分本身所造成的混亂與額外工作量、新進人員的訓練、新增加的相互交流。

每個管理者都知道這個道理，卻只是得到他的表面，往往總是挑這個最糟糕的決策來試圖解決問題，並擺出一副「你提出了你的問題，我給了你我的解決方案。你可以選擇不接受，但就不要再來跟我爭論你的問題」的模樣。

這種態度，就跟電影我在政府部門的日子，裡面一個乩童喊價的片段一樣（請見專業的定義）。

加班的問題

加班的部分，大家也都知道，加班有幾個重點：

1. 要有目的性
2. 要短期衝刺，而不是長期慣性
3. 要大家主動與心甘情願

上面這幾點若無法滿足，加班的效果就只是做做樣子，展現出「我們都很努力，但還是無法滿足時程」的模樣。糟糕的加班反而會帶來了許多負面的效果：

• 士氣低落
• 工作 12 小時仍只有 8 個小時的產出（多出來的 4 小時只是被轉換成其他形式的浪費而已）
• 公司付出了額外的成本：電費、加班費、員工的健康、員工後續的請假
• 品質低落、便宜行事、疊床架屋、破窗的開始

但還是許多管理者選擇讓自己的團隊做出那副可憐兮兮的模樣，來展現自己鐵腕的管理能力以及鞠躬盡瘁的假象。

斜率優化的建議方式

有很多方式，要比加人、加班有用，但這幾個方式往往需要相輔相成，例如：

• 自主管理
• 持續改善
• 對症下藥

實際上斜率優化為團隊本身（不是專案，而是團隊本身）帶來的價值是最高的，因為這就是大家常掛在嘴邊講的「敏捷開發的文化」。

就如人月神話中提到的”沒有銀彈” 一樣，在軟體開發中其實沒有所謂的 best practice ，最適合你們團隊的方式，就是你們的 best practice 。

現實可悲的是，往往有一堆 committee 或 PMO 總覺得適用於 A 團隊的作法，就一定適用於 B 團隊，進而強加諸在 B 團隊身上。但他們卻連去訪談、瞭解 B 團隊所碰到的問題都沒有進行，更甚至於加諸之後不聞不問，只自顧自地去領功勞，反而把原本效率極高的螞蟻團隊（源由請見螞蟻的一課）置於萬劫不復之地。

Policy, Policy, 從古至今多少罪惡，假汝之名以行 （改編自羅蘭夫人）

每個團隊最好的運作方式，只有每個團隊自己能決定。什麼方式是團隊成員都認同的，什麼問題是大家觀察、體會後，共同認定的問題。針對這些大家自己提出來的問題，大家自己提出看法，覺得以什麼樣的方式是我們團隊能接受並嘗試改善的。

只有問題是大家自己提的，方法是大家自己想的，大家才會心甘情願地去落實、體會，這是團隊要能持續改善的最重要前提，也是團隊自主管理的基本元素，更是對症下藥的不二法門。

有很多管理者迷信於開發方法論，迷信銀彈，迷信潮流趨勢，而忽略了眼前團隊的本質，忽視了團隊所提出來的問題。

有很多時候，很多團隊其實提升 velocity 的最有效方式，並不是 run Agile, Scrum, Kanban, XP …，而是提升開發團隊的硬體設備，例如有個讓眼睛舒適一點的大螢幕、讓編譯建置可以更快的 SSD 或電腦，讓大家能自主管理有效率的工作時段，更甚至讓大家不要開無意義的會議，就能戲劇化地提高所有人的生產力。

這也是為什麼，在 Scrum 中 retrospective 會議相當重要。事實上是不是 run Scrum 都不要緊，要緊的是有沒有持續改善、避免浪費、自主管理並從回饋中學習成長。

把團隊中大家共同認為的問題挑出來，大家集思廣益地找出適合自己團隊的解決方案，大家方向一致的替自己的流程進行改善，大家的問題獲得改善時，就是 velocity 提升的時候。所創造出來的盈餘時間，也就是正向循環的動力來源。

記住，是要一個 team ，而不是一堆 team member。

魚幫水、水幫魚，團隊中的每個角色互補、互相支援跟協助，讓每個人都擠出盈餘時間，就可以做更多改善或是對彼此的支援，這才叫 1+1 > 2。而每個人都擁有盈餘時間，這才是整個團隊可以持續改善的彈藥、動力來源。

如果一個團隊裡面，每個角色都自顧不暇，要他們互相支援、互補，根本就是笑話，要他們改變、改善、甚至創新，根本也是強人所難。

所以一個團隊成不成功（成功很難定義，順不順利可能比較貼近一點），看大家的表情就知道、看每個角色的盈餘時間就知道、看他們彼此的互動跟支援程度就知道。

結論

透過「專案時程」與「專案範圍」與「團隊開發速率」三個元素所組成一個簡單的燃盡圖，用它來表現出專案的金三角。不管異動了哪一個關鍵因素，所帶來的沙盤推演的變化，上述燃盡圖所提供的資訊，都能讓 PO 在當下這個時間點來進行最適合的決策。

• 時程不變、開發速度不變
  PO 要如何決定哪一些 story 可以不做，可以晚一點做，可以暫時換個方式做。該怎麼說服 stakeholders ，有哪些充足的資訊與證據來說明團隊真實的現況與當下的決策，而不是信口開河、坐地起價的討價還價。
• 專案範圍不變、開發速度不變
  PO 要怎麼說服使用者還需要花費多少時間才能滿足他們所有需求。如果使用者願意體會、理解，對使用者來說，是否認同現在 PBI 的順序，是否有哪一些是使用者覺得不是 must have, priority 卻被排在很前面的呢？
• 專案範圍不變、時程不變
  這就只能提升開發速度。是否有足夠的資訊瞭解現在困擾團隊的是哪些關鍵的問題？這些問題排除，是否就能讓團隊的 velocity 獲得改善呢？就算 PO 想要團隊透過加班來提升 velocity ，也能有足夠的資訊與目標來說服 Scrum 團隊，一起衝刺同一個目標，而不是越到後面逼近時程時，才漫無目的地透過加班來「展現出自己與團隊的盡心盡力」。如果團隊不想加班，也能請團隊在每個 sprint 中提出哪些改善斜率的方式，讓專案能在時程內滿足必要的交付項目。

持續地改善，讓團隊持續地進化，目標明確，沒有任何角色吃虧，沒有任何角色之間的敵對，一切都是透明、公開、自主。讓使用者、stakeholders、PO、Scrum team 每個角色都是朝向共同的目的去努力，而不是像傳統開發團隊碰到的那種互相推諉、只做表面、只管結案、凍結變化，最後在這個專案中每個人都輸了的局面。