很早之前在学习刘欣的线上课程的时候，就买了这本《敏捷软件开发：原则、模式与实践》，一直没怎么看。这次借着刘欣老师发起的大家一起共读计算机经典名著，没有犹豫立即报名参加，试图赶走自己的懒惰。
这本书非常经典，但是我看的时候大部分是看不大懂的，应该是因为自己这方面实践比较少，理论也没有学过，等于是空白一片，我自己都怀疑自己是个假程序猿。好了，废话不多少了，虽然看不懂，但还是要做一些笔记，多度几遍，多查资料，我相信自己一定能搞懂这些内容的。
原则、模式和实践都是重要的，但是使它们发挥作用的是人！
如果想要项目取得成功，就必须构建起具有合作精神的、自组织的团队。
问题1：什么是自组织呢？如何构建这样的组织和团队呢？
一、敏捷软件开发
敏捷开发联盟宣言：
1. 个人和交互胜过过程和工具。团队的构建要比环境的构建重要的多
2. 可以工作的软件胜过面面俱到的文档。最好的两份文档是代码和团队，代码真实的表达了它所做的事情，虽然从代码中提取系统的原理和结构信息可能是困难的，但是代码是唯一没有二义性的信息员。直到迫切需要并且意义重大时，才来编制文档。
3. 客户合作胜过合同谈判。成功的项目需要有序、频繁的客户反馈。不是依赖于合同或者关于工作的陈述，而是让软件的客户和开发团队密切地在一起工作，并尽量经常的提供反馈。
4. 响应变化胜过遵循计划。较好的做计划的策略是：为下两周做详细的计划，为下三个月做粗略的计划，在以后就做极为粗糙的计划。
敏捷开发的原则：
1. 我们最优先要做的是通过尽早的，持续的交付有价值的软件来使客户满意。
2. 即使到了开发的后期，也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势。
3. 经常性的交付可以工作的软件，交付的间隔可以从几周到几个月，交付的时间间隔越短越好。
4. 在整个项目开发周期，业务人员和开发人员必须天天都在一起工作。
5. 围绕被激励起来的个人来构建项目。给他们提供所需要的环境和支持，并且信任他们能够完成工作。
6. 在团队内部，最具有效果并且富有效率的传递信息的方法，就是面对面的交谈。
7. 工作的软件是首要的进度度量标准。
8. 敏捷过程提倡可持续的开发速度。责任人、开发者和用户应该能够保持一个长期的、恒定的开发速度。
9. 不断的关注优秀的技能和好的设计会增强敏捷能力。
10. 简单——未使完成的工作最大化的艺术——是根本的。
11. 最好的构架、需求和设计出自于自组织的团队。
12.每隔一段时间，团队会在如何才能更有效的工作方面进行反省，然后相应地对自己的行为进行调整。
二、极限编程概述
极限编程实践：
1. 客户作为团队成员。客户是指定义产品的特性并排列这些特性优先级的人或者团体。
2. 用户素材。就是正在进行的关于需求谈话的助记符。
3. 短交付周期。
4. 验收测试。
5. 结对编程。所有的产品代码都是由结对的两个程序员使用一台电脑共同完成。一个人控制键盘输入代码，一个人观察代码并寻找代码中错误和可以改进的地方。两个人频繁互换角色。不会降低开发效率，同时会大大减少缺陷率。
6. 测试驱动的开发方法。
7. 集体所有权。
8.持续集成。
9. 可持续的开发速度。
10.开放的工作空间。
11.计划游戏。搞不懂在说什么。
12.简单的设计。
13.重构。
14.隐喻。
三、计划
这一章节是极限编程中的计划游戏部分的描述，对自己来说是一个全新的概念，所以这一章讲的内容看的很不明白。后面再多看几遍。
四、测试
本章通过一个具体的示例讲解了测试驱动的开发方法和验收测试。也看的不是很明白，后面需要重点研究
五、重构
一个软件模块具有三项职责：
1. 它运行起来所完成的功能。
2. 它要应对变化。
3. 要和阅读它的人进行沟通。
重构的目的，是为了每天清洁你的代码。
前面五章算是看完了，但是很多地方还是一知半解，或者是看不大明白，需要再次仔细的强力研读。
