如何衡量敏捷团队绩效？

敏捷教练和顾问们经常告诉他们的客户：传统的度量指标，诸如收益价值、工作小时数、代码行数，以及代码测试覆盖率等都不能与敏捷项目很好地吻合。那么，

- 什么是好的敏捷度量指标？

- 如何有效衡量敏捷团队的绩效？

关于这个问题的讨论有很多，相关的书籍也有好几本。比较常见的度量参数有 - 故事点，速率，趋势，质量，客户满意度，价值等等。指导性的理论也深入人心 – 度量标准不可固定不变，要观察具体阶段和实际情况勤于调整。

你可能还听过很多名声在外的敏捷型公司，用OKR取代KPI.

然而，在项目的实际应用中，以上这些真的有助于客观公平的体现团队的绩效，并且促进敏捷方法的实施么？

作为一个敏捷教练，有幸接触很多团队，积累了大量的观察样本，观察的结果就是 – 这些度量在很多时候是然并卵，并不比传统度量更加有效。

我们举几个常见的敏捷度量参数的例子，来看一下他们理论上的优势，以及在现实操作中是怎么变得然并卵的。

1：衡量完成的故事点(或功能点)，速率或价值。

用"完成的故事点数"或者"速率"来取代"工作小时数"或"代码行数"无疑是个进步。因为前者相比后者更加关注团队在单位时间内完成了多少有价值的功能点，而不是单纯堆砌代码。

实际项目中可以有很多方式来提升每个迭代交付的故事点。比如提升团队的技能水平，团队成员之间更多合作，采用新的工作方法和工具，提高生产效率。很多人认为度量故事点和跟踪速率曲线能促进团队关注这些因素。

但是还有一种最简单的，见效特别快的，不需要动脑思考就可以达到同样效果的方法 – 加班。

2：工作质量

工作质量不管是在传统项目中和敏捷项目中，都是必不可少的衡量条件。与质量相关的参数最直接的就是bug数量。提升质量也有很多方法，比如提升研发测试人员的专业技能， 制定编码和测试规范，增加自动化测试和回归测试的覆盖率，使用更先进的监控检测工具。

当然，还有一种最简单的，见效特别快的，不需要动脑就可以达到同样效果的方法 – 加班多测试，加班修bug。

3：任务完成周期(Cycle time)

我本人是特别喜欢用这个参数衡量自己或者团队的进步的。一件事情即使做的很熟了，有了这个参数，会鼓励你去想，有没有什么办法做的更快一点？批处理？自动化？ 如何把原来需要2天完成的工作缩短到1天？

当然那种最简单的，见效特别快的，不需要动脑就可以达到的方法也适用 – 加班。

自细想一想， 客户满意度， 发布频率，等等等等其他的度量指标，没有什么是加班不能做到的。

如果不能做到，就加更多的班。

总加班，团队满意度会下降。 引入团队满意度作为指标如何？

一个能选择挥动鞭子不停加班的捷径来达到指标的公司， 团队成员的满意度即使引入了，也会被放在一个非常靠后的位置。

其余的参数，例如度量学习，成长，改进幅度等等， 虽然重要，但都是很难量化的指标，而且会受各方的主观看法影响，不能形成具有普遍说服意义的结果。

关于度量，有个著名的说法，叫度量什么，得到什么。这句话只有一半，另一半是 -只是不一定是用你期待的方式得到。

Why？为什么会出现这种情况？

因为绩效考核都包含短期目标。

因为绩效考核与团队利益相关。

不管是功能点， 还是客户满意度，还是任务完成周期，KPI或者OKR里面要求的目标，都是工作导致的结果，并非工作的过程。而无论敏捷方法，还是其他项目管理方法，还是加班，都是在工作过程中发生的事情。 他们就像达到同一个目标的不同路径。

那么『敏捷』和『加班』的路径有什么不同呢？

采用敏捷方法来达到目标，需要投入时间成本，学习成本，实践成本，并且最终对结果能促进多少增长是模糊的。

而加班只需要投入时间成本，增长也是确定的—用加班"人/小时"就可以轻松预估出来。

长期来看，采用敏捷方法类似于给土地施有机肥，见效慢但是长期来看对土地会越来越肥，并且将来会长出更健康的，美味的植物。

