某些敏捷软件开发者说像Scaled Agile Framework（SAFe）这样的预定义开发流程是敏捷方法论的背离而非延伸。他们说，敏捷与适应变化并让流程出现有关。敏捷顾问和实践者Mike Bonamassa说，这种办法比较适合于小型的敏捷项目。当他完成了大型开发项目时，在缺乏结构的情况下实践敏捷方法论效果就不是太好了。

你最先做的大型敏捷项目是什么？

Mike Bonamassa：回到2005年，有一个叫做Freddie Mac的大型计划失败了。我们开始用敏捷实践跟他们一起工作和实施，像日常的站立会议、时间限制、测试驱动开发、持续集成等等。我们看到了每天构建并以可预期的方式让所有人不断致力于开发出高品质软件所带来的好处。

说到践行敏捷方法，今天与2005年有何不同？

Bonamassa：现在我们专注于让敏捷可扩展，以便企业能清除掉应用项目面临的巨大障碍。

现在进行的敏捷修改比过去更多，也许是因为社区和项目的范围已经扩张了。人们知道，一些关键的敏捷实践是有效的，如自组织团队以及赋权。然后他们必须在大型企业内部将敏捷扩大化，可支持自组织团队就变得困难起来了。在那种环境下，了解敏捷的人必须与不了解者一起共事。这里面存在着技能、文化及语言上的障碍。在此环境下，存在着到组织的非敏捷部分要有明确的过渡点的需要。结果就是敏捷必须变得更为正式，要有更多预先确定的做法。 

自2001年写下敏捷宣言以来，你认为敏捷发生了何种转变？

Bonamassa：自宣言公布后敏捷已经发生了相当大的变化。认为敏捷是敏捷宣言及Scrum二者的结合仍然是非常主流的声音；但其他人正在悄悄制造敏捷的混合物。比方说，我们开始看到越来越多的极限编程（XP）实践被添加进来，像测试驱动开发及结对编程。那些实践本身并非真正的敏捷，因为那是出自于XP的；但XP却很难理解，也许是因为名字的晦涩。人们倾向于在业务中回避“极端”的做法。

能否详细阐述一下你用SAFe框架扩充敏捷开发的工作？

Bonamassa：我认为社区需要将敏捷划分为小型敏捷以及可谍或大型敏捷。这是两个非常不同的东西。小型敏捷这一块，开发者只需按照宣言的原则走就行了，如更多地专注于软件方面而非文档。

当你试图将此实践扩张到大型组织时，真正的挑战来了，这需要更加规范性的做法。你想要将几百号人凑到一起工作并每两周交付价值时，就必须放弃一些小型敏捷的做法。比方说那些做法在自组织团队中的部署、培训和管理需要消耗的时间太长了。这个过程要消耗的时间和磨合如此之多，以至于组织会在某个节点上对你完成此事的能力失去信任。

因此，为什么不从一个规定好该过程的计划开始呢？这就是Scaled Agile Framework的价值所在。SAFe方法正是以预定义实例的身份来执行敏捷。

SAFe如何帮助解决大型项目常见的开发问题？

Bonamassa：敏捷的一个问题是开发团队只需交付积压了2周以上的工作。这样的话，主管、产品所有者如何才能知道整个项目什么时候才能完成呢？知道产品的某一部分是否完成，整个项目何时完成成了一个大问题。

SAFe有一个中间层来帮助项目路线图。这里面有史诗，即你进行的为投资组合推动总体的价值模式的东西。在底层是故事，这是为了给冲刺完成积压工作交付功能提供动力用的。在中间层则是被分配到每4到5次冲刺后产生的潜在可交付增量中的功能。其结果就是每10到12周项目将会到达哪里的路线图。

能对项目制定路线图的关键价值是什么？

Bonamassa：拥有制定路线图的某些能力，哪怕只是部分提交，也能让主管有信心向项目投入数百万美元。这正是更加规范的方法，如SAFe能提供的东西。对于主管来说，这种办法相对于典型的外部化的Scrum更具吸引力，因为外部Scrum仅说明了何时功能可以完成它，但并不能做出保证。Scrum说，“我们正在致力于与一个功能相关的用户故事，但那是我们正在提交的唯一一件东西。”有谁能预期主管会向一个不做出承诺的项目投入数百万美元呢？我认为这就是大型项目市场目前最大的问题。