大规模敏捷（Scaling Agile）方法分析

在敏捷社区中，大规模敏捷（Scaling Agile）给大家带来很多困惑。大规模敏捷是什么意思？怎么才能做到大规模敏捷？有哪些框架和方法？采用大规模敏捷需要哪些技术改变？。对于那些想去尝试大规模敏捷的人会有这些疑问。对于另一部分人，大规模敏捷则是从小团队实施到整个组织架构实施的自然过渡。

目前已经有一些规范的方法来解决大规模敏捷的这些问题，但到底在什么情况下应该使用什么方法，人们也有很多困惑。

Richard Dolman 和 Steve Spearman 建立了一个网站，在其中他们做了一个对比矩阵用来查看不同的大规模敏捷方法。

他们声称对比的目的是：

我们想为敏捷社区提供三项内容：

• 尽量用客观标准对最流行的敏捷框架进行对比。
• 一个可以用来比较分析的模型。
• 大量引用作者、业界领袖及其他人的点评作为敏捷框架对比的“见解”。

两位最近接受了 InfoQ 的采访：

InfoQ： 请向我们介绍一下你们自己。

Steve Spearman：我已经在软件行业工作 30 多年，为各种各样的客户做过敏捷教练和培训，其中很多是企业客户。我拥有的认证包括 CST、SAFe SPC、CSM、 CSPO、 PMP 以及 PMI-ACP。

Richard Dolman：我在软件、咨询、金融服务及其他行业有 25 年工作经验。我现在是企业敏捷教练和培训师。我拥有 CSP、CSM、PMI-ACP、PSM 以及 PMI-ACP 证书。

InfoQ： 为什么要分析大规模敏捷？

这是我们行业中一个非常热门的话题，但我们还没看有一种方式能够对各种大规模敏捷方法进行公平客观地综合整理并呈现。我们并不是支持某种方法而反对另一种。我们的目的就是提供一个论坛和资源，帮助教练和组织评估他们自己的需求，然后了解和评估各种方法，最后希望他们能够找出最能满足自身要求的一种。

InfoQ： 是什么促使你们开始这项工作，试图解决什么问题？

我们俩都是有经验的敏捷教练，经常与大型企业一起合作。在 2013 年的 Scrum Alliance Coaching Retreat 活动中，我们是这个小团体中的一员，这个话题在工作坊中进行了讨论。我们看到了这种需求——用客观的方式来比较目前最常用的大规模敏捷方法。

对于大规模敏捷，传统答案差不多都是“找到适合自己的方式”。虽然在很多情况下是一个比较强有力的方法，但很多的组织需要更进一步了解。随着很多大型企业实施敏捷，随之而来的是大规模敏捷框架或方法的浮现和逐渐流行。我们只是提供一种对不同的大规模敏捷对比的方式，从而帮助组织找到适应他们特定情况的方法。

InfoQ： 什么是“大规模敏捷”？

这就是我们要开始谈论的话题……“你怎样定义‘大规模敏捷？’”。

对一些人来说，“大规模敏捷”意味着从几个敏捷团队扩展到多个甚至几百个敏捷开发团队。

当你的组织有超过三个或四个敏捷团队需要协同合作的时候，无论如何就会面临一些特殊的挑战。多数的大规模敏捷框架试图提供相应的想法或技术，在组织层面帮助大规模敏捷团队协同工作，这些合作团队少到四个，多到数百个，而且团队可能分布在各个地方。其他一些大规模敏捷的定义可能超出 IT 的范畴，例如在商业运作或组织的其他方面追求敏捷。这个需求没有在当前比较流行的方法中提供有效的支持。

InfoQ： 对于大规模敏捷，当前的观点有什么不对吗？

这个说来话长，你会得到很多不同的意见。其中的一个难点是，对于什么是大规模敏捷的最佳方法以及什么是适合的大规模框架，有太多不同的视角，并且这个话题在很多帖子和论坛中非常热门。

我们试图不对现有的争论有任何偏袒，这恰恰就是大家对当前大规模敏捷的想法。尽管在处理大规模敏捷的问题上他们给出的建议存在显著的差异, 但大多数思路都是基于对精益和敏捷的追求。

我们集中解决的问题不是关于大规模敏捷的方法和观点，而是进行客观的对话，并弥补在用模型对组织的需求进行对比分析中看到的差距。

InfoQ： 你们这个模型的目的是什么？

我们有几个不同的目标：

我们想提供一个信息中心，列出最常用的大规模敏捷框架和方法，我们称之为大规模敏捷知识库 ASK（Agile Scaling Knowledgebase）。

我们还想做出一个易于理解的决策矩阵。通过提供一种架构让人们对比其他备选的方法（很多方法超出我们所涵盖的范围），从而根据自己的情况找到一个合适的框架。

最终，我们想提供一种可扩展的工具，能够引入不同的思想和方法，并且基于用户自己的标准过滤信息，使其成为更全面的用来评估方案的方式。

InfoQ： 在这个模型中，你们选择了哪些不同的大规模方法，为什么？

我们最初关注的重点是那些最流行的方法，但我们也在论坛上提供一个地方指向其他的方法。我们的对比矩阵中包括一些基础模型，例如 Scrum of Scrums （SoS）以及更复杂的模型，如 Large Scale Scrum （LeSS）， Disciplined Agile Delivery （DAD）， Scaled Agile Framework （SAFe）。我们还包含了在 Spotify 中用到的方法。根据大家大量的讨论或我们在行业中所看到的应用，我们选择了这些模型。大规模敏捷知识库（ASK）的用户可以基于他们独特的标准增加或移除这些方法。

InfoQ：把这些模型放在一起有哪些关键的维度？

我们面临的一个挑战就是试图在主观和客观评估标准之间找到一个平衡。我们开始的时候竭力强调客观标准，但在不同的标准下我们也会提供一些主观的评分。我们也请求这方面有经验的教练对这些模型提一些意见，包括标准。基于这些，大规模敏捷知识库（ASK）的模型才可以持续地演变。

我们想强调的一个关键特性是，用 ASK 决策矩阵的人开始定义一些关键标准时要注意，这些标准必须对他们组织或状况非常重要或相关。我们也想包含来自评审员和不同框架的作者的点评，这个在不久的将来也会添加到我们的网站上。

InfoQ： 人们用这个模型选择方法时，你会给他们什么建议？

记住，这只是一种对比大规模敏捷方法的模型。我们希望在初期的时候你就发现它有用，但一定要做足功课研究，从而找到最适合自己经验和需求的模型。

也请你向我们提供反馈和其他你认为有用的信息链接，我们则可以持续改善这个模型和相关网站，让它更有价值。我们希望在行业里这是一个有价值的信息资源，其他人可以在这里提供信息和获取有价值的信息。

InfoQ： 读者在哪里可以得到这个模型？

最新的对比矩阵和帮助信息可以在这里找到。

并且我们也会在奥兰多的 Agile2014 大会上分享这个话题 。所以我希望感兴趣的人可以参加我们的演讲，并带着你们的疑问和见解和我们一起探讨。

查看英文原文： Examining Different Approaches to Scaling Agile

感谢侯伯薇对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博（ @InfoQ ）或者腾讯微博（ @InfoQ ）关注我们，并与我们的编辑和其他读者朋友交流。