而加班类似于给土地施速效化肥，土地很快会失去营养，板结。短时间内植物虽然长的快，个头大，但是口味差。

土地就是你的团队， 植物就是你团队的产品。

这是一个简单的选择题，长远利益 VS 短期利益。

但是一旦引入绩效指标考核，选择的天平就会严重的倾斜。

因为不管绩效考核什么， 它有短期目标，常见的考核有月度，季度，半年，一年。而绩效考核又与团队利益相关联。所以团队要在考核之前达到甚至超过指标，就会倾向于选择可能性更高的，更加容易预计产出的路线，这个前提下，加班明显比敏捷更有优势。恰恰上面列举的常见”敏捷绩效指标”又都可以通过加班来达到，两个因素叠加，于是…你懂啦

我听到过无数个团队跟我抱怨，敏捷就是加班。其实并不是。只是在考核指标+短期时间的压力下，团队不自觉的选择了加班这条更容易走，更确定的路线而已。你选择加班来达到目标那一刻，已经没有在践行敏捷了。

那么到底有没有合适的度量参数和方法，保证团队是践行敏捷方法获得成长，并且让组织从团队成长中受益呢？

度量结果前，先度量投入。

想着"既要，又要，还要的"，是没断奶的娃。成年人都知道，要回报，就要先投入。

作为敏捷教练，我常听到一句话，叫『度量什么，得到什么』。

举个例子，度量代码行数，就得到一行行代码，但是是否有足够价值，这个很难说。 但是如果转而度量功能点，就能在每个迭代都得到完整的功能点，意味着迭代末尾获得价值，意味着可以邀请客户进行使用和反馈。听起来不错。验证了”度量什么得到什么”。

同样，将质量纳入绩效考核体系， 团队就会关注质量。将客户满意度纳入考核，团队就会关注客户满意度。 精力放在哪儿，哪儿就能得到提升。所以似乎”度量什么就得到什么”是个非常正确的词汇。给人一种错觉---只要设计出合理的KPI 或者OKR 考核目标， 就能够”得到”想要的结果。

如果你读过本系列的上一篇文章：”如何衡量团队绩效”就知道，你可以通过调整目标(KPI或者OKR)来获得你想要提升的部分，但是可能并不是以你想要的方式。

你可以要求质量，但是要牺牲交付速率。你可以要求缩短任务周期，但是又可能牺牲测试覆盖率。 你可以既要求质量，又要求缩短任务周期，那么就换来疯狂加班，短时间达到目标，但是长期来看换来的是团队满意度下降和离职率的上升。

原因很简单，没有新的投入前提下，你的团队的人数，技能水平是固定的。它就像一块固定大小的资源。某些指标占用更多的资源，那么势必其他部分占的资源就会少。要想"既要….又要….还要"， 就需要增大这块资源。

增大这块资源有两个方法 ：

1：加班。

2：团队综合水平的提高。

(增加人力不在此讨论。且单纯增加人力未必能增大团队资源池)

加班不可持续，长期加班弊大于利。但是对于第二条，从上面的例子可以看出，度量什么就得到什么，那么没被度量的就肯定会受到损失。单纯调整KPI或者是OKR，本身是一个零和游戏，不能帮助增大资源池。

『度量什么，得到什么』是定理，还是骗局？

让『团队』这块资源增长，唯一的手段就是增加投资。

举个例子，我国政府，每次开会讨论第几个五年计划，除了规定增长目标之外，也会同时声明要配合多少投资，在哪些领域投资。

大到治理国家，小到公司创业，再小到维护身边人际关系，都是先付出再收获的。就算是理个财，也要先把钱放在银行里，存一段时间。

要通过引入一个新的工作方法获得好处，那么除了关心能获得什么好处，也要搞清楚，我要做出怎样的投资？

不管谁决定要引入敏捷方法，或者任何一种工作方法，首先要做的，就是把自己端正的摆在一个投资人的位置上，度量好自己的投资。

很多KPI和OKR之所以对拉动增长起不到效果，主要原因就是设计它的度量参数时，都只关注了结果。

而能够产生有效的结果，必须先有相应的投资。 所以，

敏捷项目考核第一条：从度量投资开始。

