为了帮助人们更好地理解敏捷软件开发的真正含义，敏捷开发联盟的成员们将他们宣言中的主要观点精炼为12条原则。我们改动了其中一些（改动之处用楷体显示），并且新加入了三条。这15条规范敏捷开发原则如下。1）我们最重要的目标是持续地及早交付有价值的解决方案使利益相关者满意。我们必须时刻牢记解决方案开发的目标应该是交付一个实际可利用的解决方案，我们不止在开发软件，通常也需要对运行软件的硬件系统进行升级，对运用该软件的业务流程进行改动，对运维和支持流程进行改进（这是“DevOps”式开发中的一个环节），甚至要对使用该软件的组织进行结构上的调整。我们需要对自己的思维方式做出调整，不能奢望在项目一开始就试图规划所有的细节，否则只会增加项目风险和成本。我们应该花些时间，抓住主要矛盾，制定应对计划，允许项目自然发展，跟随项目进度，依据具体情况调整细枝末节的东西。2）欣然面对需求变化，即使是在解决方案交付生命周期的后期也一样。为了利益相关者能够受益更多，敏捷开发过程必须能够驾驭各种变化。无论你喜欢与否，在整个项目周期内，客户需求始终都在变化。传统的软件开发团队通常会采用变更管理流程来预防或减少不确定性。但是如果你仔细想想，就会发现这些实际上是防止改变流程，而不是管理改变的流程。规范敏捷开发人员会遵循一套敏捷变更管理方法，他们会按照优先顺序进行功能开发。随着利益相关者对其真实需求理解的不断深入，他们会改变自己的要求，进而影响团队任务执行的优先级顺序。为了照顾到解决方案开发过程中所涉及的所有各方利益，我们认识到我们必须与所有可能受影响的各方都建立起联系——最终用户、最终用户的上司、管理层、实际操作人员、支持人员、公司战略制定者、IT主管人员、财务、市场及其他人员。3）能够经常性地交付可行的解决方案，相隔几周至几月，但应尽量采用较短的周期。经常性地交付可利用的解决方案能让项目利益相关者有机会提供一些实时反馈，也能让项目进度情况变得更加清晰，同时项目利益相关者也能够为今后的开发指出更加有益的工作方向。4）利益相关者与开发人员必须保持经常性的紧密合作，并贯穿于整个项目周期。如果你无法与项目利益相关者或者至少其代言人保持经常性的沟通和合作，那么你的项目就面临严重问题了。规范敏捷开发团队通常会采用客户现场开发或利益相关者有效参与的行为方式，利用各种工具和技术让利益相关者能够充分地参与到解决方案的开发过程里。5）激励个人，围绕他们构建项目。为他们提供适宜的环境，满足他们的需求，并且充分信任他们完成任务的能力。有太多的机构认为他们可以雇用一批技能水平相对较低的开发人员，然后，为其提供一套CMMI/ISO，或者其他规范且透彻的流程描述，这样他们就能开发出合格的解决方案。但是似乎这种思路在实际工作中的效果并不理想。与此不同的是，规范敏捷开发团队知道形成团队的基础是一群愿意紧密合作和相互学习的个人。他们懂得谦逊和互相尊重，并且知道在整个开发过程中，人始终是决定成败的首要因素。我们应该给他们创造一个能够共同进步和成长的环境，这包括允许他们自行建立一个鼓励合作、采用最优工具的工作环境，并且给他们足够的自由去自行规划和优化自己的开发流程。6）不论在交付团队内外，传递信息最简便有效的方式是面对面的交谈。为了让团队获得成功，团队成员们必须有效沟通和合作。人们有很多方法可以进行沟通，而通常最有效的方法就是大家坐下来，在白纸或白板上写画，进行面对面的沟通。无穷无尽的电子邮件沟通，或者制作详尽的文档远没有这种面对面沟通的效率高。有些团队的队员可能分散在不同的地方，但这并不意味着一定要回到低效率的文档沟通形式，因为视频会议等先进的通信手段能够为面对面交谈提供条件。7）可量化的商业价值是衡量项目进度的首要指标。衡量一个解决方案开发项目成功与否的首要标准就是项目是否交付了能够为利益相关者带来实际价值的可利用解决方案。最终解决方案最大的价值就在于能够实际满足利益相关者多变的需求，而不是因复杂的文档工作或者频繁地召开会议而“赢得的价值”。请注意，我们用“可量化的商业价值”代替了“可工作的软件”。显然，可用的解决方案的确是衡量项目进度的重要标准，但是如果这个解决方案不能带来预期的商业价值，那么这个衡量标准就是错误的。8）敏捷过程倡导可持续的交付。项目发起人、开发人员及用户应该能够始终保持步调一致。就像你无法在整个马拉松过程中一直保持冲刺状态一样，你无法指望强迫人们一连加班几个月，同时还能开发出合格的解决方案。我们的经验是，你在一天中只能做5～6小时高质量的脑力工作，一天中剩下的时间人们需要用来做电子邮件处理、开会、聊天等事情，所以你能够进行“实质性工作”的能力其实是有上限的。的确，你或许能够一天内做12个小时的高质量工作，也或许你还能这样坚持几天，但是紧接着你就会觉得筋疲力尽，你唯一能做的就是每天做12个小时的低质量工作。9）不懈追求卓越的技术和优良的设计，由此增进敏捷能力。高质量的源代码和数据资源相对于质量较差的源代码和数据资源更容易理解、维护和升级。所以，敏捷开发人员清楚自己必须从一开始就追求卓越的产品质量，并且通过不断的代码重构来保持高质量，还要有一整套回归测试的方法来确认自己开发出的产品是可用的。规范敏捷开发人员还应该能够吸收和遵循整个机构的各种规范，例如，编程标准、数据指南、安全指南以及用户界面规范等。10）简化——尽最大可能减少不必要工作的艺术。敏捷开发人员专注于执行具有较高价值的任务，力求使项目利益相关者获得最高的投资回报率，因此他们要么避免，要么通过自动化工具来完成低价值的重复性劳动。从精益理论来看，简化是非常重要的，所以开发人员应该专注于那些最重要的任务，并且尽可能地按时完成，避免因为同时开始了其他重要性略低的工作而引起精力的分散。11）最优秀的架构、需求和设计出自自组织团队。这是整个敏捷开发思想中最基本的一条原则，也是我们迫切希望学术界能够给予更多、更彻底研究的一条原则。敏捷模型驱动开发（Agile Model Driven Development，AMDD）以及测试驱动设计（Test Driven Design，TDD）是敏捷社区通常用来确保能够生产出有效的架构、需求以及设计的主要方法。12）团队定期反思如何能够变得更加高效，并相应地调整和改变自己的行为。软件过程改进（Software Process Improvement，SPI）是持之以恒的工作，采用例如“回顾”之类的技术手段能够帮助你提高自己的软件开发能力。13）全新：利用和演进组织生态系统中的资产，并且为此与掌握这些资产的人紧密配合。规范敏捷开发团队知道自己不是工作在真空中。现有的系统、数据资源、组织框架、各种服务以及其他资源能够并且应该充分利用，并且这些资源自身也应该得到改进，因为这种改进也是他们最终交付的解决方案中的一部分。这些已经存在的资源和条件会限制所设想的最终解决方案的架构，还会很大程度上决定解决方案中所能采用的技术路线。但是，如果专注于开发新的功能，而不是一味地谋求改变当前的基础结构的话，自己的生产效率可能会更高。14）全新：将工作流程可视化会让开发过程更加平滑顺利，同时，应该将进行中的工作最少化。DAD团队会用状态图或进度表来监控进行中的工作内容，协调下一步的工作，并且更快地发现开发过程中的瓶颈和未得到充分调动的开发人员。这能够帮助他们获得稳定而持续的工作进度。15）全新：组织的生态系统必须不断演进，并对敏捷开发团队的工作进行反思和加强，但同时也应该保持足够的灵活性，让非敏捷团队或者使用混合开发方法的团队也能够获得足够的支持。无论你喜欢与否，当面临着IT开发任务时，每个组织其实都有多种途径选择。所以组织内整体的IT开发策略，包括团队自己的主要策略，都应该在尊重这一事实的前提下制定，应该能允许采用不同开发方法的团队（无论是否是敏捷团队）有效合作。过往有太多的失败例子，都是由于一个组织重复地用一套“放之四海皆准”的策略硬套在每个IT开发项目上。
让我们暂停一会儿，回想一下，在实际的IT开发项目中，你是不是遵照这些原则来进行工作的呢？如果不是，那么你觉得是否应该按照这些原则来组织开发工作呢？再把这些原则温习一遍，是不是像有些人说的那样，这些原则只不过是一些激进的、无法实现的空谈；或者抽象的毫无意义的伪命题；抑或它们只是一些基本常识？我们的看法是，如果你能认同由这些原则构成的一系列的基本常识，那么你就能成功完成DAD项目的开发。
