上一课时整体介绍了什么样的指标是好指标以及如何寻找好的度量指标。从这课时开始，我们从具体的指标来入手，介绍度量指标对不同方面的影响。

我们都知道，软件开发是团队成员完成的，团队成员的能力在一定程度上代表了软件的交付能力。相信在你的周围也有过这样的团队：只要有一位技术大牛，交付软件的质量和效率就非常高。技术大牛以一顶十的技术水平带动了软件业的不断发展。我们熟悉的 Linux 和 Git 的创始人，大神 Linus 就是很好的例子。本课我们就来一起学习，如何度量团队能力？

团队的 T 型人才观

我记得上学时学习过韩愈的《师说》，《师说》里讲道：“闻道有先后，术业有专攻”。“术业有专攻”的意思是每个人在技能和学术上都有各自的研究方向。当我们参加工作后，大多也都是职能型组织，每个部门都有各个领域方向的专业人员，比如 DBA、网络管理员、存储管理员、前端工程师、大数据工程师等。然而，当人员过于专业化时，就会形成筒仓。在进行软件研发活动时，需要在不同部门之间进行多次沟通和交接，当没有空闲时还需要排队，这就导致了交付时间的推迟。

为了解决这个问题，一种常见的对策就是让每一位团队成员都成为通才，也就是现在经常提到的全栈工程师。如下表所示。

全栈工程师比专业人才可以做更多的工作，同时因为减少了等待时间，从而提高了整体的交付效率。在企业里可以通过交叉培训的方式，为工程师提供学习的机会，并定期让他们在不同的职位间进行轮岗，来提高相关的技能。

跨团队协作的问题相信很多人都遇到过，特别是像 DevOps 这种跨团队协作的岗位。在最近的工作中，也遇到了类似的问题，使得对团队中需要有全栈工程师的理解更加深刻了。目前我从事的工作是基于 OpenStack 的私有云产品持续部署流水线的建设。不同于上层应用程序的部署，私有云的部署是需要从操作系统开始安装，还会涉及改交换机的网卡，规划网络的 Vlan 范围，规划分布式存储的存储池等，这些都需要非常底层的专业知识，哪怕一个小问题都会影响整个云的部署和业务的可用性。

在搭建部署流水线的过程中，遇到过非常多的底层问题，当遇到问题时只能求助基础设施团队的专业同事，但其他团队的同事也会因为有正在处理的工作不能及时帮助解决，导致无法继续，部署工作一再延误。

从自己的亲身经历也能很好的说明，团队中的全栈工程师对团队的整体交付非常重要。

团队的技能图谱

在上面提到团队需要的是 T 型人才。想要 T 型人才团队就需要掌握团队成员在技能上的熟练程度，并对薄弱环节的人员进行有针对性的培训。我们可以采用技能图谱的方式呈现团队当前在各个技术方面的能力状态。如下表所示。

在图谱中，每个团队成员在每项技能上都有一个分值，它代表了该成员对该项技能的熟练程度。最高分 10 分，最低分 0 分，分值越高表示越精通。根据团队的技能图谱，可以了解团队成员的优势在哪里，弱势在哪里。团队成员由此可以根据自己的兴趣和项目的需要，制定自己在图谱上的提升计划。上图中的数据真实反映目前 DevOps 团队的技能水平。由于都不是做云出身，底层网络、交换机以及 OpenStack 是我们团队的薄弱环节。因此我们可以有针对性的培训和学习这几个技能，成员不需要达到精通的程度，当在部署整个私有云的时候，遇到问题能够排查，满足部署流水线的需求就可以了。

技能图谱制定完成后，团队需要对其进行定期更新，比如，每隔 2-3 个月团队成员要更新自己的技能评估，并制定下一步的提升计划。

如何度量团队的交付能力

在实际开发过程中，领导层想知道团队一周能开发多少个需求？如果有一个比较紧急的项目，应该交给哪个团队比较合适？这些都需要通过具体的指标来度量团队的能力。但是，度量团队的研发效能并不是件容易的事情，有以下几个原因。

& 研发过程可视化差：软件研发过程并不像制造业生产过程，是具体的、可见的。我们很难准确的定义一个需求开发完成具体需要多长时间，因为这和具体执行者的技能水平有很大关系。也很难定义每个团队每个迭代的具体产出，这跟需求的大小以及需求的难易有关系。研发过程可视化在之前的看板方法中有所涉及，就是要将研发过程中的事项以可视化的方式展示出来，便于掌握团队的工作情况。

& 工作切分的随意性：软件研发的工作事项没有统一的标准。需求可大可小，有的需要一周，有的需要一天，有的甚至一小时即可完成。有的已经知道具体的解决方案，有的可能是一个新的课题，需要时间调研、实验才能知道解决方案。

