1.3 敏捷的原则
除了敏捷宣言之外，宣言的发起者还为敏捷方法撰写了12条指导准则：
（1）我们的最高目标是通过尽早和持续地交付有价值的软件来满足客户。
（2）即使在项目开发的后期，仍欢迎对需求提出变更。敏捷过程通过拥抱变化，帮助客户创造竞争优势。
（3）要不断交付可用的软件，周期从几周到几个月不等，且越短越好。
（4）在项目过程中，业务人员与开发人员要每天在一起工作。
（5）要善于激励项目人员，给他们所需要的环境和支持，并相信他们能够完成任务。
（6）团队内部和各个团队之间，最有效的沟通方法是面对面的沟通。
（7）可工作的软件是衡量进度的首要指标。
（8）敏捷过程提倡可持续的开发。项目方、开发人员和用户应该能够保持恒久、稳定的进展速度。
（9）对技术卓越和好的设计的持续关注有助于增强敏捷性。
（10）尽量做到简洁，尽最大可能减少不必要的工作。这是一门艺术。
（11）最佳的架构、需求和设计出自自组织团队。
（12）团队要定期回顾和反省如何能够做到更有效，并相应地调整团队的行为。
接下来，我们逐条解读这12条原则。
（1）我们的最高目标是通过尽早和持续地交付有价值的软件来满足客户。
第一点是要满足客户需求。如果我们只创造了完美的项目计划和文档来让公司的项目管理办公室（PMO）或者质量保证工程师（QA）满意，那么我们就是失败的。我们关注的焦点应该是客户，客户满意是衡量项目成功的关键要素。
第二点是尽早和持续交付。我们必须让我们的项目和项目团队尽早交付及频繁交付，鼓励和支持团队成员认同这个观点。早期发现错误会有足够的时间去修正，修正的成本也是最低的。
第三点是要交付有价值的软件，而不是未完成的工作产品、工作分解结构（WBS）术语、文档或者项目计划。应该具有目标驱动，对于软件项目而言，目标就是可工作的软件；对于其他类型的项目而言，目标是产出的产品和服务或者成果。
（2）即使在项目开发的后期，仍欢迎对需求提出变更。敏捷过程通过拥抱变化，帮助客户创造竞争优势。
如果是为了交付更好的成果和更高优先级的产品，那么变更对项目就是好事。对于传统项目管理而言，变更通常被认为是负面的，这意味着项目范围蔓延和偏离了项目的计划，需要引发变更的成本。所以，传统项目中的变更控制流程非常严格，只有最高优先级的变更可以被批准。在传统项目中，项目团队大量的时间和精力都用在记录与管理变更请求上。
对于软件项目或者其他类型的有高变更比率的项目而言，严格的变更管理流程会带来很多问题。相比而言，敏捷项目管理允许变更的发生，比如：极限编程（XP）提倡“拥抱变更”。敏捷使用轻便、高可视化的方法来处理待办事项的优先级排序的变更。
高效处理变更可以帮助项目团队把更多的时间投入在产品开发上，而不是处理变更上。敏捷方法就是利用易理解、高可视的方法来处理变更，使项目更加灵活。
（3）要不断交付可用的软件，周期从几周到几个月不等，且越短越好。
虽然我们倡导越早反馈越有价值，但是每个人都会要求完美，把工作产品长时间抓在手上反而会适得其反。最好的方式是尽早并且要经常得到对工作产品的反馈，以避免在错误的道路上越走越远。
本条准则重点强调了将工作产品投入测试环境从而获得反馈。频繁的测试和反馈对敏捷项目非常重要，团队需要根据已完成产品的反馈来确定如何继续。当然，反馈中也会存在变更的要求。
短时间的交付有利于团队和业务人员之间的互动。频繁的交付使得项目团队可以得到更多的商业机会和反馈。通常在演示会上，团队会得到业务优先级的变更要求，这都是很有价值的。
（4）在项目过程中，业务人员与开发人员要每天在一起工作。
频繁的演示是业务代表和开发人员在项目中共同工作的一个很好的切入点。在实际工作中，开发人员每日和业务代表采用面对面的沟通往往比较困难，但是值得去推动。面对面的交流可以更好地观察肢体语言，相比而言，文档、电子邮件或者打电话都不能有效地传达信息。
每天和业务代表共同工作，开发团队对业务的学习程度和速度远超过在需求收集会议中对业务的理解。因此，开发团队可以提出多种有价值的解决方案来代替直接的业务申请。业务代表也可以学习到哪些类型的解决方案成本高或者开发速度慢，哪些功能成本较低，进而通过反馈来调整需求。
如果业务代表和开发团队不能每日在一起工作，那么也应该尽量将两个工作小组安排在一起，每两天或者频繁地相互参与工作。有些团队使用“代理客户”（PO或者BA有时候会成为代理客户），将“代理客户”作为商业代表的替身。
（5）要善于激励项目人员，给他们所需要的环境和支持，并相信他们能够完成任务。
正如软件估算模型构造性成本模型（COCOMO）所显示的，好的团队成员和好的流程工具，这两个因素影响之间的比例关系是10∶1。这意味着员工对一个项目能否成功会起到更重要的作用，而不是工具和流程。
显示中，我们虽然不能确保每个团队都是被精挑细选出来的理想组合，就像中国跳水团队——梦之队，但是我们可以尝试去激发团队成员，让他们成为一个可以自我驱动的理想团队。自组织团队作为项目的一个重要因素，一旦员工开始自组织和计划工作，其工作会更加高效。敏捷方法主张将团队从微观管理和甘特图中的任务式管理中脱离出来，聚焦于工作技巧和团队协作从而提高生产率。
知识性项目也包含有特殊经验和技能的成员。如果开发团队可以更好地做出日常决定以及处理好计划的工作，那么项目团队中每个成员都会是专家，可以为项目的成功给予支持。
（6）团队内部和各个团队之间，最有效的沟通方法是面对面的沟通。
写文档可以很好地做记录，但是速度缓慢会造成高成本。面对面的沟通可以快速传达大量的信息，包括表情和肢体语言。梅拉宾法则曾经提出：“在信息沟通中，除了以语言的方式外，信息还以许多方式表达。说话的内容仅占7%，语音语调占38%，肢体语言占55%。”
在面对面的会谈中，问题可以立刻得到解决，而不是被暂时搁置或者过一段时间再被反馈。
但是，面对面会谈不能用于所有的沟通场合，只是提倡尽量遵循。随着团队规模的扩大，面对面的沟通很难实现，此时，我们就需要引入适当的文档要求。
（7）可工作的软件是衡量进度的首要指标。
首先，要将可工作的软件作为项目的关注目标，努力将创建文档等活动作为支持目标的手段而不是首要任务。如果产品不能工作，就不能被认为已完成了。强调“可工作”的软件是为了提醒团队功能特性只有被接受才算完成。项目是以结果为导向的，中间过程的可交付成果（比如文档和部分完成的工作）都不会得到外部的认可，被客户使用的产品才是项目的关注点。
（8）敏捷过程提倡可持续的开发。项目方、开发人员和用户应该能够保持恒久、稳定的进展速度。
一些快速应用开发技术并非已达到可持续开发的水平，很可能会由于工作时间过长导致工作人员过度疲劳，从而造成不必要的错误。针对周期长且紧张的开发阶段，敏捷方法认为应保持稳定的进展速度，其价值在于允许团队成员维持工作和生活的平衡。可持续的速度不仅对团队有好处，也会给整个组织带来益处。过长的工作时间会导致员工辞职，组织也会失去很多资源。重新雇用和整合新的成员会是一个缓慢且高成本的过程。
因此，保持恒定的开发速度可以创造一个更加和谐、高效的团队，较小的压力会提高工作效率、促进团队之间的协作。
（9）对技术卓越和好的设计的持续关注有助于增强敏捷性。
当我们希望开发团队可以努力工作并且交付大量有价值的产品时，我们也必须注意保持设计的清晰、高效和变更的灵活性。精益求精的技术和良好的设计会使产品或开发团队更早地理解与更新设计。
在软件世界中，一旦编程的基础紊乱，组织将丧失对变更响应的能力，失去其敏捷性。因此，我们需要给开发团队足够的时间进行重构，重构使编码更加稳定从而维持更长的时间。
（10）尽量做到简洁，尽最大可能减少不必要的工作。这是一门艺术。
在软件行业中，多达60%的功能很少被使用或者从来没有被使用过。
因为很多的功能并没有被使用，而且复杂的系统会隐藏很多的不确定性，所以敏捷方法专注于简洁，只完成必要的元素。
复杂的项目耗时长，暴露的风险相对较多，从而带来更多潜在的失败风险。因此，敏捷方法寻求“允许工作的最简洁产品”，并将其推荐为首选的解决方案。这种方法在减轻风险的同时也帮助团队建立了信心。
（11）最佳的架构、需求和设计出自自组织的团队。
人们喜欢自我组织，因为他们可以通过自己的方法最佳地完成工作、协调关系以及适应环境，同时他们也非常理解和支持这种方式。
为什么最佳架构、需求和设计来自项目团队，而不是来自项目团队外部的组织中的最佳架构师、商业分析师和设计师？因为外部的建议可能存在很多技术优点，但是如果团队对其难以实施也将是一个问题。
自组织团队有更高的所有权以及对架构、需求和设计的荣誉感，团队所创建的观点如果已经通过审查，就不需要再去验证。相反，如果一些观点来自团队外部，那么需要团队来验证是否可以成功使用，这又将是一个富有挑战的任务。
此外，自组织团队更加贴近项目的技术细节，因此最适合去识别实施中的问题。虽然可以尝试采纳外部的建议，但是敏捷依然倡导用团队的能力去打造最好的架构、需求和设计。团队成员是最了解项目的人，所以也最应该被授权参与项目。
（12）团队要定期回顾和反省如何能够做到更有效，并相应地调整团队的行为。
团队在项目进展中要不断地学习，对已经完成的任务进行反思和调整，从而为余下的项目工作做好准备。
敏捷项目通常会在每个迭代的最后用回顾会的方式反映在项目工作中的一些机会以及待改进的工作项上。一个项目会有多次的回顾，而不是每个项目仅有一次复盘，这样可以注意到很多可能被遗忘的细节，团队也会相应地去调整和适用行为。