這是我在 .NET Conf Taiwan 2022 的演講 - 那些年用 Azure Boards 交付過的產品
以 5 個痛點來分享之前 Scurm 所遇到的問題,當時怎麼解決,
並將其整理成為文章版更難完整記錄本場的內容 

複雜度評估的兩個方式

在 Azure Boards 裡面可以安裝 Estimate 這個套件,在 Planning Meeting 的時候可以針對 User Story 進行估點計算,且這是一個線上即時的功能,即使遠端協作的團隊也可以達到很好的估點流程

image

這工具在出點的時候可以一起呈現,如果彼此點數落差大,可以進行多輪的討論,我們通常會用相對點數來讓團隊取得共識,此套件也能選擇很多範本

image

但如果你今天是有海量的需求,不想花太多時間一張一張評估,也許可以用 Affinity Estimation 這種方式,他的執行步驟是由PO解釋完單子後,將所有單子都建在看板上,透過團隊共同拖拉的方式,越左邊代表複雜度越小,越右邊越複雜,之後取中間當個分隔線,在給予不同大小的渠道。 最後一個步驟是針對鄰近的單子去比對,兩個大小是否是差不多大小,如果落差過大再微調

image

延伸閱讀: https://www.techagilist.com/agile/scrum/affinity-estimation-agile-estimation-method/

如何知道團隊成員工作量?

Planning 另外一個重點就是在 User Story 底下去拆技術細節去分工(Task),雖然估時估不準,但我會建議還是能在 Original Estimate 這個欄位讓工程師評估一下這個單子預計要花的時間,通常一天我們會以 6hr 為單位,如果 Task 評估大於 12hr,代表顆粒度太大,需要再細拆,為什麼要這樣做呢? 因為搭配 Capacity 針對每個工程師每日可貢獻的時數,可以讓我們知道每個工程師拿的量會不會過多或過少

但記得一點,不要用這個來挑戰工程師產值,敏捷強調自我管理,信任制,為了共用目標努力,太在乎每日產出只會造成工程師給錯誤的資訊

image

在 Planning 檢視每個人的工作量是否平均

image

如果你想要看完整的演講影片,現在也已經傳到 Youtube

5篇 Scurm 痛點文章