原则

上述价值观启发了以下12个原则。这些原则是敏捷实践和重量级过程的区别所在。

1．最优先的是尽早和连续交付有价值的软件使客户感到满意。

《MIT斯隆管理评论》(1)杂志刊登了一篇文章，主题是帮助企业构建高质量产品的软件开发实践分析文章。文章发现，许多实践都对最终系统的质量有显著的影响。其中一条就是质量和尽早交付有部分功能的系统之间有很强的相关性。文章指出，初始交付的功能越少，最终交付时的质量越高。文章还发现，最终质量和频繁交付递增功能之间有很强的相关性。交付越频繁，最终质量越高。

敏捷实践要求尽早频繁交付。项目开始后的前几周，努力交付一个原始系统。之后，每隔几周交付功能递增的系统。客户若认为功能够用，可选择将这些系统投入生产。当然，也可选择评估现有功能，报告他们想要做哪些改动。

2．即使到了开发后期，也欢迎需求的变化。敏捷过程能驾驭变化，使客户获得竞争优势。

这是态度问题。敏捷过程的参与者无惧变化。他们将需求的变化看成是好事，团队能从中更好地了解怎样做才能使客户满意。

敏捷团队努力保持其软件结构的灵活性，所以当需求发生变化时，对系统的影响微乎其微。本书以后会讨论保持这种灵活性所需要的面向对象设计原则、模式和实践。

3．频繁交付可工作的软件，从几周到几个月，间隔越短越好。

尽早和频繁地交付可工作的软件。我们不赞成交付大量文档或计划。那些东西不能算是真正的交付。目标应是交付可以满足客户需求的软件。

4．项目期间，业务人员和开发人员必须每天一起工作。

为保证项目以敏捷的方式开发，客户、开发人员以及利益相关者必须进行有意义的、频繁的互动。和发射后任其自动导航的武器不同，软件项目必须不断进行引导（制导）。

5．围绕有激情的人来完成项目。提供他们需要的环境和支持，且用之不疑。

人是最重要的成功因素。其他所有因素（过程、环境、管理等）均属次要；如果对人产生了不利影响，就要改。

6．向开发团队和在开发团队内部传达信息最高效且最有用的方法是面对面交谈。

敏捷项目要求人和人之间面对面交谈。主要通信模式是人和人的互动。仅在需要时，才按照和软件一样的时间表来创建和增量更新书面文档。

7．能工作的软件是主要进度指标。

敏捷项目通过衡量当前满足客户需求的软件量来衡量进度。不是根据当前所处阶段，或者已写好的文档，或者已创建的基础架构代码量来衡量进度。完成了30%所需功能，进度就是30%。

8．敏捷过程提倡可持续开发。出资人、开发者和用户应该能始终保持稳定的开发速度。

和50米短跑不同，敏捷项目更像是一场马拉松。团队不是全速开跑，并在项目期间保持稳定的速度。相反，是以快速但平稳的步伐跑步前进。

跑得太快会导致过劳，走捷径，最终筋疲力尽。敏捷团队会自行调整步伐。他们不允许自己太累，不会透支体力。正确的节奏是在整个项目期间一直保持最高质量标准。

9．持续关注技术卓越和良好的设计可增强敏捷性。

高质量才能保证高速度。为了加快开发速度，需尽量保证软件的干净和健壮。因此，所有敏捷团队成员都必须致力于产出最高质量的代码。不能先乱写一通，宽慰自己说有时间再清理。一旦乱了，就要马上清理。

10．尽量简化，最大化未尽事宜的艺术（减少浪费）。

敏捷团队不会华而不实。相反，他们总是走与目标一致的最简单路径。不过分关注明天的问题，也不会今天就尝试彻底杜绝于未然。相反，是今天以最高的质量完成最简单的工作，且有信心明天出问题的时候能轻松改弦易辙。

11．最好的架构、需求和设计源自自我组织的团队。

敏捷团队是自组织团队。任务不是从外部分配给单独的团队成员，而是分配给整个团队。由团队来决定完成任务的最佳方式。

敏捷团队成员在项目的所有方面都协同工作。每个成员都可以向整个团队输入。并非由单独的成员独立负责架构、需求或测试。责任由团队共同承担，每个成员都有责任。

12．团队定期反省如何提升效率并相应调整其行为。

敏捷团队持续调整其组织、规则、约定和关系等。敏捷团队知道环境持续在变化，知道必须随环境而改变以保持敏捷性。