《敏捷软件开发：原则、模式与实践（C#版.修订版）》—第1章1.1节敏捷联盟

本节书摘来自异步社区《敏捷软件开发：原则、模式与实践（C#版.修订版）》一书中的第1章1.1节敏捷联盟，作者【美】Robert C. Martin , Micah Martin，更多章节内容可以访问云栖社区“异步社区”公众号查看。

第一部分 敏捷开发
敏捷软件开发：原则、模式与实践（C#版.修订版）

人与人之间的交互是复杂的，并且其效果从来都难以预期，但是它们却是工作中最为重要的方面。

——Tom DeMarco和Timothy Lister，《人件》

原则（principle）、模式（pattern）和实践（practice）都是重要的，但是使它们发挥作用的是人。正如Alistair Cockburn所说的：“过程和技术对于项目的结果只有次要的影响。首要的影响是人。”1

如果把程序员团队看作是由过程驱动的组件（component）所组成的系统，那么就无法对他们进行管理。用Alistair Cockburn的话来说，人不是“插入即兼容的编程装置。”如果想要项目取得成功，我们就必须构建起具有合作精神的、自组织（self-organizing）的团队。

鼓励构建这种团队的公司比认为软件开发组织不过是由无关紧要的、雷同的一群人堆砌起来的公司更具竞争优势。凝聚在一起的软件团队是最强大的软件开发力量。

他在与我私人交流中如是说。

第1章 敏捷实践
敏捷软件开发：原则、模式与实践（C#版.修订版）

教堂尖顶上的风标，即使由钢铁制成，如果不懂得顺应风势的艺术，一样会很快被暴风所摧毁。

——海因里希·海涅，德国诗人

许多人都经历过由于没有实践的指导而导致的项目噩梦。缺乏有效的实践会导致不可预测性、重复的错误以及努力白白浪费。延期的进度、增长的预算和低劣的质量致使客户对我们丧失信心。更长时间的工作却生产出更加低劣的软件产品，也使得开发人员感到沮丧。

一旦经历了这样的惨败，就会害怕重蹈覆辙。这种恐惧激发我们创建一个过程来约束我们的活动，并要求某些输出和制品（artifact）。我们根据过去的经验来规定这些约束和输出，挑选那些在以前的项目中看起来好像工作得不错的方法。我们希望这些方法这次还会有效，从而消除我们的恐惧。

然而，项目并没有简单到使用一些约束和制品就能够可靠地防止错误的地步。当连续地犯错误时，我们会对错误进行诊断，并在过程中增加更多的约束和制品来防止以后重犯这样的错误。经过多个项目以后，我们就会不堪巨大、笨重的过程的重负，极大地削弱我们完成项目的能力。

一个大而笨重的过程会产生它本来企图去避免的问题。它降低了团队的开发效率，使得进度延期，预算超支。它降低了团队的响应能力，使得团队经常创建错误的产品。遗憾的是，这导致许多团队认为，这种结果是因为他们没有采用足够多的过程方法引起的。因此，在这种失控的过程膨胀中，过程会变得越来越庞大。

用失控的过程膨胀来描述公元2000年前后许多软件公司中的情形是很合适的。虽然有很多团队在工作中并没有使用过程方法，但是采用庞大、重型的过程方法的趋势却在迅速增长，在大公司中尤其如此。

1.1 敏捷联盟
2001年初，由于看到许多公司的软件团队陷入了不断增长的过程的泥潭，一批业界专家聚集在一起概括出了一些可以让软件开发团队具有快速工作和响应变化能力的价值观和原则。他们称自己为敏捷联盟。在随后的几个月中，他们创建出了一份价值观声明，也就是敏捷联盟宣言（The Manifesto of the Agile Alliance）。

敏捷软件开发宣言

我们正在通过亲身实践以及帮助他人实践，揭示更好的软件开发方法。
通过这项工作，我们认为：

人和交互重于　　过程和工具

可以工作的软件重于　　面面俱到的文档

客户合作重于　　合同谈判

随时应对变化重于　　遵循计划

虽然右项也有其价值，但我们认为左项更加重要。

