【敏捷FAQ 第2回】运维团队不适合 Scrum 吗？

感谢您阅读这篇文章。我是敏捷组的藤井智弘。

 我们团队主要从事现有系统的运维工作。主要是处理缺陷和改进需求，并不是像在 Sprint 中有计划地开发大型新功能那样的工作。培训中学到的 Scrum 看起来是以新开发为前提，而且我们这里经常会有突发任务。
Scrum 可能不适合我们团队吧？

 不合适的不是 Scrum 本身，而是“Scrum 解说所依赖的前提假设”。换个角度来看，运维对于敏捷来说是相当自然的环境。在瀑布式文化根深蒂固的开发团队中，习惯“最开始不把所有事情都决定好”这种思路是很难的。而在运维的世界里，“一开始就不把所有事情都定好”则是理所当然的。
 更进一步，运维不仅仅适合 Scrum 的“工作管理”这一面。作为锤炼 Scrum 未定义但对敏捷至关重要的另一半——测试、设计、发布等“制造技术”的场所，运维或许是最好的舞台。本文后半部分将把重心放在那里。
 首先，在匆忙下结论是否合适之前，不妨从“新开发和运维真的完全是两回事吗”这个问题开始重新思考。

 这个问题背后的前提是，有人认为“新功能开发”和“运维中的缺陷处理及改进需求处理”是截然不同的两种工作。
 在以 Scrum 为前提的讨论中，先对这一点提出疑问。下面为方便起见，将前者称为“新开发系”，后者称为“运维系”。

 如果从待办列表的视角把两者并列，就如下所示。

• 新开发系：列出想要实现的功能 → 按价值和风险确定优先级 → 小步完成并交付 → 获取反馈后决定下一步
• 运维系：缺陷报告或改进需求不断涌入 → 按影响度和紧急度确定优先级 → 修复并交付 → 根据用户反应和复发情况决定下一步

 无论是新功能还是运维，都会有有价值的工作项涌入，对它们进行优先级排序，小步完成并交付，然后根据结果来决定下一步。退一步来看，两者从结构上看是相同的。无论哪种“系”，都在运行着 Scrum 所倡导的那个循环。而且这两种待办列表都是假设事项会后续流入的列表，并不是一开始就要将所有事项都罗列齐全的列表。

 那么，是否就毫无差别呢？其实两者还是有区别的。不过，这种差别不是“种类上的差异”，而是“程度上的差异”。

• 项目规模与独立性：运维系的项目一般都比较小，且彼此独立；新开发系的项目则较大，且各项目之间往往依赖性较强
• 流入的可预测性：运维系常有突发任务流入，无法在本周就完全确定下周要做什么；而新开发系更容易进行计划

• 利益相关者的期望：新开发系会被问“什么时候、交付什么内容”，而运维系则被问“要多快、多可靠地修复”

 这些差异的确会成为调整 Sprint 长度、设定目标方式、容量分配等“运行参数（参见第一回）”的理由，但并不构成要不要实践 Scrum 的分界线。在相同的思路下，只是参数——也即调整方式——有所不同而已。

 到目前为止的讨论都是关于待办列表和优先级排序，也就是 Scrum 所定义的“工作管理”层面。然而，如果重读 Scrum 指南，就会注意到：Scrum 并没有任何定义“如何构建（如何制造产品）”。 怎样编写测试、如何维护设计、以何种频率进行集成和发布……这些都超出了 Scrum 的范畴。

 而承担敏捷“另一半”职责的，正是以 XP（极限编程）为代表的构建实践：自动化测试（以及先写测试再实现的测试驱动开发）、重构（不改变行为的前提下优化内部结构）、持续集成（频繁集成变更并自动构建与测试）、小步发布、简单设计。许多仅仅引入了 Scrum，却在“每个 Sprint 都交不出可运行的软件”“开发速度持续走低”上苦恼的团队，正是缺少了这一半。他们只有管理框架，却没有在框架内支撑产品构建的技术能力。

 对于深受瀑布式文化影响的开发团队来说，在向敏捷转型时，最大的障碍通常是“想要先把所有内容都决定好再做”的习惯（或说欲望）。他们会先画甘特图、敲定需求、敲定设计，然后才进入实现……要摆脱这个习惯，许多团队要花几个月，甚至几年才能做到。

 但请看运维的现场。
 没人知道下个月会报告什么缺陷。每个人都身体力行地明白，去精细制定半年后的应对计划毫无意义。换句话说，“一开始就不把所有事情都决定好”这种状态，无意间已然实现。开发团队费尽心力才要放弃的习惯，在这里根本不存在。

 接下来，切入正题：运维的日常工作本质上就是 XP 技术实践的练习题。

