工作动态尽在掌握 - 使用 CODING 度量团队效能

本文主要是介绍工作动态尽在掌握 - 使用 CODING 度量团队效能，对大家解决编程问题具有一定的参考价值，需要的程序猿们随着小编来一起学习吧！

在敏捷研发的过程中，或者项目结束后的复盘阶段，度量并分析团队成员在周期内的工作负荷、完成的工作量与工作动态，能够让管理者清晰的认识到团队成员的工作负载与工作效率；团队成员间也可以相互查看对方所参与的项目，近期工作动态或近期事项。

效能度量的主要功能为统计团队成员在一段时间内的计划事项数、完成事项数和所编辑的 Wiki 数以供分析。这些数据将会在趋势面板上进行显示。并且还可以自行设置分组并添加其它成员，方便快速查看团队成员近期工作概览。

使用准备

团队拥有者或管理员在【团队管理】->【权限配置】中为相应的用户组的勾选「效能度量」的「查看页面」权限。勾选完成后处于该用户组的成员的工作台会出现效能度量的功能入口。

趋势面板

面板将会反映所添加成员的工作量趋势图，以三个数据维度进行展示：计划事项数、完成事项数和 Wiki 编辑数。可以选择日、周、月三种统计周期视图进行查看，通过下方的滚轮横轴进行左右拖拉日期。

计划事项数

将会统计处理人在一个时间周期内开始和截止时间所安排的事项总数，纳入统计的事项包含史诗、需求、任务、缺陷和子任务。

• 如果事项填写了开始和结束时间，那么处在这个时间周期的每一天的事项数 +1；
• 如果事项只填写了开始时间，那么开始时间所在当天事项数 +1；
• 如果事项只填写了截止时间，那么截止时间所在当天事项数 +1。

具体的计数原理请参考计划事项数计数方式。

完成事项数

将会统计处理人在固定周期内完成的事项总数。这里的完成事项定义涵盖史诗、需求、任务、缺陷和子任务。若对这些事项做出了完成操作，即状态类型从“非已完成”到“已完成”，则视该事项被定义为完成。

• 如果在时间周期内且周期结束后状态类型仍然是“已完成”，那么完成事项数 +1。

具体的计数原理请参考完成事项数计数方式。

编辑 Wiki 数

将会统计团队成员更新过的 Wiki 篇数。若在同一个周期内对同一篇文档进行修改并执行了“提交文档”，那么编辑 Wiki 数算为 1 篇。

添加成员与分组管理

在「添加成员」中可以通过成员姓名或搜索项目一键添加项目内成员，添加进图表的成员可移除。在「分组」下拉组件中可进行添加分组、删除和重命名等操作，添加的成员默认进入当前选择的分组中。分组为用户自行设置，并不会在团队内公开显示该分组，属于个性化查看功能。

成员工作概览页

在效能度量页面中点击任意成员，可进入成员的工作概览页。页面包含：

• 成员名称和头像；
• 最近活跃时间；
• 参与的项目；
• 近期事项；
• 该成员近期的工作动态。

近期事项

近期事项的统计内容包含：

• 已完成，查询近 1 个月完成的事项，按照完成时间逆序排；
• 进行中，查询状态类型为“进行中”的事项，按截止时间逆序排；
• 未开始，查询状态类型为“未开始”的事项，按截止时间逆序排。

工作动态

工作动态为成员的日常协作动态，可按分类查询，包含：

• 项目协同
• 代码仓库
• 持续集成
• 持续部署
• Wiki
• 文件网盘 ...

权限控制

该功能涉及到的权限模块名称为效能度量，具有“查看”权限。每个团队的拥有者和项目管理员将默认勾选「查看功能」权限点。

计数方式详情

计划事项数计数方式

• 如果事项填写了开始和结束时间，那么处在这个时间段里的每一天的事项数 +1；
• 如果事项只填写了开始时间，那么开始时间所在当天事项数 +1；
• 如果事项只填写了截止时间，那么截止时间所在当天事项数 +1。

例如表 1：

事项	开始时间	结束时间
事项 A	2020 年 1 月 1 日	2020 年 1 月 5 日
事项 B	2020 年 1 月 3 日	2020 年 1 月 6 日
事项 C	2020 年 1 月 4 日	未设置
事项 D	未设置	2020 年 1 月 3 日

依据表 1 的数据，该成员的计划事项统计结果如下：

日期	计划事项数	事项
2020 年 1 月 1 日	1	A
2020 年 1 月 2 日	1	A
2020 年 1 月 3 日	3	ABD
2020 年 1 月 4 日	3	ABC
2020 年 1 月 5 日	2	AB
2020 年 1 月 6 日	1	B
2020 年 1 月 7 日	0

若同一个事项的时间跨越了 2 个周期，那么将在两个周期中分别计数 +1。例如事项 A 在的开始和截止时间为 2020 年 1 月 25 日 —— 2020 年 2 月 4 日，那么事项 A 在 1 月和 2 月都被计算为 1 个事项。

完成事项数计数方式

事项在一个周期内被做了 1 次完成动作，且周期结束后状态类型为“已完成”，则完成事项数 +1。

事项反复打开和完成的计算方式

• 事项在一个周期内被完成过，但周期结束前状态类型为“已完成”，则完成事项数 +1；
• 事项在一个周期内被完成过，但周期结束前状态类型为非“已完成”，则不贡献完成事项数；
• 事项在第一个周期内被完成，直到第二个周期才被打开，且第二个周期结束前状态类型为“已完成”，则这两个周期内完成事项数分别 +1。

例如表 2，为事项 A 在 1-4 月的状态情况：

时间	状态类型	动作
2020 年 1 月 1 日	未开始	新创建
2020 年 1 月 2 日	进行中	转入处理中
2020 年 1 月 3 日	已完成	完成操作
2020 年 1 月 20 日	未开始	重新打开
2020 年 1 月 25 日	已完成	完成操作
2020 年 2 月 15 日	未开始	重新打开
2020 年 3 月 2 日	已完成	完成操作
2020 年 3 月 3 日	未开始	重新打开
2020 年 3 月 30 日	已完成	完成操作
2020 年 4 月 1 日	已完成	维持已完成
2020 年 4 月 30 日	已完成	无操作

那么事项 A 在 1-4 月被计算的完成事项数分别为：1，0，1，0。

关于 CODING，了解更多

这篇关于工作动态尽在掌握 - 使用 CODING 度量团队效能的文章就介绍到这儿，希望我们推荐的文章对大家有所帮助，也希望大家多多支持为之网！