第1章 敏捷实践
1.1 敏捷联盟
- 个体和交互胜过过程和工具
- 可以工作的软件胜过面面俱到的文档
直到迫切需要并且意义重大时，才来编制文档。
- 客户合作胜过合同谈判
- 响应变化胜过遵循计划
原则
- 我们最优先要做的时通过尽早的、持续的交付有价值的软件来使客户满意。
初期交付的系统中所包含的功能越少，最终交付的系统的质量就越高。
- 即使到了开发的后期，也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势。
- 经常性地交付可以工作的软件，交付的间隔可以从几周到几个月，交付的时间间隔越短越好。
- 在整个项目开发期间，业务人员和开发人员必须天天都在一起工作。
- 围绕被激励起来的个人来构建项目。给他们提供所需要的环境和支持，并且信任他们能够完成工作。
- 在团队内部，最具有效果并且富有效率的传递信息的方法，就是面对面的交谈。
- 工作的软件时首要的进度度量标准。
- 敏捷过程提倡可持续的开发速度。责任人、开发者和用户应该能够保持一个长期的、恒定的开发速度。
- 不断地关注优秀的技能和好的设计会增强敏捷能力。
- 简单——使未完成的工作最大化的艺术——是根本的。
- 最好的架构、需求和设计出自于组织的团队。
- 每隔一定时间，团队会在如何才能更有效地工作方面进行反省，然后相应地对自己的行为进行调整。
1.3 结论
第2章 极限编程概述
2.1 极限编程实践
- 客户作为团队成员
- 用户素材
- 短交付周期
- 验收测试
- 结对编程
- 测试驱动的开发方法
- 集体所有权
- 持续集成
- 可持续的开发速度
- 开放的工作空间
- 计划游戏
- 简单的设计
- 重构
- 隐喻
结论
第3章 计划
初始探索
在项目开始时，开发人员和客户会尽量确定出所有真正重要的用户素材。随着项目的进展，客户会不断编写新的用户素材。素材的编写会一直持续到项目完成。
开发人员共同对这些素材进行估算。
- 探究、分解和速度
发布计划
迭代计划
开发人员和客户决定迭代规模，一般需两周。
即使没有完成所有的用户素材，迭代也要在先前指定的日期结束。
任务计划
在新的迭代开始时，开发人员和客户共同制定计划。
- 迭代的中点
在迭代进行到一半的时候，团队会召开一次会议。
迭代
在每次迭代结束时，给客户演示当前可运行的程序。
第4章 测试
编写单元测试是一种验证行为，一种设计行为，更是一种编写文档的行为。
测试驱动的开发方法
如果能够在设计程序前先设计测试方案
- 程序中的每一项功能都有测试来验证它的操作的正确性。
- 必须从程序调用者的有利视角去观察我们将要编写的程序
- 迫使自己先把程序设计为可测试的。
- 测试可以作为一种无价的文档