• 自动化测试：在修复缺陷时，“先编写能重现缺陷的测试，然后让其通过”是最自然的流程。在运维环境中，为了防止修复的部分在后续改动时被破坏，不断增加回归测试的覆盖，这也是被视为“理所当然”的做法。这与许多不成熟的敏捷项目中“测试可以放到发布前再做”的误解（或放任？）形成了鲜明对比。
• 重构：运维系的变更都比较小粒，每次都习惯于“对接触的代码稍作整理再提交”，这是在不进行大规模重写的前提下保持代码健康的唯一现实可行方式，运维工作为开发者提供了丰富的练习机会。
• 持续集成和小步发布：因为各项工作相互独立，可以逐条进行集成，也能逐条交付。“小步完成并交付”周期短，对于构建、测试、部署自动化的投入动机和收益，相较于新开发更为清晰。
• 完成的定义（团队对“完成意味着什么”的共识）：由于可以在每个 Sprint 中多次体验“完成”的过程，因此在估算、拆分以及就“完成的定义”达成共识等基本操作上的练习次数，远远超过了新开发项目。同时，检查与适应的节奏也通过故障回顾和再发防范的形式，与日常工作紧密相连。

 综上所述，“Scrum 不适合运维”这种判断是不准确的，反而如果要同时掌握 Scrum 的管理框架和 XP 式的制造技术，运维是一个极佳的舞台。

 不过，也存在一些局限。运维更易锻炼的是制造技术这一面，而在 Scrum 的管理层面，有两件事较难练习。

1. 通过 Sprint 目标将工作“整合”到一起的能力。如果只是完成小粒且相互独立的工作项，目标往往会退化成“把本次 Sprint 的所有工作都做完”。要练习把各项琐碎任务整合到一个共同目标下，如果不刻意去做，是很难发生的。
2. 围绕价值进行优先级决策的能力。在面对“理所当然要修复”的缺陷时，就缺少了“基于产生的价值来决定做什么、不做什么”的机会，从而让产品负责人的锻炼机会减少。

 在我所见的许多几乎全是敏捷初学者的团队中，他们直接投入正式开发往往以失败告终。因此，“先在运维中掌握制造技术”→“再在新开发中一边围绕目标和 PO 角色进行锻炼一边开发”的做法，十分值得考虑。

 尤其在日本，对这“制造技术”的投入在结构上往往不足。在一些管理层眼中，敏捷仅被理解为“快、便宜”。其结果是团队编制优先考虑单价，而培养投入被省略，从设计到编码、测试等“制造”能力无法作为团队整体得到提升。虽然接受了 Scrum 培训，但测试自动化和重构无人实施——这种团队却自称“已经开始 Scrum”，就冲到正式开发中的场景并不罕见。应被责备的不是个别工程师，而是这种编制和投资的决策。

 当然，在成本削减的约束下，这一决策在当时也算是合理的选择。合理选择的累积却可能走向不期望的结果——这种结构将在下回关于升级项目的讨论中再次出现。

 在我看来，这正是敏捷开发失败的一个重要原因。将运维作为磨炼舞台的提议，也正是要在日常工作中重建这种“足腰”能力的提议。

 我希望管理层能够放弃“快、便宜”的期待，转而关注这些可衡量的变化：“单个变更的交付周期缩短”、“切换或发布事故减少”、“估算偏差收窄”。这些内容，我计划在本系列后续篇章中予以讨论。

 当然，我也希望大家能以“价值创造引擎”的视角看待开发团队，不要把他们当成需要压低单价的成本中心，而要作为值得投资和培养的对象。

 假如将其应用于运维场景，以下列举几个常见困扰及对应对策。

无法设定 Sprint 目标
 如前所述，设定目标可能会比较困难。对于已经运行了几个月 Sprint 的团队来说，此时不妨干脆放弃强行设定目标，先专注于将“自动化测试和重构”这样的制造基本动作纳入日常流程。
 当然，这并不是要禁止设定目标。如果以“功能模块”的视角来设定目标，就容易卡住。从“改进”“削减”“稳定化”等角度来思考，则更容易设定目标。例如：“本月将告警数减半”“完成可废除该操作手册的自动化”“将前三大咨询问题 FAQ 化以减少咨询量”。这些都是合格的 Sprint 目标，也能作为前述“整合能力”的练习。

突发任务破坏计划
 首先，在1～2个 Sprint 周期内，记录突发任务的数量、耗时和来源，并根据实际比例而非主观感受，将团队的容量划分为“计划内工作”和“突发任务”两部分，以此来进行容量规划。至于更详细的运作（如如何记录、值班制、统一受理等），计划在第十二回左右进行专门讨论。

如果 Sprint 的划分本身就不符合实际情况
 如果突发任务长期占据超过一半，就不必拘泥于 Scrum，可以正面考虑并用或切换到看板（Kanban，不划分 Sprint，而是以工作流方式管理任务）的方法。看板通过按序拉取流入的工作、改善流速和瓶颈，更能契合以流程为中心的实际场景。
 Scrum 是手段而非目的。“不做 Scrum”并不等同于“放弃敏捷”。

 原因很简单：绝大多数敏捷的解说、培训和成功案例都是默认以“开发新功能的团队”为主角来写的。尽管读者的大多数都从事运维工作，但教材中的主角始终是新开发团队。而且在日本，新员工培训中瀑布式开发被系统地教导，敏捷却几乎不涉及。“没有教材”的状况，从职业生涯之初就已经存在。
 因此，每当新一代人出现，运维的实践者们都会抱有同样的不安：“我们是不是例外？”、“是否被剥夺了接触新方法的机会？”。
 但如本文所示，例外的不是一线现场，而是教材的前提。“在不可预知中小步完成并边做边学”的 Scrum 舞台已经准备就绪。更重要的是，Scrum 并未定义的制造技术的练习题，每天都会持续涌入。
 不妨将运维视为不是敏捷的边缘，而是锻造敏捷根基的场所。

下回：如何面对升级项目中的“现有功能保障”？