为什么精益与DevOps相得益彰？

01. 精益DevOps的背景

硅谷著名投资人、网景创始人马克.安德森在2012年提出“软件正在吞噬整个世界”。

全球最大的书商（亚马逊）是一家软件公司，其Kindle电子书销售业绩早已超过实体书
最大视频服务网站（Netflix）是一家软件公司，传统娱乐供应商正面对巨大的威胁
增长最快的电信公司（Skype）是一家软件公司，增长最快的招聘公司（LinkedIn）也是一家软件公司
......

在当今社会，尤其是处在后疫情时代下，整个组织的生存环境趋严，具体表现为：

外部环境快速变化

所有利益相关者的需求模式在快速发展，客户、合作伙伴和监管机构都有迫切地需求。例如，投资者要求业务和规模增长，导致企业收购和重组的发生；竞争对手和合作者要求采取行动以适应快速变化等。

颠覆性技术的引入

通过数字化、新模型的创新使用和自动化，使得企业和行业的一些旧有模式和技术正逐步被取代。例如机器学习、物联网和机器人技术等发展。

加速信息的数字化和民主化

信息量，透明度和信息分布的增加，要求组织快速响应客户、合作伙伴和同事的意见和需求。

新的人才争夺战

随着基于创造性知识和学习的任务变得更加重要，组织需要一个独特的价值主张来获得并保留最优秀的人才。

而软件开发需求的增长，带来更大的VUCA（易变性、不确定性、复杂性、模糊性），因此，我们开始思考如何敏锐地感知环境来灵活地调整方向，去积极地拥抱变化。

1. 精益思想的前世今生

起源于美国：1881年一位名叫泰勒的美国人，他在米德维尔钢铁厂推行劳动时间和工作方法。1913年，亨利福特T型车的流水线生产出现，大规模生产诞生，提高了企业生产效率。

由日本丰田家族发展壮大：1926年丰田自动纺织机诞生；1937年丰田喜一郎将美国的大规模生产体制引进发展，提出准时化生产JIT；1953年，大野耐一发明应用拉动看板，被世人尊称为TPS之父；1973年世界经济大萧条的情况下，丰田却获得盈利；1985年，MIT研究团队把丰田生产方式定名为Lean Production（精益生产）。

丰田在落实精益生产的过程中，真正实现了成本效益结合。

1996年开始，精益思想逐步扩展到其他领域。

2. 精益IT的演变

2003年，Mary和Tom夫妇第一次透彻地把精益原则映射到软件开发中。2004年，微软在大卫安德森提供咨询的帮助下，通过15个月将微软绩效最差的团队变为最好的团队。

敏捷开发的引入让软件开发快了，但运维并没有跟上。2009年，DevOps的概念在欧洲因传统模式的开发运维之痛诞生。

2010年，看板方法创始人David亲自撰写看板方法奠基之作，该方法脱胎于丰田生产方式和约束理论，是精益方法的进一步延伸。

2015年，在中国，招商银行最开始推行精益看板，平安科技紧随其后。

3. 精益生产 VS 精益IT

精益生产主要处理生产产品的机器，意在消除人工操作的变异性，确保恒定的质量。简单来说，精益生产是一个理性的、科学的过程，它处理以可预测的、结构化的方式生产的有形产品。

精益IT专注于精益原则的新思维模式，精益是应用于人，而不是机器，意在提高相关人员的专业水平和解决问题的能力，减少在开发过程中的浪费。IT服务在很大程度上是不可预测的，在采用精益之前我们不知道该如何改进。

4. DevOps的演变历史

DevOps不是一种革新，是过往的质量体系的延伸，也是实践者长期以来所使用的最佳实践的汇总。

DevOps发展分为三个阶段：质量检测阶段（1875~1924年）、统计质量管理阶段（1924年~1950年）、全面质量管理阶段（1950年~至今）。具体如下图：

其中，统计抽样的概念在提出以后引起了轩然大波。因为对于企业来说，在检测产品的质量问题时，如果将全部产品都检查一遍，所产生的成本比产品本身卖出的价格还要高，也就是说卖产品反倒要赔钱。因此，统计抽样方法的提出，很好的解决了这个问题。

5. 什么是精益管理？

在工作中，要做一件事情的时候要首先想好做这件事的价值是什么，定义好价值后，再去识别价值流，识别出价值流以后，把流动中的断点找出并消除，以减少浪费。

在价值流动的过程中，始终站在客户的角度考虑问题，不能闭门造车，要解决客户的痛点。用客户的视角去区分价值和浪费，通过结构性的持续改善包括文化的改善，来减少浪费，增加价值流动的速度。

定义价值：价值来源客户
识别价值流：了解、分析、展示并改进价值评估流程
增加流动性：识别并消除浪费，使价值最大化
拉动/过程同步：让过程为客户带来价值，解决客户痛点
追求完美：持续改进并增加价值

6. 什么是精益IT？

