标签：页面 多个 测试的 建立 购物 部分 bug 相互 开发效率
武老师这周又布置新作业啦，作业的内容如下：
为了培养大家的团队协作能力，建立大家的协作意识，同时本着自主性的原则，我们在第一次课就要求大家自由分组，每个组4到6人，共同完成每周的实践作业。那么，小组内不同的成员擅长的事情不一样，各自的个人发展计划也千差万别，那么，如何科学的分配团队成员对小组作业的贡献分呢？既不能委屈了劳苦功高的同伴，也不能扔下心有余而力不足的队友，让他们去打酱油啊……
这是个很有意义的问题，因为团队最终的输出是一个整体，无论是在学校还是在工作中，必然需要一种量化的指标对团队每个成员的工作贡献进行考核，以决定各个成员的利益分配。我曾在某通信公司实习过，当时该公司正全面推行敏捷开发，其中最重要的一项工作就是对成员的贡献进行评分。利用这次作业的机会，我将尝试分析各常见贡献分计算法的利弊，并且分享我所了解的在实际工作中比较高效的评分办法。
避免对成员的贡献进行主观评价
在武老师给我们的参考博客中(https://edu.cnblogs.com/campus/buaa/BUAA_SE_2017/homework/1117），我参考了几个学生团队给出的计算贡献分的方式，在团队贡献分的计算中，我认为大部分的团队犯了一个错误，就是将所谓“积极性”纳入了考评指标。对于无法量化的主观指标，我们不应该将其放入团队贡献分中。其实，作为一个团队，我们计算贡献分的根本出发点应该是提高团队的开发效率。那么，请问什么叫积极性？同样的工作，一个很厉害的编程大牛，他可能三个小时就完成了，而一个技术相对弱一点的应届生，可能要加班加点工作十多个小时。是不是就说明，该应届生的积极性比大牛高呢？显然，这是有失公允的。一旦把积极性纳入考评指标，就等于变相鼓励加班，鼓励在团队工作中“说废话”“刷存在感”，这是不利于提升团队效率的。
类似的，诸如“相互帮助（如何量化？）”、“提出建设性意见（建设性和非建设性的标准是什么？）”和“主动承担难度大的任务（太笼统）”这些指标都是应该避免的。取而代之的，应该是一些具体的量化标准，如“提交一个bug加一分”，“提前完成项目加一分”等。
规则要简单有效率
再次强调一下，在我看来，作为一个团队，我们计算贡献分的根本出发点应该是提高团队的开发效率。根据奥卡姆剃刀定律，规则过于复杂，反而会降低开发的效率。部分团队给出了一个极为复杂的贡献分计算公式，这除了看起来叼以外，对开发人员效率的提升几乎毫无帮助。计算贡献分，应该是着眼于开发上，和开发无关的事情，请不要放入贡献分的计算规则之中。
一个典型的贡献分计算方式
接下来，我将分享我实习的公司所用到的计算贡献分的方式，在我看来，这样的方式是极为合理的。
步骤一：拆分项目为子任务
假设武老师为我们布置了一个做一个购物网站前端的任务，我们在经过广泛讨论之后，将其拆分为多个子任务，如任务A，开发购物车页面；任务B，开发交易页面；任务C，开发物流展示页面等等。
步骤二：每个成员对子任务打分
每个成员需要为任务的工作量进行评测，单位是 /人/周。比如，对于任务A，开发一个购物车页面，团队成员分别打分为2个单位，3个单位，4个单位，2个单位，4个单位，那么，求得的平均工作量就是三个单位。
步骤三：认领任务并计算贡献值
每个子任务的工作量列出，由团队成员自行认领。没人选的任务提高分值，抢着选的任务降低分值。最终使得任务全部分配。作为一个团队成员，想得分高就选难的任务，想轻松点就选简单的，丰俭由人，相当高效。
局限
我在一开始提到了，这是敏捷开发中所采用的贡献分计算方法。为什么要强调这个呢？对于一个传统的开发团队，既有开发人员，也有管理人员，还有专职的测试人员，大家的分工不同，这种方法根本无法实现。哪怕搞管理的分数再高，做测试的也选不了呀！但在敏捷开发的一些具体实践中，开发团队岗位的界限被打破了，开发人员也会做测试，测试人员也得参与开发，因此这种评分办法得以实施。
标签：页面 多个 测试的 建立 购物 部分 bug 相互 开发效率
原文地址：http://www.cnblogs.com/hust-no-bug/p/7857651.html
