敏捷宣言的解释

敏捷宣言

1>     人和交互重于过程和工具

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

 

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

 

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

 

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

 

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

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

没有文档的软件是一种灾难。代码不是交流系统原理和结构的理想媒介。团队更需要编制易于阅读的文档，来对系统及其设计决策的依据进行面熟。

 

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

 

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

 

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

 

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

 

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

Martin 文档第一定律

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

3>     客户合作重于合同谈判

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

 

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

 

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

 

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

 

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

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

 

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

 

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

 

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

 

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

 

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