上一篇文章分析了 Scrum 團隊在估點活動的遭遇的困難，以及滯礙難行之處。今天來分享我時常採用的變形估點系統。在設計系統時，首要考量是要消除常見的估點方法帶來的內部張力，因此我認為必須包含以下的特性：

• 減少瑣碎：
  讓腦力密集工作者能專注在最重要的事上；避免記錄工作時數成為開發團隊的心理與精神負擔。
• 專業分工：
  領域相關的工程點數，交由領域團隊評估，而不採用全體共議。
• 容錯：
  「估」這個字的意含就是「不凖」。因此不把追求精準當作目標，而是以培養團隊經驗為原則。一個由專家給出的參考評估值，仍然會比 PO 用經驗評估來得有參考價值。
• 實踐方式指引：
  對如何將 User Story 拆分成小顆粒的工程項目，提供實踐方式供團隊參考。縮短團隊的摸索期。

接下來介紹具體的估點系統實踐方式：

123 估點法

我們定義一天的工作負擔為 3 點；並切成 3 個時間區段，每個區段分配到 1 點，如下圖：

舉幾個例子：

• 把握度高、簡單的任務 (例如更換字串) = 1 點
• 感覺需要閱讀 1 天的技術文件 = 3 點
• 感覺不到 2 天就可以完成的程式 = 5 點

感覺，其實就是大腦根據經驗在進行評估，我們最終得到的，是一個和「時間」與「複雜度」有相關性的量化數字；雖然不可能精準，但是一個有參考價值的指標。

刻意不用「時間」做時間段的分隔，這是因為我們深信腦力密集工作者必須保有一定的彈性，軟體開發活動，不適合採用工廠式的時間管理。因此，我們採用「心情轉換事件」的抽象方法來定義時間區段；設計程式是一種創作活動，即使不在座位上，一個短暫的散步，一個閉目養神都可能是靈感來源，這些行為的「計時」，是某種程度的瑣碎與負擔。而 123 估點法，可以有效的解決這個問題。

另外，這個方法也是刻意的在迴避進行太細節的時間估算。曾經合作過一些 PM，在產品專案的時間管理上，用「小時」為單位在擠開發時間，長久下來，會傷害 PM 與工程師之間的互信。

拆解 User Story

前篇文章提到過，在線上 Refinement 會議，PO 與設計師已經介紹完 User Story 的細節，此時工程團隊已經知道開發範圍，各領域開發人員也知道各自負責的內容，User Story 已被初步拆分成不同領域的工作內容，如下圖所示。

在線下 Refinement 活動，各領域開發人員就開始將分配到的項目，再進行細步拆解。以 Android 開發者分配到的任務為例，可能拆成下面的工程項目：

• 刻 UI
• 設計架構
• API 串接
• 商業邏輯撰寫與測試
• 技術文件閱讀

然後再用 123 估點法給與點數，此時若 Android 開發者為 2 人以上，就可以採用「撲克估點」的討論精神，來對齊相同領域專家的看法，降低雜訊。結果如下圖：

在這個案例，我們得知這個 User Story ，Android 開發需要點數為 15 點，也就是大約需要 5 個工作天。當其他的領域開發者完成估點任務後，可能得到下圖的結果：

至此，我們得到了該 User Story 需要 51 點的評估結果，若每個領域都同時開始進行開發，完成這個 User Story 的所需時間也就可以推估。直觀的看，也就是 Android 開發完的時間就是 User Story 的完成之時，但，實務上肯定不會這麼完美 (微笑)，我們之後的文章再來探討如何透過點數進行專案管理。

這個估點系統，我在 5 個產品團隊導入過，不敢說它是完美的方式，但對系統層面來看，的確形成一個能讓估點活動順利進行的結構。而 PO / PM 也對專案有了具有參考價值的量化數據，對風險控管產生幫助。