任何IT项目经理或应用架构师，谁在引人注目的项目上做了大量的投资，谁就感到这是一场恶梦，只能眼睁睁地看着它在生产阶段失败，因此因为非功能性需求，如性能或可扩展性问题。看到的只是，一个开发良好的应用，通过大量的应用生命周期管理（ALM）流程无缝地迁移，最后死去。或者，这个情节会更加地糟糕，实际部署的应用程序无意中暴露了特权数据，且不需要的充分的安全限制。

　　随着强大的开发和操作团队一起工作，以一种统一的DevOps方式来进行应用开发、部署和运行时管理，这些问题就可以避免了，而且应用生命周期管理可以很大程度上简化。然而，常常在DevOps应该做什么和日常操作中究竟发生了什么之间存在分歧，这是一个问题。　　

最后开发和操作会走到一起吗？

　　DevOps是一个嵌合体，创建它是用来解决战略需求问题，以及在软件初期的大量操作需求。它本就应该结合操作和开发这两个不同的派系，所以他们应该共同工作，高效地创建部署更好软件。DevOps在这两个世界中都有它的足迹，它是这两种文件中的连接和共同的理想的位置。从这里，可以定义和创建标准,来集成ITIL(信息技术基础设施库)和CMMI(能力成熟度模型集成)。因为所有人考虑问题的方式都是一样的，试图使用共同的战略来解决问题，所以流程得到了改进。　　

太少，太晚

　　不幸地，许多IT商店仍然在先开发，再操作。没有统一的DevOps，然后，当组织等到开发流程快结束时，甚至才开始思考性能和安全，这时成本增加了，风险也增加了。

　　Don Brancato，Hewlett-Packard公司的企业架构师，他只是说，“当你在产品已经形成后附加入质量和安全的话，成本就会很高。而且还有不能按时上市的风险。当在设计时非功能性问题解决后，那么开发人员可以编写代码来满足那些需求。这样成本的确会少一些。”　　

如果进展顺利，是否可以把统一的DevOps变得敏捷？

　　但随着不断提升的压力，推动产品越来越快地面市，把操作视图融合到设计阶段，这真的实用吗，尤其对于采用基于敏捷方法进行应用开发和部署的组织？

　　Brancato说，对于为什么正确的计划应用减缓敏捷和Scrum的流程，还没有理由。现在已经有大量的关于非功能性需求的信息，团队可以依赖，包括政策、程序、规则和针对每个行业的纵向指导方针。“有一本非功能性需求手册在手，就不会违反任何一条Scrum原则，”他说。我们知道这些东西是存在的。他们是隐蔽的，必须有人来做这项工作，必须在产品发布冲刺前覆盖掉它。

　　在计划、开发、或Scrum冲刺或部署阶段，参考一个规则库或行业标准手册，这并不违反Scrum原则。

　　一旦统一的DevOps正确完成，这些好处可以极大地量化出来了。通过编写正确的代码，即代码感知到非功能需求，并与其保持一致，这些代码在未来的产品中就可以重复使用。

　　“这个过程具有成本效益，” Brancato说。“我期待更好的执行商店，体验35%的代码重用，只代码最初是以安全的方式编写的，”缩减成本、减少开发时间、降低生产后期失败或后期制作风险，并确保产品质量，来满足开发和操作的期望和需求。当所有这些做完，那么组织就知道了它的应用开发人员、运营管理团队和管理ALM流程的人对DevOps做对了工作。