1.敏捷软件开发宣言
这宣言（Agile Alliance 2001a）由四个简单的价值观声明组成，这里需要理解的重点是虽然要重视右边的内容，但更应该重视左边（黑体字）的内容。理解这个宣言的比较好的方法是：明白它定义的是偏好、而不是可以彼此替代的选择，即鼓励集中精力在某些方面但并不是完全排除其他方面。敏捷联盟的价值观如下：
个人和交互高于过程和工具。软件提供是由人组成的团队开发的，要进行开发他们必须与程序员、测试员、项目经理、建模人员以及客户有效地一起工作。你认为谁能开发出一个更好的系统：在一个房间里一起工作的有他们自己工具的五个软件开发人员，还有五个有着定义明确的过程、能拿到最先进的工具和工作在钱能买到的最好的办公室但技能很差的“翻烧饼的”？如果项目相当复杂，我的钱将主要花在软件开发人员身上，你不是也一样吗？问题的关键是：人员和他们怎样一起工作是需要考虑最重要的因素，因为如果这个问题解决不好，最好的工具和过程都将没有任何用处。别误解我的意思，过程和工具是重要的，只是它们不如有效地一起工作那样重要。别忘了那句老话：有工具的傻子还是一个傻子，这对管理层可能是难以接受的，因为他们经常情愿相信人和时间或者人和月是可以互换的。
工作软件高于详尽的文档。如果问用户他们是想要一份50页的文档来描述想要建造的系统还是实际的软件本身，你觉得用户会选择哪一个？我猜100个人里有99个会选择软件。如果事情真是这样，那么快速而经常地制造出软件，交付给用户他们喜欢的产品，是不是更有意义？而且，我觉得相对于描述软件内部工作的复杂技术图或者对软件用法的抽象描述，用户会更容易理解所制造的软件，难道不是如此吗？文档有它适用的场合，如果写得好，它对人们理解系统是怎样构造的、为什么这样构造以及怎么样使用系统都是很有价值的指导。但是，永远不要忘记软件开发的主要目标是创造软件，而不是文档；否则应该称之为文档开发，不是吗？
与客户协作高于合同（契约）谈判。只有客户能告诉你他们想要什么。是的，他们可能没有技能去精确地定义系统：是的，他们可能做不到第一次就能完全表达他们的要求；是的，他们可能会改变主意。与客户一起工作是艰苦的，但这是这个工作的实际情况。与客户有个合同（契约）是重要的，理解每个人的权利与义务可以构成这个合同的需要，并在这个过程中引导客户。
对变更及时作出反应高于遵循计划。人们出于很多不同的原因会改变事情的优先顺序。随着系统工作的进展，项目关系人对问题领域的和正在构建的系统的理解会发生变化；业务环境在变化；技术随着时间也在变化，虽然变化不总是朝着更好的方向。变化是软件开发的现实，一个软件过程必须反映的现实。有项目计划没有任何过错，实际上对任何没有计划的项目我都会感到担心。但是，项目计划必须具有可塑性，在形式改变时计划必须有变动的余地，否则计划会很快变得与实际情况不相关。
关于这些价值观声明有趣的一点是：几乎每个人都会立刻赞同，但在实践中却很少会坚持。高级管理层总是宣称雇员是组织机构中最重要的方面，但却坚持遵循符合ISO-9000中规定的过程，把他们看作是可替换的资产。更糟的是，管理层经常拒绝向项目组提供足够的资源，而这些资源是他们坚持要求项目组去遵守的过程所要求的。每个人都会欣然同意创造软件是软件开发的根本目标，但却坚持要花费数月时间编写描述这个软件是什么和将怎样建造的文档，而不是卷起袖子开始建造它，你说对了--人们嘴上说的和实际做的往往是两回事，这种情况该停止了，敏捷建模人员做他们所说的，说他们所做的。
2.敏捷软件开发的原则
为了帮助人们更好地理解什么是敏捷软件开发，敏捷联盟的成员把他们宣言中表达的基本原则精炼为12条原则（Agile Alliance 2011b），敏捷软件开发方法（例如敏捷建模（AM））必须遵循这些原则。这些原则如下：
1）最需要优先考虑的是通过尽早地和不断地提交有价值的软件使客户满意。
2）欢迎不断变化的需求，即使是在卡发的后期。敏捷过程利用变化为客户产生竞争优势。
3）经常性地交付可用的软件，从几个星期到几个月，尽可能做到短的时间间隔。
4）在整个项目过程中业务人员和开发人员必须每天一起工作。
5）围绕受到激励的个人建立项目，给他们所需要的环境和支持，相信他们能完成工作。
6）效率最高的和最有效的传递信息给项目组和在项目组内部传递信息的方法是面对面的交谈。
7）工作软件是状态进展的首要度量。
8）敏捷过程鼓励可持续的开发、主办者、开发人员以及用户应该能够永远保持固定的各自的速度。
9）始终关注技术上的卓越之处和好的设计，这会增强敏捷性。
10）简单--把不做的工作量最大化的艺术--是最关键的。
11）最好的架构、需求和设计出自自我组织的团队。
12）每隔一段时间，团队应该反省怎样才能更有下，然后据此调整自己的行为。
停下来想一想这些原则，你的软件项目实际上是这样运作的吗？这是你认为的软件项目应有的运作方式吗？再读一遍这些原则，它们是不是像有的人曾声称的那样，是一些偏激的和不可能实现的目标？它们是不是一些没有意义的“老生常谈”的声明？它们是不是只是一些常识？我相信，这些原则构成了一个常识基础，可以把成功的软件开发建立在这个基础之上。而且，我还认为这些原则定义了对一个有效的软件方法的高层需求，这些需求被用来指定敏捷建模的价值观、原则和时间。
作者：银月莲
出处：http://www.cnblogs.com/moonsilvering
本文版权归作者和博客园共有，欢迎转载，但未经作者同意必须保留此段声明，且在文章页面明显位置给出原文连接，包括文章，代码，图片等本站内所有资源，否则保留追究法律责任的权利。
