因为一个偶然的原因想要系统地了解一下敏捷开发，于是买了此书回来读，发现此书只有第一个部分在讲敏捷开发，剩下90%以上的篇幅都在讲各种各样的设计模式，虽然书中各种设计模式的讲的很好，但总有一点让人心生疑虑，敏捷开发只有这么多可以说吗？
以下是读书笔记
敏捷宣言
- 个体和交互 胜过 过程和工具
- 可以工作的软件 胜过 面面俱到的文档
- 客户合作 胜过 合同谈判
- 响应变化 胜过 遵循计划
个体和交互胜过过程和工具
从使用小工具开始，尝试一个工具，直到发现它无法适用时才去更换它。不是急着去购买那些先进的、价格昂贵的源代码控制工具，相反先使用一个免费的系统直到能够证明该系统已经不再适用。在决定为团队购买最好的CASE工具许可证前，先试用百般和方格纸，直到有足够的理由表明需要更多的功能。不要认为更大、更好的工具可以自动地帮你做得更好。通常，它们造成的障碍要大于带来的帮助。
可以工作的软件胜过面面俱到的文档
没有文档的软件是一种灾难。代码不是传达系统原理和结构的理想媒介。团队更需要编制易于阅读的文档，来对系统及其设计决策的依据进行描述。
然而，过多的文档比过少的文档更糟。编制众多的文档需要花费大量的时间，并且要使这些文档和代码保持同步，就要花费更多的时间。如果文档和代码之间失去同步，那么文档就会变成庞大的、复杂的谎言，会造成重大的误导。
客户合作胜过合同谈判
不能像订购日用品一样来订购软件。你不能够仅仅写下一份你想要的软件的描述，然后就让人在固定的时间内以固定的价格去开发它。所有用这种方式来对待软件项目的尝试都以失败而告终。
告诉开发团队想要的东西，然后期望开发团队消失一段时间后就能够交付一个满足需要的系统来，这对于公司管理者来说是具有诱惑力的。然而，这种操作模式将导致低劣的质量和失败。
响应变化胜过遵循计划
较好的做计划的策略是：为下两周做详细的计划，为下三周做粗略的计划，在以后就做极为粗糙的计划。我们应该清楚地知道下两周要完成的任务，粗略地了解一下以后三个月要实现的需求。至于系统一年后将要做什么，有一个模糊的想法就行了。
敏捷开发的原则
- 我们最优先要做的就是通过尽早的、持续交付有价值的软件来使客户满意
- 即使到了开发后期，也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势
- 经常性地交付可以工作的软件，交付的间隔可以从几周到几个月，交付的时间间隔越短越好。
- 在整个项目开发期间，业务人员和开发人员必须天天都在一起工作
- 围绕被激励起来的个人来构建项目。给他们提供所需要的环境支持，并且信任他们能够完成工作
- 在团队内部，最具有效果并且富有效率的传递信息的方法，就是面对面的交谈
- 工作的软件是首要的进度度量标准
- 敏捷过程提倡可持续的开发速度。责任恩、开发者和用户应该能够保持一个长期的、恒定的开发速度
- 不断地关注优秀的技能和好的设计会增强敏捷能力
- 简单——是未完成的工作最大化的艺术——是根本的
- 最好的构架、需求和设计出自自组织的团队
结对编程
所有的产品代码都是由结对的程序员使用同一台电脑共同完成的。结对人员的一位控制键盘并输入代码，另一位观察输入的代码并寻找着代码中的错误和可以改进的地方。两个人强烈地进行着交互，他们都全身心地投入到软件的编写中。
结对的关系每天至少要改变一次，以便于每个程序员在一天中可以在两个不同的结对中工作。在一次迭代期间，每个团队应该和所有其他团队成员在一起工作过，并且他们应该参与了本次迭代中所涉及的每项工作。
这将极大的促进知识在团队中的传播。仍然会传递一些专业知识，并且那些需要一定专业知识的任务通常需要合适的专家去完成。但是那些专家几乎回合团队中的所有其他人结对过。这将加快专业知识在团队中的传播。这样，在紧要关头，其他团队成员就能够代替所需要的专家。