敏捷开发（Agile）是什么？
敏捷开发是一套方法和方法论的集合，他帮助你的团队更加高效的思考，工作和做出更好的决定。这套方法和方法论涉及所有的传统软件工程领域，包含项目管理，软件设计和架构，以及进程优化。
敏捷开发同时也是一种思维模式，这种思维模式专注于在团队中进行公开的计划，设计和整体提升团队。使用这种思维模式的敏捷团队，每个成员都能共享同等的信息，并能参与敏捷实践。
传统的开发模式
瀑布流（waterfall progress）:
A team following a waterfall process tries to write down as early as possible a complete description ofthe software that will be built. Once all of the users, managers, and executives agree on exactly what the software must do (the requirements), they can hand a document that contains those requirements (the specification) to a development team, and that team will go off and build exactly what’s written. Then a testing team comes in after‐ward, and verifies that the software matches the document. Many agile practitioners refer to this as “big requirements up front” (sometimes abbreviated BRUF).
一个遵循传统瀑布流开发模式的团队，会在项目一开始就开发做出关于产品的完整需求描述。一旦团队成员都认同了这些需求后，他们会开始着手编写一份详尽的关于产品需求的文档并交付给开发团队，开发团队就开始按照这个文档一一实现所有的需求。在开发团队完成了开发后，测试团队会进行介入并检验开发团队的产出是否匹配需求文档上的要求。瀑布流开发模式的特点是，在开发的前期就确定了所有的需求点，因此也被称为：“big requirements up front”
瀑布流存在的问题
in a perfect world, the waterfall process would work just fine, because at the start of the project everyone would know exactly what they’d need at the end. That way, they could write it all down in a neat spec and hand it off to the team to build. But real-life projects never seemed to work out that way
- 强依赖需求的前期确定和依赖相近的文档。一旦发生需求变更，所有相关的文档都需要同步，代码的重写成本大（因为代码在一开始就针对完整的需求进行了强设计）
- 由于强依赖文档，所以缺少团队交流
- 与顾客的交流少，无法适应用户真实需求的变化
敏捷开发的价值观
不完全的敏捷开发
很多只是完全或者部分地实施了敏捷开发的实践操作，但是没有充分的理解敏捷开发的思维模式的团队，相比使用传统瀑布流开发模式的团队确实有一定程度的提升，但是这种提升非常有限，我们称这种状态为“Better-Than-Not-Doing-It”。
另外由于团队成员没有很好的领会敏捷开发的思维模式，虽然每个人都在各自的领域实践不同的敏捷开发工具来帮助提升效率，但是无法从整个团队的角度来看待这些工具，技术或者实践方式，使得这种所谓的敏捷开发根本没有摆脱传统开发模式的弊端。这种无法从团队角度看待问题，我们称之为“断裂的角度”（Fractured Persective）
Fractured Perspective的问题本质，还是团队无法进行充分的沟通，团队成员对于信息的理解无法达成一致。
四大价值观
下面四条敏捷开发的规则，都是强调前者的重要性大于后者，而不是不做后者。
individuals and interactions over processes and tools
强调团队中的个体之间的交流的重要性，以及所有成员对于项目相关的决定的认同（比如开发流程，使用工具）。而不是在不确保大家充分理解的基础上，强硬使用某个流程或者工具。
working software over comprehensive documentation
working software指的是所有对项目真正有价值的东西，包括功能的实现，可用等。这条价值观强调，应当将重心放在真正对项目有价值的东西上，而不是死板的花费大量时间写非常详细的文档。并且文档并不局限于文字描述，如开发人员进行设计的流程图，测试人员进行TTD的测试用例，在广义层面上也是文档。
customer collaboration over contract negotiation
与客户的协作大于合同协定。如果团队成员将产品的开发关注在合同协定上，那么他们就不会真正去思考客户的需求，丧失创新的能力，并时刻准备以合同未靠背推卸自己的责任。只有和客户真正经常性的沟通，团队才能真正的为了用户的需求去思考和行动。
responding to change over following a plan
对变更快速响应重于遵循计划。因为计划永远跟不上变化。一个严格遵照计划的团队，面对需求变更时将手忙脚乱，花费大量时间重新修改计划，开发人员花费大量成本修改原有的代码设计。
敏捷开发的十二条原则
- Our highest priority is to satisfy the customer through early and continuous delivery of valuable software
- welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage
- Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale
- The most efficient and effective method of conveying information to and within a development team is face-to-face conversion
- Businesspeople and developers must work to gather daily throughout the project.
- Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
- Working software is the primary measure of progress.
- Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
- Continuous attention to technical excellence and good design enhances agility.
- Simplicity-the art of maximizing the amount of work not done- is essential.
- The best architectures, requirements, and designs emerge from self-organizing teams.
- At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
快速迭代，拥抱变化，重视对团队有价值的产出，不一味追求细致的文档。充分迭代团队沟通，强调个体的参与，重视和客户的交流
