一、什么是敏捷宣言？
敏捷宣言（Manifesto for Agile Software Development），也叫做敏捷软件开发宣言，正式宣布了对四种核心价值和十二条原则，可以指导迭代的以人为中心的软件开发方法。敏捷软件开发关注保持简洁的代码，经常性测试以及及时地交付应用的功能模块。敏捷宣言的创建是为了替代文档驱动的繁重的软件开发流程，例如瀑布式方法。
二、敏捷宣言的诞生
2000年9月，来自芝加哥Object Mentor公司的Bob Martin用一封电子邮件吹响了下次会议的集合哨。“我想召集一个为期2天的小型会议，时间是2001年1月或2月，地点在芝加哥，目的是让所有轻量级方法论的领袖们汇聚一堂。您们都被邀请了。如果您们觉得还有谁该来，请告诉我。”
2001年2月11日到13日，17位软件开发领域的领军人物聚集在美国犹他州的滑雪胜地雪鸟（Snowbird）雪场。经过两天的讨论，“敏捷”（Agile）这个词为全体聚会者所接受，用以概括一套全新的软件开发价值观。这套价值观，通过一份简明扼要的《敏捷宣言》，传递给世界，宣告了敏捷开发运动的开始。参会者们包括来自于极限编程、Scrum、DSDM、自适应软件开发、水晶系列、特征驱动开发、实效编程的代表们，还包括了希望找到文档驱动、重型软件开发过程的替代品的一些推动者。
三、具体内容
（一）官方网站
（二）四大核心价值[1]
个体和互动 高于 流程和工具
工作的软件 高于 详尽的文档
客户合作 高于 合同谈判
响应变化 高于 遵循计划
也就是说，尽管右项有其价值，
我们更重视左项的价值。
（三）十二原则[1]
我们遵循以下原则：
1、我们最重要的目标，是通过持续不断地及早交付有价值的软件使客户满意。
2、欣然面对需求变化，即使在开发后期也一样。为了客户的竞争优势，敏捷过程掌控变化。
3、经常地交付可工作的软件，相隔几星期或一两个月，倾向于采取较短的周期。
4、业务人员和开发人员必须相互合作，项目中的每一天都不例外。
5、激发个体的斗志，以他们为核心搭建项目。提供所需的环境和支援，辅以信任，从而达成目标。
6、不论团队内外，传递信息效果最好效率也最高的方式是面对面的交谈。
7、可工作的软件是进度的首要度量标准。
8、敏捷过程倡导可持续开发。责任人、开发人员和用户要能够共同维持其步调稳定延续。
9、坚持不懈地追求技术卓越和良好设计，敏捷能力由此增强。
10、以简洁为本，它是极力减少不必要工作量的艺术。
11、最好的架构、需求和设计出自自组织团队。
12、团队定期地反思如何能提高成效，并依此调整自身的举止表现。
四、解读[4]
（一）四大核心价值的解读
1、个体与互动高于流程和工具
这意味着虽然流程和工具重要（尤其是大型组织），但是它们无法替换有能力的个体和高效的互动。个体的技能和他们之间的互动才是最关键的。
- 当我们开发产品、解决问题或改进工作方式时，我们要寻找改进互动和提高能力的方法
- 在项目期间，产品管理和开发团队必须在一起工作
- 在项目期间，架构师、设计师和测试人员必须每天在一起工作
- 面对面沟通是极其重要的，它不能被其它形式完全替换
2、工作的软件高于详尽的文档
这意味着已集成、已测试、潜在准备发布的产品才是关键度量，它能够有效地跟踪项目进度和对发布做出决策。
- 要以小步增量的方式构建产品：做一些分析、设计，然后开始编码和测试以验证设计
- 设计需要做，比如敏捷建模工作坊(设计与文档不一样)。如果需要传递信息给客户、维护工作的人员，简易文档还是必要的
- 好架构是持续开发产品的关键，架构是设计出来的，建立一个可实现的简单架构是持续化开发的第一步。随着时间的推移，架构会演进，所以持续追求卓越技术和好设计能够增强产品敏捷性。
3、客户合作高于合同谈判
这意味着我们应该超越谈判并尝试提升与客户的合作。我们还应该建立以合作为基础的关系，而不是靠公司内的正式接口。
- 在实践中，意味着产品经理、市场或销售人员在产品开发期间要经常从客户那里请求反馈并排列优先级。
- 在与我们自己的业务方合作中，我们应该寻找开发期间增进和改善合作的方法。
- 产品管理和开发应该密切合作，而不是通过契约或手续。
4、响应变化高于遵循计划
这意味着欢迎需求变化，哪怕是开发后期。
- 首先，预先知道所有需求是不可能的。每个项目都会有浮现和继承的需求。
- 如果我们对客户需求变更做的好，我们就会增强客户的竞争优势还有我们自己。
- 为了鼓励响应变化并使其更容易操作，需要建立流程和工作方式。承认计划的不确定性
- 计划是必要的，但计划必须适应变化：我们需要持续调整计划。前期花很长时间制定详尽的计划的结果会导致大量的返工。同时，我们需要有足够的计划水平来评估业务需求和对其长期影响的判断。这是一种平衡的艺术。
（二）十二原则的解读
1、我们最重要的目标，是通过持续不断地及早交付有价值的软件使客户满意。
客户满意和有价值的软件是关键词。要确保我们开发的软件产品能够给客户带来真正的价值，这完全取决于在开发期间与客户的密切合作。产品管理是确保客户需求在开发期间被正确理解的关键。我们应该集中精力在对客户最有价值的工作上。
尽早并持续交付的能力是满足客户的关键。及时交付部分功能比最后交付全量功能更好，至少我们应该给我们客户一个选择。
2、欣然面对需求变化，即使在开发后期也一样。为了客户的竞争优势，敏捷过程掌控变化。
我们的目标是为了开发能够帮助客户提升价值的产品，要支持任何变化。变化不是一种否定，它体现了团队和产品负责人在敏捷开发过程中的一种工作方式。
3、经常地交付可工作的软件，相隔几星期或一两个月，倾向于采取较短的周期。
开发周期和发布周期完全不同。尽管有发布周期，但我们的目标是短开发周期。发布周期的长度依赖业务决策，并且和客户的期望紧密关联。短开发周期的频繁交付缩短了反馈周期并增强了学习。频繁交付还能让团队及早暴露弱点并及时移除障碍，增加了敏捷性和灵活性。
4、业务人员和开发人员必须相互合作，项目中的每一天都不例外。
只要在业务和研发之间建立起桥梁，我们就能从中受益。业务人员和产品管理知道市场状况、客户需求和客户的价值。开发团队知道产品和技术可行性。如何将这两方面结合？我们需要作出睿智的决策
5、激发个体的斗志，以他们为核心搭建项目。提供所需的环境和支援，辅以信任，从而达成目标。
知识类工作(比如软件开发)是由具有技能和激情的人来做的。为了激发个体的斗志和创造力，自由是最重要因素。要让角色去适应人而不是让人去适应角色。
6、不论团队内外，传递信息效果最好效率也最高的方式是面对面的交谈。
面对面交谈在分布式开发中尤为重要。当我们看到人们彼此交谈时，信息更多以听说的形式被传递。文档(虽然它很重要)不能代替交谈，将每件事都写下来简直是不可能的。我们不应该只依靠写文档来传递重要信息。
7、可工作的软件是进度的首要度量标准。
跟踪有多少功能已经实现，集成，测试是一种更可靠的进度度量。
8、敏捷过程倡导可持续开发。责任人、开发人员和用户要能够共同维持其步调稳定延续。
目标是为了消除高负荷工作并保持可持续的速度工作(例如，不加班工作)。质量问题通常牺牲长期收益，人们越是疲劳创造力就越低。因此可持续开发吧！
9、坚持不懈地追求技术卓越和良好设计，敏捷能力由此增强。
任何技术负债(代码缺陷、架构缺陷)都会使开发减慢。我们不应该让技术负债积压，所以要持续地做重构，更改发现的缺陷，持续关注实现架构的质量。
10、以简洁为本，它是极力减少不必要工作量的艺术。
这种简单原则既适用于产品的功能特性也适用于流程。多余的功能不要增加。所有流程步骤应该时刻面临挑战(例如，这步真的需要吗? 谁会读这个文档？…)。
11、最好的架构、需求和设计出自自组织团队。
架构、设计和需求会随着团队一起工作慢慢浮现，并且团队会从中学到很多。一些前置需求、架构和设计工作是需要的，但是不能把它们定义在纸面上传递。架构师和系统工程师是自管理研发团队的一部分，不要成为“孤岛”。
12、团队定期地反思如何能提高成效，并依此调整自身的举止表现。
花时间反思和从经验中学习能够促进持续化开发。因此“检查与调整”是敏捷核心实践之一。
五、背景和意义
Kent Beck分享了他早年的一次亲身工作经历。当时他估算的开发工作量是2个人做6个星期。结果在项目开始的时候，经理临时换了另一个人和他一起工作，最后他们花了12个星期才完成项目。他的感觉很糟，因为在后面6个星期中间，经理一直喋喋不休，嫌他太慢。Kent有点沮丧，觉得自己作为一个程序员实在是太失败。到最后，他终于意识到最初2个人做6个星期的估计其实是相当准确的。这不是他的失败，是管理者的失败（指临时换人这件事），实际上是那些持续祸害着我们这个行业的，所谓标准化、流程化的“僵化”头脑的失败。
同样的事情每天都在重复发生。市场人员、经理、外部客户、内部客户，当然，也包括开发人员，谁都不想难为自己，去做出那些艰难的、需要折衷的决定。于是他们利用组织的权责划分将难题转嫁给他人，甚至提出荒谬的要求。这不仅仅是软件开发的问题，而是无处不在。
先写到这吧。
参考
[1] 敏捷软件开发宣言-简体中文 2016/09/15 http://agilemanifesto.org/iso/zhchs/manifesto.html
[2] 51CT0博客-历史：敏捷宣言诞生记 2016/09/15 http://davidzhang33.blog.51cto.com/3095817/1103860/
[3] TechTarget中国-敏捷宣言：四大核心价值和十二原则 2016/09/15 http://www.searchcio.com.cn/showcontent_54322.htm
[4] 推酷-敏捷宣言及原则解读 2016/09/15 http://www.tuicool.com/articles/ziqIN3Y
[5] CSDN博客-敏捷宣言思想认识误区 2016/09/15 http://blog.csdn.net/youcharming/article/details/41865893