Kent Beck　　Mike Beedle　　Arie van Bennekum　　Alistair Cockburn

Ward Cunningham　　Martin Fowler　　James Grenning　　Jim Highsmith

Andrew Hunt　　Ron Jeffries　　Jon Kern　　Brian Marick

Robert C. Martin　　Steve Mellor　　Ken Schwaber　　Jeff Sutherland

Dave Thomas

1.1.1 人和交互重于过程和工具
人是获得成功的最为重要的因素。如果团队中没有优秀的成员，那么就算是使用好的过程也不能从失败中挽救项目。但是，不好的过程却可以使最优秀的团队成员失去效用。如果不能作为一个团队进行工作，那么即使拥有一批优秀的成员也一样会惨败。

一个优秀的团队成员未必就是一个一流的程序员。一个优秀的团队成员可能是一个具有一般水平的程序员，但是却能够很好地与他人合作。好的合作（沟通以及交互）能力要比单纯的编程能力更为重要。一个由一般水平的、具有良好沟通能力的程序员组成的团队，比那些拥有一批高水平的程序员，但是成员之间却不能进行交流的团队更有可能获得成功。

合适的工具对于成功来说非常重要。像编译器、IDE和源代码控制系统等，对于团队的开发者正确地完成他们的工作至关重要。然而，工具的作用可能会被过分地夸大。使用过多庞大、笨重的工具就像缺少工具一样，都是不好的。

我的建议是从使用小工具开始。尝试一个工具，直到发现它无法适用时才去更换它。不要急着去购买那些先进的、价格昂贵的源代码控制系统，相反应该先使用一个免费的系统，直到能够证明该系统已经不再适用。在决定为团队购买最好的CASE工具许可证前，先使用白板和方格纸，直到明确地知道需要更多的功能。在决定使用庞大的、高性能的数据库系统前，先使用平面文件（flat file）。不要认为更大的、更好的工具可以自动地帮你做得更好。通常，它们造成的障碍要大于带来的帮助。

记住，团队的构建要比环境的构建重要得多。许多团队和管理者就犯了先构建环境，然后期望团队自动凝聚在一起的错误。相反，应该首先致力于构建团队，然后再让团队基于需要来配置环境。

1.1.2 可以工作的软件重于面面俱到的文档
没有文档的软件是一种灾难。代码不是交流系统原理和结构的理想媒介。团队更需要编制容易看懂的文档，来对系统及其设计决策的依据进行描述。

然而，过多的文档比过少的文档更糟。编制众多的文档需要花费大量的时间，并且使这些文档和代码保持同步，要花费更多的时间。如果文档和代码之间失去同步，那么文档就会变成庞大的、复杂的谎言，会造成重大的误导。

对于团队来说，编写并维护一份系统原理和结构方面的文档总是一个好主意，但是那份文档应该短小并且主题突出。短小的意思是说，最多有一二十页。主题突出的意思是说，应该仅论述系统的最高层结构和概括的设计原理。

如果我们拥有的仅仅是一份简短的系统原理和结构方面的文档，那么如何来培训新的团队成员，使他们能够从事系统相关的工作呢？我们会非常密切地和他们一起工作。我们紧挨着他们坐下来帮助他们，把我们的知识传授给他们。我们通过频繁的培训和交互使他们成为团队的一部分。

在向新的团队成员传授知识方面，最好的两份文档是代码和团队。代码真实地表达了它所做的事情。虽然从代码中提取系统的原理和结构信息可能是困难的，但是代码是唯一没有二义性的信息源。在团队成员的头脑中，保存着时常变化的系统的脉络图。人和人之间的交互是比把这份脉络图记在纸上并传授给他人更快、更有效的方式。

许多团队因为注重文档而非软件，从而导致进度拖延。这常常是一个致命的缺陷。有一个简单规则可以预防该缺陷的发生。

Martin文档第一定律（Martin’s First Law of Documentation）

直到迫切需要并且意义重大时，才编制文档。

