Beta阶段团队成员贡献分分配规则

Beta阶段团队成员贡献分分配规则

Alpha阶段贡献分分配有些负责，在这里进行一些修改：
对任务完成得分部分进行了简化
对发现bug的惩罚措施进行了修改
移除了优化得分，不鼓励修改他人代码
移除了帮助加成，剔除主观因素

1. 得分细则

1.1 任务完成得分

L=预期任务量（1~8）：在布置任务的时候预计所需时间，不再更改
D=难度（0.0~2.0）：由于难度产生的时间变数，由之前会议商讨决定，遇到坑的时候及时在群里求助，可以更改
下面是难度系数（D）的评定参考：

评价成绩	效果
0.5	基本没有技能需求，不需要太多思考
1.0	需要一些技能基础，难度适中，或需要较大思考
1.5	坑很多，解决费了不少时间，需要较强的问题解决能力
2.0	小组成员里其他人做不到，只有老司机才能驾驭

E=完成度（0.0~2.0，默认为1.0）：1为正常，有缺陷适当扣除，有亮点适当增加，根据后期补全情况可以更改

下面是完成度（E）的评定参考：

评价成绩	效果
0.8	基本完成功能，但是很简陋，部分细节未能达到预期要求
1.0	完成得一般，要求的功能都实现了，但是还有优化的空间
1.2	完美完成，无可挑剔

最终的得分要根据完成度、预期任务量和难度三方面评定，即

任务完成得分 = E * L * (1 + D) * 5

举例：
A君接了一个任务量为6，难度系数为1的任务，但是在实际编码中发现这里面的坑比想象中的要大许多，经过和PM商议，将难度系数调整为1.5。
由于要赶在DDL之前提交任务，做得比较仓促，虽然要求确实都满足了，但是还欠缺完美，完成度为1.0，那么A君的最终得分为：

1.0 * 6 * (1 + 1.5) * 5 = 75

1.2 任务遇到问题：

注：任务延期需要向PM说明理由，若理由合理则不扣分。

1. 遇到了非常大的坑，在群里询问以及向PM汇报之后仍未解决，可以申请延期或暂时不实现相关功能，按当前完成度给予一定分数；
2. 由于个人原因（如修复bug）导致未能完成任务，获得的任务分每拖延一天乘以70%（若修复bug不影响其他工作，不扣分）；
3. 对于用户发现，且未事先进行说明的bug，视严重程度给予相应开发人员扣分，此扣分和第3条相互独立，可以叠加。
   用户发现bug扣分参考：

总扣分	严重程度
0	不注意就不会发现的问题，给予警告
5	一般功能性问题，局部影响用户使用
10	严重影响用户使用
20	相当严重的问题，甚至对接下来的开发造成影响

1.3 发现bug得分

发现影响用户使用的bug，第一发现者可获得5分奖励（不能是自己负责的功能）。

2. 最终贡献分

通过3中的计算方法，可以得到每名成员的得分，我们根据每名成员的得分比例分配最终的贡献分。
公式表达如下：

假设第x名成员得分为Ax
成员x贡献分 = Ax / ∑A * (6 * 50)

转载于:https://www.cnblogs.com/hotcode5/p/7924279.html