XP 2002 大会

记住精神

会议正式开始于 Ken Schwaber 的演讲。Ken 以敏捷开发不仅仅是重新包装一堆旧技术，而是全新的革命性事物为主题开场。将敏捷视为旧主题变体的文章，例如 Barry Boehm 最近的 IEEE Computer 文章，并没有真正理解敏捷的特殊之处。

Schwaber 将 Scrum 描述为一种产品开发方法，它超越了软件本身。他说 XP 提供了在许多 IT 组织中缺失的工程实践，而 XP 和 Scrum 的融合是敏捷流程中最纯粹的。

根据他的经验，有两种类型的项目对敏捷感兴趣，一种是陷入困境的项目，另一种是好奇的项目。他发现前者更好，因为他们会遵循敏捷建议，而后者则会对各种想法说“但是”。他批评了从敏捷方法中获取一些想法的常见做法，说这就像从精心制作的瑞士手表中取出一个精美的弹簧一样。

Schwaber 建议了几个真正的敏捷标志

• 经理认为在没有所有需求的情况下继续进行是可以的
• 业务人员对交付软件感到兴奋
• 工程师在遇到问题时会被听到
• 大楼里有一种嗡嗡声
• 团队决定如何完成工作
• 人们不再谈论通常的角色

他说，敏捷是一种权力转移，它将 IT 交还给企业。从商业角度来看，ROI（投资回报率）是成功的唯一真正衡量标准。敏捷面临的最大危险是人们过于关注实践而忘记了更大的图景，即敏捷开发的革命性方面。

实践和哲学之间的相互作用一直困扰着敏捷和 XP 社区。我认为对于 XP 来说尤其如此，因为它既包含一些关于软件开发方式的重要哲学方法，也包含一些非常具体的实践方法。这导致了一个真正的问题，即 XP 的本质究竟是什么——是实践还是潜在的哲学？这一点尤其值得注意，因为随着您在 XP 中获得更多经验，实际遵循实践变得不那么重要。但同时，您必须进行实践才能了解 XP 的真正含义（这是我在 XP 主题的变奏 中探讨的一个难题）。

在许多方面，我认为“敏捷”标签帮助我们更容易地思考这种分离。在 雪鸟聚会 中，真正有价值的是，尽管实践存在差异，但与会者在哲学方面达成了高度一致。这就是为什么宣言中的价值观如此有效。我同意 Ken 的观点，敏捷在其基本要素（从预测到适应，从面向过程到面向人）的转变更像是一种不连续性，而不是一种进步，尽管很难看到边界。

但我并不太担心关注实践——事实上，我认为这是必不可少的。良好的开发实践对于实现敏捷开发的承诺至关重要。XP 在此方面的贡献，例如其用于演化软件设计的技术，对于我们未来保持灵活性至关重要。如果没有所有部分，就没有瑞士手表可以欣赏。

制作好的文档

敏捷会议从不回避邀请那些被许多人认为是敏捷事业对手的人，例如 CMM 的 Mark Paulk 去年在 XP Universe 上发表演讲。今年，XP 2002 欢迎 David Parnas，他对 XP 持更加批判的态度。

他说，XP 的一个大问题是它专注于困扰软件开发 40 年的问题。XP 对代码的关注有其益处，但未能解决其他重要的软件开发问题。软件最大的问题是对意外事件的反应不佳以及接口的定义和控制不佳。

他批评的重点是 XP 对设计的方法，他认为这会导致延迟问题。这是一个经济问题，现在省钱，但以后要付出代价。专注于简单性是好的，但短视的简单性和有远见的简单性之间存在差异。真正的长期简单性需要规划，规划需要审查，审查需要文档，因为来自代码的反馈来得太晚。

但他并没有提倡大多数项目所做的文档。他认为大多数项目文档弊大于利，并批评了“未定义建模语言”。XP 的测试用例还不够，因为它们不可能完整。他赞成一种定义明确的数学方法，但表示形式化方法社区并没有走上正确的道路，因为这些数学规范必须比代码更容易阅读，而这对于常见的形式化方法（如 Z 或 VDM）来说是不可能的。

