对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