端正态度之后，摆在投资人桌上的，有下面几个问题：

投资方向是哪儿

需要支付哪些成本

需要投多少？

如何做风险控制

我们逐个来看一下，这几个问题

一

投资方向

放着好好的日子不过，为什么要折腾投资？ 当然是为了获得更大的利益。

在所有行业中，只有两种增加利益的办法：

A. 业务增长。

B. 成本降低。

不管你是创业团队，还是大公司内部的子单元。都逃不开这两种模式。

业务增长就好比 "我面前有个很大的蛋糕， 我现在只能吃一小块，只要我能力提升了， 我就能吃下更多" 。

节省成本就好比"我的蛋糕是固定大小的，短时间内也不会有所增长，我要考虑花更小的力气吃掉它。"

这两者的不同，决定你引入什么样的敏捷方法。以及你未来的考核大方向 – 是度量增长，还是度量节省。

歪个楼：有种抱怨说"敏捷导致裁员"。没错，如果团队或者部门蛋糕大小是固定的话，降低成本就是趋势。采用高效的工作方法，配合裁员是一种可行的选择。敏捷在这个过程里只是工具，不是原因。

投资方向清楚了。下一个摆在投资人面前的问题就是

一

需要付出哪些成本

只要引入新的工作方法，不管是敏捷还是其它，都会涉及到以下几个成本：

学习成本– 为学习新的工作方法引入的培训，购买学习材料，请教练，请有经验的人分享等等。

实践成本– 在实践新方法的时候，有可能因为不熟练而犯错，造成损失。 有时候需要重复实践多次，影响产出效率，短时间内团队产能下降。

时间成本(效率成本)：熟练掌握一门新工作方法，要通过学习和实践，学习和实践是需要时间的，所以你打算从每天8小时的工作里，拿出多少时间来作为投入？

其他成本：白板，文具采购，团队建设花费等等等等。

实际项目中，很多投资人优先投入”学习成本”和”其他成本”。这两个成本容易投入，而且风险低， 但是不可度量，收益也低。相反”实践成本”和”时间成本”投入难度大，但是后来带来的收益也高。

敏捷项目考核第二条：度量投资的条目能带来的收益。高收益伴随高投入和高风险是客观事实。

了解了投资的方向，需要支付的成本类别，下一个问题自然而然就是：

一

投资人该投入多少？

我们先来看看下图-投入收益曲线

从"需要支付哪些成本"来分析，投资会在短时间内牺牲团队的生产率。如图的阴影部分面积所示，就是投资人需要牺牲的生产率，也就是投资规模。

能投多少，风险偏好怎样，真的是因人而异。每个投资人都有不同的答案。 每个团队需要多少投入，才能看到产出，也是因团队而异，没有统一答案。

但是有几条指导原则是可以用上的：

一：期待高收获，就要有高投入，承担高风险。

二：投资必须达到一定量，且有持续性，才能有所收获。蜻蜓点水式的投资，或者是时断时续的投资，连个水花都看不到。

三：如果不熟悉你即将投资引入的工作方法，请专家来一起做这个投资。比如要投资引入敏捷方法，请个敏捷教练来一起做投入分析。

在考虑投多少的时候，问自己下面两个问题也会有所帮助：

1：在见到收益前，我能忍受多长时间？

2：如果注定会牺牲团队生产率，我能忍受的最低生产率是多少？

昨天有位比较有经验的管理人员，看到我上篇文章之后提起，根据他的经验，这个投入时间，最少是要半年起步。

那么问题来了：团队能不能是自己的投资人？答案是不能。

团队不能决定上面所说的投什么和投多少。间接引出一个歪楼来：敏捷不是团队自己的事情。任何把敏捷实施任务扔给团队的做法，注定不会取得大的收益，因为投资规模受限。

一

如何做风险控制？

投资当然有风险。引入敏捷方法也是一样。 要想得到或者超出预期结果，投资人提前做好风险控制很重要。

最大的风险莫过于回报为0。引入敏捷工作方法，也要有这个觉悟。在这个觉悟的基础上，我们谈谈怎么避免风险。

风控手段一：

我们在上一节”投多少”里提到了两个问题：

1：在见到受益前，我能忍受多长时间？

