多年来，我们已经证明了DevOps实践会带来更好的绩效和组织成果，也学习并分享了组织的发展，以及如何更快地发布更好的软件。
看到显著进展的同时，我们也看到大多数组织都在努力超越他们进阶的中间阶段。这些团队可能是较难扩展DevOps工作方式的开发团队、运维团队和安全团队。
然而，有些组织确实取得了成功。他们扩展了DevOps超出最初早期采用团队的实践，继续在整个组织内不断发展和改进。是什么造成了这种区别？成功的组织实施的更深层次结构的变化。今年的DevOps调查显示可以产生优异结果的结构变化：将DevOps原则应用于软件交付和变更管理。
为何是研究平台模型和需求变更管理这两个方向呢？
平台模型是相当有效地赋能应用团队的新方法。一旦正确实施，它就会起作用，结果就是更快、更有效地交付高质量的软件、满足组织的业务需求——大规模应用也同样如此。需求变更的管理是常见的拖慢软件发布速度、阻止企业实现目标的因素，高效的需求变更管理提高了组织在业务所需级别上按时、保质、安全地发布软件的能力。
报告中，我们在调查中讨论了发现的各种变革管理各种方法，并展示如何应用DevOps原则把变更管理从阻碍变成更快、更安全的软件交付的方法。
将DevOps扩展到Dev和Ops之外
在任何组织中，通过软件创造价值不仅仅依赖于开发人员和运维人员之间的良好协作。几乎所有相邻的业务功能最终都是软件过程的一部分，这些功能需要与技术交付团队一起发展。敏捷曾经是工程师的专属财产，但现在已经不是了。这些年来，从软件团队扩展到财务、人力资源、执行领导团队等等。我们希望DevOps原则和实践除了最初开始与他们合作的开发和运维团队，在其他领域也会继续传播，比如DevSecOps、FinOps，可能还要其他我们没见过的新的表现形式。
也许再过几年，“DevOps”这个词已经是老生常谈——甚至逐渐消失——因为有那么多的人和组织完全采用了DevOps的协作原则：沟通、小批量迭代、反馈循环、持续学习和改进。
运用内部平台团队扩展DevOps实践
DevOps从根本上讲就是让人们能够彼此合作，为了共同的商业目标而奋斗。这必然包括团队使用的过程和工具，但是还需要经常进行对话来解决组织内部阻碍良好发展的结构性问题，让工作能够自由流动和持续改进。尽管DevOps的实践已经被很好地理解和采用了十年。在这场运动中，我们仍然看到大多数组织都在努力将DevOps扩展到少数成功领域之外。DevOps往往无法进一步扩张的一个原因是，大多数企业的结构造成了激励不一致和缺乏责任感，这使得合作无法推进。
DevOps演化模型
单独采用一组实践的团队不能进一步推进DevOps 的进阶，必须进行相应的结构更改，以优化团队的工作方式。 DevOps演化模型表明，在没有团队外部的人工批准的情况下，在第4和第5阶段之前，组织不会在自助服务和安全集成方面取得进展（第三阶段）。
第三阶段是一个关键的趋同点——信任已经在第一阶段和第二阶段建立了；团队获得了更多的自主权；部署不再是一场灾难。 在这一点上，团队可以扩展他们的新合作方式，跨越更多的功能边界，超越Dev和Ops。
在第3至第5阶段，我们看到了一刀切的规则和流程的松动，其基本重点是自动化。在这些阶段，自动化已经超越了为单个个体或团队解决局部问题的范围，扩展到了更独特、更高的目标：为企业创造价值。
