敏捷开发中如何进行团队绩效管理

敏捷开发中，绩效管理是管理层非常关心的问题，而敏捷（或Scrum）中没有关于绩效的定义或做法。本文是Ken Rubin基于自己20多年的敏捷开发经验总结出来的、敏捷团队中如何进行绩效管理。

几乎我教过的每堂课或辅导过的每个组织都有下面这个问题：“我应该用什么指标来确定团队是否运行良好？”我可以理解这个问题的背景是，大多数人想问开发团队的绩效，而不是整个Scrum团队（包含产品负责人、ScrumMaster和开发团队），也不是整个组织的绩效。

有时候我也想知道开发团队做得怎么样，所以我会在本文阐述这个问题。但是，对我来说这个问题和下面两个问题几乎不相关：“作为敏捷组织我们做的怎么样？”或“Scrum团队做的怎么样？”。这些问题的答案可以使我们在经济相关性和可操作性层面有更深入的理解。在组织层面我想了解我们是否高效地交付客户期望的价值。为了理解这一点，我会采用如下指标：

无用功（Idle work） 和闲散员工（idle workers） — 衡量工作流受阻的时间和频率（而不是衡量员工有多忙）。

交付可工作和验证过的产品—如果我们交付的产品客户不用的话，那么按时及在预算内交付就没有任何意义。

作为组织我们的学习速度—采用如innovation accounting （精益创业的概念）的指标来评估我们学习的速度，该速度可以作为汇聚业务价值结果的进度指标。

在组织层面之下我会关注整个Scrum团队。3个角色一起交付正确的客户价值并快速较好的完成。所以我更喜欢下面这个指标“每个迭代Scrum团队都在交付较好的价值吗？”（more on this shortly）。但是如果我们只想衡量开发团队怎么办（以下简称“团队”）？或许我们想知道给团队分配某人是否是正确的选择。如果开发团队会长久在一起，那么我们就想知道团队的绩效。下面我推荐几个指标（排除使用开发速率）：

几乎每次团队都能完成迭代目标

产品负责人相信团队交付较好的经济价值

团队以可持续的节奏工作

团队的T型技能（一专多能）

团队的学习速度

开发速率（不建议使用这个指标）

许多人认为，开发速率是一种衡量团队绩效显而易见的方法。不幸的是，开发速率应该只是一种计划工具（如发布计划）和团队诊断指标（如流程改进工作）。速率不应该作为一个绩效指标来判断生产效率。因为速率太容易做假了。如果团队成员知道速率作为绩效指标的话，他们就会在每个迭代随意增大产品backlog条目的大小（故事点通胀），或者为了完成更多的故事而偷工减料（注：即牺牲质量或增加技术债）。在《Essential Scrum》一书中，详细描述了什么是速率，应该如何使用速率以及应用速率的误区。在本文中，我不会把速率作为团队绩效的指标。

实现迭代目标

排除了开发速率，我们应该用什么来衡量团队绩效呢？一个指标是团队以什么频率实现迭代目标。作为Scrum原则，每个迭代应该有一个目标（就像可执行的汇总说明），这个目标是团队一起承诺要实现的。每个迭代团队尽最大努力实现目标。我宁愿每个迭代团队没有完成目标，因为这可能是团队习惯性无法完成承诺的迹象。有时候，团队为了达到目标做出了相当的努力，但最终由于正当的原因（比如目标的弹性比较大）而没能完成。这个现象更好地表明了团队应该在合理的限度内进行工作。

交付价值

检查和平衡团队“虚报估算”的一种简单而恰当的方法是，咨询产品负责人是否每个迭代都能获得良好的价值。多数的迭代都是固定成本的——我们知道团队人员和迭代的时间长度都是固定的，因此每个迭代的成本也就是固定的。假设每个迭代的成本是2万美元，对产品负责人而言一个重要的问题就是，“你觉得每个迭代能至少获得2万美元的价值吗？”好的产品负责人会知道答案。如果产品负责人说，“没错，我很满意团队正在交付的价值，”那么这就是团队良好绩效的表现。再说明一点，产品负责人对迭代级别和发布级别的经济性是总体负责的。因此，如果产品负责人草率地花了2万美元，让团队只交付1万美元的价值的话，那么这个产品负责人就是不负责任。总之，交付良好价值是整个Scrum团队（产品负责人，ScrumMaster和开发团队）的责任，当评估开发团队时可以考虑这个指标。

可持续的节奏工作

我还想要知道是否每个迭代团队都能以可持续地节奏交付良好的价值。我们都见过为了交付迭代目标而一周工作80小时的情况。对于这个情况的第一个反应可能是，“看看，多么棒的团队，他们为了完成工作愿意加班！” 常常一个迭代中为了完成目标，工作更长时间切更努力一点是必须的。因为总是有一些难以预料的事情。然而，人们不能长时间以这种节奏工作，所以一周工作80小时的团队不会长久的成为“优秀团队”，很快他们就变成“疲惫不堪的团队”了。因此，第三个衡量高绩效团队的指标是，每个迭代都以可持续的节奏交付良好的价值。

扩展T型技能

另一个高绩效团队的指标是：“团队成员有没有更进一步扩展T型技能？”T型技能职这样一个比喻，用来描述一个人在专业领域有深入的垂直技能，同时其它相关领域拥有广泛的（没必要那么深入）水平技能。由T型技能的人组成的团队更不易受到工作变化的影响，因为可能多个团队成员都可以工作在该领域上，所以在有大量工作时团队可以蜂拥式的集中工作。我认为团队成员的T型技能是团队健康和高效能的重要指标。

快速频繁地学习能力

最后，需要评估团队的学习能力。尤其是，我想评估团队完成学习循环的能力：假设、构建、反馈、检视和调整。高效能团队总是快速验证重要的假设，并根据结果而采取行动。高效能团队以最大化学习重要细节能力的方式组织工作，因此他们可以根据学习进行调整。考虑到快速而频繁学习的重要性，我会在组织层面和团队层面都采用这个指标。快速学习重要信息并尽最大的努力工作，超越那些学习慢的团队，就像团队那样，学习最快的组织常常痛击他们的对手。

总结

总结一下，当衡量绩效的时候，首先考虑的是较高层面如组织、Scrum团队级别的。当评估开发团队的时候，不要采用速率。相反，考虑之前我提到的一套多维的指标会获得团队绩效的全面情况。最后一点意见。以我的经验，组织里好的经理实际上不需要任何官方团队绩效的指标。这样的经理和团队保持紧密联系，细心观察发生的一切。咨询一个好的经理关于团队绩效，包含强项和弱点，这个经理都会马上给出全面的答案。

摘自PM圈子网(www.pmleader.cn)一个集项目管理、敏捷开发、产品管理、DevOps的综合智库，是IT互联网、从事项目工作的经理人、技术人员的学习充电之地。