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说明理由，若理由合理则不扣分。
- 遇到了非常大的坑，在群里询问以及向PM汇报之后仍未解决，可以申请延期或暂时不实现相关功能，按当前完成度给予一定分数；
- 由于个人原因（如修复bug）导致未能完成任务，获得的任务分每拖延一天乘以70%（若修复bug不影响其他工作，不扣分）；
- 对于用户发现，且未事先进行说明的bug，视严重程度给予相应开发人员扣分，此扣分和第3条相互独立，可以叠加。
用户发现bug扣分参考：
| 总扣分 | 严重程度 |
|---|---|
| 0 | 不注意就不会发现的问题，给予警告 |
| 5 | 一般功能性问题，局部影响用户使用 |
| 10 | 严重影响用户使用 |
| 20 | 相当严重的问题，甚至对接下来的开发造成影响 |
1.3 发现bug得分
发现影响用户使用的bug，第一发现者可获得5分奖励（不能是自己负责的功能）。
2. 最终贡献分
通过3中的计算方法，可以得到每名成员的得分，我们根据每名成员的得分比例分配最终的贡献分。
公式表达如下：
假设第x名成员得分为Ax
成员x贡献分 = Ax / ∑A * (6 * 50)