加拿大 XP/敏捷方法扩展研讨会

提出的问题

在会议筹备阶段，参与者被要求就如何为大型团队扩展 XP 和敏捷方法提交他们的意见。根据询问对象的 不同，大型团队的定义可以是从 20 人到 200 多人不等。

向与会者提出的具体问题是

• 敏捷方法的可扩展性如何？
• 早期采用者的经验如何？
• 我们可以进行哪些实验来扩展这些方法的使用？

我们参与了多个 XP 项目，因此我们渴望听到其他人如何看待 XP 扩展，并分享我们自己在大型团队中使用 XP 的经验。

肯·施瓦伯

第一位主题演讲人是 Ken Schwaber。Ken 和 Jeff Sutherland 是 Scrum 敏捷方法的作者和创始人。Ken 首先描述了他在大型项目中使用 Scrum 的经验，以及他在项目生命周期的早期阶段成功使用的一些技术。

Ken 解释说，在一个项目中，团队非常关心在开发的早期阶段验证系统的整体架构。早期的项目迭代（Scrum 术语中的冲刺）包含专注于验证系统架构的故事，并穿插着几个真实的业务案例。经过几次迭代，在此期间不断完善和测试架构，团队对架构是否足以满足业务需求有了很好的了解。

然后，通过由原始架构团队的创始人组建新团队来实现扩展。解决了大部分架构问题后，新团队可以专注于在当时稳定的架构之上实现业务逻辑。

Ken 还强调了拥有一位不管理团队的 Scrum master 的重要性——相反，团队自我管理非常重要。Ken 发现，当团队能够自我组织并自行决定如何最好地完成交给他们的工作时，他们的效率会更高。这对习惯于命令和控制式领导风格的经理来说是一个挑战，而且一开始非常违反直觉。

Ken 提到的一个有趣观点是，局外人最初会如何看待敏捷方法。与所有取得一定成功的 新事物一样，人们自然会问这对他们有何作用。这是他们一直在寻找的“银弹”吗？Ken 想知道 XP 和敏捷是否会遭遇与 CMM（能力成熟度模型）类似的命运。

CMM 背后有很多优秀的人才，他们阐述了公司可以做些什么来提高软件项目成功的几率，并展示软件过程的成熟度。然而，CMM 从未像作者最初预期的那样被广泛接受和成功实施。据报道，2/3 的 CMM 项目实施都失败了。此外，当一家公司能够达到的认证级别往往取决于他们聘请谁来执行认证时，业内许多人对 CMM 持有一种愤世嫉俗的看法。

敏捷方法会遭遇类似的命运吗？当然，早期采用者已经取得了成功，但这些团队通常由技术娴熟、积极主动、对编写软件充满热情的 人员组成。可以说，无论名义上或实践中使用何种方法，由这类人员组成的团队都会取得成功。

在我们看来，这与敏捷关系不大，更多的是 人员对项目具有一级效应这一不可避免的事实。当你看到建立这类团队的反面（技术欠佳、缺乏动力、对编写软件没有热情的人）时，这一点就变得很明显了。对于这些团队来说，无论名义上或实践中使用何种方法，都无法让他们取得成功。

虽然 Ken 同意优秀的开发人员有助于推动流程顺利进行，但根据他的经验，同样正确的是，那些被归类为 平庸甚至糟糕的人，在敏捷提供的支持性、创造性和团队导向的环境中，往往会变得优秀。他见过以前由平庸的专业人士组成的、各自为政的团队，完成了他以前认为只有顶级人才才能完成的伟大事业。

来自现场的报告

会议的中间部分留给了其他从业者和研究人员，让他们分享他们对大型项目的思考和经验。

Philippe Kruchten（Rational）描述了使用 RUP 的大型团队（200 多人）过去如何成功交付大型项目。在项目的早期阶段，由高级从业者组成的团队负责完成初始的高级架构并制定开发实践。

随着项目进入构建阶段，会添加更多团队（由详细说明团队的创始人组成）。如果分解得当，每个团队都可以相当自主地工作（以迭代周期）。在某个团队需要另一个团队构建的组件的情况下，可以在两个团队之间协调同步点和里程碑。以这种方式处理大型项目，使团队产生了一种错觉，认为他们已经足够独立，可以获得小型敏捷团队的优势。

ClearStream Consulting 的 Gerard Meszaros 分享了他在一家大型电信公司与大型团队一起构建数字交换机的经验。他们在整个项目生命周期中都使用了频繁发布和重大的架构变更。然而，在他们能够做到这一点之前，系统已经达到了临界规模。

Gerard 还就当前有关 XP 和敏捷实践的行业文献提出了一个有趣的观点。在他看来，当今的大多数文献都是针对那些已经知道如何开发软件的人。如果要让 XP 超越早期采用者，就需要一套截然不同的文献。重复使用的比喻：“今天我们有针对那些知道如何烹饪的人的食谱。我们今天没有的是针对那些不知道如何烹饪的人的食谱。”

一家大型加拿大能源公司分享了他们在公司内部采用敏捷的经验。通过结合使用 Scrum 和 XP，他们在项目管理方面取得了巨大成功。在管理层的支持下，他们现在拥有一支专门的团队，向公司内的其他团队展示如何使用敏捷来提高成功的几率。关于 XP 和 Scrum 的进一步评论是，它们使团队能够调整和修改实践，以满足每个团队的需求。他们更喜欢这种方式，而不是他们过去使用的那种一刀切的项目管理形式。

