SAFe 是否已经破解了大规模采用敏捷的难题？

由 Dean Leffingwell创建的 Scaled Agile Framework (SAFe)似乎正在为我们的社区带来动力，而且它还被赞誉为在组织层面上能够与 Scrum 相媲美。目前 _SAFe_ 得到了若干厂商的支持，包括 Rally、 Net Objectives和 Valtech。另有一家提供培训和认证的 _SAFe_ 学院。最后，_SAFe_ 也欢迎其他公司成为 _SAFe_ 合作伙伴。以上全部这些内容——工具支持、冠名厂商支持、认证计划和官方标准——让大型组织机构的高官们感到安心。这些人知道他们正在做什么，并知晓存在针对大规模采用的支持系统。此外，这里还有一个展现了以上所有内容的美妙的图表，被称之为整体视图（Big Picture），如下所示：

不过，社区中并不是只有对 _SAFe_ 的赞誉。实际上，许多成员表现出强烈的负面反馈。_DavidJ.Anderson_ 和 _Ken Schwaber_ 都已经针对 _SAFe_ 公开发表了反对观点。此外，在今年的敏捷大会上，当 _SAFe_ 作为演讲者与若干知名且经验丰富的敏捷实践者和顾问对话时，显然也出现了不同的声音。

因此，让我们先来看看 _SAFe_ 能够带来哪些好处。首先，_SAFe_ 是很具体的。它从团队、计划和投资组合的层面，分别提供了有针对性的指南——这让它们更易于理解，因为这些正是我们在当前的业务架构中所面对的层级。_Raly_ 的 _Rob Pinna_ 发表了博客文章关于 SAFe，你需要知道的 41 件事情中，详细描述了它实际上意味着什么。

Scaled Agile Framework®（又名 _SAFe_）提供了一份在企业范围采用敏捷的秘诀，展现在整体视图中。_SAFe_ 之于敏捷企业，就像 _Scrum_ 之于敏捷团队。

另外来自 _Davibase_ 公司的 _Josh Fruit_，在题为那些或许会促使我们想要尝试 SAFe 的 5 个原因的文章中这样写道：

1. 如果我们已经成功地在团队层面尝试了敏捷，并且现在对于跨计划或跨部门来实施一致的敏捷方法有兴趣。
2. 如果我们拥有多支团队，它们分别运行各自独有的敏捷实现。但是当某支团队依赖另外一支的时候，我们经常会遇到阻碍、延迟或失败。
3. 如果我们渴望在组织机构内部扩展敏捷，但又不确定会需要哪些新角色，以及哪些现有角色（例如管理者）需要改变、如何改变。
4. 如果我们试着在组织机构内部扩展敏捷，但却苦于难以实现跨业务部门的一致策略，并且从资产组合层次到计划和团队层次进行一致的调整。
5. 如果我们知道自己的组织机构需要提升产品开发交付时间，而且听说了像 _John Deere_ 这样的公司使用 _SAFe_ 扩展敏捷所取得的成功，并且想要了解他们是如何做到的。

最后，_Josh_ 在文章中将 _John Deere_ 使用 _SAFe_ 取得的成功作为典型代表。在 2012 年 3 月 _InfoQ_ 的文章用敏捷方法生产拖拉机中， InfoQ_ 就其努力的细节采访了 _ChadHoldorf——看起来他大获成功。

由此看来，我们似乎有充足的理由选择使用 _SAFe_。而如果我们去询问某位 _SAFe_ 的合作伙伴，那么或许会得到这样的答案：大规模采用敏捷已经没有任何问题，难题已经被解决。如果身处大型组织机构中，那么我们都应该采用 _SAFe_。然而，有趣的是，在实践中还存在着对 _SAFe_ 的强烈的负面的声音——来自于知名的社区领袖和实地参与者。

_Scrum_ 的两位创造者之一 Ken Schwaber, 站出来对 SAFe 表示了如下反对意见：

来自 _RUP_（_Rational_ 统一过程）的小男孩们又回来了。在 RUP 意义深远的失败的基础上从头来过，他们正在推动 SAFe 作为适合于敏捷组织机构的一剂简单的万用灵药。随着与工具厂商 Rally 的合作，他们将其方法变得更加复杂。顾问们能够为客户量身定制，就像 RUP 一样。