2：如果注定会牺牲团队生产率，我能容忍的最低生产率是多少？

这两个问题也是投资人的风控底线，也就是止损线。 如果超越了底线，就应该止损离场了。

预先搞明白上面两个问题，能帮助投资人量化 "我是否还要继续敏捷" 这个问题。

风控手段二：与团队干系人(Stakeholder)对”投入阶段”达成统一认知，取得利益相关者(stakeholder)的理解和支持。并且与干洗人对于投入阶段的投资规模，承担的风险和期待的收益取得共识。

风控手段三：在投入阶段，引入手段保证客户利益不受损。

任何时候不要因为引入新的工作方法而牺牲客户利益。很多敏捷转型变成疯狂加班，或者因为客户压力不得不停止，就是因为事先没有考虑"敏捷投入阶段"，对客户可能产生的影响。 所以在打算投资的时候，你就要想好应对的办法，在团队生产效率降低的情况下，如何能保证客户利益不受损？是否有其他团队可以临时借过来分担生产效率的损失？干系人可不可以提供一些支持？在这个问题上要寻求广泛的意见和帮助。

为什么要做这些风控？ 因为一旦你开始投资敏捷方法， 不管中间被客户压力打乱，还是被强势的干系人(Stakeholder)打乱，团队的工作节奏和士气可能会有损，而且已经发生的投资，也要打水漂。不管是团队，还是已经发生的投资，都妥妥的是『投资人』的资产，它们都是投资人的切身利益。合格的投资人，当然要考虑和提前制定风控措施。

『度量什么，得到什么』并不是一个骗局。前提是建立真正有效的度量。 KPI和OKR，还有开头提到的故事点等度量，都只是度量的某些方面，并不全面。引入『投资度量』才能预计风险和收益，做出更加合理的行动。并且一旦投资失败，投资人也能更清楚的知道失败的原因有哪些方面，为下一次投资做改进。

提起度量，就是考核，就是对比，就是数字游戏，就是你好我坏你上我下。但是，事物都具有两面性，度量既可以让人们在一条窄道上拼个你死我活，也提供了弯道超车的捷径。

这个方式分为三个步骤：

明确度量目标是什么(What)

度量通往度量目标的路径(Path)

构建组合度量参数，同时度量What 和Path，取代单一参数度量。

我们来逐个看一下，这三步的技术细节

明确度量什么【What】

找出"度量什么"是度量的第一步。这个"度量物"可以是价值，客户满意度，可以是公司设定的KPI，人/天，代码行数，质量，故事点。 什么对体现团队绩效重要，就考核什么。或者干系人，客户看重什么，就考核什么 --- 把他们关心的数据增长放在他们案头。Measure what matters ，就是这么简单。

有人觉得度量什么很重要， 但是我目前觉得这反而是比较不重要的一步。或者说，在现实情况中， 度量什么往往是不能自主选择的。况且全世界的老板和客户真正关心什么，一共也就那么几项，十个手指头都数的过来。但是，” 通往"度量物"的路径”(Path)却是可以选择，而且能起很大作用的，也是接下来我们重点要度量的。

通往度量目标的路径【Path】

有一种度量，叫做『我不关心过程！我只关心结果！』

如果是这种方式的话，只需要明确”度量什么”然后找根鞭子握在手里就好了。之所以所有的度量都有可能导向加班，就是因为度量指标都是结果(What)， 导致无论是度量的人，还是被度量的人，都只聚焦在达成结果上, 过程上一团糟。

这方式要是真好用而且没有副作用，绩效考核也不会是一个世界性难题了。

而度量的重要意义在于，不仅仅是要达到结果，还是要推动以期待的方式达到结果。

比如说要求生产率提高50%。 如何做到呢？可用的方式有：加班；增加人手；减少与提高生产率无关的工作；在工作估算的环节玩数字游戏； 提高技术人员的工作能力；减少生产过程中的浪费。

你希望以哪种工作方式来达成目标，就应该在度量的时候，加入对这种工作方式的度量。

所以一个有效的度量，应该是同时包含：

"目标度量"(度量What)：度量是否朝着既定目标前进

和

"路径度量"(度量Path)：度量是否沿着选定的路径前进。

