国外在软件研发变革、研发效能、组织赋能这方面进行系统的探究比我们领先许多，2018年出版的中文版《DevOps实践指南》包含了众多科技公司在较早(2020左右)时的一些敏捷&DevOps实践案例，现在看来依然具有很大的参考价值，而里面的一些措施与手段，是现今国内IT业还在摸索的。
笔者目前担任国内大型商业银行的DevOps教练，就实际工作而言，阻碍颇多且繁杂，其中90%都是传统软件研发思维与敏捷的碰撞产生的摩擦，因此本文将日常工作中遇到的一些“坑”结合书本中的理论进行对比讨论，相比于只识理论，结合实际场景特别是国内IT研发现状来看更能够加深认知，希望对以下三种读者有所裨益：
- 对正准备实施 DevOps或敏捷的企业，提醒它们能够做好充足准备，不打无准备的仗，认识到 BizDevOps的价值与本质，不至于一腔热血开始，鸡飞狗跳中结束.
- 对正在实施 DevOps或敏捷的企业帮助他们 think out of the box，在风风火火的实施中，不要只停留在虚假的繁荣，让敏捷和DevOps对企业的发展产生本质上的积极影响.
- 对已经实施 DevOps 或敏捷到一定程度的企业帮助他们回过头来查漏补缺，看下有没有遗漏掉业务侧的缺失而引起的瓶颈，能否将业务侧也纳入到企业数字化战略实施的全景中，建立起贯穿全流程的交付价值流，进一步释放企业商业价值.
一、前言
二、流动原则
- 流动原则放在第一步是因为它是转型的基础，发现问题、优化问题、解决问题、提高效能，空口无凭，我们必须建立了统一的视野，所有stakeholder 都在 same page以后才有讨论的基础，否则就是鸡同鸭讲。如何能达到这一目标？我想首先建立全局端到端的价值流图是一个很好的方法，为什么价值流图这么重要，因为它是可视化的基础，我们都知道精益来源于丰田这个车企，丰田作为实体制造业，价值流先天可视化，随处可见，因此“一个组织基于客户的需求所执行的一系列有序的交付活动”并不需要非常刻意的梳理，而作为IT软件研发而言，因为非实体，所以很多流程中的阻塞点非常难以发现，其次，IT软件研发的流程因为操作频繁且成本低(鼠标点一点就可以踢皮球)，再加上大型企业中，各个管理平台，造成数据孤岛，所以我们将整个过程和状态可视化出来，便可以一目了然的发现问题了，基于发现的问题，进行特别的优化，才能药到病除
-流动原则里面的有6个内容：
-- 使工作可见：前面已经说了
--限制在制品数：比如紧急需求插队的情况，虽然日常中很难避免，但并不是一件值得推崇的事。因为前序工作还没有完成，新的工作又开始，极有可能导致前序工作的问题，另外数量的增加，对于质量的控制就会变得松懈。负责人员需要不断在不同的任务间切换，犯错的可能也会增加
--减小批量大小：批量越大，交付时间越晚，那么发现问题的时间就越晚，修复成本就越高，结合实际便是每次都是开发完大量的功能以后，才开始做测试，质量检查等，小批量便是每次代码改动以后触发提交级构建流水线完成基本的质量检查
--减少交接次数：融合团队，两个披萨团队可以在一定程度解决这个问题，比如环境的申请、测试的执行都是团队内部完成，那么来回扯皮推诿的事情就会少很多
--消除价值流中的困境和浪费：比消除浪费更需要先实施的是如何找到浪费，那么可视化的价值流便可以有效帮助我们识别阻塞和浪费，当浪费可视化以后，再来系统性的消除便会容易很多。比如，当我们发现其实大量的时间都在寻找正确的人提供资源，完成工单流程的时候，其实这就是浪费，我们是否可以通过明确的在线可视化流程，标准化工程来完成消除这样的浪费了？
三、反馈原则
--为什么需要建立及时的反馈机制，因为我们不想等到发生损失的时候才回过头来检查问题，在软件研发过程中，我们需要在开发测试过程中发现bug，生产发现，那就是生产事故了。此外，流动原则中需要发现并定位阻塞和浪费，那么完善的度量反馈，可以以数据的形式告诉我们浪费与阻塞存在于哪个环节。理想状况下，对于软件研发生命周期中的每一个环节我们都应该建立足够的信息反馈，来可视化数据展示可能存在的问题，当出现异常数据的时候及时报警，很简单的一个例子，便是红灯修复时长，过长的红灯修复时长，表明了我们搁置一个问题的时间，这是不合理的。
--群策群力的解决问题，在复杂系统中，可能没有一个人了解系统的全貌，明显的例子，如丰田制造里面的“安灯绳”，一旦生产线出现了问题，拉下“安灯绳”，所有人停止工作来解决问题。看起来这很浪费大家的时间，但从长远来看这是有所帮助的，首先解决问题的速度会变快，那造成的等待会减少，其次解决问题的过程也是组织级经验传播与沉淀的过程，最后尽可能在早期扼杀掉问题，这一点人员时间的支出，收益会很高
--从源头保证质量，我们每个人需要在自己所处的控制域里保证质量，避免自己交付的内容存在问题，这就是敏捷中为什么强调DoD的原因，明确的准入准出的定义，保证了质量的内建，如果此项工作没有达到DoD的标准，则不能进行流转，那么实际中我们通过验收标准来实施评判便是一个具体的实践，保证了价值流的顺畅。“做决策的地方一般远离执行工作的地方”这句话在实际工作中不断得到验证，是一种官僚与责任推卸的体现。
--为下游工作中心而优化，对于下游的同理心，是责任心的一部分，如果主动思考如何让下游的对接人更好的开展工作，将提升全局的效率与组织级的凝聚力，这是devops中建立信任组织的重要内容。书中的例子是我们应该关注架构、性能、部署方式等等的优化，便是对于内部下游人员的同理心
四、持续学习与实验原则
-- 建立学习型组织和安全文化意味着blame free，总是指责是官僚的做法，是滋生逃避与推诿的做法，我们需要解决问题，为后续的操作沉淀经验，关注如何设计系统避免事故发生，指责会带来恐惧，恐惧会带来推诿。虽然实际工作中践行这一条很难，我们一直强调要把责任抓实，但我们应该借鉴这种思维来管理我们的组织
--将日常工作的改进制度化，很典型的例子就是我们应该关注sonar扫描结果，比如技术债，也许一时半会并不会影响我们生产上的运行，但是持续下去只会造成问题的推积和低质量代码的繁衍(因为很多时候我们会参考别人写的代码)，但出现问题的时候，修复成本会变得很高，这也是为什么一直强调“重构”的原因，重构带来更好的系统架构，为我们实施敏捷devops打下基础，很多人都忽视了，系统架构本身对于敏捷和devops的重要影响，如高耦合性造成没办法小批量的持续交付，老旧的框架没办法完成自动化测试与单元测试
--把局部发现转化为全局优化，书中举了一个很好的例子，“美国海军核动力推进计划”，很重要的一条是无论出现的问题细微或者大小，都必须沉淀为手册经验，这样当发生任何问题的时候，我们都可以快速依据过往的经验进行解决，且这样的经验可以规模化的推广在整个组织中(可以理解为一个wiki或者指南)
--在日常工作中注入弹性模式，这里的例子便是混沌工程，我们需要人为刻意的去制造问题来检验我们系统应对问题的能力，增强我们系统的抗脆弱性。而不是被动的等待问题发生来救火
--领导层强化学习文化，领导会在更高的层面设计和执行流程，其他人在这方面没有足够的洞察力和权力，但是领导没办法亲自去实施，所以领导应该创造条件给员工去发现问题，引导他们在日常工作中主动的发现问题，提出问题，然后一起思考解决方案，两种角色是互补的，这样才能建立一个真正的学习型组织，推动我们在日常工作中改进，从而建立一个安全有活力的组织
五、选择合适的价值流作为切入点
--绿地项目和棕地项目的选择，对于大型企业来说，建议还是从绿地项目开始，因为棕地项目会存在大量的技术债不说，老旧的充满耦合的系统架构，根本没办法实施小批量的交付，与其它系统间的依赖导致了上线的相互等待，缺乏特性、功能开关导致上线的反复调整，所以从绿地项目开始更加合理
--记录型系统和交互型系统，虽然理论上说我们应该兼顾两者，任何一种系统都应该持续改进，提升交付质量与效率，通过devops的实施来增强自动化能力、质量内建能力、持续交付能力，但实际中我们对于一些较为老旧的系统，还是应该从局部的一些小的工程实践开始(甚至最后停留在这些小的工程实践)，实施devops或者敏捷的一大基本诉求就是快速交付应变市场，但是始终有一些系统不存在这样的诉求，所以这些系统我们可以从流水线、质量扫描等小的工程实践实施
--从最乐于创新的团队开始，变革、转型都是需要勇气与魄力的，并且看起来是一个充满风险的动作，但真的具备创新、创业意识的团队才能最快的意识到其中的价值。比如银行内部的一些年轻的团队。
--扩大DevOps的范围，积极的宣传项目组转型以后的成效，用实打实的数据，或者具体的案例来展示更具有说服力，从而形成规模效应。你或许可以取得小规模的成功，但推动整个组织的转型比想象中难多了，我们从小而精的团队开始实施，但是大规模开展以后，你会发现经验并不是总能复用，资源有限的情况下，先做什么需要站在企业的高度来思考这个问题
六、理解、可视化和运用价值流
--在一个项目决定实施敏捷或者devopss转型以后，第一步应该让所有可能参与的人，意识到价值在哪里，而流动会经过哪些人做哪些事，那么我们使用价值流映射这个方法论来实施整个过程,整个过程需要我们围绕一个产品(产品思维而不是项目思维)交付的全流程开展，所有相关人员必须投入热情同时参与，因为没有一个人能够知道为客户创造价值所要做的每一项工作。所有参与的人员，应该是在自己所在岗位有权限作出改变的，不然只会浪费时间，绘制整个价值流图不是为了确定每一个细节，而是识别价值增益点和阻碍点。那么价值流图画出来以后，我们应该重点关注，哪些工作存在频繁返工、等待(明明不上线但是又要提测)、浪费(同一个工作反复做，比如配置某个环境的参数)，我们明确价值流中的每个模块的前置时间和处理时间以及%C/A(percentage of complete/accurate，this is the percentage of information-based work that is complete and accurate the first time and requires no rework by downstream process),一旦确定了想要改变的指标，那么制定任务将变得清晰可见了
--------------------------------------------------------------持续更新中
