有敏捷教练说他们在做研发效能，有DevOps教练说他们在做研发效能，有项目经理说他们也在做研发效能，但是细问之后得知，他们做的和以前做的没区别，就是换了个名字。那么到底什么是研发效能？如果新建一个研发效能团队，所做的事情，和上诉团队之前的工作有什么区别呢？

研发效能到底是什么？

直接抛出答案，研发效能提升就是在度量体系下，通过可持续的方案，提高投入产出比，主要是提高人均交付、提高交付质量、提高平均成本交付、提高交付能力。

• 度量体系是说，要做一项改进，需要提前分析出该改进是否有必要做，不能盲目的堆最佳实践，否则就是浪费（这里也体现出精益思想），做完后，度量出效果，以证明该改进有效/无效。
• 人均交付：同样的人，交付的量更多了。
• 平均成本交付：对于组织来说，能让较初级的人做出更高质量更高效率的工作，使得组织不必花更多的钱去聘用很贵的人，是有必要的。同时该能力也说明我们做的某些事情，使得工作传承的成本降低，相应的瓶颈也降低了。
• 交付质量：除了传统的高质量以外，我把做对需求也放在这里了。某些理论是把它单独拿出去的，不过我认为，做对需求本身就是质量内建的一部分，也是最重要的。如果需求没做对，还验收什么。
• 提交交付能力：交付能力有时暂时不会提现到该项目的交付效率、质量里，比如变更前置时间等，但是对于组织来说，该能力的提升是强壮了肌肉，为未来的效率、质量提升提供了保障。

那么回过来说，和上诉提到的敏捷、DevOps有什么关系？

现在各流派都在泛化自己的范围，都讲端到端交付，所以才有了敏捷的一部分人说，DevOps被包含在其之内。反之，DevOps的一些人也说，他们关注的是从需求到交付生产再回来探讨需求的端到端，所以敏捷也在其之内。这里我们不去争辩这个，而是相对应的都采用狭义的敏捷、DevOps，即敏捷解决如何快速相应变化，做对需求，DevOps关注如何更多的自动化，打破后半部分的混沌之墙，以把事情做对。这样既划分清楚职责，又可以重点做自己的事情。实际工作中也是这样的，你们会发现，不管口头上怎么说，但是做改善的时候，敏捷教练往往对云原生技术只能说个大概，DevOps教练又很少能带着团队做需求拆分。

好了，我们先区分了敏捷和DevOps，再接着看，他们和研发效能的关系。

• 首先，如上诉解释，他俩只是各解决了软件交付的一部分的问题，所以事实上并不是端到端的。
• 其次，他们也只是软件交付的一个选择，比如有的项目就用瀑布交付就可以了，不需要用敏捷的交付方式。DevOps是内在的肌肉，但是有时，问题不在于DevOps这里，所以有可能你一段时间的提升改进在于别的地方，但是也叫研发效能提升。
• 第三，敏捷和DevOps只是研发效能提升的手段，而不是目的，这个很重要，有些教练在做提升的时候，以敏捷、DevOps为目的了，而不是以提升为目的，比如会重点看你敏捷会议开没开，而不是看是否需要开。
• 第四，也是最重要的，研发效能里，度量是必不可少的，虽然传统的项目管理也有一些度量，比如甘特图，燃尽图等，但是没有做到对问题域的详细拆解，比如甘特图上显示实际晚于计划，那么到底什么原因的，往往这时候就开始分析了，而没有进一步拆解的数据帮助你，给出更多的提示。

总而言之，研发效能提升的时候，围绕度量找问题，然后根据实际情况，采用敏捷或者DevOps的一些实践来帮助解决问题。

这一篇就聊到这里，下一篇我们一起来解读中关村智联软件服务业质量创新联盟发布的《软件研发效能度量规范》。