讓 Scrum 團隊有更好的預估之一

圖片來源：www.freepik.com

這同是 2016 年的舊文，根據現在的閱讀習慣重新整理，文章分成三回陸續發布，本回先談談在 Scrum 中，為什麼要估時，然後談談比較常見的單位與用法。下回則是幾個小方法，讓團隊能有更好的估算。最後一回，則是一些過去的自省與感想。

2016 離開水果公司，和朋友一起創業，對於要不要要求團隊估時與 CEO 曾有一些討論，當時討論的結論忘了 (路人：怎麼覺得這兩位是好隨便的 CEO 和 CTO，笑)，不過，最後決定先照目前的流程跑，然後用 kanban 進行持續的觀察與優化，不過，對於 Scrum 團隊估時倒是有些個人想法可以分享。

為什麼要估時 (或估點)？

剛開始導入 Scrum 時，團隊大概最不能適應的事情之一，就是預估這件工作從 PM 移交給團隊了，過去由 PM 負責切 WBS，然後根據 WBS 規劃時程，有經驗的 PM 也許還好 ，沒經驗的 PM 則是用 dead line 天馬行空地認為團隊能在某個時間點全部開發完畢、然後進行測試等等，反正，一般來說，開發人員在水深火熱之中對於預估是無感的，甚至是排斥的，畢竟要花多少時間，開始開發才知道，說那麼多都沒用，即便 PM 規劃的時程多麼不合理都隨它去了。

在 Agile 方法中，預估的目的首要還是提供進度的可預測性度量，這是不可避免的，即便是粗略的估算，也是要有個大概的時程讓 stackholder 有個譜 (但是這譜有時會變成爭執的焦點又是另外的故事了)，但在進行預估的會議中，像是 refinement meeting 或是 planning meeting，預估還有另一層意義：透過預估的方式，確定團隊對於工作內容都有一致的共識，個人認為，這才是將預估這件事交由團隊負責最有價值的地方。

至於可預測性量度，如果我們計劃得夠詳細了 (稍後會提到)，是不是就能估算的很精確呢？答案是否定的，因為變異性是難以預測，在 Scrum 中的則是當團隊有穩定的預估和穩定的開發能力後，相對來說就比較具有可預測量度。感覺很玄吧！難就難在穩定不是嗎？基本上，答案就是信賴團隊全體的智慧。

以點數為例，當大小或複雜度差不多的 stories (或任何要進行預估的工作單位)，團隊都能給予相近的點數，此時團隊的預估是彼此有共識的且穩定的；在有穩定的估預估前提下，當團隊能在一定的衝擊範圍 (有人突然重病無法上班、有人離職、新人加入或是遇上原先不預期的困難) 內，團隊能夠互相支援，依然能交付承諾的工作，此時團隊就有穩定的開發能力了。但這上述二點，不是瞬間就能擁有，是要團隊一定時間的磨合後才會穩定下來的。

預估的單位種類

穩定的開發能力需要多種 practice 組合和團隊組合的優化 (cross-functional team)，不在這次討論的範圍，即便是有穩定的開發能力，但預估的大小變動範圍很大，也很難有一個穩定的數值可以參考，因此前面才會提到穩定的預估是很重要的前提，大多數 Scrum 書籍都會建議 user story 用點數當作單位，以小時當作 task 的估算單位，但這不是絕對，單位可以分成幾種：

時數

這是最直覺的單位，大家都習慣以『我要花多少時間』完成這個 story 或 task 的想法來估算，但也是最難估的準的單位，特別是用時數估算 story 時，除非 story 夠小，不然動不動就出現 20 或 40 以上的數字，意義就不太大了。如果團隊估時是用 planning poker 方法的話，有時也會容易造成 senior 與 junior 對於時數僵持不下的情況 (稍後再提)，不過對剛開始使用 scrum 的團隊來說，用時數當成 task 的單位，在還沒有 velocity 參考數字之前，多一個數字作為一個 sprint 可以選多少 story 的參考。

通常是把每個團隊成員的實際可工作時數 (工作天數 * 5 - 休假時數 - 已知開會時數) 加總，作為一個 sprint 可選進 stories 的上限，從最優先的 story 開始挑，挑到時數已滿時，就不再加 story 了。

點數

和時數這種量測的單位相較，點數就有點抽象，但其實相對大小是比較容易比較的，點數代表複雜度的相對程度，也就是 2 點的 story 其複雜度會比 1 點的 story 要多複雜一倍，這也是為什麼撲克牌會是 1、2、3、5、8 的數列。那單看一個故事的點數有意義嗎？本身沒有，相對來看才有意義，在沒有 velocity 的情境下，也無法得知這個 story 要做多久。一般來說，點數可以用在 story 和 task 上，要使用點數作為單位估算，團隊必須先從過去開發的經驗中，找出一個不大不小的工作項目，訂下一個基礎點數 (3 點或 5 點)，接下來所有的估算都是依照新工作比這個基礎複雜幾倍或簡單幾倍來估算。

有一種方法是找到一個最小的工作，當作是 1 點或 0.5 點，但『最小』有時候不容易找到，且也難保未來不會有更簡單的工作項目出現。

工作數

這個單位，我個人是比較建議團隊較成熟後，團隊的 task 切割有一定的慣性，例如切割方式都很類似，大小接近，此時可以簡化成 story 點數估完後，拆解完 task ，團隊對於 task 的內容有共識後，就可以開工了，PO 與 SM 看有多少 task 就大概知道時數的分布會在哪個區間，加快 planning meeting 的進行。由於缺少時數的 burn down chart，若真的想觀察更細微的團隊進度，可以用 task burn down chart 搭配 story burn down chart 來觀察。

個人的想法是，剛開始使用 Scrum 的團隊，還是用點數估算 user story，然後以時數估算 task，至少在一開始決定要納入多少個 stories 到一個 sprint 時，有比較好的參考點，當漸漸成熟時，是可以省去 task 時數的估算，但 story 的點數還是要有，因為團隊是會持續進步的 (當然也可能是退步)，或是有人員異動，story 的消耗情況雖然是落後指標，但依舊可以觀察團隊的情況，即使有浮動或劇烈震盪，也應該要慢慢趨向一個穩定值才是夠成熟的團隊。

小結

這回讓大家了解在 Scrum 中，估算背後真正的價值是取得對需求的共識，不管是用點數還是時數，就只是個討論用的工具，最後的數字，雖然有用，但卻不是最重要的產物，真正有價值的產物是團隊把對的東西交付給客戶。下回，將介紹幾個常見在估算時要避免的事項。