敏捷团队如何进行绩效评估？

每年我们都痴迷于为团队成员评级。回顾软件开发领域，好像已经有近50年历史，有一些我们可以肯定的是：软件是由团队来创建的，而不是个人的。此外，每个人都需要积极主动的合作来生产有质量的软件，这意味着团队中的每个人来承担集体所有制，并且相互帮助。因为他的主旨并不是成为一名英雄，而是创建一个超高质量和可预测的最终产品。多亏了敏捷，我们每天都在这么做，并且产生好的软件。但我们也在逐渐培养为团队成员评级的恶习。而这恰好是与敏捷背道而驰的。（详见“在scrum中按个人绩效来分组”）。众所周知，将两个人和两个团队的工作相比是非常愚蠢的——但我们还是这样做了。个人绩效评估是实事，目前scrum仍然支持跨职能，跨管理团队的主义，个人间相互帮助来完成任务，提供价值。完成用户故事的所有权不在于个人，而是一个完整，团结的团队。

这个与评估过程相矛盾，因为他几乎总是以个人表现为中心，不可避免的是，使用scrum的团队必须围绕个人的表现而量化及产生矩阵的数量，这就产生了以下的问题：

当我们完成它的时候，能否向任何个人贡献sprint（或者用户故事）的良好成绩？

我们如何量化以及如何考虑大多数开发有时相互帮助来完成一个任务或者用户故事这一事实？

我们如何鼓励团队成员无私的相互提供帮助？

总而言之，我们是否可以衡量个人的速率？

这里有一些方法可以用来处理它：

用速率来衡量个人绩效。我们是否可以找到开发的速率，告诉我们他/她在一年内所完成的工作。就我们所知，速率是指一个团队在特定的sprint中完成的量，他可以因团队而异。想成为团队中的每个人找出它很困难，并非不可能，因为用户故事是由团队完成，而不是个人完成的。所以速率是对团队而言的，我们也只能这样。

为每个人制定一个任务矩阵。 我们可以来跟踪个人完成的任务，或者找出他/她的用户故事的完成百分比。如果我们知道这个，那在团队中谁的产量最多也将很容易知道。但不幸的是（或许也是幸运的是），个人在做任务时相互帮助。所以因此某人完成了较多的任务并不意味他/她在工作上更好。

用为团队评级来代替为个人评级。要是我们为团队评级以及对他们进行评估他们，而非针对个人的，那会怎样？现在的问题简化到如何比较两个团队。重申一下，速度和加速度在这里不是我们的朋友。只有当我们可以衡量相当的用户故事以及团队如何处理他们时，比较团队才是可行的，而在同一组织中，要给出不同的分歧是有难度的。

用敏捷来解决他。目前它是评估个人最实际的方法。让我们大概记一下人们如何通过敏捷的方法来处理这个过程。

1.为个人决定目标。这个目标需要集中在个人上——例如，他/她如何实现这些目标，并且让软件产物变得更好？当我们制定每个目标时，我们需要为它定义一个清楚的验收测试，以及演示目标是不是满足预期。让我们以为产品进行自动化验收测试制定目标为例。如果有60%完成了，那我们说目标被实现了；如果有60%~80%的内容被实现了，那我们说这个人已经超过了预期；如果有80%~100%的内容被实现了，那这个人远远超过了预期。值得注意的是，乍一看，像是个人目标，但他需要合作，所以每个人都会将面临，或者没有人会面临。因此对于每一位开发来说，它是一位好的竞争者。

2.为个人创建一份评估待办列表，包括每个目标以及目标验收准则。及时捕捉如何以及为什么这些目标在这个意义程度上会失败。

3.这个待办列表的PO应该是个人的导师。他/她会在这个阶段为目标划分优先权。

4.现在导师需要向不同的目标分配故事点数。例如，上面讨论的验收测试目标可以分配到11点中的8点，那他就需要相当一部分的努力（工作量）。

5.在和个人进行适当的讨论后，导师是可以随意的向个人目标待办列表中随意的增加更多的目标。

6.导师和个人需要定义一个sprint的长度，在这之后他们将评审产品待办列表以及做演示。许多组织已经这个样，并且每月进行一到两次的会议。不同的是，我们需要设定目标，为其设定清晰的验收条件，并对其评分。举个例子，在一个月后举行的自动化测试验收评审会上，大家发现只完成了百分之五十的自动化脚本。那么这个时候，导师应该和团队成员聊聊，看看之前定的目标是不是太难达到，还是他们在这个过程中遇到了什么阻碍，或者说这个目标对他们来说是根本不肯能的任务。导师应该作为驱动者，帮助团队成员到达或者修正目标，在这个过程中，可以降低目标的权重以及放宽验收标准来使目标更容易达到。当然，随着难度的降低，得到的奖励也相应地应该减少。

7.接下去，sprint的待办列表将会在这个sprint的产出物中衍生出来。如果个人没有达到5个故事点，那么在下一个sprint中，他不会给一个8个故事点的目标。他将会给一个5点或者少于5点的目标。这个会从根本上帮助他/她的全面发展。

8.在演示中，顺利完成验收测试并且使目标合格。此外，你可以有选择性的准则来超过或者远超目标（注意当我们在第一步中讨论目标的时候我们决定了自动化的百分比范围）。

9.在最终的绩效评审中，他可以看下目标矩阵以及合格的验收准则。这个矩阵应该捕捉每个迭代，每个月的信息。

10.就像我们在更早的方法中看到的一样，将一个项目和另一个项目相比非常困哪。同理可见，比较两位员工对产品特性的贡献是不现实的。分析的过程应该是以目标集为基础的，并且这些目标集所包含的目标不应该是基于同一个sprint的。

11.计算一下达到的目标数，超过预期的目标数，以及远超预期的目标数。然后这个矩阵可以在透明的方法下计算绩效评级。

Scrum是困难的，而且通过他我们使估算过程变得更复杂更繁重。然而如果有必要的使用以及适应这个过程将会注意到在评估过程中遇到的许多问题。就像Scrum的其他方面中一样，导师、PO有很大的作用，因为我们使他们成为个人绩效的决策人。虽然使用敏捷应该将这些目标和业务及变化保持一致以及现实，因此我们应该给予个人现实的机会去提升以及衡量他们的年度绩效。

总而言之，我们承认当业务发生变更时，绩效目标必须也随之发生相应变化。让估算目标周期变的灵活互动，以及可适应的，会使产出物更有可预测性——真的使过程变得更加敏捷。