值得庆幸的是，每一个时代总会有那么几个思想开放的英雄如漆黑中的萤火虫般冒出来。他们知道这些不同团队的开发者们必须要找到一个可以协同工作、进行交流、并且能够弹性的向客户保证对方将会拿到最优的解决方案的方式。这种尝试最早可以追溯到1957年，伟大的约翰·冯·诺依曼和同行们的努力。但是我们最终却是等到2001年才收获到革命的果实，当时行业的十多个精英创造出了如今闻名世界的“敏捷宣言”。
敏捷宣言基于以下十二条原则：
我们的首要任务是通过尽早地、持续地交付可评价的软件来使客户满意。
乐于接受需求变更，即使是在开发后期也应如此。敏捷过程能够驾驭变化，从而为客户赢得竞争优势。
频繁交付可使用的软件，交付间隔越短越好，可以从几个星期到几个月。
在整个项目开发期间，业务人员和开发人员必须朝夕工作在一起。
围绕那些有推动力的人们来构建项目。给予他们所需的环境和支持，并且信任他们能够把工作完成好。
与开发团队以及在开发团队内部最快速、有效的传递信息的方法就是，面对面的交谈。
可使用的软件是进度的主要衡量指标。
敏捷过程提倡可持续发展。出资人、开发人员以及使用者应该总是共同维持稳定的开发速度。
为了增强敏捷能力，应持续关注技术上的杰出成果和良好的设计。
简洁——最大化不必要工作量的艺术——是至关重要的。
最好的架构、需求和设计都源自自我组织的团队。
团队应该定期反思如何能变得更有战斗力，然后相应地转变并调整其行为。
敏捷宣言是为银河系带来和平以及维护各自的平衡所迈出的很重要的第一步。在很长的时间里，相比此前基于流程和机械化的方式，这是第一次基于文化和“人性”来将不同的关键项目关系人连接在一起的方式。人们开始互相交流，进行基本的碰头会议，并开始不断的交流意见和看法。他们开始意识到他们是有着很多比想象中还多的共同点的，客户也开始成为他们之中的一员，而不再是像以往一样只是往项目砸钱然后开始求神拜佛祈求一切顺利如愿。
尽管前面还是有不少的障碍需要克服，但是未来已经光明了许多。敏捷意味着开放和拥抱(需求)改变。但是，如果改变过多的话，人们就很难专注到最终的目标和交付上来。此时精益软件开发就开始破土而出了。
因为对精益软件开发的着迷以及为了达成放逐和驱赶风险的目的，一些程序员的子孙们就开始探首窗外，开始向软件之外的行业进行取经。他们从一家主要的汽车生产商身上找到了救赎。丰田生产系统在精益上面的成就是不可思议的，同时它们的精益生产的经验也是很容易应用到软件开发上来的。
精益有以下7个原则：
杜绝浪费
内建质量
创建知识(放大学习)
延迟决策(尽量延迟决定)
快速交付
尊重人员(团队授权)
全局优化
将这些放到敏捷上去的话，精益原则就能让人们在从精神上关注做正确的事情，同时还能够让整个开发流程拥有足够的弹性。
一旦敏捷和精益软件开发被软件开发团队采纳，那么下一步就是把这一套原则应用到IT团队上来。把IT也纳入到整体战略上，然后我们就来到了DevOps跟前了！
进入DevOps – 高速公路的三条车道
老一派的软件开发团队成员会包含业务分析员，系统架构师，前端开发者，后端开发者，测试员，等等。优化如敏捷和精益原则等的软件开发流程的关注点就在这些地方。比如，软件一旦达到”可以生产“的程度，就会发到系统工程师、发布工程师、DBA、网络工程师，安全专家这些“运维人员”的手上。这里该如何将横在Dev(开发)和Ops(运维)之间的鸿沟给填平，这就是DevOps的主要关注点了。
DevOps是在整个IT价值流中实施精益原则的结果。IT价值流将开发延伸至生产，将由程序员这个遥远的祖宗所繁衍的所有子孙给联合在一起。
这是来自Gene Kim的对DevOps的最好的解析，如果你还没有看过他的《凤凰项目》这本书的话，我建议你真的该好好花时间看看。
你不应该重新招聘DevOps工程师，且DevOps也不应该是一个IT的新部门。DevOps是一种文化，一种理念，且是和IT糅合成一整体的。世间没有任何工具可以把你的IT变成一个DevOps组织，也没有任何自动化方式可以指引你该如何为你的客户提供最大化的效益。