几乎所有关于敏捷的入门课程，都会从敏捷宣言讲起。
这不仅是因为敏捷宣言是敏捷的起源，还因为它确立了敏捷运动的4条价值观：
个体及交互比流程与工具更有价值
可用的软件比冗长的文档更有价值
与客户的协作比合同谈判更有价值
对变化的响应比遵循计划更有价值
而更为重要的，是写在这四条价值观下面的一行小字：
也就是说，我们认可上述右边事项的价值，但我们更加重视左边的事项
2. 左右事项的辩证关系
敏捷宣言虽然更认可左边的事项，但也绝不否认右边事项的价值。
流程与工具是有价值的，文档是有价值的，合同谈判、遵循计划也同样是有价值的。
要是没注意到这点，就极容易陷入“敏捷不需要写文档”的误区。
敏捷的价值观不过是更加认可重视对变化的响应、客户的协助、可用的软件以及个体与交互罢了。
3.四条价值观剖析
捋清完左右事项的辩证关系后，四条价值观又有着怎样的具体含义呢？
3.1个体及交互比流程与工具更有价值
在我们传统的计划驱动的项目管理过程当中，充斥着大量的流程性东西。比如评审流程，项目立项的流程等等。但在敏捷看来，彼此互相的沟通其实更加有价值。
3.2可用的软件比冗长的文档更有价值
在一个项目开发的过程当中，我们更加重视及早地产出用户可以试用的软件，所以我们所用的各种各样的方法，不管是Scrum的方法，还是极限编程的方法，都是出于这样的目的。
3.3与客户的协作比合同谈判更有价值
在对接一些外国公司的项目时，和客户的协作时间比例往往比较大，软件交付最终呈现的效果也会比较好。
而在国内，许多客户普遍缺乏协作意识，在这种情况下，很多客户甚至会在项目结束之后才第一次看到软件，随即就开始觉得UI不好、软件性能也不好，就造成了大量的变和返工。
虽然国内这种协作意识淡薄的环境短时间内无法改变，但我们在项目过程当中应当思考通过什么样的手段和技术方法，来增强与客户的协助。
3.4对变化的响应比遵循计划更有价值
乌卡时代，具有敏捷思维的人欢迎变化、拥抱变化，面对变化可以及时做出响应。
做项目，最怕的是客户随时都有可能提出变更。事实上，变更无法避免，与其逃避苦恼，不如主动拥抱。
除了制定敏捷宣言，Kent一行人还发布了与敏捷相关的十二条原则。
前面提及的Scrum框架，以及各种各样的方法论其实都是对这十二原则的具体实践。
敏捷十二原则
原则一 价值优先
我们最重要的目标，是通过持续不断地及早交付有价值的软件使客户满意。
这条原则秉持着前文谈及的敏捷的价值观，呼吁我们努力思考，尽早地提供有价值的软件给客户，使客户满意。
原则二 拥抱变化
欣然面对需求变化，即使在开发后期也一样。为了客户的竞争优势，敏捷过程掌控变化。
当具备了一些敏捷的思维，掌握了敏捷的工具之后，一些突如其来的变更也算不了什么了！
原则三 短迭代交付
要不断的交付可用的软件，周期从几周到几个月不等，而且越短越好。
这条原则里同样包含及早交付的概念，但是更强调要把迭代周期缩短。
原则四 业务参与
项目过程中，业务人员与开发人员必须在一起工作。
正如前文所说，不管是客户，还是前台的销售或者售前的工程师，绝大部分情况下，在整个软件开发的过程当中，他们并没有参与进来。
这就需要我们想各种各样的办法，比如在敏捷实践过程当中，在一些场景里将这些业务人员，甚至是客户，带到团队里面来进行紧密合作，以保证交付可以达到客户的预期。
原则五 以人为本
激发个体的斗志，以他们为核心搭建项目。提供所需要的环境和支持，辅以信任，从而达成目标。
这一条原则在Scrum框架里面体现的非常明显，在Scrum里边有一个角色叫Scrum master。
Scrum master最主要的工作就是挡住外界环境对整个团队开发的影响，让整个团队能够专注在一个迭代过程当中，完成所要交付的任务。此外，要以整个项目团队为核心，意味着我们额外重视整个敏捷团队的自组织、自管理的能力。
一个开发人员通常都是被动完成任务，没有主动地投入到项目中为客户创造价值。所以敏捷的一个核心价值观就是想办法激发所有成员的积极主动性。
比如说产品经理提供相关的需求时，只需要讲清楚客户想要什么，具体怎么做应该是由团队内部自行来做决定，并且将其实现。
原则六 面对面沟通
不论团队内外，最有效的沟通方法就是面对面的交谈。
敏捷团队或Scrum团队鼓励大家是坐在一起。
不妨回想下我们手头所在进行的项目，项目组里面的成员坐得远不远？好的敏捷团队就是大家坐在一起，抬头就可以进行沟通，而不是要在企微上。
企微的沟通效率比面对面沟通差一点，而邮件的沟通效率又比企微差一些 。所以，在敏捷团队里，我们鼓励大家坐在一起，面对面进行交谈。
原则七 成果导向
可工作的软件是衡量进度的首要指标。
传统的瀑布模型要求我们一步一步的进行项目开发。首先需要分析，再做系统的设计、开发、再做测试，测试完之后才得到一个可工作的软件。
而敏捷的做法则甚至是想让每一个迭代都能够获得一个可工作的软件。
原则八 保持节奏
敏捷过程倡导可持续开发。发起人、开发人员和用户要能够长期维持稳定的开发步伐。
Scrum框架会去设定2-4周为一个迭代周期。在整个项目开发工程中，迭代周期一旦确定，之后就需要保持相对应的节奏，不能随意变动，否则步调不够稳定，节奏感不强，开发人员就不太清楚版本的发布规律。
原则九 追求卓越
坚持不懈地追求技术卓越和良好设计，敏捷能力由此增强。
在整个项目期间要去追求一些技术、设计上的比较好的设计方式。
原则十 简单务实
要做到简洁，即最大可能减少不必要的工作，这是一门艺术。
在敏捷当中有一种叫作精益的方法论，目的就是减少一些浪费。
项目开发中的浪费实际上就是工程师的时间。工程师如果老是把时间耗费在一些不必要的工作上，无法对客户产生任何价值，那在敏捷当中就要尽可能减少。
原则十一 团队自组织
最好的架构、需求和设计出自于自组织团队。
一个好的敏捷团队是自管理、自组织的，可以激发团队成员的积极性。
原则十二 持续改进
团队定期地反思如何能提高成效，并相应地协调和调整自身的行为。
Scrum框架里面有回顾会，即在团队中对刚刚结束的迭代进行一次回顾。做得好的就继续保持，做的不太好的，就寻找更优的解决方案。这种定期的反思会不断改进团队，提升项目交付的进度和质量。
以上就是所有从敏捷宣言背后延伸出来的十二条原则。
这些原则最重要的目的就是为了让我们的整个团队，不管是产品团队还是项目团队，能够尽早交付具有客户价值的软件。
并且敏捷当中的每一个工具和方法论其实都是对这些原则的具体实践。
现在我们一起跳出局部思维，俯瞰全局，全面深入地认识和学习敏捷。
三、 敏捷的“道、法、术、器”
1.敏捷技术全景图
道家文化的传承强调了“道”“法”“术”“器”四个字。
这是希望我们对事物的认识，不能只停留在表面，要深入内里，掌握规律，把握原则，了解方法和技术，掌握相关工具和环境。
敏捷思维，也是如此。
