In 91

擁有熱血魂，熱衷敏捷開發相關的點火師，專門點燃其他人內心的火種

2015-12-19

Scrum Estimation－如何估算專案時程

當瞭解單一個 story 怎麼使用 relative estimation 的原則估算出 story point 後，這篇文章將介紹怎麼運用同樣的精神，針對整個專案的時程進行推估。公式只有一個，而且再簡單不過了。

時程(schedule) = 範圍(PBI story points) / 速率(velocity)

前言

在上一篇文章《Scrum Estimation－Dog Point Game》中提到，該如何讓敏捷開發團隊透過 Dog Point Game 來熟悉相對估算的精神，並以團隊一同進行估算的方式，針對需求複雜度取得相對客觀的共識。

然而，一個傳統團隊要成功轉型成 Scrum 開發團隊將面臨許多困難，其中有很大一部分是來自於產品擁有者（Product Owner, 後續簡稱 PO ）的思維，是否能接受敏捷開發的概念。想讓 PO 接受敏捷開發，就必須先瞭解 PO 的需求以及他可能會碰到的問題。只有協助滿足他的需求，解決他的問題，才能建立 PO 與 Team 之間的信任。

而 PO 最重要的問題之一就是「如何評估專案時程」，本文將提出一種能在 Scrum 中運用相對估算的精神，透過實際的數據進行相對推估，以便 PO 能隨時依據不同情況回答這個棘手的問題。

要解決問題，而不是解決提出問題的人。

迷思

在 PO 詢問團隊：「能否讓我知道，這個專案你們預計多久可以完成？」

團隊請千萬不要回答：「因為我們 run 敏捷開發，所以要到實際估算時才會知道每一個 story 要花多久。而且我們只估算接下來的 1~2 個 sprint ，因為之後的一切都會變化，估了也估不準，告訴你也沒用。」這樣的答覆只是在逼你的 PO 走回頭路。

PO 心裡可能會想，為什麼在傳統的開發方式中，開發團隊至少可以透過工作分解結構（Work Breakdown Structure，簡稱 WBS）來評估一個時程目標，到了敏捷開發反而變成「做多少，算多少」這種不負責任的態度？那還不如用傳統的方式來進行開發，至少讓我可以對我的老闆跟客戶交差，至於品質與時程，當然還是開發團隊要負的責任，跟我 PO 無關。而且敏捷開發不是說要擁抱變化、儘早交付、鼓勵需求異動？到時候我看你們怎麼死的。

當 PO 開始用這樣的態度來要求團隊時，團隊成員就會覺得這個 PO 沒有敏捷心態（Agile Mentality），是個不知上進、改變、跟不上趨勢潮流的落伍角色，而又開始製造出角色之間的對立。

每一個專案都有時程與範圍的限制，不會因為敏捷開發方法就消失。

Step 1：按順序整理好 Product Backlog Items

首先請 PO 整理好整個專案的專案待辦項目（Product Backlog Items，後續簡稱 PBI），別被詞彙嚇到了，其實就只是在專案範圍內，有哪一些 features/stories/function list 需要完成。

請記得，在敏捷開發中的優先順序（Priority ）相當重要，因此當所有 PBI 都被整理出來後，務必請 PO 按照優先順序排好。

若以開發一個購物車系統的部分需求來當例子，如下表所示：

PBI 的描述不用長，只要能簡單清楚說明出 what work needs to be done 即可。如果可以，請盡量避免 PBI 之間存在著相依性。此外，在整個專案開發過程中，後續可隨時調整順序，以及插入或移除 PBI 項目。

Step 2：以 T-Shirt Size 來定義 PBI 的相對大小

這個步驟相當簡單，先以 t-shirt size (Small, Medium, Large) 三種等級來定義 PBI 的相對大小。

PO 只需要問自己：「如果只有大、中、小三種 size 的話，這個 PBI 應該屬於哪一種等級？」

還記得上一篇不斷強調的觀念嗎？相對比較要比絕對估算來得簡單。

假設 PBI 在 PO 評估完 size 後，結果如下表所示：

把整個 PBI 的大小等級都分類完後，應該每個 size 都有被使用到，否則可能需要協助 PO 回顧一下，這樣的相對分類是否需進行調整。

這作法可以參考 Mike Cohn 的《Estimating with Tee Shirt Sizes》一文。在 Scrum 中這樣的方式也常用來估算專案的成本，而這篇文章則是運用同樣的概念來估算時程。

此外，可以按照團隊與 PO 的習慣或需求，區分成更多等分，例如 “1, 2, 3, 4, 5” 或 “S, M, L, XL, 2XL”，雖然分越多類似乎越精準，但太多類其實反而容易造成 PO 定義 size 的困擾。建議 3 類，最好不要超過 5 類。當然，在整個專案開發過程中，還沒完成的 PBI 也隨時可以調整其 PBI 的 size 評估。

Step 3：使用 Sprint 0 進行穿刺實驗

接著有兩種方式可以方便估算出，整個 product backlog 需要團隊花多少時間才能交付。假設目前團隊正式的 sprint 時間為 2 週。

