在最近的一次 ITSM的所有事项 在 Knowledge 16 的播客中，有人问我对敏捷和 DevOps 的看法。
对 IT 行业的任何人来说，DevOps 都不是什么秘密，它是当前 ITSM 领域最热门的话题，因为企业正试图打破 "开发 "和 "运维 "之间的壁垒，加快创新，实现新功能和服务的持续开发和发布。
尽管像这样的公司 焦点网 我们已经展示了他们是如何在这种新模式的基础上建立起一种新的工程文化，许多传统的IT组织在试图从旧的 "IT工厂模式 "转向一种新的、更加水平一致的、敏捷的合作模式时，面临着完全不同的挑战。
这个问题与其说是在开发方面，不如说是在运营方面，许多组织仍然缺乏基本的IT流程整合，如事件管理（IM）、问题管理（PM）和变更管理（CM）。
我们在与客户的合作中每天都能看到这种情况，我们发现IM、PM和CM处于不同的领导之下，有不同的优先级，并且很少有接口来确保数据的良好交接。通常缺少的是三个学科的端到端（客户）流程视角，在这种情况下，最终都是为了更快、更持久地解决客户和技术问题，同时最大化IT可用性。
我个人认为，这与ITIL®这样的框架被--我们可以说--"误读 "有很大关系。虽然他们的主要目标之一是建立一个更注重流程的文化，但许多组织已经把它们作为一个理由，围绕不同的流程建立整个功能，在许多企业中，这些功能最终成为很少相互交流的孤岛。
不管有没有DevOps，我们都需要问自己，把这些学科拆开，而不是在一个共同的目标下调整和整合它们，为客户带来什么价值，最终的商业目标是改善正常运行时间和客户体验。在这一点上，我们可能已经准备好转向DevOps，它是关于 "横向业务管理 "和围绕一个共同目标（而不是结构）调整具有不同技能组合的多学科团队。
然而，重新整合企业的运营方不仅仅是在一张纸上调整组织和团队。改变组织结构图本身并不会对业务成果产生影响。这种调整需要与理顺我们的流程并驾齐驱，去除不增值的工作，通过赋予我们的员工在更广泛的学科范围内工作的技能，使他们能够工作。我们需要奖励他们正确的行为（而不是通过把他们放在某个盒子里来限制他们的思维），并清理我们的工具环境，以确保我们能够创造有意义的知识，并能够将简单、重复的任务自动化。
只有这样，我们才能够利用DevOps的真正价值。
