绩效考核
敏捷开发 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和实现高并发请求,根本不是一个难度层级。
绩效考核图标 (仅供参考)
公众微信号:ProgrammerCoke
如果觉得《研发(软件 不包含硬件相关)人员绩效考核推荐》对你有帮助,请点赞、收藏,并留下你的观点哦!