第一種是按照 PBI 順序挑出第一個 L 、第一個 M 、第一個 S 的 PBI ，來當做穿刺實驗（Spike in XP 及 wiki 的說明）的標的物，並在 sprint 0 中完成這三個 PBI 。

Spike 的時間長度，可由團隊自行決定。在本文例子中，也就是將 sprint 0 視為非正規的 sprint，可能只花一週，也可能花了三週）。這個 spike 主要目的就是估算出三種 size 的 story point ，以及一個 sprint 預計可以能完成多少 story point ，也就是團隊產出速率（Velocity ）。

第二種是直接以 sprint 1 當穿刺實驗的基底，按照 PBI 的順序進行 story point 的估算與開發，在 sprint 1 結束後，一樣可以得到團隊產出速率。

這個方式可能碰到的問題是，若 sprint 1 少了某個 size 的 PBI ，那就無法在 sprint 1 結束時，對整個 product backlog 進行時程的估算。

不論採用何種方式，期望得到的資訊如下：

  • 每一種 size 評估出來的 story point。
  • 推估出團隊每個 sprint 的產出速率，也就是團隊每個 sprint 可完成多少 story point。
  • PBI 的 size 是否有大到超出 sprint 的範圍，也就是一個 sprint 做不完某一種 size 的 PBI 。若有此情況，則需考慮拆細 PBI 並調校 size 的定義。

以 sprint 0 的 spike solution 為範例，假設估算如下所示：

假設這三個 PBI 總共花了團隊 1 週的時間完成 （4/20~4/26）。因此可以得到以下的基礎資訊：

  1. 團隊的 velocity 為 (20+13+5) * 2 = 76
  2. 各 size 對應的 story point 基準為
    • L: 20
    • M: 13
    • S: 5

目前 product backlog 上分別有 2 個 L ， 2 個 M ， 2 個 S 共 6 個 PBI 。以上述兩個資訊為基礎，可以推算出完整的 product backlog 總大小為 2*20 + 2*13 + 2*5 = 76，剩下的 product backlog 大小為 38 。

團隊每個 sprint 可完成 76 個 story points ，因此要消化剩下的 PBI 只需要 38/76 = 0.5 個 sprint ，也就是一週的時間，也就是若 4/27 開始進行，可以在 5/3 完成整個專案。

考考你

如果經過 Spike 試驗後， L 為 40 ， M 為 20 ， S 為 10 ，每個 sprint 為 2 週，團隊的 velocity 為 50 ，sprint 1 從 2015/5/4 開始進行，那麼下面的 product backlog 何時可以完成？

推估如下：

  1. 整個 product backlog 大小為：2*40 + 3*20 + 4*10 = 180 story points
  2. 團隊 velocity 為 50 ，所以需要 180/50 = 3.6 個 sprints = 50.4 天，約 51 天。
  3. Sprint 1 起始日為 5/4，整個 product 預計於 6/24 可完成。

結論

透過上述簡單的三個步驟，Scrum 團隊以實際的估算來相對推估出整個 product backlog 的大小，並以實際的產出來推估出團隊的 velocity。

其重要的精神在於：

  1. PO 透過相對比較，定義 PBI 大小
  2. 團隊實務上的相對估算，放大到完整的 product backlog ，推算出 product backlog 大小
  3. 團隊實務上的產出速率，推算到整個 product backlog 需消化的時間
其實 product backlog 的大小 + 時程 + 團隊 velocity 就等於 burndown chart，這個在下一篇文章再來為各位說明 burndown chart 簡單中所蘊含的奧妙。

這樣的方式帶有幾點好處：

  1. 團隊一起進行
  2. 實務回饋
  3. 以 PO 的分類與順序為基底進行
  4. 隨時可以對 PBI 的 size 與順序進行調整，也隨時可以移除或插入新的 PBI ，都可以計算出整個 product 相對應的交付時程，或限定時程內可以交付的 PBI 有哪些。

最後，我個人比較喜歡使用「推估」而非「預估」，雖然相對估算並等比例放大很可能會帶有誤差，但總比過去 WBS 那種以個人過去經驗來「猜測」整個專案的時程來得可靠得多。而且這樣的估算方式，示每一個變化的當下，都可以進行 review 與調整，也就是 Scrum 中重要的精神： inspect and adapt 。

請不要再把 PO 推向懸崖了，請把 PO 當成團隊最重要的一員，只有成為「一個團隊」，衝刺（Sprint）才會是同個方向，才會有力道。

實務回饋指的是每個 sprint 對每個 PBI size 的估算與 velocity 都可以納入計算的基準，例如以加權平均來計算各 size 所對應的 story point 以及團隊平均的 velocity 。

另外，完整的 product 交付時程，建議以 sprint 為單位，也就是最後要無條件進位，會比較貼近實務上的需求與經驗。

blog 與課程更新內容，請前往新站位置：http://tdd.best/

 

關於我 (91)

 

本頁段落

系列文章

標籤雲