他说，这种数学方法需要基于函数和关系。识别需要监控和控制的变量，并从监控变量中推导出受控变量。然后，这些变量可以以表格形式放置，以便领域专家可以阅读，每个受控变量对应一个表格。他引用了一个航空电子系统项目，飞行员根据这种规范发现了数百个错误。当然，时间不允许他深入解释该系统。

关于 XP 对设计方法的争论非常激烈，这也是我 在 XP 2000 上演讲的主题。在软件开发的早期职业生涯中，严格但易读的规范一直是我的一个主题。我在软件会议上的第一篇论文是关于图形设计技术如何以数学上严格的方式使用，这正朝着相同的方向发展。

我认为，Parnas 也会同意我的观点，这种形式化规范的价值在于能够发现错误，以便比其他技术更有效地修复错误。如果您的开发方法是计划设计，您期望在编码开始之前设计基本完成，那么这至关重要，因为否则规范中的错误直到流程的后期才能发现。

XP 从几个方向攻击这个问题。它使用短迭代，这意味着您可以从代码中获得快速反馈，因为用户在几周内就开始获得可以使用的系统。它使用重构，允许以比没有重构的情况下更低的成本修复短视的简化，并支持积极的测试和持续集成。

问题的关键是，这种形式的数学规范是否比 XP 的方法更具成本效益，以及在什么条件下。我从未相信任何特定方法都一定适合所有不同类型的软件开发，因此最适合航空电子设备的方法可能不是企业应用程序的正确途径。我在企业世界中对更正式方法的实验让我相信，领域专家无法很好地使用它们来发现错误，就像迭代交付一样。我还惊讶于演化设计在 XP 环境中的有效性，尽管我仍然偏爱一点计划设计。然而，话虽如此，我还没有尝试过 Parnas 的特定技术。我希望一些 XP 人员在与客户合作时尝试这些技术，看看它们是否值得使用成本。虽然我认为 Parnas 将这些技术视为在预测环境中使用，但我认为它们可以在迭代环境中使用。

使用二十年前被抛弃的做法

如果 David Parnas 是 XP 社区的局外人，那么 Enrico Zaninotto 是整个软件开发世界的局外人，他是一位经济学教授。他对将敏捷方法与制造业的最新发展进行比较感兴趣，这源于他看到一个软件开发项目使用 20 年前领先制造商抛弃的技术的经历。

Zaninotto 概述了四个主要驱动因素，这些驱动因素增加了制造或软件开发工作的复杂性。

• 系统可以进入的状态数量
• 各个部分之间的相互依赖性
• 您可以采取的各种行动的不可逆性
• 环境中的不确定性

他将泰勒和福特模式描述为通过专注于系统可以进入的状态数量来处理复杂性。他们通过分工、标准化部件和装配线来解决这些问题，装配线固定了可以制造的产品，从而限制了状态数量。Zaninotto 将瀑布式流程视图视为遵循这种模式。泰勒/福特模式的局限性在于，当您遇到不可预见的后果时。这种方法在您知道将会发生什么的情况下优化了情况，但容易受到不确定性的影响。

制造业的范式转变是丰田系统。他说，在四个复杂性驱动因素中，丰田系统解决了不可逆转性问题，允许改变决策。泰勒/福特控制信息流，将其嵌入系统中，而丰田系统将决策权推到行动点。

像丰田系统这样的灵活系统最大的困难是它们可能不会收敛。为了使事物收敛，丰田系统将变化控制在一定范围内，并使用高水平的质量控制。Zaninotto 将这种收敛问题视为 XP 的限制点。XP 的真正界限是收敛仍然发生的界限。

