Liz Keogh：敏捷十年——对失败的预言，以及预言的失败

本文属于 InfoQ 发布的敏捷宣言10 周年系列文章。

在我的职业生涯第一个七年中，我所参加的项目仍保有很多瀑布式的习惯。七年的时间，我坐在电脑屏幕前，一个键一个键敲出代码，在地下室里，直到夜晚，有时甚至是周末；而且这七年里我开发的任何东西都没有转化成产品。项目有无数新增特性，它们被重新启动，被置之高阁，曾有某个项目进入到了诉讼阶段，但是没有一个人用过我这七年里开发的任何东西。

所以当我第一次遇到敏捷的时候，像很多运动的新来者一样，我充满热情。“你们做错了！那样不行的！”我大喊着，看着那些公司，它们无法拥抱全新的、增量式的、协作式的软件开发方法。当时的社区普遍流行这样的态度。预言已经写下来了：无法变革的公司将会无法生存。

敏捷宣言写成到现在已经十年了，很多公司还是无法高效地交付软件。某些这样的公司“在做敏捷”。其他公司仍挣扎于它们长达数年的项目中，依旧使用项目前期进行分析、设计的方法。但是它们还活着。

敏捷宣言的开头是：“通过自己践行并帮助别人践行，我们正在发现交付软件更好的方式。”对应到作者们当时应用敏捷方法的上下文，这是可行的。很多是小型团队，坐在一起，而且有互相配合的技能，易于成功。过去这几年，我们不断把敏捷应用到大型的项目和组织中。这些企业大怪兽变起来更慢，如果还可以变的话。Richard Durnall 写了一篇关于敏捷实施模式的博客，说明商业组织各个方面是如何被打破的，而且被迫变革去支撑敏捷实施，包括人、工具、监管、客户、财务控制和组织结构。然而，很多时候，我们看到的是公司的结构对变革流程会强力抵抗。人们保持瀑布式的习惯和思维方式，制定出武断的项目结束时间，并让开发团队严格遵守。人们使用工具而不是对话交流，更不要说记录和支持了。监管部门仍然要求确定性，可这在项目的完整生命周期中很难获得。客户坐在一个办公室里，开发人员在另一个，他们无法顺畅沟通或是提供反馈。财务总监坚持分析必须要先完成，在理论上要保证预算获得好的投资回报。

我们面临的问题是：传统上，瀑布式有一种“自行车式思考方式”。其前提是：软件项目可以通过分析分解成很多小部分，并得以实现，而且这些实现可以组合成一个系统。

不幸的是，“软件项目”并不是分析就可以完成的，分析得到的实现也无法组合得到一个成功的项目。项目的组成包括参与进来的人，他们的想法和阐述，其上下文是由围绕着这些人的其他人创造出来的。然而，这些人并不是项目的资产。Jurgen Apello 在他的书《Management 3.0》中指出：系统的资产通过系统中各个元素的交互浮现出来。只要环境让交互僵化，或是鼓励像层级式这样更简单的交互方式，那么敏捷就无法成功。

如果复杂度无法避免，我们就必须遵循项目中人与人的交互、以及项目之间的交互浮现出的模式。作为社区，我们签署了“个体和交互胜过流程和工具”，然后又强制推行流程来控制交互，同时使用工具而不是交互来支持流程；这样做我们是有罪的。未来，我们传授的实践将会促进交互，而不是控制它们。我们已经看到这样的趋势，比如看板等元流程的兴起。帮助理解复杂度、特别是人的复杂性的模型，也在世界各地的敏捷大会中传授，比如系统化思考、复杂度思考、心理学和社会学等等。

我们需要在组织的更高层次改变的，还有一种实践：让反模式的影响更加明显。在开始时我们语言的变革还没有看到多少。也许在接下来十年中，我们将会看到不同的宣言出现，它的开头是：“通过自己践行并帮助别人践行，我们正在发现推进变革更好的方式。”

关于作者：

Liz Keogh 是一位经验丰富的经验和敏捷教练、培训师、博客写手和知名的国际讲师。她有坚实的技术背景，工作成果覆盖多个领域，包括软件开发、架构，到心理学和系统化思考。她因其在 BDD 社区的积极参与而知名，并在 2010 年获得 Gordon Pask 大奖，理由是加深了敏捷领域中对于现有思想的理解，同时还能“提出自己某些非常疯狂的想法”。

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