讓 Scrum 團隊有更好的預估之三
圖片來源：www.freepik.com
在上回讓 Scrum 團隊有更好的預估之二提到一些應該要避免的措施，以及時時梳理 product backlog 讓團隊有較好的估算，這回則是作為一位 scrum master，我們該如何自省與發現估算的問題，也是以自我反省的方式完結這個系列。
其實從每天的 daily scrum meeting 就能觀察出預估與實際執行的落差，但即使出現落差，先別急討論預估的問題，這比較適合在每次 sprint 結尾的的自省會議中討論，自省會議 PO 可以參加，但如果要討論對預估的調整，我個人比較建議 PO 不參加自省，通常 PO (特別是兼主管職時) 參加會讓團隊不說話或是口頭上應付。討論時，scrum master 可以將該 sprint 的 story 與 task 的 burn down chart 作為會議討論的參考素材，也比較不會失焦。通常兩張圖擺在一起看可以看到三種類型：
Type 1 - 火力分散
在頭幾次的執行上，我個人的觀察是比較容易出現像下圖，團隊拼命地做自己擅長的事情，當一個 story 自己擅長的事做完後，就趕緊將下個 story 拉到進行中的狀態 (如果有累積圖的話更能印證)，繼續做自己擅長的事情。因此，時數的消化很正常 (紅色折線)，也貼近目標線 (黑色虛線)，但真正完成的 story 很少 (藍色折線)，此時檢討的重點恐怕不是預估的品質好不好，因為火力過度分散，導致團隊真正的效率還沒出現，所以，要先讓團隊能集中火力 (Stop starting, start finishing) 將已經開始的 story 盡量完成，讓 story 的 burn down 能持續下降。
Type 2 - 過度承諾
當線圖已經有比較順的下降，但到 sprint 結束時，總是有些 story 無法完成甚至還沒開始，如下圖一樣，這時候團隊就可能是過度承諾的狀態，這只是可能，story 無法完成的原因很多，像是中途改變了些需求，為了因應這些變動，團隊花了較多的時間導致無法處理別的 stories，或是遇到當初沒預期到的技術困難，這就是軟體專案上的變異性，光是技術困難這一件事就很難預期，例如：當初覺得 A 這個第三套件能完成 B 工作，但沒想到會影響系統，光是解決因第三套件引起的問題，就花了很多時間 survey，這通常是無法預期的。
因此，遇到下圖的情況，恐怕要 case by case 請團隊找出原因，而不是一開始就討論下次是否要少安排一點 stories，像是剛剛所說的第三方套件引起問題，那改進方向可能可以是下次在 refinement 後若有要使用不確定的技術，可以跟 PO 協調安插 prior study 的 story，在受控制的環境中實驗新技術；或是，太晚與 PO 確認完成的 story 導致 review 前一天才發現某個地方做錯了，那可能的改進方向就更不一樣了。
當其他原因都排除了，就可以重新檢視這次排入的 stories 數量與點數，未完成的 stories 點數，然後訂出下個 sprint 的 stories 點數上限，並在下次的 planning meeting 嚴格執行，否則團隊會覺得自省是玩假的：明明都做不完了，還是要我們吃下去。
Type 3 - 過度保守
可能有人覺得怎麼可能出現下圖？在 sprint 的一半時間就做完所有預估的事情？但事實上我擔任 scrum master 期間遇到過，而且不只一次，當出現下圖時，偶而出現是還好，畢竟團隊如果沒有一些盈餘時間，是無法學習新技術與改善團隊的。此時，scrum master 可以讓開發團隊與 PO 討論是否要再拉新的 stories 進來，或是用剩餘的時間處理技術債，又或是研究接下來可能用到的新技術，不論是哪種，都要與 PO 討論，確保真正重要的事被優先執行。
但如果這現象是頻繁地出現，可能就是一個團隊過度保守的信號，在估點與估時的時候，數字帶有過多的 buffer，雖然說 PO 依舊可以在 sprint 期間加入新的 stories，但會讓本來穩定的 velocity 貶值，表面上 velocity 數字好像變大了，但其實整體來看完成的功能並沒有變多，此時，可能要決定是讓 velocity 續貶 (讓每個 sprint 能納入的 story 點數繼續增加)，或是修正基礎點維持 velocity 的相對穩定 (從已完成的 story 中挑選一個作為新的比較基準)，也可以跟團隊檢討，如何能有比較不虛胖的點數出現。當然，這也可能是團隊開發速度提升的信號，所以 scrum master 要小心應對，不然會讓本來開始進步的火苗又被澆熄了。
小心 mini-waterfall
Scrum 框架其實很簡單，卻是易學難精，若沒有理解藏在背後的 agile 精神，就容易變成只是依樣畫葫蘆卻沒有得到好處，例如，為了有『精確的』預估，為了有『漂亮的』的 burn down chart，一個 refinement meeting 開整整一天 (若是兩周為一個 sprint，一般是建議 refinement 不要超過 4 小時)，把所有的設計細節全部寫下來，卻忘記當初使用 user story 的初衷是一個 placeholder 讓大家看到時，能用說故事的方式讓別人了解為什麼需要這功能，以及要完成什麼功能，怎麼完成是到 planning 及施工時，讓團隊發揮的，一次 planning meeting 要一天甚至兩天 (一樣，若是兩周為一個 sprint，planning meeting 也不建議超過 4 小時)，task 切到小到不行，但卻又互相依賴，變成一次要領好幾個 task，這時恐怕是走火入魔，忘記當初這兩個會議的本意了。
總結
從上面看下來，怎麼覺得開發團隊好像小朋友似的，都要 scrum master 像保母一樣照顧，但如果 scrum master 或 PO 真的像保母一樣帶團隊，那團隊就真的永遠是小朋友了，要讓一個團隊成長，要像對待成年人一樣，放手讓團隊走自己的路，上述很多觀察或是方法，能讓團隊發自內心提出來是最好的，甚至讓團隊想出更好的辦法，這時靠的是引導而不是教導 ，更不是指示，scrum master 要能從團隊的表現與現象觀察出問題，但切記別揠苗助長，適當地授權，團隊慢慢就能自我組織，自己解決問題。
