DevOps和敏捷方法论无疑改变了技术团队的优先级和实践。现在，随着组织为即将到来的后Covid热潮做准备，这些努力将需要站在文化变革和吸引客户的最前沿。DevOps和agile需要脱离IT部门，成为每个人的最佳实践。未来一年，IT专业人士和管理人员的职责将是将所学知识应用到企业的其他部门，并对其进行教育和演示这些理念的威力。
毫无疑问敏捷现在无处不在，至少在IT界是如此。正如我们之前讨论的最新数据显示95%的组织采用敏捷开发方法。然而，只有33%的人报告说他们的团队中有超过一半的人在实践敏捷原则。
敏捷实践可能是许多企业在企业大分散的情况下度过危机的原因。”“看看当流感大流行来袭时，许多人能以多快的速度适应新的形势，”Johan Karlsson说，他是性能”即使是非常大的企业也能在很短的时间内转变为完全分销，这真是令人震惊。这是一个已经实施的敏捷改进变得格外有价值的例子。”
随着我们进入下一个时代，DevOps和敏捷的许多发展都是关于拥有正确的心态。例如，DevOps“是一个拒绝被定义的运动，”Mike Loukides说，他是O'Reilly Media“许多组织都将DevOps作为一套特定的工具和管道来使用部署应用程序。然而，在利用DevOps进行运营团队、开发人员和管理层之间的互动文化变革的组织方面，它仍然参差不齐。当谈到在开发人员和操作人员之间提供直接协作时，这一点更多地体现在违规行为上。”
那么，DevOps是否兑现了它的承诺？在一些专注于正确使用DevOps的公司，结果令人印象深刻。”我们采用了多种实践，最重要的是，文化心态的改变，这是DevOps的核心所在https://smartcommunications.com/“target=”\u blank“rel=”noopener noreferrer nofollow“data component=”externalLink“>智能通信”开发和操作团队的这种更紧密的协调，减少了为满足操作需要而对功能进行的修改、更频繁的发布、更好的操作稳定性和更高的质量。”
DevOps计划的成熟度是一个主要因素。”Karlsson说：“一方面，整个行业，比如游戏开发行业，都因实时运营而发生了革命性的变化，DevOps很快就成为了其中的一部分。”另一方面，有些行业正从更孤立的方法发展而来，这些方法只是触及可能性的表面，但它们已经开始了这段旅程。”
“你不能只是拿一个敏捷证书，读一本书，看一段视频，然后实施那里建议的实践，”卡尔森说希望实现大规模敏捷框架的管理团队会遇到这种风险。最真正的痛苦通常不在团队层面，而是跨团队的系统层面。”
是软技能可以决定DevOps和敏捷项目的成败。”您可以设置所有的DevOps工具、管道和仪表盘，但是如果团队开始恢复到旧的临时更改、部署而不进行测试的方式，那么流程和方法就会分崩离析，”Cisco杰出的客户体验工程师Joe Clarke警告说：“同样，使用敏捷，您需要一种与战略保持一致的透明文化，在这种文化中，所有工作都被记录下来，这样您就可以对战略进行端到端的跟踪和问责。”
在Donoghue的公司，DevOps面临的最大挑战是将利益扩展到客户。这意味着“平衡对客户的支持和对影响他们的变化的不同偏好，”他说连续交付就是一个很好的例子：有些客户知道他们总是有最新的更新，而有些客户则担心更改的频率。确保所有客户对变更的质量有高度的信心是继续向前迈进的一个关键部分。”
客户还需要成为敏捷工作的前沿和中心。”Loukides说，向客户演示“应该是任何敏捷计划的核心”敏捷实际上就是通过对你的方向做许多小的、中间的修正来达到正确的终点。所以，如果在大多数情况下，缺少的是对客户的承诺。”
当然，客户在各个层面都有参与，不一定是手机消费者。”Donoghue说：“我们已经发现，需要一种DevOps方法来继续改进并将收益扩展到运营中，作为大型企业的供应商，我们还没有发现开发团队直接与最终用户协作是切实可行的。我们更愿意与客户代表合作，他们的重要职责是在每个客户中找到合适的合作者，收集和整合他们的反馈，然后平衡他们不同的需求和优先级。”\
Donoghue建议从“自动构建、测试和部署”开始DevOps。微服务方法有助于封装更改的范围，允许有针对性地发布较小的版本。在清楚了解和更容易控制风险的情况下，这些措施的实施速度会更快。通过最小化开发、测试和生产环境之间的差异，进一步增加控制和降低风险，集装箱化进一步改善了这一点。”
通信切断了DevOps或敏捷工作可能遇到的误入歧途的粗糙补丁。”克拉克说：“现在面对面的时间和直接合作减少了，这一点尤其如此。”不要让问题恶化，让工作脱轨。“良好的协作和沟通工具会有所帮助，他补充道——”在这些工具适合你的工作流程的地方完成工作比在与人同步时做一些不自然的事情要容易得多。“同时，他建议保持这种工具的简单。”体系结构中的盒子越多，东西就变得越脆弱和支离破碎，这会导致流程的挫败和软弱。“研究正确的工具”用于源代码管理、CI/CD构建、测试和部署以及问题跟踪，因此，您可以使用单一的工具来完成特定的任务，而不是每天都使用一个新的工具或其他相互竞争的工具来完成相同的任务，”Clarke建议说。
需要注意的是，仅仅宣布您正在创建一个DevOps实践并不能完成任何事情创建DevOps团队或雇佣DevOps工程师的组织几乎完全没有抓住重点DevOps是关于现有团队之间的协作，而不是创建新的团队和新的专业。在很大程度上，DevOps所设想的开发小组和操作小组之间的协作还没有发生。”
人工智能和机器学习的出现可能有助于改变这一等式，Loukides继续说在这方面已经取得了一些进展，因为人们现在正在谈论MLOP——而DevOps完全有能力解决这些问题。但目前MLOps还很不成熟。我们刚刚开始需要很多工具，比如数据的版本控制，模型的版本控制，不确定应用程序的测试，模型的部署管道需要几天的时间来训练，Loukides补充道：“人们还没有充分认识到人工智能应用程序与DevOps成长过程中的典型web/数据库应用程序有着根本的不同。”如果你和从事软件开发的人交谈，你会发现他们中的许多人都在做敏捷流程，这些流程只是他们旧流程的重命名版本敏捷有很多价值，但在敏捷宣言发表20年后，我们仍然没有兑现承诺。“虽然宣言强调与客户的深入接触，但一些工程团队仍然避免与客户接触，”他说这意味着敏捷宣言中最重要的事情是大多数开发团队最不可能做的事情Karlsson说：“一个团队可能真的通过正确的工具集和心态获得了成功。”然而，如果没有管理层和其他团队的正确支持来实现全局优化和成功的交叉传粉，他们可能只是将潜在的问题从一个领域转移到另一个领域。”他补充道，“如果一个组织告诉我他们已经到达了最后一站，那么他们已经到达了敏捷的天堂他们错过了持续改进的全部内容，令人难以置信。”
