「时光不负，创作不停，本文正在参加2021年终总结征文大赛」
初闻
印象中，在14年的国庆节，和几位好友相约，要以DOTA开黑的形式，来为我们的祖国母亲，好好庆祝一下生日。 输了一晚上后，想借着宵夜平复一下心绪，再接再厉。 在西二旗街边的烧烤摊上，就着空气中厚厚的孜然味，一位朋友指着百度大厦提到 – 百度成立了研发效率部。
在这之前，有听到过研发效率这个词，但从没想过会有专注于此的部门。 心想，不管怎样，有人看重和投资，总归是件好事。 后来的时间里，听到最多的，都是来自DevOps的研发效能。 因为听到的次数和场和越来越多，越来越频繁，以至于感觉DevOps的另一个名字，就叫做研发效能。
转眼到了2021年，百度的研发效率部和质量部合并后，变成了现在的研发效能部。并在2018年发布了《工程效能白皮书1.0》。
4KM OKR
今年初，公司准备尝试OKR来加强凝聚力。 在以革新科技产业为大的方向的前提下，经过小伙伴们思想的碰撞后，决定将持续向行业输出有价值的解决方案作为目标，我们将研发效能相关的4KM(Four Key Metrics)，填在了KR(所有项目的4KM达到high及以上)栏里。 就这样，拉开了我的研发效能2021序章。
在OKR讨论会议上，4KM这个缩写词的普及率确实让我吃了一惊。 无论是什么角色，大家都明了这个词的涵义，不需要为此作额外的解释。这也恰恰证明了DORA(DevOps Research)的影响力。 DORA最著名的产出就属它的DevOps行业报告了，从14年至今，除了2020年不知什么原因断更外，基本上每年必更，一直到现在。
在最新的2021年报告中，和研发效能相关的描述有如下片段：
“To meet the demands of an ever-changing industry, organizations must deliver and operate software quickly and reliably. The faster your teams can make changes to your software, the sooner you can deliver value to your customers, run experiments, and receive valuable feedback. ” - Accelerate State of DevOps 2021
说的是，企业如果想要赢得瞬息万变的市场，需要具备快速并可靠的交付和运营软件的能力。
这是DORA对研发效能的理解。 为了能正确理解研发效能，降低试验过程中风险，咱们再多看看几家，看看大家是怎么理解研发效能的。
几家
下面是当前国内几家云厂商对研发效能的理解。
共识点：
- 全流程/一站式，也就是我们所说的端到端
- 提供的服务也是类似的，项目管理、代码管理、持续集成、持续交付，家家都有。从工具的角度来说，我认为二十几年来，敏捷活动算是成功的，毕竟大家现在都在用敏捷理念相关的这些工具。
个性点：
- 百度效率云强调自己是SaaS解决方案，就像AWS，提供一揽子工具，供用户自行选择使用。
- 腾讯云CODING DevOps强调的是云端高效协同，主要在于提升软件交付质量和速度。
- 阿里云云效则强调“双敏” - 研发敏捷和组织敏捷，以及关键词云原生、数字化转型等。
- 华为云软件开发平台DevCloud，则重点强调安全可信，提供的是云原生DevSecOpts。
这样看来，这几家都完全买单研发效能的理念，主动进入到了研发效能的大舞台。 经过持续投入，孵化并以云的形式开放了这些服务。 基于自身的文化和特长，和对研发效能的不同理解，强化了自己的个性和擅长点。
效率和效能
百度从效率到效能的转变。 在2018年先发布了《工程效能白皮书1.0》后，2019年合并了质量部门，从此改名研发效能部。
这也容易理解。效率代表的，在同等资源下，单位时间的产出物。 也就是我一晚上打DOTA能输10把，这是我输的效率。而效能说的是，输是输了，但要输的有质量。 比如，前面我输了10把，可能因为我并没有发挥真正的实力，这10把都是水局，没有质量可言，大家体验不好。 我认起真来后，每把都打得都很用心，插眼、游走、Gank一个不落，这样我能输15把，关键大家的游戏体验还很好。
一个强调产出物数量，一个强调有效产出物数量。
工具全了，效能就高了？
从上面几家来看，大家都提供了一揽子工具。 那工具全了，研发效能就高了？我想阿里云的云效有着不一样的理解。
云效有提到“双敏”这个概念，也就是研发敏捷和组织敏捷。 假设研发团队得到了工具很好的支撑，相比没有趁手的工具，研发效能肯定会有一定的提升，毕竟效率和效能正相关。 如果组织不敏捷，还是传统的功能型组织，团队作为基本单位，效率越高，在制品数量越多，浪费也会变多，效能会因为局部效率提高而有一定的提升，但明显还有很大的进步空间。
研发效能
怎么看待4KM
KR里的4KM，是结果指标，是动态的一组数据。 和RETRO一样，我们选择相信团队尽了最大的努力基于实际情况做到了最好，就像所有的路都是必经之路，没有捷径一样。
因为能影响这个结果的因素有很多。 比如人员的稳定性、团队的成熟度、团队的梯队健康度、整体氛围等等，都能影响到结果，产生波动。 我们希望通过可视化4KM，为团队多提供一组可参考数据，和团队一起分析和理解，作为参考，自主制定合适的计划，进行持续优化。
敏捷组织
这个不用多说，在我们公司里，这些都是团队天生的优势。 在团队组建时，就已经将该技能点点了满级。 所有的团队都是全功能团队，角色齐备，所有人作为一个整体，共享职责。 比如开发人员不分前后端，谁都可以胜任不同类型卡的日常交付。 交付流程出现瓶颈时，不同角色第一时间互帮互助，移除瓶颈，减少浪费。团队直接对接所有的Stakeholder，所有的成员都可以参与Governance/Showcase，和Stakeholder建立良好关系，引导需求，自主交付，对结果负责。
敏捷交付
工具集
相较于各大云厂商，我们的工具集由数字化平台Digital Platform全力赞助：
- Kanbanize Enterprise
- GitHub Enterprise
- CircleCI Enterprise
- GCP + AWS
- …
4KM可视化
我们相信进步从可视化开始。 从手动收集，到自动化采集；从凭感觉，到有数据可依，可视化的过程，本身就是一种进步。
4KM报告功能，是Digital Platform在团队内Hackson活动上，孵化的众多idea中的一个。
经过短短一个星期，正式上线。
除了方便团队获取最近三个月数据报告外，在月度项目健康度检查报告里，有关于团队研发效能的信心和状态趋势图：
从今年三月份开始，前几个月团队信心和状态波动较大，还处于适应和调整阶段，到了中期，变化趋势不再反复，说明团队已经逐渐适应。最近几个月相对平稳，已进入平稳期。最后成功进入冲刺期，说明团队现在信心十足！
知识传递
作为知识工作者，在敏捷交付过程中，我们所坚持的实践，都是为了更好更迅速的知识传递。 因为敏捷软件开发就是靠口口相传的。 比如迭代开始前，要和客户沟通，确认好需求，开发后要showcase。 交付过程中，有IPM，站会，结对编程，开卡，deskcheck，等等。都涉及到交流沟通。 工程实践中像主干开发也是鼓励持续提交，小步快跑，提前合并，这不也是一种沟通吗。 为了有足够的社交化活动，团队内我们已经在持续优化。 我们也组织了不同的兴趣小组和社区创造环境，鼓励社交活动，以增进知识传递。
研发效能兴趣小组
兴趣小组探讨的主题是： 在一个敏捷组织里，有一个开发者友好的高效能平台，可以让所有人专注在核心业务上。那这个平台要长啥样?
小伙伴们马上就能口若悬河，滔滔不绝。 仿佛这个问题早就探讨过，千千万万遍。 大概说的是：作为开发人员，知识工作者，所有我要做的事情，就是推送核心业务代码。 代码管理全自动，没有的新建，有的自动对接，为什么我还要去查一查名字有没有被占用，点一点选公开还是私有？基础设施全自动，什么流水线、运行环境，通通全自动，我为什么要关心是K8S, 还是K9S？ 也不要老发什么预警信息，有问题自修复，自愈合。 别老让我往Digital Platform上发什么API, Events, Data, 就不能自嗅探，生态自建吗？什么代码检测、安全扫描、测试策略、认证授权、全链路可视化、数字孪生，等等等等，该有的一个都不能少...
有梦想，有目标，总归是好的。
同时也要知道我们将要从哪里出发，因为基本上所有团队都在容器化，所以我们也设定了一下范围，决定将容器化定为探讨方向。（后续有机会可以分享，先挖好坑)
工程实践和4KM
工程实践是我们软件交付价值观的一种具体体现。 也是我们的基本功，所以我们管这些实践叫“Sensible Default Practices”。
并且用下面这张图给出了工程实践和4KM之间的关系：
为了更好的夯实基础，我们最近也筹建了工程实践社区。
希望能从不同的角度，多创造一些环境和机会，来帮助这些核心知识的传递。 让大家更真切的感受到研发效能其实并不是什么遥远的概念，她更像是一种文化，一种价值观，并且从未远离，一直都守护在我们身边。