在 Zaninotto 的演讲中，我并没有处于最佳状态，会议晚餐提供了一个非常棒的乐队和大量的 Mirto——这导致了深夜和疲惫的夜晚。而且 8.30 对我来说从来都不是最好的时间。但我对这次演讲很着迷。Zaninotto 用非母语演讲，他阅读了他的文本，但在许多方面，演讲的简单性放大了内容的质量。丰田系统和敏捷流程之间的联系是 Mary Poppendieck 已经绘制出的领域，这促使我进一步探索，但 Zaninotto 为我之前学到的知识增添了新的想法。（这是为数不多的几个值得阅读 全文 的案例之一。）

可逆性问题，以及不可逆性是复杂性原因的观点，是我特别感兴趣的一点。DSDM 的一个有趣之处在于，其九项核心原则之一是“开发过程中的所有变更都是可逆的”。将可逆性放在像这样的方法论的首位是不寻常的。一个论点是，可逆性是增量变更的必要保护措施。这意味着最糟糕的情况是暂时出现问题，然后恢复到以前的状态。当然，这些临时问题可能非常严重，就像任何计算机缺陷一样，但一旦发现故障，即使无法立即找到根本缺陷，也可以通过恢复来修复。

当我阅读最近的 FDD 书籍时，我注意到他们在核心实践列表中包含了配置管理。配置管理被排除在 XP 之外，不是因为它不必要，而是因为 XP 认为配置管理是基本能力的一部分。然而，经常会遇到一些人似乎不明白如何正确使用配置管理。

另一个让我印象深刻的因素是可逆性和迭代开发之间的相互关系。如果你做出了错误的决定并迅速发现，那么你可以使用某种形式的可逆性来撤销你的错误，或者你可以在错误失控之前进行重构。但是，如果你不能快速发现它，那么它就会嵌入到系统中，难以逆转。迭代周期使你能够更早地发现错误，在它们难以逆转之前，重构进一步降低了消除错误的成本。最终结果是，你不会被绑定到第一次就把事情做对，这消除了一个主要的复杂性来源。严格流程的大部分思考都是关于应对不可逆流程的，而旨在应对不可逆性的技术一旦消除了这种复杂性，就会成为多余的负担。

XP 实践的隐喻

Bill Wake 是今年全体会议演讲节目中唯一一位知名的 XP 领导者，他的演讲语气比其他许多全体会议演讲都轻快。他的主题是隐喻，不是像 XP 中的隐喻实践那样，而是指各种 XP 实践的隐喻。以下是我注意到的那些隐喻。

• 测试先行就像数学问题，它们只告诉你偶数答案——重点不是答案，而是过程。
• Spike 就像木工，你只做一个来观察它的工作原理。测试先行也在这里发挥作用，因为你可以在制作物品之前弄清楚事物应该如何配合。
• 集体代码所有权就像电影和电视剧（如西翼）中的情况室。重点是每个人都可以访问所有信息，因此能够为解决问题做出贡献。
• 结对编程就像四手联弹钢琴音乐，或者可能像双人摔跤。
• 迭代就像钟表上的擒纵机构。
• 学习 XP 就像学习一门外语。
• 持续集成就像平衡支票簿。如果你只每年做一次，那会很痛苦，但如果你每周做一次，那很容易。
• 下班前清理干净（用绿色条形码签入）就像日内交易，你在一天结束时将你的投资组合保持平衡。
• 站立会议就像赛跑的起跑器，之后每个人都朝着同一个方向奔跑。
• 迭代回顾就像一支运动队观看他们上一场比赛的录像。

隐喻在 XP 中是一个有争议的话题，我发现当隐喻运作良好时，它会令人难以置信地令人满意，但想出一个运作良好的隐喻非常困难。将这种隐喻性思维作为一项强制性实践是有限制的，因为它要求你做一些困难的事情，而更简单的事情通常可以完成足够的工作。因此，在使用 XP 时，我不太担心隐喻，但我不会让它阻止我使用一个好的隐喻，如果它出现的话。

