敏捷宣言

敏捷软件开发宣言

           人和交互     重于     过程和工具

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

           客户合作     重于     合同谈判

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

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

原则

1.我们最优先要做的是通过尽早地，持续地交付有价值的软件来使客户满意。

项目开始的几周内交付一个基本功能。然后，每几周交付一个功能渐增的系统。客户选择将功能加入产品或者继续改进功能。

2.我们欢迎需求的变化，即使到开发后期，敏捷过程能够驾驭变化，为客户创造竞争优势。

需要保持软件结构的灵活性，需要面向对象设计的原则、模式和时间来维持灵活性。

3.经常交付可以工作的软件，从几个星期到几个月，时间间隔越短越好。

不赞成交付大量的文档或者计划，关注的目标是交付满足客户需要的软件。

4.在整个项目开发期间，业务人员和开发人员必须朝夕工作在一起。

客户、开发人员以及利益相关者之间必须要进行有意义的、频繁的交互。

5.依靠斗志高昂的人构建项目，给他们提供所以须的环境和支持，并且信任他们能够完成工作。

人是项目取得成功的最重要的的因素，其他的因素（过程、环境、管理等）都是次要的，当它们对人有负面影响是，就要对它们进行改变。

6.在团队内部，最有效率也最有效果的信息传达方式，就是面对面的交谈。

首要的沟通方式就是人与人之间的交互（包括语音，视频，分享桌面）。

7.可以工作的软件是进度主要的度量指标。

度量当前满足客户需求的软件功能来度量开发进度。仅有30%的必须功能可以工作时，才可以确定进度完成30%。不能用代码量和文档量进行衡量。

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

敏捷团队会测量自己的速度，不允许自己过度疲惫（产品上线前一周除外）。

9.对卓越技术和良好设计的不断追求有助于提高敏捷性。

致力于只编写他们能够编写的最高质量的代码。今天制造了混乱，就在今天把混乱清理干净。

10.简单——尽量减少工作量的艺术是至关重要的。

不要构建华尔不实的系统，采用和目标一致的最简单的方法。不看重明天会出现问题的预测，也不会再今天对问题进行防御。

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

敏捷团队是自我组织的团队，整个团队共同承担职责，不会出现A负责系统架构，B负责需求，C负责测试的情况。

12.每隔一定时间，团队都要总结如何更有效率、然后相应地调整自己的行为。

不断的对团队的组织方式、规则、决定和关系等进行调整。