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

閱讀時間約 7 分鐘
圖片來源:www.freepik.com

圖片來源: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)。

raw-image

所以在自省時 (稍後會說如何看過度悲觀或過度樂觀) 也不需要過度反應,非要團隊想出一個辦法或是要團隊在下次一定要估的很準,特別是承諾的 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 保持在有足夠細節的狀態,讓團隊在預估時就比較容易達成共識,避免團隊成為橡皮章、避免換算、避免僵局與避免懼怕承諾措施,讓團隊更有信心說出內心的想法,如此才是團隊的共識,而不是某某人說的算,這種沒有根據的假設了。

52會員
102內容數
這是從 Medium 開始的一個專題,主要是想用輕鬆閒談的方式,分享這幾年軟體開發的心得,原本比較侷限於軟體架構,但這幾年的文章不僅限於架構,也聊不少流程相關的心得,所以趁換平台,順勢換成閒談軟體設計。
留言0
查看全部
發表第一個留言支持創作者!