就像大多数隐喻一样，我发现 Bill 的一些隐喻很有趣，但大多数对我来说并不适用。持续集成 == 平衡支票簿运作得很好，我会通过指出使用自动化支持来平衡支票簿更容易来扩展它（使用 Quicken 非常有用）。我也喜欢情况室/集体代码所有权的类比——尽管我从未看过西翼。

但我从来没有真正喜欢过四手联弹钢琴音乐——至于双人摔跤？至少我可以玩一下 Ron "The Hammer" Jeffries 和 Ann "Wild Woman" Anderson 对战 Kent "Alpha Chimp" Beck 和 Robert "Black Hole" Martin 的心理图像。（我只想确保 Rob Mee 是我的搭档。）

只构建你需要的功能

Jim Johnson 是 Standish Group 的主席，因此毫不奇怪，他的演讲中包含了 Standish Group 在过去几年中一直在跟踪的统计数据。经常被引用的标题是，只有 28% 的 IT 项目真正完全成功：49% 的项目“有挑战性”，23% 的项目失败。

当然，这种统计数据在很大程度上取决于成功的定义，重要的是，Standish 混沌报告将成功定义为按时、按预算完成，并且具有大部分预期功能。像敏捷社区的大多数人一样，我对此表示质疑。对我来说，一个项目如果延期并且超支，那就是估计的失败。一个项目可以延期，超支很多，但仍然是一个巨大的成功——就像 Windows 95 对微软来说一样。项目成功更多地取决于软件是否提供的价值大于投入资源的成本——但这很难衡量。

Jim 提到的另一个有趣的统计数据是软件产品中未使用的功能所占的比例很大。他引用了两项研究：杜邦研究引用了只有 25% 的系统功能是真正需要的。Standish 研究发现，45% 的功能从未使用，只有 20% 的功能经常或总是使用。

这当然符合许多敏捷主义者的轶事证据，他们认为传统的需求收集方法最终会收集比真正需要用于发布可用版本的需求更多。我认为这也表明，大多数项目应该只有目前规模的四分之一。如果你还考虑软件的规模不经济，这表明许多团队也应该更小。

这一点在 Johnson 对两个 SACWIS 系统的比较中得到了体现。SACWIS 是一个儿童福利系统，美国所有州都必须实施。他指出，佛罗里达州于 1990 年开始其 SACWIS 系统，最初的成本估计为 3200 万美元，计划于 1998 年交付，开发团队约有 100 人。当他们最后一次查看时，新成本为 1.7 亿美元，预计于 2005 年交付。他指出，明尼苏达州必须以与佛罗里达州几乎相同的社会人口问题构建相同的功能——导致非常相似的广泛系统需求。明尼苏达州于 1999 年开始工作，于 2000 年完成，由 8 人完成，耗资 110 万美元。

这种比较令人震惊地说明了 Chet Hendrickson 的说法：“在每个大型系统内部，都有一个小型系统试图摆脱”。我不能说我真的能判断导致这两个系统在成本和工作量上如此不同的细节。Standish 集团将这种差异主要归因于明尼苏达州在最大限度地减少需求方面更加成功，并且还使用了标准基础设施。如果说它没有别的，它非常暗示了通过关注将需求归结为其本质可以获得多少影响。当然，敏捷的论点是，短期的基于价值的迭代比预先的需求收集活动更有可能最大限度地减少需求。我们还需要一段时间才能获得关于这方面的真实数据。

无论你是否认同这种敏捷论点，我认为 SACWIS 的故事表明，软件行业面临着非常现实的挑战，即理解要构建多少才能提供价值。它表明，仅仅通过构建我们需要的功能，我们就可以大幅降低软件系统的成本。我的观点是，预先的需求流程对你不利，因为人们经常在没有成本的情况下查看需求。我检查过的需求文档几乎从未提及成本以及将成本理解为需求收集的一部分的重要性。在我看来，没有成本的需求文档几乎可以保证过度构建某些东西，特别是如果它与固定范围/固定价格合同捆绑在一起，这只会将不必要的费用固定到位。