失眠网 > 研发（软件不包含硬件相关）人员绩效考核推荐

研发（软件不包含硬件相关）人员绩效考核推荐

时间：2022-08-08 11:11:57

绩效考核

敏捷开发 Agile定制化敏捷开发流程优缺点绩效考核图标（仅供参考）

敏捷开发 Agile

定制化敏捷开发流程

敏捷开发一般迭代的周期为2周，在迭代的周期内会有1-N个User Story，每个User Story会包含许许多多Task，每个User Story会有一个Owner和一个Director。给大家画个结构图比较好理解

User Story用户故事: 需要实现某种需求，某种用户场景，功能

a)Plan Point：估算完成这个用户故事所需要的时间，一般1point = 1 人/天。可以因人而异

b)Task: 完成US所需要做的步骤，用来细化开发过程（一般包含：Analysis，Implement，Peer Review, Local Test, Functional Test, Deploy）

i.Owner拥有者：这个Task是属于开发还是测试

ii.Estimate Time预计完成时间：第一次定下来就不允许修改，可以判断这个Task所有者对于Task评估是否准确， Actual Time越接近Estimate Time越好

iii.Actual Time实际完成时间: 每天累加更新，记录在此Task上所花费的时间

iv.Rest Time剩余完成时间: 预估还有多少时间能完成任务，方便管理者和拥有者进行时间上的安排。

c)US Owner用户故事的拥有者：负责此用户故事的编写，也负责解答开发过程中所存在的疑点。开发完成时由US Owner进行验收

d)Director实现者：负责此用户故事的实现，一般由前/后端开发担任，当QA完成测试时，负责通知US Owner来验收每个迭代周期内Plan Point的数量，一般根据开发人员数量定死，不进行任何改动。时间线：

a) 第一周周一上午：进行计划会议。会议讨论User Story内容，团队对于Plan Point估值，分配User Story。

b) 第一周周一下午：每个人根据分配的User Story进行Task的创建。每个人所有task的Estimate Time总和理论上等于US Plan Point * 计划每天工作量（6-8小时，推荐小于8小时，其他时间用于开会、发送邮件交流等）

c) 第一周周五：进行发展会议。对于开发过程中遇到的问题进行公开讨论、寻求非团队内部帮助，如因为X的影响导致Y用户故事的Plan Point要增加。

d) 第二周周三：进行第二次发展会议。重复上次内容。

e) 第二周周五下午：理论上所有用户故事的所有者完成验收，总结此次迭代中发现的问题，如何改进，也可以表扬赞美团队成员（商业互吹）。敲定下个迭代周期的用户故事。

优缺点

其中Plan Point是一个非常适合作为绩效考核的指标，Point是由团队所有研发人员共同讨论制定的。Point多的US自然就相对困难。统计每个人一年的US完成数量，可以大致知道这个人的工作量。软件发布后，所有的Defect/Bug理论上都是可以追溯到具体哪个US的，因此US完成量 / Bug数量可以作为代码质量的参考

缺陷：只能判断一个大概，毕竟一个新人完成大量的CRUD相关的US，他得到的point远超一个DevOps/Hybris专家。这种情况也容易发生。每个US的难易程度无法辨别，实现CRUD和实现高并发请求，根本不是一个难度层级。