精益IT是精益制造和服务原则在信息技术产品和服务开发和管理中的延伸，其目标是不断提高IT组织为客户提供的价值和IT人员的专业水平。精益IT专注于改善IT人员、IT流程和信息技术，以便为客户提供更多价值。

精益IT的7大原则：消除浪费、增强学习、推迟决策、尽快交付、授权团队、着眼整体、嵌入完整性。具体如下：

就精益理念的引入来说，制造行业引入得比软件行业要快，因为制造行业天生就需要用到精益的理论，很多制造业行业的IT企业里，都有精益管理的部门，这些部门会把精益的经营理念带到企业中去；而软件行业更多的是在说敏捷。

7. 精益和DevOps是怎么相得益彰的？

精益是指Just In Time，需要的时候按需要的量，生产需要的产品。

在精益应用领域、应用程序开发、生产力提高、应用程序维护和生产支持五个方面，精益思想跟DevOps相辅相成、共同作用，提高企业的生产经营效益。具体如图：

02. 企业该如何进行精益DevOps转型

1. 精益DevOps转型的愿景目标

企业在做精益DevOps转型的时候，首先要确定愿景目标，设立文化、组织、流程、能效和方法工具等不同层面的度量管理。

以前很多企业没有度量管理，因为在当时的阶段不需要，现在需要了，所以需要相应的度量管理体系（中国信通院正在制定相应的度量体系）。

2. 精益DevOps转型的组织架构变化

DevOps从来都不是技术问题，而是管理问题。

不管是精益管理还是敏捷管理，最终都是要服务于企业战略目标，降低成本、提高效益。在后疫情时代，对大多数企业来说，最根本的是怎么存活下去，而精益DevOps是提高企业存活率的利器，减少浪费、增加价值。

3. DevOps现状调研

DevOps精益调研需要从企业的角度去思考问题，才能真正给企业带来价值。

精益实践咨询调研从需求承接、立项、需求评审、来发、SIT测试、UAT及部署、最后上线整个流程，针对不同的人员进行一对一访谈，具体如图：

4. 支持稳敏双态的DevOps平台

调研做完后，需要对数据进行差距分析，把企业所有的痛点、期望、现状问题等梳理和抽象。在建设敏稳双态DevOps平台时，强调平台的可变性，根据领域模型，平台功能按721分（70%固定功能，20%可配置功能，10%定制功能）。

在将DevOps平台引入企业时，尽量保证平台的通用功能比较多，做一定的配置就能能够实现流程的流转。最后，再根据企业自身需求做定制开发，这样才能保证平台引入后能快速投入使用，赶超同业。

在DevOps的咨询阶段，需要思考在流程体系层面怎么去做咨询。另外就是工程实践层面，把流程体系定完之后，需要有工程实施的指导。

企业需要真正的把DevOps用起来，因为哪怕采用的是最先进的架构，最先进的方法论，不去实践运用的话也是白搭。

在企业研发流程中，要关注平台端到端是否能联通、可配置，平台功能否满足不同团队的需求。

虽然我们想尽量的把团队进行统一管理，但通常来说非常难。因此，在建设时需要思考怎么尽量地使团队间的协同达成一致，只进行少量的裁剪，去做相应的支撑。

精益DevOps是智慧研运中台的一部分，支撑整个业务和生态。本人的理想就是未来在中国，IT人员只需要懂代码和业务，剩下的通过研运中台来实现。

03. 精益DevOps实践的价值和收益

在产品规划、需求/项目管理、开发/测试管理、上线/运维管理、产品运营都会使用到精益的原则，精益的原则不仅是闭环，也是底层逻辑。从客户提出需求，再到最后产品交付给客户的这一过程里，怎么通过持续不断的改进，最终减少浪费，以提高价值流动速度，是精益DevOps的核心。

精益型组织需要在灵活性和稳定性中找到平衡，将组织环境的不确定性转化为组织发展的目标和增长绩效的确定性。精益型组织具备的三个特征：

快速响应

能够快速响应，灵活，赋能于行动，并使行动变得容易。通过创造无“墙”的透明文化，检视和调整以快速响应变化。

反脆弱

当面临压力时，敏捷组织的反应不仅仅是强健有力，而且随着压力的增加，绩效反而有所提高。培养学习和分享的文化，激发团队思考和创新力。

持续改善

很少有公司实现了整个组织的敏捷性，但很多公司都已经在业绩单元中推广敏捷性组织运用，并都希望员工采用敏捷性的工作方式。通过持续改善，为IT团队提供最大的支持。

04. 精益DevOps总结

精益思想的核心理念是精益（发现问题）+六西格玛（解决问题）+戴明环（螺旋上升，持续改善）。

认知负荷包含本质负荷、相关负荷和外来负荷。信息本身有复杂度，在做的过程中学习，在做的过程中有可能会受到干扰。

每个人的认知负荷都是自己的瓶颈，经验是“十年一年”还是“一年十年”，取决于自己。条条大路通罗马，精益与DevOps让你生在罗马。