他们在本周 _Nashville_ 的 _Agile2013_ 大会上兜售其流程和工具。他们应该现身于 _RUP_ 大会，但那里却找不到他们的身影；他们应该出现在瀑布（Waterfall）会，但他们已经不再参与该活动；因此他们来到了我们的会场。这很奇怪，但他们也没别的去处了。所以尽量对他们礼貌一点吧。

_Kanban_ 创始人 David J. Anderson表示虽然他并不是一位得道认证的 SAFe 从业者，但是基于他与这个群体之间的对话，以及他正在阅读的公开文档，发表了这样的意见：

有一种论调，认为将成功的实践集合在一起 [包含 SAFe]，那么从总体上来说也能够取得成功。我认为可以将这个假设与这样的场景进行对比：我们独立测试现代客运飞机中的 30 万个组件，而后宣称由于所有的组件都经过测试，因此由这些部分组成的飞机是“安全的”！从某个框架中剪裁的流程的真正本质，在于它意味着每一种实现方式都可能是独一无二的，而且该流程的设计却因此将缺乏测试和验证。这个新的流程在单一变更的方式实现，而不是采用演进的方式——每一个增量步骤都要测试适用性，并且基于测试成功进行选用——来实现。这样做的风险在历史上已经得到了公认。

这些强烈的意见都来于自社区中备受尊重的领袖们。然而，公平地说，无论 _Ken_ 还是 _David_ 在尝试 _SAFe_ 的时候都未曾接受过相关的训练。因此让我们看看其他拥有更多背景知识，但又不是经过认证的合作伙伴的人怎么说。在参与某次与 _Dean Lenffingwell_ 的关于 _SAFe_ 的用户组见面会后， Robert Galen撰写了一篇文章：

他（Dean Leffingwell）引用了在 10 支团队的规模上采用敏捷的案例。这些团队奋力工作，并且在这些工作的最后规划了 10 项冲刺审查。利益相干者以及管理者们会尽职地参与第一轮的 10 个会议，随后便走开。

_Dean_ 向这些人提问：其中有多少人会在下一次冲刺审查中再次出现？这个问题背后的含义是，这些人显然不会用自己宝贵的时间，来重复审阅所有 10 个团队的工作。他暗示在“现实世界中”，这些人只不过是因为没有时间来干这件事情，而这是将是不可持续的。

作为变通，团队需要推动他们的成果成为非凡的表演项目——非常接近最终发布，或是就在发布前的最后一版——我们称之为发布预览。通过这样的方式，利益相干者和领导者们的时间将能够得到有效的保证。团队也将会因为展示更成熟的软件并且获得更广泛的反馈和可见性而获益。我认为这种想法或心态是无可救药的：领导者的时间最为宝贵，而团队天生要为其“服务”。如果团队正在从事地球上最高业务优先级的工作，而且该工作是所有敏捷团队的前提，那么作为一个领导者我需要离开自己的座位，去参与到团队中。我应该特别关心他们在做什么、他们怎么去做，以及他们所做的看上去怎么样。

最后，_SAFe_ 认证的专业顾问（SPC） Valerie Santillo——同时她还拥有实现 _SAFe_ 的经验——表达了对 _SAFe_ 的欣赏与忧虑交织的观点。她看到了部分实践中的价值，也对缺乏对人的关注而感到忧心：

任何框架都会存在不能胜任要求的风险，然而这并不是框架本身的问题。问题在于人。是人的部分让框架和流程能够运转。购买任何框架也都具有风险，同样风险还是来自于人——销售人员。销售 _SAFe_ 的人有义务描绘更多的内容，而不仅仅是框架。_SAFe_ 在扩展方面是敏捷的，这意味着其中包含文化和策略方面的元素。组织机构要想达成期望的成果，必须注意这两方面，并且为此而努力。

目前显而易见的是，SAFe_ 已经占有一席之地，而且正是时下的热点。而且对于 _SAFe，赞誉者和批评者的数量都很庞大。各位读者对 _SAFe_ 的经验又是怎样的呢？

查看英文原文： Has SAFe Cracked the Large Agile Adoption Nut?