對azure?devops此工具的功能深挖，結合jira的使用經驗的分析

1、在backlog的功能描述，可理解為需求項，這里包括了bug，從開發的角度修復bug也是個工作項，所以需求的范圍是真正的需求（開發接收到的已經確認的需求），

可是這不是項目管理的需求，而且bug是怎么引入的也沒有明確來源，所以這個角度的局限性就體現出來了，從開發管理的角度，這個是沒有問題的。這屬于開發能自主確認迭代范圍的模式。

2、sprint 的功能描述，是迭代，其實就是把backlog的內容分散到不同的sprint中，每個沖刺有自己的計劃開始和結束，就是迭代周期。這里也沒有考慮測試，只是從開發角度去完成工作。

從管理的角度，每一次開發提交的代碼，后續都有一個SIT測試的過程，測試過程會發現bug，所以開發還要修復，這并不是真正的開發結束，而是從任務分配的角度，開發的計劃任務完成。

3、sprint下的任務拆解，可理解成開發團隊人員分配任務，非常典型的敏捷團隊方式，

分析：團隊人員不多，任務項不多，不復雜，sprint下面直接就是WBS結構中的底層任務，需要明確人，計劃開始和結束日期，計劃工作量。

4、容量的概念。是針對團隊成員設定每個人的日常工作量，從容量圖表的角度來統計剩余工時，

從管理角度，工作量和工期是兩個概念，而對于上班這件事，需要設定每天的工時標準，就是一天7小時，還是8小時。確定這個的標準，就是要體現加班工作量，人員飽和度，還有從整體工作量的角度去衡量生產力，目的不是考核，是為了工作量估算，需要一個平均值，加buff的方式，去定計劃，對管理的人是一個非常有效的數據。只不過原來這些數據在某個資深的管理人員腦子里。現在需要量化在管理工具上體現，那么就要體現平均值。

度量數據采集是一個需要過程，然后可以計算平局值，平均工作量。

這個圖上活動類型，我理解就是具體任務分類，如果按照這個維度，是可以采集各種不同任務的工作量的，計劃工作量，實際工作量就有了，偏差的分析就有了。

上圖是微軟給的官方手冊的示例，這個就能能看到容量的作用，看到不同的任務類型，不同人員的剩余工時，在容量方面的設計，也能體現一個人在多個團隊，需要給每個團隊設定這個人的容量，來計算在這個團隊的剩余容量。

在容量角度的設計，能體現如何統計工時的思路

會持續更新 2024-2-29