Scrum之团队绩效评估

Scrum Guide对团队的描述如下：
Scrum 团队
Scrum团队由产品负责人、开发团队和 Scrum Master 组成。Scrum团队是跨职能的自
组织团队。自组织团队自己选择如何最好地完成工作，而不是由团队外的人指导。跨职能
团队拥有完成工作所需要的全部技能，不需要依赖团队以外的人。这种团队模式的目的是
最大限度地优化灵活度、创造力和生产效率。
Scrum团队迭代增量式地交付产品，最大化获得反馈的机会。增量式地交付“完成”
的产品保证了可工作产品的潜在可用版本总是存在。

开发团队有以下几个特点：
 他们是自组织的，没有人（即使是 Scrum Master都不可以）告诉开发团队如何把
产品待办事项列表变成潜在可发布的功能。
 开发团队是跨职能的，团队作为一个整体，拥有开发产品增量所需要的全部技
能。
 Scrum 不认可开发团队成员的头衔，无论承担哪种工作他们都叫做开发人员。此
规则无一例外。
 Scrum 不认可开发团队中的所谓“子团队”，无论是测试还是业务分析的成员都
不能划分为“子团队”。此规则无一例外。
 开发团队中的每个成员可以有特长和专注领域，但是责任属于整个开发团队。

敏捷强调团队的团队精神和自组织性。

基于人类的天性，都会很自然的选择偷偷懒、磨磨洋工。本人在央企、外企都待过，现在在私企。从实际情况来看确实也是这样的情况，我了解到的企业，对IT员工的的激励措施有点吃大锅饭的意思，或者纯粹凭老板一句话的去进行激励。这样就导致想干活、多干活的员工没有得到应有的回报，自然没有动力。最终的结果要么就是被同化，呆在公司大家一起优哉游哉；或者就找更好的公司、平台跳槽。

怎么解决这样的问题？

首先：我们承认人类的天性的存在，不能期望每位成员都能够自发的，不计利益的投入到项目中。

第二：我们认识到不同的的成员在技能水平、职业素养上存在差异，有效产出、生产率是不一样的，对应所得的利益和激励应该也要不一样，这样才公平

第三：我们认识到类似于制造业，软件开发过程的工作量也是可以度量和评估的。

有了以上的共识，那么我们可以参考《科学管理原理》来实行团队的绩效评估。具体的实行办法如下：

1、绩效评估的范围：只对个人收入的绩效部分进行评估，在目前大环境下，IT员工还是只能实行高工资，低绩效的方式，否则可能人员招聘上会有很大的麻烦。

2、采用计时的方式进行绩效评估。（计时、计件现在应该是制造业的基本方法）

3、工作量的评估，在Scrum计划会议的时候采用扑克牌的方式，开发团队和Scrum Master一起投票确定。投票过程采用求大同、存小异、取平均的方式。计划会议过程采用：讲解需求->提问与解释->匿名出牌->讨论->重新出牌->达到近似一致->采取平均的流程，确保大家都理解功能点的业务需求、处理方式。如果投票出现大的差异，比如说(9/1/1/1)的情况，那么需要再讲解需求、讨论。直到近似一直。最后取平均。

4、工作任务的认领。我们认识到就算大家一起投票评估出来的工作量，也还是存在有些偏高、有些偏低的情况。**为了确保公平，工作任务的认领严格按照顺序、循环自愿认领。**A今天第一个选择任务，那么明天就只能是最后一个来认领任务，以此循环。

5、绩效评估的统计及公布。每个Sprint迭代结束时候的反思会公布统计排名结果。邮件发送给全体成员，并记录到项目的总的绩效统计中。在项目奖的分配上严格按照工作量的统计结果计算。每个Sprint及时公布统计排名结果非常重要。在《门后的秘密》中提到：

在事件发生后，第一时间给出反馈意见。等到年终考核才给出反馈意见起不到任何作用。即使等到季度考核，也是无济于事。

经过一个项目的实施，好得方面，总结一下：
1、项目抱怨的人减少了，团队气氛好转

2、项目最后收尾的时候没有出现因为某一个功能的delay导致整个项目无法交付的情况。

3、项目进程中没有疯狂的加班，基本正常上下班，除了scrum master承担的压力大一点，工作稍微多一点。

不好的方面，也总结一下：

1、原先效率低、产出低的成员，还是效率低，但是产出略有提高

2、出现过一下难度稍大的功能，没人主动认领，需要通过scrum master干预。