几乎在每一家我工作过或者咨询过的公司，都因为不同环境（开发，测试，阶段，产品 ）的配置不同而造成巨大的浪费，我把它称为“环境地狱”。你听到过多少次一个开发者说“it worked on my laptop”？当代码从一个环境到下一个的时候，软件会因为每个环境的配置不同而崩溃。我曾见过团队花费几天甚至几周的时间来修复环境问题中的bug，但是这些bug不是由于代码中的错误而引起的。无疑，环境的不一致是敏捷性的头号杀手。

Tip：创建标准的基础设施蓝图和实现持续交付，可以确保所有的环境都是完全一致的。

人工干预会导致人为错误和不可重复的过程。在测试和部署两部分，人工干预对敏捷性影响最大。如果手动进行测试，是不可能敏捷地实现持续集成和持续交付。此外，手动测试增加了产品不合格以及产生意外产品的可能性。当部署是完全或部分手动执行时，部署失败的风险显著地增加从而降低质量和可靠性，导致增加额外的工作量。

Tip：自动化构建和部署过程以及实现自动化测试方法，如测试驱动开发（TDD）。

一个团队的软件开发生命周期（SDLC）的成熟度直接影响他们的提供的软件的性能。没有什么新奇的，SDLC成熟度已经困扰了IT几十年。在DevOps的年代，我们努力提升可靠性和质量来达到以较短的增量来交付软件德目的。对一个团队来说有一个成熟的开发过程更为重要。

有些我访问过的公司还在练习瀑布方法。这些公司在促进DevOps，因为他们没有任何敏捷开发的经验。但是，并非所有的企业敏捷开发都做得很好，一些是企业还在他们的敏捷开发行程的早期，而另一些已经实施了名为“Wagile”的方法。

Tip：在训练方面投入时间精力和非指责性事后调查来不断地得到反馈和改善。

很多公司已经变更管理流程很多年，并且已经熟悉了新的流程。问题是，这些进程是在公司部署和更新后台解决方案后，或者是在更新不经常发生的基础设施变化后才会形成。快进到如今的环境下，应用由许多可以快速改变或者部署小组件或者为微服务组成，因此突然之间，这个过程妨碍了应用程序的性能。

许多大公司有完善的ITIL流程来促进DevOps。在这些环境中我看到了开发团队实现高度自动化的CI/CD过程，只为了停下并等待每周一次的人工审核大门。有时，这些团队不得不经过多重审查（安全，运营，代码和变更控制）。更糟糕的是，等待审查是需要很长很长的时间的，导致审查程序不得不推迟一个星期。许多这些审查是可通过对现有进程一个小小的改动，就可以完全避免的。