We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on
the right, we value the items on the left more.
中文翻译:
敏捷软件开发 (ASD) 是一种面向人的协作方法,该方法专注于高价值的活动。敏捷应用程序开发人员一般以一种“渐进”(重复并增加)的方式工作,周期性地创建运作的软件。
敏捷宣言 (Agile Alliance 2001a) 定义了四个简单的价值声明,作为敏捷方法的基础:
1:个体和交互胜过过程和工具。人们组成团队来构建软件系统,为了实现这个目的,他们需要高效的合作 — 包括(但不限于)编程人员、测试人员、项目经理、建模人员和客户。工具和过程很重要,但它们没有高效的合作重要。
2:运作的软件胜过面面俱到的文档。当您问用户他们想要一份 50 页文档(说明您想要构建什么)还是软件本身时,您认为他们会挑哪一个?如果您能够快速地创建软件并经常可以为用户提供他们更喜欢的东西,难道这种工作方式不是更有意义吗?而且,我对用户能够通过复杂的技术框图 — 它们说明软件内部工作方式或提供软件用途的一个概括 — 来更容易得多地理解您开发的软件表示怀疑。文档有它的作用;如果写得适当,它对人们理解一个系统如何和为什么构建,以及如何利用这个系统进行工作是一个非常有价值的指导。不过,永远别忘了软件开发的主要目的是创建软件,而不是文档。否则,它将叫做文档开发,难道不是吗?
3:客户合作胜过合同谈判。与客户合作很难,但现实工作中您必须这么做。与他们签订合同很重要,但这并不能代替交流。成功的开发人员与客户密切合作,他们投入精力来了解客户需要什么,并且他们自始至终培训他们的客户。
4:响应变化胜过遵循计划。人们会因各种各样的原因改变他们最初的计划;随着工作的进展,他们对问题的理解和解决方案将发生变化。商务环境和底层的技术也会发生变化。有一个项目计划没什么错 —实际上,我怀疑会不会有一个项目没有计划。不过,一个项目计划必须是可塑的;也就是说,当情况变化或您的计划很快变得落后于事态发展时,必须能够灵活地修改它。如果变化是现实存在的,那么遵循一个反映实际情况的过程,而不是试图以一种通常效率低下和僵化的方式来勉强地控制变化难道不是很有意义吗?
经常指责敏捷应用程序开发人员没有在正式的软件过程上投入精力。相反:敏捷应用程序开发人员实际上的确使用开发工具并遵循软件过程,只是我们坚持使用能够增加价值的工具和专注于成功地交付软件的过程 — 这与专注于成功交付文档的完全僵化的过程相反。敏捷应用程序开发人员的确建模并编写文档,但我们专注于高价值的模型(其中许多模型在使用后就丢弃了)和简洁高效的文档。我们能够很好地管理变化;只是我们认为不必遵循一个麻烦而且僵化的过程来实现这个目的。