扩展不需要蓝图和敏捷扩展循环

在 GOTO Berlin 2015 会议上，Stefan Roock 讨论了敏捷扩展不需要蓝图。InfoQ 有幸对其进行了采访，主要关于向 Scrum 中添加 XP 实践，为什么将敏捷框架作为组织设计的蓝图是不成熟的优化，和当扩展敏捷时，为什么文化和原则比实践更加重要。Roock 还解释了敏捷扩展循环（agile scaling cycle），并提供了如何使用的案例，讨论了这种方法对敏捷扩展的优点和缺陷。Roock 还用案例解释了如何使用敏捷扩展循环，讨论了这种方法对敏捷扩展的优点和缺点。

InfoQ：您讨论了在 mobile.de**** 中同时使用 Scrum**** 和 XP。添加 XP**** 实践的优势是什么？

Roock：一开始，mobile.de 能够每月发布一次。这在 Scrum 之前完全满足他们的工作方法。随着拥有超过 10 个并行 Scrum 团队之后，每月发布一次成了一个瓶颈。我们通过组织合并时隙（merge slot）设法解决这个问题——预定义每个团队将贡献合并候选版本的时间。

每个团队都尝试将尽可能多的特性放入每月发布一次的版本里，因此会为了下一次合并时隙产生冲突。当然合并过程中会发生不可预见的问题，因此合并会超过合并时隙。在这种情况下我们会为了该做什么争论不休。

• 我们是否应该从发布中移除制造问题的团队，这样接下来的合并时隙计划可以保持不变。
• 我们是否应该允许团队扩展合并时隙，如果这么做：我们是否应该推迟发布直到每个团队成功合并，或者我们是否应该从发布中移除晚于合并时隙的团队。

有一个专门负责这些事情的发布经理。

引入 Scrum 后不久，我们将重点放在持续集成和自动化测试方面（单元测试和 UI 测试）。这带来了更高的质量和更少的开支。团队更少使用分支，合并工作急剧下降。合并噩梦消失了，发布经理这一角色也过时了。

与此同时，mobile.de 开始使用 TDD、ATDD 和结对编程。

今天，如果需要，mobile.de 可以每天发布好几次。mobile.de 开发人员也在 ebay dev blog 记录了一些他们的经验。

InfoQ：您说将敏捷框架作为组织设计的蓝图是不成熟的优化。您能解释一下吗？

Roock：在我看来，局部和全局的蓝图 / 框架是不一样的。Scrum 是一种蓝图，也能够起作用。它帮助人们跨出第一步，给人们理解敏捷是什么和意味着什么提供指导方针。

当人们接受了敏捷的思维方式，他们就会找到适合他们自己的扩展方法。它会从实践中出现迭代——团队会检查 & 接受通往结构的方法。

扩展蓝图会对这种结构进行预先定义。但是为了什么呢？成熟的敏捷团队不需要它，并且会因此受到不必要的限制。而敏捷初学者团队也不应该扩展敏捷。在跑之间他们必须学会走路。

InfoQ：您有人们在不理解原则的情况下开始实践的案例吗？

Roock：在我开办的某次产品负责人培训中，曾经有个参与者说他有好几年的敏捷经验。当我们讨论产品 Backlog 时，他询问工具支持。以前他们使用 EXCEL，但是因为行数超出范围，他们又不得不舍弃它。原来，这家公司的实践非常的不敏捷，但是自己在局部贴上了 Scrum 标签。参与者觉得在公司学到了 Scrum，并且认为他真的有 Scrum 方面的经验。

另一件非常常见的事情是 Sprint 评审。我的培训学员中 80% 都将 Sprint 评审作为鉴定会（approval meeting）在使用：我们是否完成了我们计划的内容？只有非常少的一部分公司将 Sprint 评审用于讨论 Sprint 的投资回报率（ROI），并收集反馈用于改善产品。

而每次我被邀请去评估某个 Scrum 实施时，每日 Scrum 站立会议几乎每次都成了无聊的状态会议，而不是目标明确的充满精力的团队构建和计划活动。

InfoQ：您能否解释一下为什么你觉得在扩展敏捷时，文化和原则比实践更重要？