要度量Path，就要先找到Path。

我们拿 "交付质量" 这个常见的开发团队度量物举个例子。交付质量是"What"，那么怎么搞清楚有多少路径，和团队要选择哪条路径呢？ 我在做教练的时候，经常用下面三个问题跟团队一起找出答案：

1：对团队的工作来讲，”好的交付质量”的定义是什么？

2：有哪些方式，能够帮我们达到或超过”好的交付质量”？

3： 结合当前团队的情况，我希望优先采取哪些方式？

我们来逐个看一下这几个问题：

1：对团队的工作来讲，”好的交付质量”的定义是什么？

“好的交付质量”定义，是度量目标(What)的一部分。大多数情况下是来自于客户，或者公司干系人的定义。或者是KPI里规定的bug数量， bug修复速度，可能是优异的性能，也可能是几者的综合。必要时我们还会请干系人予以澄清 – 质量对他们来讲意味着什么。

好的考核目标要有一定的清晰度，提供足够的信息指导工作。 不能是”提升质量”，”提升客户满意度”这种模糊的描述。

基于一个清晰的考核目标，我们就可以讨论和选择达到目标的路径， 并且下一步建立度量路径机制。

2：有哪些方式，能够帮我们达到或超过”好的交付质量”？

我希望团队和团队的管理人员，在讨论这个问题时将所有可能的路径都列出来。而不是直接列出他们想要走的路径。

一个测试团队，可能会给出如下答案：

A．  反复测试

B．  增加测试人员

C．  增加自动化测试的覆盖率，节省不必要的手工测试。

D．  提高测试人员对业务逻辑的熟悉水平。

E．  ………

列出所有路径除了能帮助拓宽视野外， 还能帮助做出最佳决策。你会发现每条路径都有好处，也需要支付成本。

"反复测试"好处是实施简单，需要支付时间成本. "增加测试人员"好处是能投入测试的人数增加，需要支付额外的人力成本，培训成本，以及新成员加入的风险成本。增加自动化测试覆盖率的好处是用技术节省时间。需要支付的成本是写更多自动化测试用例的成本。

3: 结合当前团队的情况，我希望优先采取哪些方式？

这时，我们就要引入上一篇文章中提到的”成本度量”方法，选出对团队而言性价比最高的路径

不同的团队，面对同一个考核目标(What)的时候，他们选择的路径(Path)可能是完全不一样的。 甚至同一个团队在不同时期，对于同一个目标，选择的Path也是不一样的。

当你的度量体系里既关注What又关注Path的时候，有趣的事情就会发生了： 即使全公司使用统一的KPI目标，考核同样的内容，你仍然可以通过度量不同的Path，引导具体某个团队根据自己的切身需要去发展。这样的考核体系既可以覆盖公司的大目标，又可以兼顾具体团队的差异。

* 我们花了很大的篇幅来搞清楚度量物体What 和Path。这恰恰是大部分度量里缺乏的。也是大量的考核最后沦为数字扯皮游戏的最根本原因。

到此为止，我们就搞定了度量的目标(What)和要度量的路径(Path)。那么，你期待的干货就要来了：

使用组合参数度量取代单一度量

当确定了达到绩效考核的目标(What)，和我们即将采取的路径(Path)后，我们需要为路径(Path)来制定一系列度量参数，保证我们是走在正确的路径上。

我们还是以质量考核作为一个例子，假如我们的KPI是"生产环境报告的Bug数量每个月保持在10个以下"。

在以前的"关注结果式"考核下，可能会产出下面这样的报告。

几乎所有”只考核结果”的考核都会出现这种check list式的跟踪报表。考核单一数字，只能得到单一数字。

假设经过第二步，我们想采用到达目标的路径是 "增加自动化测试覆盖率， 减少手动测试占用测试人员的时间。"

那么这个考核就不仅仅包含"bug数量保持在10以下" 这一条了，它会扩展为类似于下面的列表：

-每月的Bug数量 (度量目标)

-自动化测试覆盖率的增长（度量路径）

-自动化测试帮助测试人员节省的时间（度量路径）

-测试人员单位时间内完成的bug数量。(度量路径)

-其他…..

