有人说DevOps是关于文化的，而另一些人说DevOps本来就是一种软件开发方法论。尽管业内一直存在争议和讨论，每个人也有各自不同的定义，但通常万变不离其宗，DevOps是一种强调IT行业的软件开发人员与其他干系人之间的沟通、协同与合作的哲学。
为什么DevOps？
一条公认的知识是：实际上软件开发、质量保证和IT运维之间是相互依赖的关系，而且必须确保这些职能组成一个整体工作运转才能确保快速交付满足行业标准的产品和服务（传统上职能之间都是相互分家的）。正是因为这个原因，持续集成（开发领域）、自动化（QA）以及持续交付（IT运维领域）这些概念日渐流行和普及。不过这些目标都是一样的，即：如何能够向你的最终用户交付稳定、功能丰富的系统。
公认认为，DevOps包含了一整套工具和技术，这些工具和技术能够将应用软件开发生命周期的各个阶段（从需求、开发、测试直到部署）无缝整合在一起。如果实施和集成的方式恰当，这些工具就能够赋能团队实现『持续构建』、『持续集成』、『持续测试』以及『持续部署』。所以，DevOps让团队能够对产品和网站进行持续地小规模变更和升级，同时还能保证0宕机时间。如今，以应用交付和消费为基础的SaaS已经称霸全球，DevOps已经成为科技厂商近乎实时交付新产品特性、修复缺陷、进行性能和安全升级的关键成功因素。
为什么用看板方法落地DevOps？
看板方法的主要优势之一在于，它鼓励团队专注于改进流程系统中的工作流转。当采用看板方法，团队会变得善于持续交付他们完成的工作。所以，看板方法能够促进团队以少量新功能或缺陷修复来完成增量的产品发布。看板方法的这一特性令其非常符合DevOps要求的持续交付与持续部署。
看板方法的另一大优势在于，它让团队能够对整个价值流加以可视化且确保稳定的流动。所以，它能合并不同职能、不同活动的流程，从开发到集成/构建、测试、部署直到之后的应用监控。最开始，它会帮助开发人员和运维人员共同协作。一段时间后，这两个职能和各自的流程就能够进化成一个单一团队和一条同时包含开发与运维两项活动的单一流程。看板方法让你能够看到DevOps运作的整个过程，并且看到向DevOps文化的转变。
这种可见性确保了每个人都知道一个工作项必须流过哪些阶段才能够称之为『完成与成功』，这样做优势明显：
01
要解决哪些事情
当流程呈现在眼前，你就会看到，对于所遵循的整个流程中，需要先解决哪些问题。实际上，若采用看板方法，你会从你当前正在做的方式开始，而后尝试持续改进。
02
优先级一目了然
干系人只要瞜一眼『看板墙』，就能知道哪些事情优先处理以及有哪些工作项。这能确保在考量各项工作对整个流程系统稳定性的影响之后，再选择正确或重要的工作。选择正确的工作项能确保给流程带来的摩擦力最小，也就是说，这能确保每个团队（包括内部客户团队）明白哪些工作是与公司或部门目标是一致的。
03
立即注意到受阻
如果存在依赖或者问题，决策者和解决者能立即介入并弄清楚下一步怎么办，从而消除了反馈延误的代价。
04
采用拉动系统
看板方法鼓励『暂缓开始，加速完成』。这能确保你同一时刻只在最少量的工作项上花时间，减少了上下文切换和生产力流失。这还能确保恒定的流动，当你卡在了一项任务上，不会阻止其他人拉入新的工作，整个系统是稳定的。
05
自动化有的放矢
看板墙会展示工作如何流动、哪里有瓶颈、周期时间有多长，实际上也就展示了在哪里进行自动化最有效、哪里需要改进。
看板方法无法取代战略意图。你需要具备一些愿意做一点QA工作的开发人员，并搞清楚在不破坏流程的前提下，他们会对整个系统带来哪些变化。你需要你的运维团队理解需要准备好哪些改变和功能才能保证稳定性。看板方法显然能帮助你做到这两点。当你让所有人都在看板墙上时，周围的紧张气氛就会减少，每个职能和个人变得更高效，每个人都会明白究竟要完成什么。
为什么不用Scrum落地DevOps？
Scrum确实能够在没有『持续』要求的交付环境发挥作用，但毕竟它使用了2-3周的迭代冲刺。看板方法天生更合适持续的要求。如果你看看真实的DevOps实施，就会发现标准的冲刺迭代很难适应。看板方法采用拉动替代推动的方式以及流动的理念，这让它的根基能很好的结合DevOps。而且，持续交付也能和看板方法很好地搭配，两者都是准时化系统，聚焦于一次只做一件正确的事（大多时候）。当然，看板方法的灵活性会带来额外加分。
怎样上手开始？
-
开发团队要能在单独的看板墙上跟踪自己的工作。有关如何用云敏看板设计适合团队现状的看板墙，请关注本连载系列的后续文章《用云敏进行看板墙建模》。
-
运维团队可以围绕自动化、生产维护和IT支持建立单独的看板墙，对应的工作项类型可以是『实施』、『维护』、『桌面/服务器支持』等。
-
整体价值流应当建立另一块单独的看板墙，开发和运维团队分别占用一条横向泳道。关于如何使用多层级看板墙，请关注本连载系列的后续文章《用云敏看板管理项目组合》。
-
我们不建议仅仅用在用户故事或用例级别的需求上运用DevOps。无论是MMF（最小可售卖功能）、史诗需求（一句话需求）都应当有WIP限制。这或许是唯一一条明智的、最简单的帮助组织绘制和管理整条价值流的途径。
你是否已经开展DevOps了？你是否需要评估DevOps团队的看板落地？使用云敏看板和云敏持续集成，即刻获得你的DevOps解决方案！还不赶快联系云敏项目组？！
文字：李淳
排版：岳媛
—— E N D ——
长
按
关
注
EBCloud公众号
ID : EBCloud
原创文章，作者：EBCloud，如若转载，请注明出处：https://www.sudun.com/ask/33586.html