1.1.3 客户合作重于合同谈判
不能像订购日用品一样来订购软件。你不能够仅仅写下一份关于你想要的软件的描述，然后就让人在固定的时间内以固定的价格去开发它。所有用这种方式来对待软件项目的尝试都将以失败而告终。有时，失败是惨重的。

告诉开发团队想要的东西，然后期望开发团队消失一段时间回来后就能够交付一个满足需要的系统，这对于公司的管理者来说是具有诱惑力的。然而，这种操作模式将导致低劣的质量和失败。

成功的项目需要定期且频繁的客户反馈。不是依赖于合同或者关于工作的陈述，而是让软件的客户和开发团队密切地工作在一起，并尽量经常地提供反馈。

一个指明了需求、进度以及项目成本的合同存在根本的缺陷。在大多数情况下，合同中规定的条款远在项目完成之前（有时甚至是远在合同签署之前）就变得没有意义。那些为开发团队和客户的协同工作方式提供指导的合同才是最好的合同。

我在1994年为一个大型、需要多年才能完成并有50万行代码的项目达成的合同，可以作为一个成功合同的样例。作为开发团队的我们，每个月的报酬相对是比较低的。大部分的报酬要在我们交付了某些大的功能块后才支付。那些功能块没有在合同中详细地指明。合同中仅仅规定在一个功能块通过了客户的验收测试时才支付该功能块的报酬。那些验收测试的细节并没有在合同中指明。

在这个项目开发期间，我们和客户紧密地工作在一起。几乎每个周五，我们都会把软件提交给客户。到下一周的周一或者周二，客户会给我们一份关于软件的变更列表。我们会把这些变更放在一起排定优先级，然后把它们安排在随后几周的工作中。客户和我们如此紧密地工作在一起，以至于验收测试根本就不是问题。因为他们周复一周地观察着每个功能块的演进，所以他们知道何时这个功能块能够满足他们的需要。

这个项目的需求基本处于一个持续变化的状态。大的变更是很平常的。在这期间，也会出现整个功能块被去掉，而另外的功能块被加进来的情况。然而，合同和项目都经受住了这些变更，并获得成功。成功的关键在于与客户的紧密协作，并且合同指导了这种协作，而不是试图去规定项目范围的细节和固定成本下的进度。

1.1.4 随时应对变化重于遵循计划
随时应对变化的能力常常决定着一个软件项目的成败。当我们构建计划时，应该确保计划是灵活的，并且易于适应商务和技术方面的变化。

计划不能考虑得过远。首先，商务环境很可能会变化，这会引起需求的变动。其次，一旦客户看到系统开始运作，他们很可能会改变需求。最后，即使我们知道需求是什么，并且确信它们不会改变，我们仍然不能很好地估算出开发它们需要的时间。

对于一个缺乏经验的管理者来说，创建一张优美的、关于整个项目的PERT或者甘特图，并把它贴到墙上是很有诱惑力的。他们也许觉得这张图赋予了他们对项目的控制权。他们能够跟踪单个人的任务，并在任务完成时将任务从图上去除。他们可以将实际完成的日期和计划完成的日期进行比较，并对出现的任何偏差做出反应。

然而，实际会发生的是：这张图的组织结构不再适用。当团队对于系统有了新认识，当客户对于需求有了新认识，图中的某些任务会变得没有必要。另外一些任务会被发现并增加到图中。简而言之，计划图的形状（shape）将会改变，而不仅仅是日期上的改变。

较好的做计划的策略是：为下一周做详细的计划，为下3个月做粗略的计划，再以后就做极为简略的计划。我们应该清楚地知道下周要完成的任务，粗略地了解一下以后3个月要实现的需求。至于系统一年后将要做什么，有一个模糊的想法就行了。

计划中这种逐渐降低的细致度，意味着我们仅仅对于迫切的任务才花费时间进行详细的计划。一旦制定了这个详细的计划，就很难进行改变，因为团队会根据这个计划启动工作并有相应的投入。然而，由于该计划仅仅支配了一周的时间，计划的其余部分仍然保持着灵活性。

本文仅用于学习和交流目的，不代表异步社区观点。非商业转载请注明作译者、出处，并保留本文的原始链接。