最近做
敏捷推广，发现很多人虽然号称了解敏捷，但是实际的一操作，很多人明显的完全不懂什么是敏捷，所以最后只能从头做起。
今天就准备先讲一下敏捷宣言，也就是敏捷的价值。
首先我们看一下敏捷的原文：Agile Software Development。很多人都知道这是敏捷
软件开发，然后就自动理解为一种新的开发方法或者模型，区别于瀑布，迭代等。岂不知，这应该是敏捷的软件开发的简写。也就是说Agile是个形容词，是说让软件开发变的灵活具备快速应对变化的意思。很多人都没理解到这点，所以出发点就错了。
然后看看中文mediawiki上的解释：
敏捷软件开发，又称敏捷开发。是一种从1990年代开始逐渐引起广泛关注的一些新型软件开发方法，是一种应对快速变化的需求的一种软件开发能力。
它们的具体名称、理念、过程、术语都不尽相同，相对于“非敏捷”，更强调程序员团队与业务专家之间的紧密协作、面对面的沟通（认为比书面的文档更有效）、频繁交付新的软件版本、紧凑而自我组织型的团队、能够很好地适应需求变化的代码编写和团队组织方法，也更注重软件开发中人的作用。
好吧，不说了，基本上都是似是而非
看看英文版的：
Agile software development is a group of software development methods in which requirements and solutions evolve through collaboration between self-organizing, cross-functional teams.
敏捷软件开发是一个需求和解决方案不停演化的自组织，跨功能团队所拥有的一系列软件开发方法的集合。
It promotes adaptive planning, evolutionary development, early delivery, continuous improvement and encourages rapid and flexible response to change.
它促进了自适应式规划，演化式开发，预先式交付，持续式改进，并鼓励快速和灵活的响应变化。
明显的理解有差异的，这就是中国的通病，很多人只看别人翻译，或者到处转载那些明显有问题的听起来简单的解释，反而南辕北辙。
所以想了解敏捷软件开发当初的起源，就需要真正的去看一下敏捷宣言。
敏捷宣言从一个整体来说需要按如下顺序阅读读：
（要注意，敏捷宣言每一项是按顺序来的，也就是说有相互的依赖）
We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
我们一直在实践中探寻更好的软件开发方法，身体力行的同时也帮助他人。由此我们建立了如下价值观：
Individuals and interactions over Processes and tools
个体和互动 高于 流程和工具
Working software over Comprehensive documentation
Customer collaboration over Contract negotiation
客户合作 高于 合同谈判
Responding to change over Following a plan
响应变化 高于 遵循计划
That is, while there is value in the items on the right,
we value the items on the left more 也就是说，尽管右项有其价值，我们更重视左项的价值
1. 首先强调人和交流
2. 首先强调能够展现的软件
3. 首先强调团队合作
4. 首先强调按需变化，动态调整
5. 但是，并不是说我们追求左边4项就认为右边四项不重要了
6. 也就说流程和工具还是必须的，是为了更好的个人产出和高效沟通
7. 能够展现的软件是由那些必要的文档实例化的结果，文档对软件是强力的补充
8. 合同谈判的目的是为了树立统一目标，然后双方合作，而不是单方检验
9. 计划是开始的基础，我们在计划上调整响应变化，而不是没有计划。
10. 右边4项必须存在，才能让左边四项发挥更大的作用
11. 左边4项就是为了让右边4项敏捷起来
12. 敏捷的软件开发是基于有序的开发基础上，更具备灵活性。
让我们逐一看一下这四项
1. Individuals and interactions
in agile development, self-organization and motivation are important, as are interactions like co-location and pair programming.
个人的重要性体现在自我组织和主动精神上。
而限制工作区域和结对编程都能带来良好的交互。
所以真正敏捷的团队的人都知道，敏捷对每个人的要求很高。需要很强的主动精神，愿意为了达到团队价值全力贡献自己的价值。然后具有很强的自我组织和自我管理的能力。同时，能够和团队所有成员高效协作。
这就是为什么一个敏捷团队很少会换人，保持团队的稳定，才能保证团队的敏捷性。为了团队建设，大家面对面的坐在一个限制性的区域里从而能够随时沟通非常重要。而结对编程使得大家能够不停的互相促进，并形成同一种风格，使得产品的稳定性极大增强。
2. Working software
working software will be more useful and welcome than just presenting documents to clients in meetings.
能够直接演示的软件远远比文档更容易被客户所接受。
我们能够通过各种文档向客户演示我们要交付的内容，但是这些东西对客户的吸引力完全没有一个能够展示的软件更有力。通过实际的展示，讲解，操作和试用，能够得到极大的UE提升。
但是，Demo的时间毕竟有限，各种文档还是必须的，用户不可能在那么短的时间内有效的获取所有信息，所以Demo之后/之前，都可以进行一次文档交付，让用户获得更多的详细信息。
3. Customer collaboration
requirements cannot be fully collected at the beginning of the software development cycle, therefore continuous customer or stakeholder involvement is very important.
需求在软件开发周期的初始阶段是不可能充分获取的，所以和用户协作不断的探讨和更新需求是非常重要的。
合同讨论的其实是一个大的框架，我们首先要知道我们大体要完成内容，这样才能够集中精力去做。也就是说先有Scope，然后才能去制定交付。否则，纯粹开放型的需求等于没有需求。 很多产品人员认为需求可以不断的变更，其实是因为他们根本对客户的需求没有理解透彻，从而不断更新。
敏捷强调更新，强调过程中补充，但是不是说你连最起码的目标都不清楚。而且，所谓的补充信息不能是关键点，只能是迭代更新，而不是增量更新。敏捷更会控制需求变更，而不是纯粹的接受所有变更。 所以在很多敏捷框架中，都指明了能够进行需求变更的时间段，以及变更的风险，以及sprint失败的条件。
4. Responding to change
agile development is focused on quick responses to change and continuous development.
敏捷开发关注于快速的响应变化和持续开发。
敏捷开发响应变化的目的是响应用户的变化。 也就是，真正的变化是你在给客户进行Demo之后，然后由客户发起的需求变化。而不是在研发过程中，不停的由产品经理发起变化。为了避免这种情况，所以各个sprint周期才会普遍采用一周/二周的短时间段。就是为了能够用1/2周的损失避免1/2个月的时间损失。
所以很多人认为敏捷就是迭代的/增量的开发。其实跟这个一毛钱关系没有，很多敏捷做得好的公司，只要产品目标明确，瀑布开发也能够很敏捷。
所以敏捷不依赖于你采用哪种开发模式，它是你如何让你的产品开发敏捷起来而采用的所有方法的集合。现行的敏捷框架都是每个公司自己的成功结果。