Roock：所有的敏捷方法都是非常的轻量化。只有少数的规则、角色、会议等等。这给适应目前的情况和改进留下了非常大的空间。同时也给错误留下了非常大的空间。

如果没有采用敏捷文化和原则，人们在敏捷实践时就会发生错误。他们会依据现有的参照标准解释实践。产品 Backlog 就会被看成是另一种形式的需求规格说明文档。Sprint 评审就会被当成鉴定会。每日 Scrum 站立会议就会变成状态报告。Scrum Master 就会扮演产品经理的角色，而产品负责人就成了某种官僚，负责向利益相关者索取需求。

敏捷原则有助于发现这些错误。

“欢迎改变需求，即使是在开发的后期。”这句话告诉我们一个固定的“产品 Backlog”肯定不能与敏捷思维同步。

“最好的架构、需求和设计来源于自组织团队。”这句话告诉我们如果仅仅向利益相关者询问他们的需求，开发肯定会发生错误。

在扩展方面，对于如何应用敏捷宣言有些方面并不明显。因此，一些教练包括我建立了扩展原则（详见 http://scaledprinciples.org ）。这些扩展原则并不是新的发明，仅仅是有关扩展的现有原则的集合。

InfoQ：您能解释一下敏捷扩展循环的步骤吗？您为什么建议以这种顺序执行这些步骤？

Roock：敏捷扩展循环是一种简单的三步循环模型。在第一步中，我们减少团队之间的依赖。自主团队非常擅长敏捷。然后团队必须怀有敬意地对剩下的依赖关系进行协调。在这个工作中，组织的功能障碍会暴露出来，而团队的 Scrum Master 也没有能力移除每一个功能障碍（有些可能需要公司整顿）。Scrum Master 将为目前情况找出一个应急措施，而潜在的功能障碍将会在第三阶段得到解决：开发组织。

这个模型是我与 Peter Beck 在一次敏捷扩展培训中提出的。我们要求学员在便利贴上写下他们知道的扩展实践。当观察完学员写的内容后，我们意识到我们面临着一个巨大的工作量，我们需要一个结构来系统化实践。我们发现了三个集群：减少依赖、协调团队、开发组织。这些集群似乎非常有用，之后我们开始在演讲中使用，一段时间后，“敏捷扩展循环”这个称号就出现了。

与所有其它的模型一样，敏捷扩展循环也是错误的。但是有时它是有用的。敏捷扩展循环非常有利于集群扩展实践并且它有助于重点关注两个要点：

1. 自主团队很重要。
2. 检查 & 调整从而提高组织是必然的。

敏捷扩展循环错在次序。实际上，这三个步骤是并行完成的。你不会在步骤 2 中忙上几个月（协调团队），然后停止工作，带着一大堆的组织功能障碍问题进入步骤 3。

InfoQ：您能举例说明组织如何使用敏捷扩展循环？

Roock：我们通常被要求与不同团队一起“修复”敏捷实施。客户提的最多的问题是计划和协调团队。因此，他们在寻找更强大的计划和协调实践。

这些情况下，通常开始执行敏捷扩展循环步骤 1：减少依赖之后。当建立跨职能团队后，几乎所有情况下的这种问题都消失了。

第二个方面跟敏捷扩展循环的步骤 3 相关。企业必须认识到不仅仅团队层面需要持续改进过程。我们试图通过培训使大家建立这种认识。

InfoQ：敏捷扩展循环的优点和缺点？

Roock：优点之一是一开始你不需要拥有最佳结构。我非常喜欢 LeSS，但是一开始就完整安装 LeSS 对企业而言可能比较困难。敏捷扩展循环告诉我们努力减少依赖，然后与剩下的依赖一起合作。有问题的依赖就会暴露出来，那时就可以解决他们。

缺点之一是人们可能误解敏捷扩展循环是一个顺序过程，会推迟移除组织的功能障碍。另一个缺点是减少依赖和协调团队需要经验来选择合适的实践。当然，人们可能倾向于尽可能多地使用扩展实践——仅仅是为了确保成功。因此我创建了“Stefans 敏捷扩展成熟度模型”：你不再需要大量的协调实践。少即使多。

查看英文原文： Scaling Without Blueprints and the Agile Scaling Cycle