团队转型，Scrum与DevOps要如何取舍？

团队在践行敏捷的过程中，会有多种选择：Scrum、XP、Kanban、Crystal、精益生产、规模化敏捷等，其中最流行的敏捷开发方法当属Scrum。正因如此，大部分人对其产生了刻板印象： 认为敏捷就是Scrum，实施敏捷就是套用Scrum方法。

而产生在敏捷之后的DevOps集文化理念、实践和工具于一身，可以提高组织高速交付应用程序和服务的能力，与传统的软件开发和基础设施管理流程相比，能够帮助组织更快地发展和改进产品，也逐渐成为衔接开发团队和运维团队的胶合剂。在这种情况下，大家反而会常常限制在一个 思维困境中： 团队转型，是选择Scrum还是DevOps？

在这里，有必要纠正一下人们的思维误区。首先，敏捷并非等于Scrum，敏捷作为一种软件开发运动，其发起人试图以一种更为敏捷的新方式来思考软件开发、方法论以及组织架构，从而帮助行业中的人们。Scrum作为一种方法论，并不是详细的操作规范，而是一套行为框架，在此框架基础上，各团队根据自己团队实际情况制定合适的迭代任务。

而DevOps关注的不只是开发阶段的内容，它关注的是整个系统，以促进端到端的价值流动为目的。从客户提出需求，到进入开发阶段，再到交付客户成果，价值的流动并非局限于某一阶段中。整套系统中各个单元都相辅相成，因此某一部分的改变会影响其他部分，为了使价值顺利地流动出去，需要系统中各个单元的相互配合。

因此，当人们对Scrum和DevOps并不了解时，常常会陷入二选一的误区。实际上，Scrum与DevOps并不冲突，从性质上来讲， Sc rum偏向于基础框架，DevOps偏向于文化理念； 从另一个角度来讲，Scrum与DevOps是局部与整体的关系：Scrum更注重每一sprint结束后的成果交付，DevOps则注重构建、开发、运维等阶段的整体运行、前后的衔接与持续交付。

在Scrum团队中，除却原Scrum团队中的开发人员，还包括架构人员、分析人员、销售人员等，团队下一步要考虑的问题是如何将将各职能成员联系在一起。部分已经意识到此问题的团队为了解决单一的Scrum方法论仅注重开发阶段这一弊端，开始寻求DevOps的支持。

1.持续交付

在Scrum中引入DevOps的持续交付概念，强调每个sprint的完成应以产品增量为目标。

• 首先，在sprint期间，Scrum Master不会制定详实的sprint计划，而是 仅制定sprint中前几日的计划，之后便随着冲刺期间的工作改进、调整灵活变动计划内容；
• 其次， 每日召开Scrum会议，同步团队中成员计划，提高成员之间的协作效率；
• 最后，在sprint结束后， 团队需要召开回顾会议来汇总这一阶段所做的工作，反思这次冲刺中的不足之处及应该注意的事项，以便在下次sprint中调整团队的整体方向。

在sprint阶段里，Scrum团队不断地进行学习、获取反馈，努力提高改进、产出速度，使产品尽可能多地发布到交付环境中。随后Scrum Master 通过这一期的目标完成情况决定下一期的sprint目标，在这一期间仍要注意的是，尽量减少过程中的人为干预，从而减少发布过程的周期。

2.扩大反馈

Scrum团队通过验收会议、回顾会议以及每日Scrum同步团队成员的任务进度，以及获取上一sprint成果的反馈。与单一的Scrum不同，应用DevOps的Scrum验收已经处于生产环境中的sprint成果，验收标准也不再是单一的性能测试，而是围绕产品本身、部署架构、市场等方面进行多方位评审，从而制定下一期sprint计划。

扩大反馈的方式有很多，总的来说首要步骤就是如何提高生产效率。有以下几种方法： 可以利用结对编程来增加工作效率，使产品尽可能多地交付到环境中。 也可以统一代码规范，减少额外成本的增加：当团队拥有良好且统一的代码规范时，会有效规避因某个成员的缺席造成团队工作停滞的风险，也能够提升代码的可读性，从而提高工作效率、扩大反馈。

Scrum的仪式感常常表现在 迭代计划会议、 每日站立会议、 回顾会议等方面。而DevOps更注重在整个价值流中快速并持续交付价值，这种价值的快速流动需要产品发布过程中每个人的参与；同时，透过自动化“软件交付”和“架构变更”的流程，逐渐消除人为干预，使得构建、测试、发布软件更加地快捷、频繁和可靠。

DevOps文化倡导 “共同责任”，也就是在产品发布全流程中，所有成员通过协作确保产品有价值，因此，在Scrum框架基础上应用DevOps能够帮助Scrum团队更好地进行知识学习和创新。