历史
2001年2月，17位敏捷方法论的代表聚集在美国犹他州的雪鸟滑雪场起草了敏捷“软件开发”宣言。这份敏捷宣言从当时流行的各种软件开发流程中提取出共同点。这些软件开放方法包括极限编程，SCRUM, DSDM, 自适应性软件开发，水晶以及特性驱动开发等。
敏捷宣言
Individuals and interactions over processes and tools 个体和互动 高于 流程和工具；
Working software over comprehensive documentation 工作的软件 高于 详尽的文档；
Customer collaboration over contract negotiation 客户合作 高于 合同谈判；
Responding to change over following a plan 响应变化 高于 遵循计划；
也就是说，尽管右项有价值，我们更重视左项的价值。
敏捷十二条原则(宣言背后)
1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software 我们最重要的目标：是通过持续不断地及早交付有价值的软件使客户满意
很多时候做项目，是为了让项目经理满意，而不是客户。把客户放在第一位，尽早的频繁交付产品，获得及时反馈的同时，还能防止团队滑向服务组织而不是客户的行为模式。
2. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. 欣然面对需求变化，即使在开发后期也一样。为了客户的竞争优势，敏捷过程掌握变化。
科技巨变时有发生，市场的变化也会给项目带来需求的变化，团队要应对需求的变化，拥抱变化并采取对策
3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. 经常的交付可工作的软件，相隔几星期或者一两个月，倾向于采取较短的周期
时间越短，工作必须越高效。短周期强迫团队专注于重点。
4. Business people and developers must work together daily throughout the project. 业务人员和开发人员必须相互合作，项目中每一天都不例外
开发人员认为业务人员总是问些浅薄的问题，业务分析的不够透彻；业务人员认为开发人员骄傲自大很古怪，关心代码比关心产品多。这两大派别都有各自的立场和关注点，但是如果他们一个月见一次面，那所有的判断都会成真。应该经常在一起，互相有产生同理心，早协作，多协作
5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. 激发个体的斗志，以他们为核心搭建项目，提供所需的环境和支援，辅以信任，从而达成目标。
可以有很多种方式来激励员工，金钱还有权利，但都并不长久。卡耐基说过，让一个人做好一件事情唯一的方法是他自己愿意做。
软件开发并不是工业化流程，开发团队成员也不是在装配流水线上执行任务，可随意替换的机器。团队成员不是human resource，也不是code monkey。
people first, 而非process first，让团队成员自己来决定工作流程，任何新成员的加入或者在不同的项目阶段，都可能影响工作流程。给团队成员所需的空间和自由，等待他们的成果
6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. 不论团队内外，传递信息效果最好效率也最高的方式是面对面的交流
比较典型的现代人工作方式是坐在格子间里，与同事交流是发邮件，还有聊天软件，即使对方坐在对面。敏捷团队则在更加开放的共享空间中，只要有可能会选择口头交流。
人们想当然的认为，90%的情况下其他人能够看出他们邮件中的语气是讽刺还是陈述，而实际上这个数字只有56%，电话交流能比这个数字更好些，但是还是少了些肢体语言的交流。
有些人认为分布式团队就不能敏捷了。但是注意这条原则只是说面对面是最好的方式，远程方式也可以实践敏捷团队协作，只是要格外留意如何建立沟通流。
视频，以及一周左右现身一次会是比较好的选择
7. Working software is the primary measure of progress. 可工作的软件是进度的首要衡量标准
看到结果才作数，所以团队要不断的拿出产品让项目经理和客户有信心。但是一定是可工作的软件，比如要demo登录页面，所谓可工作是用户可以输入用户名密码以及可以点击登录按钮登录。不能build不过，页面出现400错误
8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. 敏捷过程倡导可持续开发。责任人，开发人员和用户要能够共同维持其步调稳定延续。
有可能你经历过所谓的’关键时刻’，就是项目结束阶段大家都忙道很晚，生活就是睡觉，吃饭和工作。996.但是人在高强度工作模式下，生产力反而会下降。可能你有和我一样的感受，就是头一天晚上百思不得其解的问题，第二天一早就轻松迎刃而解，所以，预期强迫团队成员加班，不如花点心思想象如何解决真正要解决的问题
9. Continuous attention to technical excellence and good design enhances agility. 坚持不懈的追求技术卓越和良好设计，敏捷能力由此增强
有人认为敏捷开发就是快，其实不然。敏捷开发需要团队持续地关注设计，架构，测试和代码整洁度。刚开始不会快反而会慢。敏捷团队不会做过重的设计，而是强调在整个项目开发阶段都要持续不断的进行设计，投入学习测试驱动开发，设计模式和最新先进实践，这些学习都将会再项目生命周期上得到回报
10. Simplicity--the art of maximizing the amount of work not done--is essential. 以简洁为本，它是极力减少不必要工作量的艺术
Standish Group的一项报告中指出，一个典型的软件系统，有45%的功能未曾使用。一直在用的功能只占7%，还有13%属于常用功能。
敏捷项目先构建最重要的那部分功能，而那些多于的活着特别傻帽的功能，一旦被发现就会自然而然地从列表中掉落出去
11. The best architectures, requirements, and designs emerge from self-organizing teams. 最好的架构，需求和设计出自自组织团队
错误一：认为应该让架构师在处理架构，
如果架构师能一直和团队共处并且在项目过程中带领团队参与编码工作，那架构师更有水平打造精品无可厚非，但是事实并非如此。相比之下团队有一致的奋斗目标
错误二：软件项目就是做一个东西。
软件项目的目的绝对不是为了做一个东西，而是为了构建一个解决某问题的系统。在解决问题这件事情上，一个人就算再有天赋，也不如团队速度快。
12.At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. 团队定期地烦死如何能提高成效，并依此调整自身的举止表现。
定期的检验和适应，增强有效方法，并改进无效方法，这是任何敏捷流程都有的主要成分。
回顾时很强大的工具，可以用来完成这种调优，专注于观察学习刚刚发生的一切，现学现用，一边未来的路走的更顺利些。
参照文档
Agile Manifesto:http://agilemanifesto.org/
