运维 | 敏捷和DevOps：是敌是友？

DevOps是敏捷在软件开发团队的另一应用。那么相比之下，哪个更胜一筹?

一边，有业界认可的scrum master，它的朋友极限编程者，以及由其衍生的 LeSS、SAFe、DAD等，是敏捷。

另一边，有精益文化机器，用代码持续交付其基础架构，它的名字左边是开发，右边是运维，合起来就是DevOps。

虽然我已尽我所能在普及这两个概念，但人们关于敏捷和DevOps的争论依然让它们听起来完全不同。更糟糕的是，尽管他们都已经有了各自的行业术语和口号，但两者的概念还是没办法准确定义。鉴于敏捷诞生早于DevOps ，所以它的定义也相对清晰一些，但DevOps五花八门的定义仍然让很多人都很困惑。而正是因为二者都缺乏准确的定义，所以导致人们经常会有一些误解。

很多人认为敏捷等于scrum，DevOps等于持续交付。过度简化的理解让敏捷和DevOps之间形成了不必要的对峙，但最终你会惊讶地发现二者其实是非常好的朋友!

毫无疑问DevOps和敏捷之间的联系由来已久。在2008敏捷大会上，Patrick DuBois和Andrew Clay Schafer尝试建立二者之间的关系并提出“敏捷架构”这一概念，这时，敏捷与DevOps之间的关系就已初现端倪。尽管Patrick后来提出了“DevOps”一词，但敏捷大会依然被追溯为DevOps的起点。所以我们不妨透过Scrum和持续交付的表面，深入了解二者的历史，来思考一下敏捷和DevOps之间还存在哪些关联。

一、敏捷绝不仅仅是Scrum

某些团队中，scrum让团队工作介于一成不变、苦苦挣扎和量产、高回报之间。还有一些团队，scrum用客观和聚焦代替主观和过度承诺。我们也可以把它视为一种教条。当业务收到限制或工作本身需要做出改变的时候，敏捷团队将利用scrum的基本原则，审视自身的工作并做出更有效的调整。尤其是当scrum应用于软件开发环境之外的业务时，这点尤为重要。

提前规划计划外的工作

在DevOps社区，有敏捷经验的人都觉得scrum能够有效追踪计划中的工作。一些正在运行中的工作可以被计划：如发布一个重大系统变更、切换数据中心或系统升级等。但在运行中大多数事情是没办法计划的：如性能到达峰值、系统中断或安全问题等。这些突发事件都需要快速做出反应。没时间等到把这些事项在backlog中确定优先级后再做或放到下个sprint规划会议中处理。正因如此，很多团队开始慢慢接受DevOps思想，Scrum之外再引入Kanban。这样使得团队可以同时追踪两种类型的工作，帮助他们理解两者之间的联系。或者，他们采取了一种综合方法，叫做Scrumban 或 Kanplan (也就是有backlog的看板)。

在很大程度上，scrum得以广泛应用的关键可能在于它不对技术方法设限。Scrum作为轻量级管理方法，往往能为团队带来巨大变化。之前，可能会有来自多个master的优先事项互相竞争，但在scrum中，backlog中只会存在一组优先事项。之前，团队中可能会存在同时推进很多工作的情况，而现在取而代之的是一个在限定时间内可以完成的工作计划。综合来看，这些都可以将团队的生产率带到一个新的水平。然而，团队可能会因技术实践的缺乏而受到限制，如代码审查、自动化验收测试、持续集成。

其他敏捷方法如极限编程，也对技术如何使团队保持可持续交付节奏并向管理层和利益相关者提供透明度和可见性提出了明确要求。一些Scrum团队倾向于将研发任务放在backlog中。虽然这在scrum的指导下适应得很好，但很快就会遇到Product Owner对产品功能的偏向性问题。除非Product Owner的技术能力很强，否则TA可能无法评估技术的成本或收益。尤其是当技术任务延伸到运维、可靠性支持、性能、安全性等方面时，对Product Owner来说更加困难。

Product Owner 和Service Owner

在Worktile，我们认识到，为我们运营的产品设置两个不同角色很有必要。Product Owner善于理解用户的功能性需求，但可能并不擅长权衡产品功能与性能、可靠性和安全性等非功能性功能之间的优先级。因此，一些SaaS产品也配备了Service Owner角色，负责确定前述非功能性功能的优先级。尽管两个角色经常需要讨价还价，但大部分情况下，独立的团队都可以自行完成这两个角色的任务。虽然这并不是“强化反馈”的唯一方法，但确实能够克服Product Owner对产品功能中比较常见的偏见问题。但设置‘两个Owner’并非实现DevOps的唯一途径。重要的是将非功能性特征理解为“功能”，并将它们像功能性的用户故事一样，进行规划和优先级排序。

• 在DevOps成为主流前，不能确定scrum自然发展的结果一定是DevOps。

敏捷方法中，Scrum有一个内在的“过程改进”机制，叫做回顾会议。因此，我们有理由相信一些scrum团队会想用DevOps作为灵感来源，用scrum回顾会议作为向DevOps方向调整的契机。然而，事实让我们意识到大多数团队需要注入外部思想。在DevOps成为主流前(哪怕成为学校必学内容)，我们不能确定scrum自然发展的结果一定是DevOps。团队到底是有敏捷教练还是DevOps教练参与并不重要，只要他能给团队带来在构建、测试、部署等方面的自动化经验即可。

二、DevOps也不仅限于持续交付

如果应用得当，持续交付的规则可以有效限制在制品数量，而部署的自动化有助于打破工作局限。通过这样的方式，持续交付让软件开发团队频繁交付更高质量的产品，而不必在二者之间抉择。然而，正如仅专注于scrum的团队可能会忽视更广泛的敏捷环境那样，仅专注于持续交付的团队也会错过更广泛的DevOps环境。

持续交付实践并不能直接解决业务部门和开发团队之间的沟通问题。如果业务部门设定了一个为期一年的预算驱动计划，那么产品交付团队每次交付产品后都需要等待数月才能得到业务部门给的反馈。而这些反馈通常都是一些影响后续工作的步骤性功能，像取消项目或者更糟糕的是需要扩充项目团队(因为大量涌入新人会影响团队已有的稳定性)。

敏捷流畅度模型将“价值聚焦”视为流畅度的第一层级，即团队需要注重透明度和一致性。如果价值不聚焦，持续交付很容易陷入技术改进的无限死循环而无法向业务交付可观的价值。团队可能擅长快速高质量的交付，但就产品本身而言，可能对终端用户或者企业来说几乎没有价值。即使很多用户给出了较好的评价，但从较大的业务组合层面来看可能就会评估为低价值。因此，没有价值聚焦这一重要流畅度，团队很难在技术和功能之间权衡取舍。

这点对于有遗留代码库的团队来说尤为重要，因为遗留代码库可能没有自动化测试或适合频繁部署的设计。在一个遗留环境中，持续交付转换可能需要数年的时间。因此，证明产品的商业价值就显得尤为重要。

三种方法

（编辑：济南站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!