这些现实的问题增加了度量团队研发效能的难度，使得度量的指标不准确，不具有指导意义。

度量团队效能的误区

在实际工作中，使用指标度量团队的效能存在几个误区。这样的度量有两个不足：

& 侧重产出而不是结果。

& 侧重个人或局部的度量，而不是团队或全局的度量。

其中常见的有“代码行数”、“故事点数”这些经常被误使用的指标。

1. 代码行数。

使用代码行数来度量团队的交付效能这种方式在很多企业中依然存在。在一些公司甚至要求统计开发人员每天、每周的代码提交量，以此作为团队工作饱和度的评判依据。这样会使得开发人员为了增加代码行数，在完成代码逻辑时尽可能地多写代码，导致软件变得越来越臃肿，使得代码维护成本更高。 同样，也不能用最小代码行来作为衡量标准，这样会导致代码足够精简而增加了理解的难度。

因此，代码行数不应该作为度量效能的指标，最有效的代码应该是能够解决业务问题的。

2. 故事点数

在敏捷软件开发方法中，将需求拆分成故事，用故事点数来估计每个故事的大小，以此表示预期完成这些故事需要的工作量。 在有些团队中，也会根据故事点数来衡量团队能够交付的工作量大小，或者推断团队完成一个需求需要多长时间。使用故事点来作为评判团队交付效能会使得团队成员只关注那些故事点数多的任务，或者过多的评估故事点数。

因此，故事点数也不应该作为度量效能的指标，只是计划产能的度量，不是真实生产效率的度量。

度量团队效能的指标

那么什么样的指标是度量团队效能的有效指标呢，这类指标应该具备两个关键特征：

& 应该专注全局结果，以确保团队之间不会相互竞争。比如：奖励开发人员的高吞吐量以及运维团队的系统稳定性。这是开发和运维之间有一道墙的关键因素，即开发为了提高吞吐量将质量差的代码提交给运维进行部署，而运维为了保证系统的稳定性通过复杂烦琐的变更流程来抑制产品发布。

& 应该关注结果而不是产出。在企业里，领导经常会说“我只看结果不看过程”，也是这个道理。很多人以“没有功劳也有苦劳”作为跟领导辩驳的理由或许收效甚微。没有为企业创造价值的付出都是徒劳的。

下面介绍一下有哪些可以度量团队效能的指标，这里参考权威的全球 DevOps 现状报告中的内容。

《2018 全球 DevOps 现状报告》中引入了“软件交付效能”这个概念，并将不同的团队划分为精英、高效能、中等效能和低效能四种级别。为了度量团队的交付效能，采用了 5 个软件交付效能的度量指标，用来展示软件交付的 3 个方面。如下图所示：

部署频率：是指团队将应用程序部署到生产环境频率的度量。根据报告指出精英组织会按需部署，并且每天都会部署多次。相比之下，低效能组织一周或一个月部署一次。

前置时间：是指从代码提交，到代码成功运行，到生产环境的时间。精英组织的变更前置时间一般不到一个小时，而低效能组织则需要 1 到 6 个月的前置时间。

恢复时间：是指服务故障到服务恢复所需要的时间，也就是经常说的 MTTR。精英组织服务恢复时间一般在 1 小时以内，而低效能组织则需要 1 周到 1 个月之间。

变更失败率：是指应用程序部署到生产环境后需要回滚的百分比。精英组织的变更失败率一般在 0% 到 15% 之间，而低效能组织则在 46% 到 60% 之间。

可用性：是指团队确保软件产品或服务可用的能力，可以通过 SLA 度量。精英组织和高效能具有卓越的可用性，一般是低效能组织的 3.5 倍。

从以上可以看出，最优秀的精英组织总是能在吞吐量和稳定性上同时达到高绩效水平，而不是在两者之间取舍。在精英组织中，通过将任务尽可能地自动化，来将团队成员从低价值的任务中解放出来，从而从事那些可增加真正价值的创新型工作。在任何行业里，团队的效能都是驱动组织业务发展的关键因素，最终实现组织的商业目标。

总结

本课时主要介绍了如何度量团队效能这一关键因素。首先介绍了团队的 T 型人才观，说明在团队里，全栈工程师在提高团队效能方面更加重要。这里并不是说，在招聘的时候只招聘全栈工程师，而是建议通过企业培训的机制让团队成员快速了解其他领域的知识。这里采用了技能图谱的方式了解团队成员的技能水平并制定提升计划，以此加强团队成员的技能提升，打造全栈工程师精英团队。

在度量团队效能方面，避免采用像代码行数、故事点数这种面向过程、局部的度量指标，而是采用像部署频率、前置时间、恢复时间、变更失败率和可用性这些面向结果的、全局性指标。