敏捷宣言

转自：http://ghostboat.blogbus.com/logs/341042.html

敏捷软件开发 (ASD) 是一种面向人的协作方法，该方法专注于高价值的活动。敏捷应用程序开发人员一般以一种“渐进”（重复并增加）的方式工作，周期性地创建运作的软件。

 

敏捷宣言 (Agile Alliance 2001a) 定义了四个简单的价值声明，作为敏捷方法的基础：

1:个体和交互胜过过程和工具。人们组成团队来构建软件系统，为了实现这个目的，他们需要高效的合作 — 包括（但不限于）编程人员、测试人员、项目经理、建模人员和客户。工具和过程很重要，但它们没有高效的合作重要。

2:运作的软件胜过面面俱到的文档。当您问用户他们想要一份 50 页文档（说明您想要构建什么）还是软件本身时，您认为他们会挑哪一个？如果您能够快速地创建软件并经常可以为用户提供他们更喜欢的东西，难道这种工作方式不是更有意义吗？而且，我对用户能够通过复杂的技术框图 — 它们说明软件内部工作方式或提供软件用途的一个概括 — 来更容易得多地理解您开发的软件表示怀疑。文档有它的作用；如果写得适当，它对人们理解一个系统如何和为什么构建，以及如何利用这个系统进行工作是一个非常有价值的指导。不过，永远别忘了软件开发的主要目的是创建软件，而不是文档。否则，它将叫做文档开发，难道不是吗？

3:客户合作胜过合同谈判。与客户合作很难，但现实工作中您必须这么做。与他们签订合同很重要，但这并不能代替交流。成功的开发人员与客户密切合作，他们投入精力来了解客户需要什么，并且他们自始至终培训他们的客户。

4:响应变化胜过遵循计划。人们会因各种各样的原因改变他们最初的计划；随着工作的进展，他们对问题的理解和解决方案将发生变化。商务环境和底层的技术也会发生变化。有一个项目计划没什么错 —实际上，我怀疑会不会有一个项目没有计划。不过，一个项目计划必须是可塑的；也就是说，当情况变化或您的计划很快变得落后于事态发展时，必须能够灵活地修改它。如果变化是现实存在的，那么遵循一个反映实际情况的过程，而不是试图以一种通常效率低下和僵化的方式来勉强地控制变化难道不是很有意义吗？

经常指责敏捷应用程序开发人员没有在正式的软件过程上投入精力。相反：敏捷应用程序开发人员实际上的确使用开发工具并遵循软件过程，只是我们坚持使用能够增加价值的工具和专注于成功地交付软件的过程 — 这与专注于成功交付文档的完全僵化的过程相反。敏捷应用程序开发人员的确建模并编写文档，但我们专注于高价值的模型（其中许多模型在使用后就丢弃了）和简洁高效的文档。我们能够很好地管理变化；只是我们认为不必遵循一个麻烦而且僵化的过程来实现这个目的。

 

 

 

敏捷软件开发宣言 :
 个体和交互        胜过   过程和工具
 可以工作的软件    胜过   面面俱到的文档
 客户合作          胜过   合同谈判
 响应变化          胜过   遵循计划

敏捷宣言遵循的12个原则：
1.我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意。
2.即使到了开发的后期，也欢迎改变需求，敏捷过程利用变化来为客户创造竞争优势。
3.经常性地交付可以工作的软件，交付的间隔可以从几个星期到几个月，交付的时间间隔越短越好。
4.在整个项目开发期间，业务人员和开发人员必须天天都在一起工作。
5.围绕被激励起来的个体来构建项目。给他们提供所需的环境和支持，并且信任他们能够完成工作。
6.在团队内部，最具有效果并且富有效率的传递信息的方法，就是面对面的交流。
7.工作的软件是首要的进度度量标准。
8.敏捷过程提倡可持续的开发速度。责任人、开发者和用户应该能够保持一个长期的、恒定的开发速度。
9.不断地关注优秀的技能和好的设计会增强敏捷能力。
10.简单--使未完成的工作最大化的艺术---是根本的。
11.最好的构架、需求和设计出自于自组织的团队。
12.每隔一定时间，团队会在如何才能更有效地工作方面进行反省，然后相应地对自己的行为进行调整。

 

让我们互相交谈 让我们构建软件给你看 让我们彼此信任 让我们对正在发生的一切和我们所学到的东西做出响应