2 敏捷原则
敏捷宣言的签订者很快对4则价值观达成共识，但是他们在宣言的12条附加原则上耗费的时间较长。
我们把这些原则分为四个类别：交付、沟通、执行和改进
客户不总是对的，要向人们提供真正需要的东西，而不是提供他们要求的东西
为了考虑变化，团队应当在项目中的很多时间点快速地改变自己的方向。“预先指定大计划”的瀑布流开发方式限制了团队响应这些变化的灵活性
2.1 交付项目
2.1.1 原则1：最优先要做的是尽早、持续地交付有价值的软件，让客户满意
这条原则包含三个独立概念
- 尽早发布软件
- 持续交付价值
- 让客户满意
既然客户只有在看到了可工作的软件之后才能给你真实有信息量的反馈，那么获得反馈的最佳方式就是尽早交付
敏捷团队选择出能交付最大价值的特性和需求，并据此计划项目的迭代，来持续交付有价值的软件
2.1.2 原则2：欣然面对需求变化，即使是在开发后期。敏捷过程利用变化位用户维持竞争优势
大多数软件工程师都是在技术自豪感的驱动下工作的：我们交付的产品我们能负责，而且能满足用户的需求。而项目中发生的变化则对这种自豪感产生了威胁，因为变化意味着质疑你采用的方法和设想
可以尝试从客户的角度看问题，客户无法预测未来，所以肯定会发生变化，理想的客户是不存在的
欣然面对变化意味着
- 不要认为有变化就会有人倒霉。
- 我们是一条绳子上的蚂蚱。团队中的每个成员，包括客户都要对需求和需求的变化负责。
- 我们不把变化拖到最后。
- 我们不要再把变化当成犯错。考虑到当时掌握的信息，我们已经做出了最好的决策，这个决策本身没有错误。
- 我们通过变化学到东西
2.1.3 原则3：频繁交付可工作的软件，从数周到数月，交付周期越短越好
传统的应对变化的方式：命令-控制模式
- 命令指的是项目经理给团队分配任务的方式，项目经理可以控制所有人的任务分配
- 控制指的是项目经理管理变化的方式。项目经理不断监控这些变化的发生并更新项目计划，来引入变化
敏捷中应对变化的方式：频繁发布可工作的软件
-
团队通过迭代将项目分割至定期的截止时间。在每一轮迭代中，团队都要发布可工作软件
-
可预测的进度安排(每日站立会议和迭代启动会议)和持续检查(回顾会议)可以帮助团队尽早掌握变化，并且大家一起制订解决这些变化的方式
2.2 沟通和合作
在传统观念中，人们把软件文档看作是一种必须的文档管理系统。如果这个系统具有可以跟踪性，可以理清所有信息之间的所有关系，那么需要的产品、测试，以及部署和维护方式便一目了然
对于敏捷团队来说：只需要写够项目开发用的文档就行。敏捷并不是完全放弃文档，但是如果一种文档不能给团队开发软件带来帮助，那么就没有写下来的必要。
2.2.1 原则4：在团队内外，面对面交谈是最有效、也是最高效的沟通方式
在软件团队中，面对面的沟通方式几乎总是优于文档沟通。敏捷沟通实践更关注个人与个人的沟通，而文档则用于记录那些以后需要回忆具体细节的复杂信息
团队沟通的终极目标是形成一种集体意识，在成员之间建立不必直说就能领悟的共同知识
2.2.2 原则5：在整个项目过程中，业务人员和开发人员必须每天都在一起工作
为了出色地完成软件开发，开发团队需要与业务人员进行大量面对面的讨论。业务人员了解需要什么软件，而开发团队可以通过讨论了解这些。
当业务人员和开发人员同在团队中开发软件的时候，最有效的方式就是让他们在项目完整周期内每天坐在一起工作。这样可以尽早处理变化。
而开发团队应该把最有价值的特性优先开发，这样的话，业务人员可以第一时间享用这些价值。
2.2.3 原则6：以受激励的个体为核心构建项目，为他们提供环境和支持，相信他们可以把工作做好
所有人的绩效应该根据团队交付的成果来评定，而不是根据每个人自己的角色来判定
2.3 项目实施
2.3.1 原则7：可工作的软件是衡量进度的首要标准
可工作的软件可以更好的给所有人汇报项目最新进展，因为这是团队用来交流当前已经完成工作的最好方式
2.3.2 原则8：敏捷过程倡导可持续开发。赞助商、开发人员和用户要能够共同、长期维持其步调
敏捷团队信奉的是维持可持续的开发节奏。他们会针对预留的时间制订切实可完成的计划。通过迭代式的开发，这种计划的可行性很高，因为预估接下来的两周、四周或六周的工作量远比预估未来一年半的工作量要简单的多。
2.3.3 原则9：坚持不懈地追求技术卓越和设计优越，以此增强敏捷的能力
设计良好并很好实现的软件可以最快交付，因为这种软件修改起来很容易。
敏捷开发人员会培养起很好的编程习惯，从而帮助自己编写设计良好的代码
2.4 持续改进
2.4.1 原则10：简单是尽最大可能减少不必要工作的艺术，是敏捷的根本
采用迭代式开发以及在项目初期将文档量控制到最小，可以避免交付不必要的软件
敏捷团队避免开发不必要的特性以及过于复杂的软件，保证给出的解决方案尽可能简单
2.4.2 原则11：最好的架构、需求和设计来自自组织的团队
在敏捷团队中，所有人都对架构负责
自组织团队并没有明确的需求和设计环节。自组织团队不依赖某个负责计划的人，会用合作的方式对项目进行规划。他们先把项目分解为多个用户故事，从能够给公司带来最大价值的用户故事着手，然后再考虑详细的需求、设计和架构。
2.4.3 原则12：团队定期反思如何提升效率，并依次调整
敏捷团队再每一轮迭代结束的时候和项目结束的时候会花时间总结过去，讨论总结经验，提高开发软件的能力