Laurent Bossavit：敏捷十年之路

为什么对“敏捷十周年纪念”大做文章？只因我们喜欢整数？还是有更深远的意义？

计算机还是个年轻的领域，因此十年对于任何存在的事情来说都是相当长的时间。十年，对于我们的业务来说，只有极少数东西才有“历史”。

软件从业人员对历史有多关注呢？远远不够。我仅从业二十余年，可能不足取信。

“在计算机领域工作了超过半个世纪之后，有一件事让我很担忧，远超其它事情：那就是缺乏历史感。”Jerry Weinberg 在一篇文章 [1] 的开篇写道，Weinberg 在 IBM（成立于一个世纪以前）工作时，为 Mercury 项目（超过 15 年）进行操作系统开发。

所有人都知道“前车之辙，后事之师”（但我们真的照做了吗？）Weinberg 的文章是他二十年前一篇文章的更新，那时正是结构化编程概念达到顶峰的时候。令人沮丧的是，他对结构化编程运动缺点的评论仍然中肯，只是把“结构化编程”替换为“敏捷”。

历史很重要，如果不被曲解的话。

作为曲解的一个例子，想想“创造神话”，我们创建敏捷的初衷，是为了推翻笨重、腐坏的瀑布方法。故事还在继续，瀑布方法在人们悲剧性的错误理解了 Winston Royce 在 1970 年发表的论文后而广泛被接受。论文的第一页包含了如今知名的描述软件项目模型的图例，这个模型将软件项目分解为一系列顺序的阶段。但这只是一组逐渐复杂的图例中的第一幅，这系列图例逐步揭示了 Royce 真正想表述的；但读者——那些忙碌的人——没有翻过第一页，且忽略了第二页上 Royce 的警告：“我相信这个概念，但实施起来充满风险并容易招致失败。”

这个（很诱人的）故事的问题在于，Royce 没有开创软件开发的顺序阶段模型。如果仔细的阅读历史文献，如 1968 年 NATO 会议的记录 [2] ，在那次会议上创建了软件工程的原则，会发现大量证据表明这个模型早已流行。

准确的了解历史，并正确的怀疑引人瞩目的神话，是构成真正前进的基石。

如今，即便是敏捷社区也很少关注记录各种构成其“知识体系”的想法的历史，我对此时常感到沮丧。

例如，那些对敏捷了解很少的人知道“敏捷已经十年了”，这本身就是一种曲解。敏捷的根基其实远早于 2001 年 2 月在 Snowbird 的那次会议。Scrum 和极限编程，在那时已经积淀了十年。

最危险是关于概念的曲解，不幸的是，如今普遍认为，敏捷包含一系列互相竞争的流程“流派”：Scrum、极限编程、精益还有看板（Kanban）。为了推行这个或那个流派，我们年轻的历史将会充斥有趣的细节。

比如，Scrum 标准的讲解中让学员或读者相信“Sprint 回顾”过去是、现在是、未来也是 Scrum 的一部分。实际上，回顾是最近才加入 Scrum 的，回顾由极限编程引入，因一小部分《项目回顾》一书的热情实践者才流行开来，该书由 Norm Kerth 写于 2001 年。回顾作为敏捷实践的“常态”只可追溯到 2006 年。

重建敏捷的准确历史很困难，这是由敏捷运动自下而上的本性决定的：它的参与者倾向忽视教条和集权。他们接纳新想法只因为他们认为这些想法有趣并有效；他们在自己的项目中试验这些想法，保留有效的并放弃无效的。他们通常不关心这些方法的优先级和来源。

在 2011 年，敏捷不再等同于那些“流派”，比如 Scrum、极限编程、精益软件开发或那些声称是敏捷先锋的方法。（对我来说，这是 2001 年会议的价值，回过头来看很清楚：它标志着，不是敏捷运动的开始，而是这些流派衰落的开端。）

然而，现在仍很难确切知道敏捷 2011 意味着什么。整十年诱使我们编造故事，制造某种转折点，如“敏捷已到来”，为某些“到来的”价值。

我视其为黑暗中的呼啸。

准确理解历史的价值在于，我们能估计实际能完成了多少，及剩下多少工作要做。

多少：敏捷运动成功的推翻了很多过去的“正统观念”。不仅仅归因于敏捷导致瀑布模型的消亡，因为自 1980 年代 Boehm 的 Spiral 模型提出以来，瀑布模型已经开始走下坡路。我认为更重要的在于让“开发人员测试”复兴——70 年代，我相信很大原因在于 Glenford Myer 关于软件测试的书，“开发人员绝不能测试自己的代码”这一见解得以确立，成为公认的智慧。测试驱动开发的实践，最初在极限编程中形成，但适用于绝大多数敏捷项目，显示出如果过度泛化将适得其反。

与之类似，敏捷为很多存在很久的问题给出新的见解，例如软件设计、项目计划或程序员的管理。本文无法深入讨论这些新见解，但我想指出敏捷和其它软件工程或项目管理方法相比有着不同的原则，既不能减少也不能照单全收。当这些原则最终完整的成长后，会发挥出巨大的潜力。

然而我们必须承认我们实际完成了很少。正如 Weinberg 在他文章中的评价，如今多数团队声称“做敏捷”，其实只是三心二意的执行一些缩水的、理解有限的敏捷实践的子集。

抱怨“不称职的敏捷”、“Scrum 持保留意见”很容易，并容易导致责备受害者——这就像责备学生无法理解那些几乎没讲解过的东西，而不是责备讲师没尽到责任一样。

到目前敏捷运动仍然还是一个运动，一个社区。我们正在努力，我认为在组织会议、颠覆会议（unconference）、工坊（workshop）、提出新点子和交换每个人关于软件的想法方面我们做得很棒。但很多方面还不那么好，比如踏实工作、巩固共识、乐于帮助“新手”、也没有在改变现如今全球大学生软件工程教学方面取得哪怕一点儿进展。

我对敏捷社区日益惊人的革新能力充满希望。特别是，我认为需要新一代敏捷机构——不是替代敏捷联盟、Scrum 联盟和很多小规模但重要的小组，而是与之共同协作，投入到诸如组织会议、颠覆会议或编程道场（Coding Dojo）之类的工作中。例如，这样的机构可以开始着手解决如何与研究和教育社区更有效合作的挑战。

是的，十是一个好看的整数，但走过十年的敏捷才刚刚开始，尚需努力——通向下一十年。

关于作者

Laurent Bossavit 是敏捷的“早期实践者”，在 Snowbird 会议前一年偶然发现了极限编程。他因对敏捷实践的贡献而获得 2006 年 Gordon Pask 奖。他目前领导敏捷学院（ Institut Agile ），敏捷学院是一个私人资助的独立实体，目标是培养敏捷商业的生态系统，加强对敏捷方法感兴趣的商业社区和研究社区之间的联系，并提供敏捷实践优势和劣势更有说服力的证据。

[1] Beyond Agile Programming

[2] The NATO Software Engineering Conferences

[3] Agile@10

查看英文原文： Laurent Bossavit: Agile Ten Years On

感谢崔康对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家加入到 InfoQ 中文站用户讨论组中与我们的编辑和其他读者朋友交流。