软件研发效能提升之美
微软现任 CEO 萨提亚·纳德拉 说过这样一段话：
There cannot be a more important thing for an engineer, for a product team, than to work on the systems that drive our productivity. So I would, any day of the week, trade off features for our own productivity.
对工程师和产品团队来说，没有比构建一个能够提升研发效能的体系更重要的事了。为了提升研发效能，我愿意随时舍弃某些功能的交付。
软件研发效能概论
研发效能的 “第一性原理”：顺畅、高质量地持续交付有效价值的闭环。
- 顺畅：价值的流动过程必须顺畅，没有阻碍
- 高质量：如果质量不行，那么流动越快，死得也会越快
- 持续：不能时断时续，小步快跑才是正道，不要憋大招
- 有效价值：这是从需求层面来说的，你的交付物不是真正解决了用户的本质问题。比如：“女生减肥不是本质问题，女生爱美才是”
- 闭环：强调快速反馈的重要性
MVP（最小可行性产品 Minimum Viable Product） 这个概念来自 Eric Rise 的《精益创业》一书，其核心思想是指以最低成本尽可能快的展现核心概念的产品策略，即用最快、最简明的方式建立一个可用的产品原型，这个原型要表达出产品最终想要的效果，然后通过迭代来完善细节。
这个思想特别适用于研发效能平台的建设，我们必须在识别出待解决的研发效能问题之后，给出最简单的解决方案，并在后面实践中不断优化和迭代，如果我们视图关起门来打造一个研发效能平台，指望等所有功能都完美了，再推给业务团队使用，那必然是死路一条。
在这里特别指出一下 MVP 的常见误区：
实现了某一个功能，但是暂时对客户没有实际价值，而要等后面功能出来后，才能对客户有用，这种产品策略不是 MVP。
MVP 追求的是 “麻雀虽小五脏俱全”，也就是实现的功能点可以很小，可以比较简陋，但是对客户有价值是必需的。
伪需求：伪需求是指研发效能团队自己臆想出来的需求，是属于典型的 “手里拿着锤子，看什么都像钉子” 的典型案例。
那么如何识别伪需求呢？识别的标准其实很简单，就看用户是不是愿意和你分摊成本，如果业务线已经开始做了，或者想要开始做，那就说明那是业务线的刚需，
如果研发效能平台能帮助用户提供方案，那么研发效能平台的接入就是水到渠成的事情。
好的策略是承认每个人都是自私的，但是我们制定的策略要能够人人都是自私的基础上获得全局利益的最大化。
如果全局利益最大化是建立在要求每个人都是大公无私的基础上，那就是失败的设计，因为这必然会导致失败。
回到研发效能提升这个问题上，我们必须抱着 “不是我们的研发效能平台有多好，而是业务线用了以后有什么提升” 的态度来定位自己，才能从结构上获得成功的筹码。
我们先来讲两个概念：“唱戏的” 和 “搭台的”。
刚开始做研发效能的时候，我们既是搭台的，又是唱戏的，在研发效能平台（搭台）的基础上提供各业务线的解决方案（唱戏）。
但是，当业务线的接入规模不断扩大的时候，各个垂直领域的多样化需求越来越多，我们已经很难应对各家的个性化非通用需求了（每家要唱的戏都不同）。
此时，研发效能平台的开放能力就成为关键，它必须能够应对这种多样性，让业务线能够在平台上实现各自的个性化需求，所以研发效能平台本身的技术架构设计必须考虑可扩展性和灵活性。
一种掩耳盗铃的错误实践是，普遍采用虚荣型指标来做度量效能。
那么到底什么是虚荣型指标呢？虚荣型指标是指那些不能直接用来指导后续行动的指标，我们需要的是可以指导我们行动的可执行指标。
吃自己的 “狗粮”：意为 “做研发效能平台的第一个用户”，研发效能平台本身的研发流程必须通过自己的平台来执行，这样才能站在用户的角度看待自己的方案，才能和业务线用户 “共情”。
如果我们作为效能工具平台的研发团队，自己都不用自己的工具平台来完成研发过程，就很难要求别人来使用我们的研发效能平台。
研发效能的进阶解读
效能提升的一个大前提是建立合适的度量体系与标准，正所谓 “If you can't measure it, you can't manage it.”（无法度量，就无法管理）。
霍桑效应：实验者对新的实验处理会产生正向反应，即由于环境改变而改变行为。
当人们意识到自己正在被关注时，会不自觉的改变自己的某种行为。
团队知道自己正在被统计需求交付吞吐量数据，于是会更重视这方面的工作，从而促进了需求交付效率的提升。
那么怎么规避这些影响呢？比较好的办法是采用双盲实验法，让实验者和对照者都不知道自己是在做实验。
在工程上，双盲实验有一定的代价，需要做到无侵入度量，并尽可能规避一切宣传手段，以免引起实验者的感知和互相交流，这在实践上比较难以做到。
另一种可以在一定程度上减轻霍桑效应的方法称为环境弱化法，尽可能弱化实验结果给实验者带来的影响，尽可能弱化环境变化、工具变化、流程变化等内容，不设定 KPI，避免不必要的访谈等工作。
本质是淡化对实验者的心理暗示，减轻霍桑效应的影响。
霍桑效应给我们的启示是：渴望尊重和欣赏，是人性的需求之一。适度的关注和赞美能够产生强烈的心理暗示，继而带来效能的提升。
反摩尔定律，是由 Google 前 CEO 埃里克·施密特 提出的：一个 IT 公司今天要想和 18 个月前卖掉同样多、同样质量的产品，那么它的营业额就会下降一半。
反摩尔定律逼迫各公司马不停蹄的跟进摩尔定律所规定的速度，否则就不得不面对被淘汰的危险。
敏捷开发最大的目标之一，就是更快的交付价值，这里的 “快” 指的不是绝对速度，而是更早的交付。尽快将有效且高质量的产品交付，以追赶摩尔定律的速度，抢占市场先机。
在《人月神话》中有个著名的论断：“向进度落后的项目中增加人手，只会使进度更加落后”。
其中一个很大的原因是，新员工总是需要老员工进行指导，这其中就会产生看不见的沟通成本，这些沟通成本挤占了老员工原本的计划工作时间，造成在短期内无法提升项目进度。增加的人手越多，沟通成本所带来的影响越大。
重视沟通的影响，提升沟通效率，对研发效能的帮助也是非常可观的。
人与人之间的沟通，其实质是信息流的传递。1948 年，香农提出了 “信息熵” 的概念，解决了信息的量化度量问题。
在日常工作中，沟通信息的传递过程会受到很多因素的影响，如果我们将人与人之间的沟通和网络通信传输做类比，会发现人的沟通也有带宽（语速和信息量）、丢包（没听清楚）、延迟（传输介质影响）、协议转换（不同语言）等因素，这些因素会削弱信息量和信息价值。
项目管理中的提效手段
敏捷宣言：
- 个体和互动 > 流程和工具
- 工作的软件 > 详尽的文档
- 客户合作 > 合同谈判
- 响应变化 > 遵循计划
敏捷开发强调人的贡献和团队沟通，鼓励当面沟通和建立信任。
合适和正确的工具能够帮助人们更好的完成工作，如果认为过程和工具会对项目成败起关键的决定性的作用，那么就是本末倒置了。项目是由人来完成的，成败的关键在于每一个人的态度。
不要认为更大的、更好的工具可以自动的帮你做的更好。通常，它们造成的障碍要大于带来的帮助。
软件开发作为一项智力活动，很难用静态文档对其进行完备的定义和分析，与其让软件工作者和客户面对众多繁杂而又单调的文档，不如采取演示和讲解的方式更高效。
Martin 文档第一定律：直到需求迫切且意义重大时，才撰写文档。
软件开发工作难以标准化，进度难以度量，这些是其固有的属性，我们不要纠结于合同措辞和商务谈判，而是要与客户加强沟通，尽可能频繁的给客户反馈，让客户与开发团队密切的凝聚在一起，这才是最好的 “合同”。
被动的遵循计划，不如主动的拥抱变化，这可能是敏捷开发最重要的理念之一。
敏捷开发方法
自组织是指一个系统在内在机制的驱动下，自行从简单向复杂、从粗糙向细致方向发展，不断的提高自身的复杂度和精细度的过程。
自组织团队并不是虚无缥缈的概念，早在 1986 年，《The New New Product Development Game》一文中就写道：“一个群体具备三个条件时拥有自组织能力：自治、自我超越、正向交互”。
敏捷团队的所有角色需要朝着共同的目标前进，荣辱与共。
在实践上，尽量避免针对不同的角色制定可能会产生冲突的 KPI，比如对测试人员制定 Bug 数量的 KPI，针对研发人员制定相反（解决 Bug 数量）的 KPI。
我们甚至建议对整个项目的参与人员制定共同的 KPI，如果项目失败或延期，那么整个团队都应该为此负责，并持续改进。
古德哈特定律：当决策者试图以一个事物的客观测量指标作为指针来施行政策时，这一指标就再也不能有效测量事物了。
某公司将缺陷解决时长作为度量标准，并以行政方式加入研发团队的 KPI 中，最后产生的效果是，很多研发人员私下与测试人员 “串通”，将一些棘手的缺陷晚些时候提报，甚至私下修复，以此规避度量指标的记录。
这个例子给我们的启示是，应以客观、理性的姿态对待度量这件事，用度量来指导改进，而不是生硬的将度量指标加入 KPI 中，以期达到完美的效果。
度量的目标是消除系统性瓶颈，这意味着我们在进行度量时始终要有全局性思维，下沉的同时要能够回到山峰统揽全局。
某大型公司再制定项目策略和团队规划时，会采用 “目标-策略-打法-抓手-资源” 这样逐层拆解的方式，确保始终以目标为核心执行各项工作，尽力保证目标的有效达成。
同理，在研发效能度量时，也应时刻反思制定的度量标准和结果，是否能对目标有贡献，要多看数据，少看数字。
在研发效能度量时，我们得到的是大量的数字，但数字恰恰是经常被曲解的部分，谎言并不来自数字本身，而是来自错误的解读。
探索出数字背后的规律，将数字的真实价值直观而又清晰的表达出来，是数据可视化的最终目的。
数据可视化从表面上看是通过图表等形式展示数据，实则建立一种视觉暗示，以图像为载体将数据背后的故事叙述出来，使人一目了然。
看板能够保证软件研发过程中的各项重要工作的进度始终处于可视化状态，这是一种非常强烈的结构性视觉暗示，所有阻碍流程的事务能够快速识别和暴露。
充分的风险暴露是看板的另一个作用，有一句加拿大格言：如果你看见了问题，那就离解决它不远了。
及早暴露风险，及早投入解决，百利而无一害。
从某种意义上来说，软件研发的过程就是不断提供正向反馈的过程。
研发阶段的调试和设计工作提供了可行性全面反馈，测试工作提供了质量反馈，交付工作则面向用户提供了反馈。
快速反馈是软件行业始终追求的目标，我们希望能够在十分钟内跑完整个回归测试用例集，在一周内交付一个中等规模需求的软件产品，等等。
解耦是获得提速的一项有效手段，我们要尽可能的让软件研发过程中的各个角色不出现互相等待的情况，能够并行工作。
通过快速且频繁（即高频）的交付，能够解决信息割裂的问题，从而提前暴露和收敛风险。
目前在软件行业已经成为普遍做法的持续集成，就是应用这一理念诞生的产物，通过频繁的集成，辅以自动化测试和可视化管理，在早期充分暴露问题，加快问题收敛周期，同时倒逼能力提升。
竖井效应 指的是，公司内的各个职能团队各自为政，均达成了局部的高效，然而从全局角度却不见得高效。
软件产品最终是交付给用户的，用户往往只关注产品何时能够按质量交付，也就是端到端的整体效率。
如果仅关注小范围的研发效能，则很容易陷入局部最优、而全局不优的窘境。
要达到全局最有，需要用端到端的视角来看待整个研发过程，特别是要以业务价值为导向，而不是以研发人员的产出为导向。
前置时间是业务感知效能的重要指标，该指标表示从业务提出需求到产品发布（即交付）的时长。
周期时间通常用来度量内部研发效能，指的是研发人员针对需求从开始着手研发工作，到交付业务验收的时长。
约束是控制复杂度的第一步，因为每多一种变量，就多一分风险，如果遵守统一的标准规范，就可以收敛出错的情况，也有利于团队的共同认知与交流。
管理学大师 彼得·德鲁克 说：管理要做的事情只有一件，就是如何对抗熵增。在这个过程中，企业的生命力才会增强，而不是默默走向死亡。
依赖工程师的自觉一般是不靠谱的，需要有制度和流程上的约束，良好的代码评审机制和走读机制可以在一定程度上规避一些问题，团队的文化建设和工匠精神的培养则是制度的有力补充。
盲目自信的根本原因是缺乏对意料之外事件的主动觉察能力，特别是消极因素的主动觉察能力，想当然的做出决策。
DevOps 落地实施精要
2001 年 “敏捷宣言” 的提出，对软件工程管理方法论是一次革命性的反思，人们逐渐意识到小批量交付、高频交付，以及拉通协作的重要性。
伴随着越来越多的实践，这股思潮逐渐从项目管理层面蔓延到了基础设施建设，乃至组织方式变革上。
在《关键对话》一书中，作者提到一种解决分歧的手段，叫做 “向上寻找共同目标”。
DevOps 的 “六大武器”：
- 标准化作业：DevOps 倡导通过流水线、自动化等工作，达成流程上的不可变性，即标准化。
- 快速失败：尽可能的在早期发现问题并立刻失败，避免问题隐藏至后期，进而增加解决成本。
- 快速反应
- 高质量与高效率：通过持续部署、快速反馈的方式，更好的将不确定性逐步转变为确定性，从而保障高质量交付。
- 降低成本：快速迭代的流水线初成规模后，软件研发的效率将大大提升，研发成本将明显降低
- 团队协作：依靠工具和自动化（尤其是流程自动化）来弥补开发和运维之间的技能、沟通鸿沟。
自动化是 DevOps 的核心实践之一。
著名软件公司甚至将 DevOps 解释为 “使软件开发和 IT 团队之间的流程实现自动化的一组实践”，为用户创造持续的价值。
根据业界的主流观点，可以将 DevOps 的生命周期划分为 7 个阶段：持续开发、持续集成、持续测试、持续监控、持续反馈、持续部署、持续运营。
GIGO 原则：输出质量是由输入质量决定的。
TDD 试图将测试工作从软件研发流程的下游逆转至上游，从而达到更快暴露质量问题的目的。
目前主流的工作流包括 GitFlow、GitHub Flow、GitLab Flow 等。
从 DevOps 的视角看，流水线是持续交付的载体，通过构建自动化、集成自动化、验证自动化、部署自动化 等工作，完成从开发到上线的持续交付过程。
精益理论强调了价值流动的重要性，而价值流动需要通过一定的方式来体现，DevOps 流水线从某种程度上说就是一个很好的载体，因为它几乎覆盖了整个端到端的流程。
在流水线上，各环节流转的越快，价值流动就越快，这间接体现了公司的研发效能。
随着 DevOps 研发实践的不断普及，传统的软件安全开发体系已经力不从心。
随着软件的发布速度和发布频率的不断增加，传统的应用安全团队已经无法跟上发布的步伐来确保每个发布都是安全的。
为了解决这个问题，组织需要再整个软件研发生命周期中持续构建安全性，以便使 DevOps 团队能够快速、高质量的交付安全的应用。
越早的将安全性引入工作流中，就能越早的识别和补救安全弱点和漏洞。
亚马逊首席技术官 Werner Vogels 也持有相同的观点，他认为，安全需要每个工程师的参与，安全不再是单独安全团队的责任，是整个组织所有人的一致目标和责任，只有这样才能更好的对研发过程中的安全问题进行管控。
DevSecOps：安全专业人员需要积极参与 DevOps 计划，并忠实于 DevOps 精神，拥抱其团队合作、协调、敏捷和共同责任的理念。
也就是说，完全遵循 DevOps 的思想，将安全无缝集成到其中，使之升级为 DevSecOps。
DevSecOps 意味着安全成为整个团队共同的责任，每个人都应该在 DevOps 的 CI/CD 工作流中构建安全体系。
AIOps：整合大数据和机器学习能力，通过松耦合、可扩展方式去提取和分析在数据量（volumn）、种类（variety）和速度（velocity）这三个维度不断增长的 IT 数据，为所有主流 IT 运维管理产品提供支撑。
DevPerfOps 所解决的问题是，将性能保障的活动植入研发过程的各个环节，从而从源头来保证软件的高性能和高可靠性。
组织效能提升
组织的成立是为了承担并完成个体无法独立完成的任务。
另外，我们可以认为组织是交流的结果，软件研发作为人类的创造性活动，不是研究人员单纯利用计算机就能完成的，沟通和交流占据了软件研发过程中的大量时间。
因此，成立组织的目的是，尽可能减少团队成员在交流和合作方面所花费的时间，以此提升整体组织效能。
工程效能部依然属于支撑型团队，而不是推动型团队。
作为支撑型团队，团队所服务的需求是用户（内部技术人员）提出的，痛点是用户暴露的，我们要做的是服务好用户。
而作为推动型团队，需求和痛点都是团队通过主动挖掘和分析得出的，团队的方向就是公司工程效能的发展方向。
支撑型团队是被用户推着走的，而推动型团队是拉着用户走的。
在未来，我们更倡导工程效能部能够成为一支推动型的团队。
业务中台就是将业务领域的通用能力进行合并。
业务中台的目标是，对通用业务领域和业务能力进行抽象、合并，以灵活支撑上层的业务需求。
而质量中台的目标是对通用质量工具和平台进行抽象、合并，以减少质量工具和平台的重复建设。
虽然两者面向的对象不同，但都具有中台的两个特点：标准化和适配性。
大部分人可能只关注自己的付出，但并不关心付出所获得的实际效果，作为组织的管理者应该为苦劳故障，为功劳付钱。
高效组织建设的最佳实践
- 不要制定冲突的目标
- 善用激励手段，敢用惩罚手段
- 规避形式主义，勇于做减法
- 重视创新，鼓励 “小轮子” 经济
企业研发效能提升的常见误区
- 视图提升研发效能的绝对值
- 迷信单点局部能力
- 过高估计普适性通用研发效能工具的能力
- 用伪工程实践和面子工程来滥竽充数
- 忽略研发效能工具体系的长尾效应
- 盲目跟风
软件研发效能提升之美
微软现任 CEO 萨提亚·纳德拉 说过这样一段话：
软件研发效能概论
研发效能的 “第一性原理”：顺畅、高质量地持续交付有效价值的闭环。
MVP（最小可行性产品 Minimum Viable Product） 这个概念来自 Eric Rise 的《精益创业》一书，其核心思想是指以最低成本尽可能快的展现核心概念的产品策略，即用最快、最简明的方式建立一个可用的产品原型，这个原型要表达出产品最终想要的效果，然后通过迭代来完善细节。
这个思想特别适用于研发效能平台的建设，我们必须在识别出待解决的研发效能问题之后，给出最简单的解决方案，并在后面实践中不断优化和迭代，如果我们视图关起门来打造一个研发效能平台，指望等所有功能都完美了，再推给业务团队使用，那必然是死路一条。
在这里特别指出一下 MVP 的常见误区：
实现了某一个功能，但是暂时对客户没有实际价值，而要等后面功能出来后，才能对客户有用，这种产品策略不是 MVP。
MVP 追求的是 “麻雀虽小五脏俱全”，也就是实现的功能点可以很小，可以比较简陋，但是对客户有价值是必需的。
伪需求：伪需求是指研发效能团队自己臆想出来的需求，是属于典型的 “手里拿着锤子，看什么都像钉子” 的典型案例。
那么如何识别伪需求呢？识别的标准其实很简单，就看用户是不是愿意和你分摊成本，如果业务线已经开始做了，或者想要开始做，那就说明那是业务线的刚需，
如果研发效能平台能帮助用户提供方案，那么研发效能平台的接入就是水到渠成的事情。
好的策略是承认每个人都是自私的，但是我们制定的策略要能够人人都是自私的基础上获得全局利益的最大化。
如果全局利益最大化是建立在要求每个人都是大公无私的基础上，那就是失败的设计，因为这必然会导致失败。
回到研发效能提升这个问题上，我们必须抱着 “不是我们的研发效能平台有多好，而是业务线用了以后有什么提升” 的态度来定位自己，才能从结构上获得成功的筹码。
我们先来讲两个概念：“唱戏的” 和 “搭台的”。
刚开始做研发效能的时候，我们既是搭台的，又是唱戏的，在研发效能平台（搭台）的基础上提供各业务线的解决方案（唱戏）。
但是，当业务线的接入规模不断扩大的时候，各个垂直领域的多样化需求越来越多，我们已经很难应对各家的个性化非通用需求了（每家要唱的戏都不同）。
此时，研发效能平台的开放能力就成为关键，它必须能够应对这种多样性，让业务线能够在平台上实现各自的个性化需求，所以研发效能平台本身的技术架构设计必须考虑可扩展性和灵活性。
一种掩耳盗铃的错误实践是，普遍采用虚荣型指标来做度量效能。
那么到底什么是虚荣型指标呢？虚荣型指标是指那些不能直接用来指导后续行动的指标，我们需要的是可以指导我们行动的可执行指标。
吃自己的 “狗粮”：意为 “做研发效能平台的第一个用户”，研发效能平台本身的研发流程必须通过自己的平台来执行，这样才能站在用户的角度看待自己的方案，才能和业务线用户 “共情”。
如果我们作为效能工具平台的研发团队，自己都不用自己的工具平台来完成研发过程，就很难要求别人来使用我们的研发效能平台。
研发效能的进阶解读
效能提升的一个大前提是建立合适的度量体系与标准，正所谓 “If you can't measure it, you can't manage it.”（无法度量，就无法管理）。
霍桑效应：实验者对新的实验处理会产生正向反应，即由于环境改变而改变行为。
当人们意识到自己正在被关注时，会不自觉的改变自己的某种行为。
团队知道自己正在被统计需求交付吞吐量数据，于是会更重视这方面的工作，从而促进了需求交付效率的提升。
那么怎么规避这些影响呢？比较好的办法是采用双盲实验法，让实验者和对照者都不知道自己是在做实验。
在工程上，双盲实验有一定的代价，需要做到无侵入度量，并尽可能规避一切宣传手段，以免引起实验者的感知和互相交流，这在实践上比较难以做到。
另一种可以在一定程度上减轻霍桑效应的方法称为环境弱化法，尽可能弱化实验结果给实验者带来的影响，尽可能弱化环境变化、工具变化、流程变化等内容，不设定 KPI，避免不必要的访谈等工作。
本质是淡化对实验者的心理暗示，减轻霍桑效应的影响。
霍桑效应给我们的启示是：渴望尊重和欣赏，是人性的需求之一。适度的关注和赞美能够产生强烈的心理暗示，继而带来效能的提升。
反摩尔定律，是由 Google 前 CEO 埃里克·施密特 提出的：一个 IT 公司今天要想和 18 个月前卖掉同样多、同样质量的产品，那么它的营业额就会下降一半。
反摩尔定律逼迫各公司马不停蹄的跟进摩尔定律所规定的速度，否则就不得不面对被淘汰的危险。
敏捷开发最大的目标之一，就是更快的交付价值，这里的 “快” 指的不是绝对速度，而是更早的交付。尽快将有效且高质量的产品交付，以追赶摩尔定律的速度，抢占市场先机。
在《人月神话》中有个著名的论断：“向进度落后的项目中增加人手，只会使进度更加落后”。
其中一个很大的原因是，新员工总是需要老员工进行指导，这其中就会产生看不见的沟通成本，这些沟通成本挤占了老员工原本的计划工作时间，造成在短期内无法提升项目进度。增加的人手越多，沟通成本所带来的影响越大。
重视沟通的影响，提升沟通效率，对研发效能的帮助也是非常可观的。
人与人之间的沟通，其实质是信息流的传递。1948 年，香农提出了 “信息熵” 的概念，解决了信息的量化度量问题。
在日常工作中，沟通信息的传递过程会受到很多因素的影响，如果我们将人与人之间的沟通和网络通信传输做类比，会发现人的沟通也有带宽（语速和信息量）、丢包（没听清楚）、延迟（传输介质影响）、协议转换（不同语言）等因素，这些因素会削弱信息量和信息价值。
项目管理中的提效手段
敏捷宣言：
敏捷开发强调人的贡献和团队沟通，鼓励当面沟通和建立信任。
合适和正确的工具能够帮助人们更好的完成工作，如果认为过程和工具会对项目成败起关键的决定性的作用，那么就是本末倒置了。项目是由人来完成的，成败的关键在于每一个人的态度。
不要认为更大的、更好的工具可以自动的帮你做的更好。通常，它们造成的障碍要大于带来的帮助。
软件开发作为一项智力活动，很难用静态文档对其进行完备的定义和分析，与其让软件工作者和客户面对众多繁杂而又单调的文档，不如采取演示和讲解的方式更高效。
Martin 文档第一定律：直到需求迫切且意义重大时，才撰写文档。
软件开发工作难以标准化，进度难以度量，这些是其固有的属性，我们不要纠结于合同措辞和商务谈判，而是要与客户加强沟通，尽可能频繁的给客户反馈，让客户与开发团队密切的凝聚在一起，这才是最好的 “合同”。
被动的遵循计划，不如主动的拥抱变化，这可能是敏捷开发最重要的理念之一。
敏捷开发方法
自组织是指一个系统在内在机制的驱动下，自行从简单向复杂、从粗糙向细致方向发展，不断的提高自身的复杂度和精细度的过程。
自组织团队并不是虚无缥缈的概念，早在 1986 年，《The New New Product Development Game》一文中就写道：“一个群体具备三个条件时拥有自组织能力：自治、自我超越、正向交互”。
敏捷团队的所有角色需要朝着共同的目标前进，荣辱与共。
在实践上，尽量避免针对不同的角色制定可能会产生冲突的 KPI，比如对测试人员制定 Bug 数量的 KPI，针对研发人员制定相反（解决 Bug 数量）的 KPI。
我们甚至建议对整个项目的参与人员制定共同的 KPI，如果项目失败或延期，那么整个团队都应该为此负责，并持续改进。
古德哈特定律：当决策者试图以一个事物的客观测量指标作为指针来施行政策时，这一指标就再也不能有效测量事物了。
某公司将缺陷解决时长作为度量标准，并以行政方式加入研发团队的 KPI 中，最后产生的效果是，很多研发人员私下与测试人员 “串通”，将一些棘手的缺陷晚些时候提报，甚至私下修复，以此规避度量指标的记录。
这个例子给我们的启示是，应以客观、理性的姿态对待度量这件事，用度量来指导改进，而不是生硬的将度量指标加入 KPI 中，以期达到完美的效果。
度量的目标是消除系统性瓶颈，这意味着我们在进行度量时始终要有全局性思维，下沉的同时要能够回到山峰统揽全局。
某大型公司再制定项目策略和团队规划时，会采用 “目标-策略-打法-抓手-资源” 这样逐层拆解的方式，确保始终以目标为核心执行各项工作，尽力保证目标的有效达成。
同理，在研发效能度量时，也应时刻反思制定的度量标准和结果，是否能对目标有贡献，要多看数据，少看数字。
在研发效能度量时，我们得到的是大量的数字，但数字恰恰是经常被曲解的部分，谎言并不来自数字本身，而是来自错误的解读。
探索出数字背后的规律，将数字的真实价值直观而又清晰的表达出来，是数据可视化的最终目的。
数据可视化从表面上看是通过图表等形式展示数据，实则建立一种视觉暗示，以图像为载体将数据背后的故事叙述出来，使人一目了然。
看板能够保证软件研发过程中的各项重要工作的进度始终处于可视化状态，这是一种非常强烈的结构性视觉暗示，所有阻碍流程的事务能够快速识别和暴露。
充分的风险暴露是看板的另一个作用，有一句加拿大格言：如果你看见了问题，那就离解决它不远了。
及早暴露风险，及早投入解决，百利而无一害。
从某种意义上来说，软件研发的过程就是不断提供正向反馈的过程。
研发阶段的调试和设计工作提供了可行性全面反馈，测试工作提供了质量反馈，交付工作则面向用户提供了反馈。
快速反馈是软件行业始终追求的目标，我们希望能够在十分钟内跑完整个回归测试用例集，在一周内交付一个中等规模需求的软件产品，等等。
解耦是获得提速的一项有效手段，我们要尽可能的让软件研发过程中的各个角色不出现互相等待的情况，能够并行工作。
通过快速且频繁（即高频）的交付，能够解决信息割裂的问题，从而提前暴露和收敛风险。
目前在软件行业已经成为普遍做法的持续集成，就是应用这一理念诞生的产物，通过频繁的集成，辅以自动化测试和可视化管理，在早期充分暴露问题，加快问题收敛周期，同时倒逼能力提升。
竖井效应 指的是，公司内的各个职能团队各自为政，均达成了局部的高效，然而从全局角度却不见得高效。
软件产品最终是交付给用户的，用户往往只关注产品何时能够按质量交付，也就是端到端的整体效率。
如果仅关注小范围的研发效能，则很容易陷入局部最优、而全局不优的窘境。
要达到全局最有，需要用端到端的视角来看待整个研发过程，特别是要以业务价值为导向，而不是以研发人员的产出为导向。
前置时间是业务感知效能的重要指标，该指标表示从业务提出需求到产品发布（即交付）的时长。
周期时间通常用来度量内部研发效能，指的是研发人员针对需求从开始着手研发工作，到交付业务验收的时长。
约束是控制复杂度的第一步，因为每多一种变量，就多一分风险，如果遵守统一的标准规范，就可以收敛出错的情况，也有利于团队的共同认知与交流。
管理学大师 彼得·德鲁克 说：管理要做的事情只有一件，就是如何对抗熵增。在这个过程中，企业的生命力才会增强，而不是默默走向死亡。
依赖工程师的自觉一般是不靠谱的，需要有制度和流程上的约束，良好的代码评审机制和走读机制可以在一定程度上规避一些问题，团队的文化建设和工匠精神的培养则是制度的有力补充。
盲目自信的根本原因是缺乏对意料之外事件的主动觉察能力，特别是消极因素的主动觉察能力，想当然的做出决策。
DevOps 落地实施精要
2001 年 “敏捷宣言” 的提出，对软件工程管理方法论是一次革命性的反思，人们逐渐意识到小批量交付、高频交付，以及拉通协作的重要性。
伴随着越来越多的实践，这股思潮逐渐从项目管理层面蔓延到了基础设施建设，乃至组织方式变革上。
在《关键对话》一书中，作者提到一种解决分歧的手段，叫做 “向上寻找共同目标”。
DevOps 的 “六大武器”：
自动化是 DevOps 的核心实践之一。
著名软件公司甚至将 DevOps 解释为 “使软件开发和 IT 团队之间的流程实现自动化的一组实践”，为用户创造持续的价值。
根据业界的主流观点，可以将 DevOps 的生命周期划分为 7 个阶段：持续开发、持续集成、持续测试、持续监控、持续反馈、持续部署、持续运营。
GIGO 原则：输出质量是由输入质量决定的。
TDD 试图将测试工作从软件研发流程的下游逆转至上游，从而达到更快暴露质量问题的目的。
目前主流的工作流包括 GitFlow、GitHub Flow、GitLab Flow 等。
从 DevOps 的视角看，流水线是持续交付的载体，通过构建自动化、集成自动化、验证自动化、部署自动化 等工作，完成从开发到上线的持续交付过程。
精益理论强调了价值流动的重要性，而价值流动需要通过一定的方式来体现，DevOps 流水线从某种程度上说就是一个很好的载体，因为它几乎覆盖了整个端到端的流程。
在流水线上，各环节流转的越快，价值流动就越快，这间接体现了公司的研发效能。
随着 DevOps 研发实践的不断普及，传统的软件安全开发体系已经力不从心。
随着软件的发布速度和发布频率的不断增加，传统的应用安全团队已经无法跟上发布的步伐来确保每个发布都是安全的。
为了解决这个问题，组织需要再整个软件研发生命周期中持续构建安全性，以便使 DevOps 团队能够快速、高质量的交付安全的应用。
越早的将安全性引入工作流中，就能越早的识别和补救安全弱点和漏洞。
亚马逊首席技术官 Werner Vogels 也持有相同的观点，他认为，安全需要每个工程师的参与，安全不再是单独安全团队的责任，是整个组织所有人的一致目标和责任，只有这样才能更好的对研发过程中的安全问题进行管控。
DevSecOps：安全专业人员需要积极参与 DevOps 计划，并忠实于 DevOps 精神，拥抱其团队合作、协调、敏捷和共同责任的理念。
也就是说，完全遵循 DevOps 的思想，将安全无缝集成到其中，使之升级为 DevSecOps。
DevSecOps 意味着安全成为整个团队共同的责任，每个人都应该在 DevOps 的 CI/CD 工作流中构建安全体系。
AIOps：整合大数据和机器学习能力，通过松耦合、可扩展方式去提取和分析在数据量（volumn）、种类（variety）和速度（velocity）这三个维度不断增长的 IT 数据，为所有主流 IT 运维管理产品提供支撑。
DevPerfOps 所解决的问题是，将性能保障的活动植入研发过程的各个环节，从而从源头来保证软件的高性能和高可靠性。
组织效能提升
组织的成立是为了承担并完成个体无法独立完成的任务。
另外，我们可以认为组织是交流的结果，软件研发作为人类的创造性活动，不是研究人员单纯利用计算机就能完成的，沟通和交流占据了软件研发过程中的大量时间。
因此，成立组织的目的是，尽可能减少团队成员在交流和合作方面所花费的时间，以此提升整体组织效能。
工程效能部依然属于支撑型团队，而不是推动型团队。
作为支撑型团队，团队所服务的需求是用户（内部技术人员）提出的，痛点是用户暴露的，我们要做的是服务好用户。
而作为推动型团队，需求和痛点都是团队通过主动挖掘和分析得出的，团队的方向就是公司工程效能的发展方向。
支撑型团队是被用户推着走的，而推动型团队是拉着用户走的。
在未来，我们更倡导工程效能部能够成为一支推动型的团队。
业务中台就是将业务领域的通用能力进行合并。
业务中台的目标是，对通用业务领域和业务能力进行抽象、合并，以灵活支撑上层的业务需求。
而质量中台的目标是对通用质量工具和平台进行抽象、合并，以减少质量工具和平台的重复建设。
虽然两者面向的对象不同，但都具有中台的两个特点：标准化和适配性。
大部分人可能只关注自己的付出，但并不关心付出所获得的实际效果，作为组织的管理者应该为苦劳故障，为功劳付钱。
高效组织建设的最佳实践
企业研发效能提升的常见误区