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

圖片來源：www.freepik.com

在上回讓 Scrum 團隊有更好的預估之一討論 Scrum 對於估算的精神與常見的估算單位，這回就來討論一些應該避免的事項，讓團隊能有更好的估算，下回則是過去的自省與感想。

要讓團隊有較高品質的估算，agile coach 或 scrum master 可以觀察一些徵兆，若有發現盡早排除，免得讓團隊成員有壞習慣或是對估算這件事有陰影。

避免團隊成為橡皮章

首先，不論點數和時數都應該是由實際執行的團隊評估，PO 與 SM 都不要有建議，像是對團隊的數字說：『會不會估太少或估太多？』 (雖然，很多人都說遇到的 PO 大多是後者，但不管哪一種都不好)。最重要的是，不到非用不可的地步，PO 不要說：『不管怎樣，這些 stories 在這個 sprint 一定要做完。』這句話的殺傷力很大，因為就算團隊估算完後做不完也無法把 story 吐出來，會讓團隊之後更加不願意估算。而且為了趕上，犧牲掉的通常就是品質 (刪除某些細節的規格或是省略掉一些例外的處理)，或堆積更多的技術債。但切記，對團隊信任度的傷害卻已經造成了。

就過去的經驗和參加其他活動聽到的經驗，很多的 dead line，都不是真的 dead line，通常是壓著說一定要做完，等到 sprint 最後一天，PO 看著牆面然後就冒出新的 dead line，或是當團隊勉強完成了，卻發現遲遲沒有真的上線，團隊才知道客戶根本沒這麼急著要。但 dead line 是一定會有的，像是奧運一定是在某一天開幕，作為支援的系統，勢必要在那一天之前上線，但如果真走到這一步，加班是避免不掉的，只是這應該是所有 agile 方法都在極力避免的 (透過減少未完成品的數量)。

避免換算

若同時使用點數與時數，要注意一點：點數與時數之間不一定有必然的關係，有可能某個 1 點的 story 切完 task 後估算結果是 8 小時，另一個 1 點的 story 估算後是 6 小時，這都是可以的。像剛剛我提到不大不小的 story，到底怎樣的 story 算是不大不小呢？我刻意避開像這樣的形容詞：『一人能在一天內完成的』story，原因就是避免讓團隊又落入以時間換算點數的情況，這樣就失去相對大小比較的好處了。

當排入 spring backlog，且 task 已經切好，也估完時數後，story 的點數雖然還是有一些統計上的意義，但沒那麼重要，因此不用拘泥於點數與實際的時數對不起來的問題，還特地回去修改點數或是調整時數，因為本來就沒有對應關係。當每個 spring 消化的點數趨於穩定，代表團隊的開發速度穩定，product owner是 是可以參考 velocity 大略估算時程，但這也不是絕對的時程。

即使事後統計發現有關係，也不需要拿出來跟團隊說，以後 1 點就是 5 小時，這會讓團隊在估算時礙手礙腳，一直在計算彼此之間的換算，或是讓團隊先估時數再回去推算點數。

避免僵局

若方法正確的話 (除了 planning poker 外，也可以參考 團隊估算遊戲)，點數在估算上比較少會出現僵局，但 task 的時數就比較容易出現僵局，本來估點與估時的重點是釐清問題和尋找共識，但因為是以『如果是自己做這個 task 要花多少時間』就容易出現 senior 和 junior 就經驗上和能力上的不同有不同的數字，通常 junior 會比較擔心若在預估的時間內做不完，會不會讓自己的考績變差，因此會堅持較大的時數。此時也許可以考慮連 task 都用點數估算，所有的東西都是看相對的，這樣就可以排除不同人做同一件事時間不同，造成估算上的爭執。當全都以點數估算時，daily stand up meeting 就很重要了，因為那是團隊能知道實際還要多少時數的機會，這時就以真正做事情的人進行估算還需要多少時間，因為已經開始做了，這時候通常比較有把握，因此比較沒有爭議。

一般來說，我說的是一般，但還是有些人本身很在意數字。團隊的氛圍通常是避免僵局最容易的方法，若對於多估 (實際執行時數比預估時數少) 或是少估 (實際執行時數比預估時數多)，團隊能有開放性的檢討與改進，而不是批評或是做為考績的參考時，團隊也就比較不會對於數字斤斤計較，讓估時陷入僵局。

避免懼怕承諾

剛開始導入 Scrum 進行估時，通常都是估不準的，要不是過於樂觀就是過於悲觀，這都是正常現象，通常，團隊大概需要幾次的估算後才會趨於穩定，有點像下圖 (只是舉例，可能像任何數值)，一開始沒經驗，因此承諾較多的點數 (40)，但最後沒有完成， 於是下個 sprint 就曾諾較少的點數 (10)，後來可能提前做完，因此又在下個 sprint 承諾較多的點數 (33)，這震盪現象會持續一陣子，最後趨於一個穩定值 (大約20)。

所以在自省時 (稍後會說如何看過度悲觀或過度樂觀) 也不需要過度反應，非要團隊想出一個辦法或是要團隊在下次一定要估的很準，特別是承諾的 stories 沒有做完時 (這裡排除做錯被退的情況，單看因估計錯誤造成的沒做完)，過度的反應有時會有反效果，像是花更多時間預估 (造成會議時間拉長)、數字灌水 (讓統計失真)、在估算時討論過多細節 (請參考後面的 mini-waterfall) 或是懼於給承諾。

在 TCP 網路協定中有個 Reno (Slow Start) 規則，當出現速度等異常時，傳送方會將傳送速度降到一半，然後慢慢再往上增加速度，當出現預估過度樂觀時，也許可以建議團隊先降低一個 sprint 能納入的 story 點數，當在 sprint 中提前做完，可以再添入 story 或是處理技術債，並在下次的評估中增加點數的上限，反覆幾次也能找到一個穩定值。

時時梳理

先前有提到，預估有一個重點是：團隊透過估點的方式釐清問題，看是否有不清楚的部分，因此若真要說一個 user story 本身點數有什麼意義的話，當點數很大時，例如：13、20，通常代表的是團隊根本不知道這個 story 要做什麼？或是太過複雜，應該再更進一步切小。一般來說 product backlog 中，高優先度的 story 點數應該都比低優先度的 story 要小，不然就應該安排 refinement meeting 將高優先度但點數仍然很大的 story 進行 refine，refinement 的重點也不是在切割，切割只是釐清問題後的結果，不是必然的過程。若團隊將一個不大不小的 story 點數是以5點來計算時，當進入 planning meeting 的 stories 點數都介在 1 ~ 8之間，時數估算的結果通常也會比較穩定。

切小還有一個好處是讓 PO 或 stackholder 有機會挑選真正最重要的功能來開發，agile 的 12 個原則中的一個是『將未完成的工作量最大化』，這一點看起來很矛盾，但這是因為一個軟體中，通常大部分的功能是使用者沒在用的，就算開發完成也只是浪費，同樣，一個需求，當初可能規畫得很完整，但切成小 story 後，可以根據時程與各項條件，把某些較不重要的 story 優先度調降，專注在更重要的 story 上，若擔心只有一個 product backlog 無法看到需求的全貌 (那些 stories 完成了，那些還沒)，可以考慮 user story mapping 協助追蹤整個全貌。

小結

透過時時梳理讓 product backlog 保持在有足夠細節的狀態，讓團隊在預估時就比較容易達成共識，避免團隊成為橡皮章、避免換算、避免僵局與避免懼怕承諾措施，讓團隊更有信心說出內心的想法，如此才是團隊的共識，而不是某某人說的算，這種沒有根據的假設了。