作者（Jonathan Rasmusson 和 Jim McDonald）也有机会分享了我们自己在大型团队中使用 XP 的经验。因为我们主要使用 XP，所以我们研究了核心实践，并将它们分为两组——我们认为可以扩展的实践和不能扩展的实践。

我们相信与编写代码机制相关的 XP 实践是可以扩展的。我们认为，没有什么能够阻止大型开发人员团队编写测试、重构和结对编程。多年来（在 XP 或敏捷出现之前），人们一直在大型和小型项目中成功地实践这些技术。这些仅仅是良好的实践。

然而，那些以沟通为中心的实践将难以扩展。例如，对于 20 多人的团队来说，每日站会将变得很尴尬。迭代计划会议，即所有开发人员和分析师聚集在一起计划即将到来的迭代，将难以管理，因为协调这么多人会产生组织和沟通上的开销。我们认为扩展 XP 面临的最大挑战，与我们看到的每个大型项目面临的挑战相同——如何有效地沟通和协调大量人员。

我们也开始质疑这个问题本身。为什么人们想要扩展 XP？在小型团队中取得成功后，我们认为想要扩展是非常违反直觉的。相反，我们更愿意首先寻找替代方案，看看如何将大型项目缩减到我们知道 XP 能够很好地发挥作用的规模。

马丁·福勒

会议的最后一天以 Martin Fowler 的主题演讲“为什么扩展敏捷是你最不想做的事情”开始。他的主题演讲的标题改变了会议的基调。在那之前，会议的大部分时间都致力于试图回答如何扩展 XP 的问题。然而，Martins 的主题演讲却颠覆了这个问题，并询问听众这是否是 我们真正想做的事情。

他的演讲分为两部分。第一部分是一个经验报告，内容是关于 Thoughtworks 的一个项目，该项目涉及一个大型团队，在一个复杂的租赁应用程序上使用 XP 类型的流程。第二部分进一步阐述了标题，解释了为什么我们应该在尝试扩展 XP 之前寻找替代方案。

Martin 首先提醒我们，为什么构建复杂的业务应用程序具有挑战性。业务逻辑是一个矛盾修饰法。大多数业务方面（尤其是租赁）都没有什么逻辑可言。捕捉业务规则、隐藏假设、特殊情况，并将这些抽象成一个可靠的、经过实战检验的领域模型，是软件设计中最具挑战性的部分之一。

在大型项目中，需求收集也非常困难。Martin 对编写需求文档和写书进行了有趣的比较。写一本书需要投入大量的时间和精力。即使经过同行评审和专业编辑的反馈，作者也不一定总是能够成功地向读者传达他/她想要表达的信息。他的观点是，如果作者在写书时都很难做到这一点，那么想象一下，在资源少得多的情况下，要捕捉复杂业务应用程序的需求会是什么样子。

在该项目中，一个非常有效的做法是将人员轮换到应用程序的不同部分。这对项目分析师来说一开始很令人沮丧，因为当开发人员刚刚开始了解问题领域时，他们就会被调到系统的另一部分。然而，随着项目的进展，将人员调到应用程序其他部分的好处开始显现。最终，大多数开发人员都对应用程序的足够部分有所了解，以至于他们可以胜任许多角色。对少数几个人在应用程序的特定部分工作的依赖性降低了。开发人员自身在技术和业务领域都变得更加强大。对应用程序有更全局的了解，使他们能够洞察如何在维护整体系统架构的同时，最好地实现新功能。

Martins 主题演讲的后半部分重点介绍了为什么我们应该寻找扩展敏捷的替代方案。有些项目确实需要大型团队。需要完成的工作量通常太大，小型团队无法在合理的时间内完成。这方面的例子包括电信行业的大型项目和大型军事应用。对于这些团队来说，如何扩展敏捷是一个非常现实的问题。

然而，根据 Martin 的经验，许多团队规模过大。这些团队在尝试扩展敏捷之前，应该寻找替代方案（例如缩减团队规模）。Martin 要求听众中曾经参与过这样的项目的人举手：如果移除团队中最弱的一半成员，项目的生产力水平仍然可以保持不变。大多数听众都举起了手。这似乎反映出，许多听众都有类似的经历，他们参与的项目团队规模远远超过了必要规模。因此，Martin 建议团队不要首先考虑如何扩展 XP 和敏捷，而是首先考虑如何缩减不必要的庞大项目。

证据在哪里？

与会者似乎难以回答的一个问题是，什么样的实验可以提供经验证据，证明 XP/敏捷可以用于大型项目。学术/研究界承担了一项具有挑战性的任务，即提出实验和经验证据，证明敏捷方法可以扩展到大型团队。

虽然我们理解研究人员想要证明敏捷有效性的愿望，但我们也看到了证明这一点的几个挑战。Jonathan 认为，挑战在于如何客观地衡量软件质量和生产力。如果没有明确的、可量化的质量和生产力指标，如何对软件工程实践进行实验？Jim 认为，真正理解敏捷的途径是研究社会学，研究量化和描述人类互动方式的难度。由于沟通在敏捷项目中起着至关重要的作用，他认为对这些领域的研究将有助于更深入地理解敏捷为何有效。

总结

会议本身取得了巨大成功，所有与会者都享受了分享他们对如何最好地解决研究界提出的挑战性问题的想法和意见的机会。XP 和其他敏捷流程似乎开始受到学术界的关注，并开始得到认真对待。无论早期采用者提供什么建议，很明显，与任何新工具一样，XP 在未来几年将会被应用和误用。