敏捷软件开发宣言：
1。个体和交互 胜过 过程和工具
团队的构建要比环境的构建重要的多。许多团队和管理者就犯了先构建环境，然后期望
团队自动凝聚在一起的错误。相反，应该首先致力于构建团队，然后再让团队基于需要来配置环境
2。可以工作的软件 胜过 面面俱到的文档
3。 客户合作 胜过 合同谈判
那些为开发团队和客户的协同工作方式提供指导的，合同才是最好的合同。
4。响应变化 胜过 遵循计划
计划不能考虑得过远。首先，商务环境很可能会变化，这会引起需求的变动。其次，一旦客户
看到系统开始运作，他们很可能会改变需求。最后，即使我们熟悉需求，并且确信它们不会改变，
我们仍然不能很好地估算出开发它们需要的时间。
较好的做计划的策略是：为下两周做详细的计划，为下三个月作粗略的计划，再以后就作极为
粗糙的计划。我们应该清楚地知道下两周要完成的任务，粗略的了解一下以后三个月要实现的需求。
至于系统一年后将要做什么，有一个模糊的想法就行了。
敏捷开发原则：
敏捷开发12 条原则，它们是敏捷实践区别于重型过程的特征所在。
1．我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意。
MIT Sloan 管理评论杂志刊登过一篇论文，分析了对于公司构建高质量产品方面有帮助的软件
开发实践①。该论文发现了很多对于最终系统质量有重要影响的实践。其中一个实践表明，尽早地
交付具有部分功能的系统和系统质量之间具有很强的相关性。该论文指出，初期交付的系统中所包
含的功能越少，最终交付的系统的质量就越高。
该论文的另一项发现是，以逐渐增加功能的方式经常性地交付系统和最终质量之间有非常强的
相关性。交付得越频繁，最终产品的质量就越高。
敏捷实践会尽早地、经常地进行交付。我们努力在项目刚开始的几周内就交付一个具有基本功
能的系统。然后，我们努力坚持每两周就交付一个功能渐增的系统。
如果客户认为目前的功能已经足够了，客户可以选择把这些系统加入到产品中。
或者，他们可以简单地选择再检查一遍已有的功能，并指出他们想要做的改变。
2．即使到了开发的后期，也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势。
这是一个关于态度的声明。敏捷过程的参与者不惧怕变化。他们认为改变需求是好的事情，因
为那些改变意味着团队已经学到了很多如何满足市场需要的知识。
敏捷团队会非常努力地保持软件结构的灵活性，这样当需求变化时，对于系统造成的影响是最
小的。 在本书的后面部分，我们会学习一些面向对象设计的原则和模式，这些内容会帮助我们维持
这种灵活性。
3．经常性地交付可以工作的软件，交付的间隔可以从几个星期到几个月，交付的时间间隔越短越
好。
我们交付可以工作的软件（working software ），并且尽早地（项目刚开始很少的几周后）、经常
性地（此后每隔很少的几周）交付它。我们不赞成交付大量的文档或者计划。我们认为那些不是真
正要交付的东西。我们关注的目标是交付满足客户需要的软件。
4．在整个项目开发期间，商务人员和开发人员必须天天都工作在一起。
为了能够以敏捷的方式进行项目的开发，客户、开发人员以及涉众之间就必须要进行有意义的、
频繁的交互。软件项目不像发射出去就能够自动导航的武器，必须要对软件项目进行持续不断地引
导。
5．围绕被激励起来的个体来构建项目。给他们提供所需的环境和支持，并且信任他们能够完成工
作。
在敏捷项目中，人被认为是项目取得成功的最重要的因素。所有其他的因素——过程、环境、
管理等等——都被认为是次要的，并且当它们对于人有负面的影响时，就要对它们进行改变。
例如，如果办公环境对团队的工作造成阻碍，就必须对办公环境进行改变。如果某些过程步骤
对团队的工作造成阻碍，就必须对那些过程步骤进行改变。
6．在团队内部，最具有效果并且富有效率的传递信息的方法，就是面对面的交谈。
在敏捷项目中，人们之间相互进行交谈。首要的沟通方式就是交谈。也许会编写文档，但是不
会企图在文档中包含所有的项目信息。敏捷团队不需要书面的规范、书面的计划或者书面的设计。
团队成员可以去编写文档，如果对于这些文档的需求是迫切并且意义重大的，但是文档不是默认的
沟通方式。默认的沟通方式是交谈。
7．工作的软件是首要的进度度量标准。
敏捷项目通过度量当前软件满足客户需求的数量来度量开发进度。它们不是根据所处的开发阶
段、已经编写的文档的多少或者已经创建的基础设施（ infrastructure）代码的数量来度量开发进度的。
只有当30%的必须功能可以工作时，才可以确定进度完成了30%。
8．敏捷过程提倡可持续的开发速度。责任人（sponsors）、开发者和用户应该能够保持一个长期的、
恒定的开发速度。
敏捷项目不是50 米短跑；而是马拉松长跑。团队不是以全速启动并试图在项目开发期间维持那
个速度；相反，他们以快速但是可持续的速度行进。
跑得过快会导致团队精力耗尽、出现短期行为以致崩溃。敏捷团队会测量他们自己的速度。他
们不允许自己过于疲惫。他们不会借用明天的精力来在今天多完成一点工作。他们工作在一个可以
使在整个项目开发期间保持最高质量标准的速度上。
9．不断地关注优秀的技能和好的设计会增强敏捷能力。
高的产品质量是获取高的开发速度的关键。保持软件尽可能的清洁、健壮是快速开发软件的途
径。因而，所有的敏捷团队成员都致力于只编写他们能够编写的最高质量的代码。他们不会制造混
乱然后告诉自己等有更多的时间时再来清理它们。如果他们在今天制造了混乱，他们会在今天把混
乱清理干净。
10．简单——使未完成的工作最大化的艺术——是根本的。
敏捷团队不会试图去构建那些华而不实的系统，他们总是更愿意采用和目标一致的最简单的方
法。他们并不看重对于明天会出现的问题的预测，也不会在今天就对那些问题进行防卫。相反，他
们在今天以最高的质量完成最简单的工作，深信如果在明天发生了问题，也会很容易进行处理。
11．最好的构架、需求和设计出自于自组织的团队。
敏捷团队是自组织的团队。任务不是从外部分配给单个团队成员，而是分配给整个团队，然后
再由团队来确定完成任务的最好方法。
敏捷团队的成员共同来解决项目中所有方面的问题。每一个成员都具有项目中所有方面的参与
权力。不存在单一的团队成员对系统构架、需求或者测试负责的情况。整个团队共同承担那些职责，
每一个团队成员都能够影响它们。
12．每隔一定时间，团队会在如何才能更有效地工作方面进行反省，然后相应地对自己的行为进行
调整。
敏捷团队会不断地对团队的组织方式、规则、规范、关系等进行调整。敏捷团队知道团队所处
的环境在不断的变化，并且知道为了保持团队的敏捷性，就必须要随环境一起变化。