上面这个列表是一个参数组合。包含”目标度量参数”和”路径度量参数”。目标度量参数保证你关注目标，路径度量参数保证你在之前选择的路径上。

路径度量参数组合的时候，应该挑选一些该路径上的独有特征。比如” 测试覆盖率的增长”就算一个独特的特征，它是”反复测试”或者”增加测试人员”这些路径做不到的。

所有的参数组合起来，作为一个结果评审，而不是checklist式的逐个评审。

度量参数组合，它会产出类似以下的报表：

从这张报表上，除了能够读出我们将bug限制在规定数目之外，还能反映出以下数据：

当自动化测试覆盖率超过一定百分比后，继续保持它的增长， 对降低bug数量，和测试人员工作效率的提高起到的作用有限。这就是度量过程的意义，让你”看见”过程里发生了什么。

那么问题来了，【看见】有神马用？？

通过看见，我们能知道以下问题的答案：

增加自动化测试覆盖率是否能够帮助完成KPI？

答案：能

我们的自动化测试，做的够好了麽？

答案：做的是不是够好，不重要，重要的是够了，图中可以看出，超过60%以后，覆盖率的继续增长对于控制bug数量和提高测试人员生产力的贡献不大。

下一步应该怎么办？

答案：应该保持自动化测试覆盖率在当前水平， 并且尝试其他路径继续提升质量。

综上所述，通过对过程的度量，让我们可以清晰的了解现状，做出未来的决策，或者提供有力的证据帮助公司和客户做决策。

再举个例子，如果你想通过引入敏捷方法中控制WIP来提高生产效率，加速交付速度，一样可以制定类似的组合度量参数，它可能类似于：

-每个月(迭代)交付的功能点数(度量目标)

-每天WIP的数量(度量路径)

-每个功能点的cycle time(度量路径)。

常常有人问，WIP多少算合适？那么通过度量上面的组合， 当你发现过了某一点之后， WIP的继续减少不能对迭代交付的功能点数的增长，和Cycle time的减少有帮助时， 那个WIP就是合适你团队的WIP。

同样的你还可以通过设置其他的组合度量参数，来了解『user story 多小合适』，『是否还要继续推行某敏捷实践』等等因团队而异，没有统一答案的东西。

相比单纯的度量结果，这种度量结果+过程的式能带来的好处有：

既照顾了公司的整体目标，又能考虑到团队之间的差异，提供个性化考核。

可以帮助清晰的了解现状，而不是对现状停留在”感觉”的状态 并且基于分析，形成对未来的洞见。

帮助追踪路径的工作方法的的有效性。 不至于盲目的推行某种工作方法；或者过度驱动某种工作方式；辅助做决策。

有人可能觉得，度量就是为了提供一个标准，比优劣，定赏罚，度量就是竞争。如果抱着这样的想法，恐怕看完这三篇文章，会觉得，这家伙说了很多，但是并没有什么实际用处。最后的结果就是行成了个洞见，还是比较不出好坏来。

确实是这样的。因为我对度量的理解并不是比较的手段，而是【看见】的手段。相比传统的"只对结果进行度量"的方式， 这种度量"结果+过程"的方式，能让我看见三个事情：

看见到底是哪些工作方法（Path）在起作用.

看见这些方法在起什么样的作用.

看见我们什么时候应该停止对某种方法的投入，转而尝试新的方法。

而且这种【看见】是基于客观数据积累的，并不是基于【感觉】，它有更高的准确性和更强大的说服力。

自己能够【看见】,并且帮助组织和客户【看见】，就实现了自身价值的提升，并为公司或客户提供了更大的价值。从而获取更高层次的认可和收获。在激烈的竞争中做到弯道超车。

度量，可以用来提升自己的价值，为客户带来更多价值。也可以用来跟周围的人论短长，玩数字游戏，互相竞争，互相添堵。

最后我们总结一下使用（度量+过程）组合参数的过程：

1：明确度量目标。

2：通过度量成本，选择要采用的过程，也就是方法。

3：构建组合度量参数：

填入第一类参数 - 度量目标

填入第二类参数 – 选择过程里的一些独有特征参数，作为确认过程发生的方法

4：持续追踪，生成报表。密切观察第二类参数对第一类参数的作用，形成洞见。