这个IEEE的DevOps发布研讨会上周致力于提供“关于如何通过加速整个企业的软件交付来加快创新速度的专家建议”，这显然意味着DevOps是一个很好的方法，我完全相信这一假设。
但在山景城的计算机历史博物馆活动主持人花费的时间相当数量的谈论广泛的耐药性的起源到许多真实世界的DevOps实现，以及如何克服人们完全可以理解担心的DevOps会变成对每个人来说都意味着更努力的工作!
“这是很自然的，”主持人说杰斯谦卑，Chef的副总裁兼DevOps相关书籍的合著者(精益企业：高绩效组织如何规模创新，和持续交付：通过构建，测试和部署自动化可靠的软件发布)，因为DevOps对组织的所有部分都提出了新的要求。
弗雷德里克·保罗
DevOps如何影响业务人员
Humble说，在DevOps环境中，业务人员突然需要花更多的时间与工程师交谈，而这项任务他们可能并不总是喜欢。例如，忙碌的营销人员可能不会把时间花在担心他们过去可以忽略的技术问题上。
DevOps如何影响开发人员
与此同时，软件工程师现在必须与商业人士交谈。在很多情况下，Humble指出，人们成为工程师的全部原因是这样他们就不必和其他人交谈。
而这只是开发人员面临的变化的开始。Humble说，在许多组织中，开发人员通常是根据简单的（如果经常是愚蠢的）指标来衡量的，比如他们编写了多少行代码。DevOps提供了一组新的、更复杂的开发人员度量。
DevOps如何影响IT运营
Humble说，在瀑布式开发环境中从事IT运营的人可能习惯于“每18个月就有一件讨厌的事情发生”。在DevOps环境中，“现在它总是会出现”，尽管这些版本应该与瀑布版本有着深刻的不同，但ops人员最常见的反应是，“请停止它！”
怎么办呢
对大多数人来说，自然的反应是创造一个障碍，在许多组织中，这种障碍的形式是变革管理实践。”“其目的是确保变革永远不会发生，”Humble声称。这种阻力很容易理解：人们害怕失败，害怕失去工作，Humble说，很多公司都用精益原则（包括DevOps）作为“解雇很多人的隐喻”
如果人们害怕，谦卑说，“他们会尽一切努力阻止你，让整个事情停止。”为了防止这种情况发生，他说，你必须清楚地表明，这种改变不是解雇员工或减少员工，而是学习新技能和对你所做的事负责。
研讨会的主持人指出，开发人员喜欢抱怨DevOps如何让他们把所有的时间都花在测试上，而让他们没有时间编写任何代码。“这可能是一个问题，”Humble指出但这比开发人员编写代码而不关心它在现实世界中的工作方式要好。”
“离散事件不傻还是邪恶，”他总结道。“但是，如果他们从来没有体验自己行为的后果，他们无法得到它更好。”
见Jez Humble的陈述：企业DevOps：打破开发和IT运营之间的障碍.