10-敏捷和DevOps是敌是友？
作者：互联网
狭义的DevOps
首先呼应标题，敏捷和DevOps理应是友，狭义的角度来说敏捷和DevOps不存在竞争关系，他们都是为了提升交付效率而进行的管理改进和流程优化，在DevOps出现之前，敏捷开发重点解决的是研发过程中的效率问题，期望是通过敏捷开发、敏捷管理来提升团队绩效，通过迭代、增量的方式快速交付产品增量；
但是当研发效率提升后，我们兴致勃勃的想要发布产品增量时，却发现需要经过明确的部门间交接，严格的审批流程和低效的手工操作才能完成功能发布，所以从整个交付管道上来说，运维开始成为价值流中的瓶颈，这时狭义的DevOps变诞生了，当然这也是DevOps兴起时重点关注的部分，即通过持续交付流水线将发布过程标准化、自动化，以此来解决发布最后一公里的效率问题，但是交付效率提升并没有终点，也不是搞了敏捷和DevOps就能解决问题的，应该是一个持续改进的过程，类似木桶原理，价值流中也永远会有一个瓶颈，不断找到瓶颈并进行优化才能助力效能的持续提升。
广义的DevOps
随着近几年DevOps的流行和火热，有了所谓的广义DevOps，简单来说广义的DevOps应该是建立在精益、敏捷、持续交付等理论基础之上的，它不是一个新事物、新方法，而是把各种实践结合在一起，归根结底还是如何运用各种方法提升效能的问题。
广义DevOps应该包含如下的几部分内容：
首先是精益，它是源自1980年代的丰田管理系统（TPS），关键实践包括价值流、看板和消除浪费等理念，目标是通过小批量、甚至是单件流的交付方式，缩短Lead Time。精益的原则聚焦在如何通过系统思考为用户创造价值。
敏捷 前面多篇文章都在聊敏捷，这里就不在赘述了，总之，2001年17位行业专家提出了《敏捷宣言》，敏捷里强调轻量级软件开发，小批量、增量式的发布，建立跨职能的小团队提升组织的效率。
持续交付 持续交付是2009年由Jez Humble和David Farley共同提出的，把持续集成做逻辑上的延展，形成持续交付的新方法。持续交付的核心概念是部署流水线。
丰田套路（持续改善） 提到持续改善，会有一个有意思的故事，随着丰田生产系统、精益生产被更多人熟知后，出现了大量的专家学者去到丰田学习精益管理，但是丰田内部人士对很大一部分人的评价是，他们只学习了消除浪费、看板管理、自働化、JIT等实践和方法，却忽略了我们最核心的东西，持续改进的文化。
所以一种观点认为DevOps是集合了多种方法和理论的效能改进思路，有时候更像是盲人摸象，每个人都有自己的理解，但关键是能否通过自己理解的DevOps来帮助企业解决问题。
DevOps三步工作法
所谓的DevOps三步工作法是希望通过流动、反馈和持续改善的三步走，来指导企业实现DevOps改革：
建立流动 建立流动更多的是要关注组织交付价值流，从可视化、可视化管理、限制在制品、小批量交付到价值流映射一步步建立高效流动机制，确保持续的价值交付；
获得反馈 反馈的建立可以通过给团队授权、借鉴制造业安灯拉绳的理念、提倡通过质量内建保证产品质量、结合ABTest、灰度发布、蓝绿部署等测试右移的理念加速反馈，并结合反馈实现持续改进；
持续改善 持续改善其实是最难的部分，不是简单的实践堆砌，更多的是文化上的转变，比如：如何建立学习型组织、怎样营造安全文化，这里的安全更多强调的是一种安全感，确保员工可以勇于尝试和创新，有空间去发挥自己的价值，激发内驱力，当然持续改善还要关注如何做到全局改进和系统思考，总之，不是依靠约束和管理就能实现，需要持续的文化建设和理念上的认同。
CALMR
最后，借鉴SAI对DevOps的解读做一个收尾，DevOps理论中首当其冲的就是文化建设，除此之外还应关注自动化、精益流动、度量、和恢复能力，而如何度量会是DevOps运动中的一个难题，恢复能力又容易被轻视。所以，敏捷还是DevOps并不重要，或许用不了多久又会一个新的名词诞生，重点是它能不能帮助组织进化，帮助企业走的更远。
DevOps is a mindset, a culture, and a set of technical practices. It provides communication, integration, automation, and close cooperation among all the people needed to plan, develop, test, deploy, release, and maintain a Solution. --© SAI.
标签：10,丰田,持续,DevOps,精益,交付,敏捷 来源： https://blog.51cto.com/13676635/2589449