《人月神话》
1.在众多软件项目中，缺乏合理的进度安排是造成项目滞后的最主要原因，它比其他所有因素加起来的影响还要大。导致这种灾难如此普遍的原因是：
a: 我们对估算技术缺乏有效的研究，更加严肃地说，它反映了一种悄无声息，但并不真实的假设-----一切都将运作良好。
1：所有的编程人员都是乐观主义者（这次它肯定会运行，我刚刚找到最后一个bug）
2：进度安排背后的第一个错误的假设是：一切都将运作良好，每一项任务仅花费它所“应该”花费的时间
3：在单个任务中，“一切都将运转正常”的假设在进度上具有可实现性。因为所遇到的延迟是一个概率。
4：分布曲线，“不会延迟”具有限定的概率，所以现实情况可能会像计划安排得那样顺利。然而大型的编程工作，或多或少包含了很多任务，某些任务间还具有前后的次序，从而一切正常的概率变得非常小，甚至接近于无。
b: 我们采用的估算技术隐含地假设人和月可以互换，错误地将进度与工作量相混淆。
1：成本的确随开发产品的人数和时间的不同，有着很大的变化，进度却不是如此。
2：用人月作为衡量一项工作的规模是一个危险和带有欺骗性的神话。
3：人数和时间的互换仅仅适用于以下情况：某个任务可以分解给参与人员，并且它们之间不需要相互的交流。这在割小麦或收获棉花的工作中是可行的。
4：无论哪个母亲，孕育一个生命都需要10个月。
5：对于可以分解，但子任务之间需要相互沟通和交流的任务，必须在计划工作中考虑沟通的工作量。因此，相同人月的前提下，采用增加人手来减少时间得到的最好情况，也比未调整前要差一些。沟通所增加的负担由两个部分组成，培训和相互交流。培训增加的工作量（不能分解）随人员的数量呈线性变化。相互交流的工作量按照n(n-1)/2递增。
c: 由于对自己的估算缺乏信心，软件经理通常不会有耐心持续地估算这项工作。
在进度安排中，顺序限制所造成的影响，没有哪个部分比单元测试和系统测试所受到的牵涉更彻底。
进度安排参考法则：
1/3计划
1/6编码
1/4构件测试和早期系统测试
1/4系统测试，所有的构件已完成
在许多重要的方面，上面的进度安排与传统的方法不同：
分配个计划的时间比平常的多。即便如此，只是勉强够产生详细和稳定的计划规格说明，并不足以容纳对全新技术的研究和探索。
对所完成代码的调试和测试，投入近一半的时间。
容易评估的部分，如编码，仅仅分配了1/6的时间。研究发现，很少有项目允许为测试分配一半的时间。但大多数项目的测试实际上是花费了进度中一半的时间。他们中许多项目，在系统测试之前还能保持进度。
d: 对进度缺少跟踪和监督。
非阶段化方法的采用，少得可怜的数据支持，加上完全借助软件经理的知觉，这样的方法很难生产出有力的，看似可靠的和规避风险的估计。
开发并推行生产率图表、缺陷率图表、估算规则等等，而整个组织最终会从这些数据的共享上获益。
e: 当意识到进度的偏移时，下意识（以及传统）的反应是增加人力。这就像使用汽油灭火一样，只会使事情更糟。
项目的时间依赖于顺序上的限制。人员的最大数量依赖于独立子任务的数量。
2. 需要协作沟通的人员数量影响着开发成本，因为成本的主要组成部分是相互沟通和交流，以及更正沟通不当所引起的不良结果（系统调试）。这一点也暗示，系统应该有尽可能少的人员来开发。
3. 对于效率和概念的完整性来说，最好有少数干练的人员来设计和开发，而对于大型系统，则需要大量的人手，以使产品能在时间上满足要求，如何调和这两方面的矛盾。Mills的建议：大型项目的每一个部分由一个团队解决，但是该团队以类似外科手术的方式组建，而并非一拥而上。也就是说，同每一成员截取问题某个部分的做法相反，由一个人来完成问题的分解，其他人给予他所需要的支持，以提高效率和生产力。
4. 外科手术团队：
外科医生（首席程序员）：定义功能、设计、编码、测试、要很高经验，熟悉业务
副手：外科医生的保险机制。提供设计、编码、功能的建议，不负责具体的事务
管理人员：管理财务、人员、工作地点、办公设备，听从外科医生
编辑:文档的生成，维护。来自于外科医生的口述或者草稿。
两个文秘：管理人员和编辑各配一个文秘。负责项目的协作一致。
程序职员：负责团队所有的程序和数据的管理。
工具维护人员：保证所有基本服务的可靠性，一致性以及构建，升级，维护。
测试人员：编写测试用例和准备测试数据。
语言专家：语言方面的专家，咨询。解决复杂，棘手的问题。
5. 对于计算机系统而言，出现概念差异和不一致性的问题，是由于设计被分成了由若干人完成的若干任务。所以需要具备设计上的完整性，就需要一个系统架构师从上之下的进行所有的设计。要使工作易于管理，必须清晰地划分体系结构设计和实现之间的界线，系统架构师必须一丝不苟的专注于体系结构。（本文的体系结构指的是完整和详细的用户接口说明，更偏重于现今的需求概念，不是指系统的框架。）
6. 功能与理解上复杂程度的比值才是系统设计的最终测试标准，也就是易用性。而易用性需要设计的一致性和概念上的完整性来保证。体系结构和实现必须要严格分离开来。产品的成本性能比很大程度上依靠实现人员，就如同易用性很大程度上依赖架构师一样。两者都有需要很高的创造性。
7. 系统架构规定实际上是增强，而不是限制了实现小组的创造性。一旦他们将注意力集中在没有人解决过的问题上，创意就开始奔涌而出。在毫无限制的实现小组中，在进行系统架构上的决策时，会出现大量的想法和争议，对具体实现的关注反而会比较少。
8. 当建议由小型体系结构团队来编写系统的所有外部技术说明时，编程人员常常会提出这样的反对意见：
该说明中的功能过于繁多，而对实际情况中的成本考虑比较少。
警惕second-system effect。在设计第一个项目时，架构师会面对不断产生的装饰和润色功能，但这些功能都会被搁置在一边，作为“下一个”项目的内容。第二个系统是设计师们所设计最危险的系统。而当着手第三第四个系统时，先前的经验会相互验证，得到对此类系统通用特性的判断，而且系统之间的差异会帮助他识别出经验中不够通用的部分。
second-system effect：一种普遍倾向是过分的设计第二个系统，向系统中添加很多修饰功能和想法。另一种倾向是对某些技术进行细化、精炼的趋势，由于基本系统设想发生了变化，这些技术已经显得落后。
架构师获得了所有创造发明的快乐，剥夺了实现人员的创造力。
具体实现中创造和发明的机会，并不会因为指定了外部技术说明而大为减少，相反创造性活动会因为规范化而得到增强，整个产品也是一样。
当体系结构的队伍缓慢工作时，很多实现人员只能空闲的坐着等待。
在外部技术说明完成的时候，才雇佣实现人员。 ；）
9. 把工作进行垂直划分，保证概念的完整性；尽量避免水平划分。
10. 文档化的规格说明----手册：手册是产品的外部规格说明，它描述和规定了用户所见的每一个细节；同时它还避免描述用户看不见的事物。后者是编程实现人员的工作范畴，而这里他的设计和创造自由是不应该被限制的。体系结构设计人员必须为自己描述的任何特性准备一种实现方法，但是他不应该试图支配具体的实现过程。
11. 周例会是每周半天的会议，有所有的架构师，加上硬件和软件实现人员代表和市场计划人员参与，由首席系统架构师主持。会议中，任何人可以提出问题和修改意见，但是建议书通常是以书面的形式，在会议之前分发。周例会的决策会给出迅速的结论，使工作继续开展下去。这种会议的卓有成效是在于：
数月内，相同小组-----架构师、用户和实现人员-----每周交流一次。因此大家对项目相关的内容比较了解，不需要安排额外时间对人员进行培训。
上述小组十分睿智和敏锐，深刻理解所面对的问题，并且与产品密切相关。没有人是“顾问”的角色，每个人都要承担义务。
当问题出现时，在界线的内部和外部同时寻找解决方案。
正式的书面建议集中了注意力，强制了决策的制定，避免了会议草稿纪要方式的不一致。
明确的授予首席架构师决策的权力，避免了妥协和拖延。
12. 电话日志：日志中，它记录了每一个问题和相应的回答。QA表
13. 产品测试：项目经理最好的朋友就是他每天要面对的对手----独立的产品测试机构/小组。每一个开发机构都需要这样一个独立的技术监督部门，来保证其公正性。测试人员不时地总会发现一些没有贯彻执行、设计决策没有正确或准确实现的地方。出于这方面的原因，设立测试小组是使设计决策得以贯彻执行的必要手段，同样也是需要尽早着手，与设计同时实施的重要环节。
星期五, 二月 23, 2007
敏捷方法书籍（转载）
“敏捷软件开发宣言：我们正在通过亲身实践和帮助其他人实践，揭示更好的软件开发方法，通过这项工作，我们认为：
人和交流胜过过程和工具
可工作的软件胜过面面俱到的文档
客户协作胜过合同谈判
响应变化胜过遵循计划
虽然右项也有价值，但是我们认为左项更重要。”
—— Kent Beck，Mike Beedle，Arie van Bennekum，Alistair Cockburn，Ward Cunningham，Martin Fowler，James Grenning，Jim Highsmith，Andrew Hunt，Ron Jeffries，Jon Kern，Brian Marick， Robert C. Martin，Steve Mellor，Ken Schwaber，Jeff Sutherland，Dave Thomas
敏捷软件开发这个词在2006年的中国软件界听起来仍然显得有些陌生。自2001年敏捷联盟被发起以来，敏捷方法的实践经验和理论研究都在不断的更新。而我国的大多数程序员还是只能在书本上读到敏捷的好处，很难在项目中进行实践。这其中的原因，主要是缺乏拥有实际敏捷项目经验的人来带领实施敏捷。虽然敏捷开发是种实践行为，很难从书本上直接学习，不过多数程序员了解敏捷，却都是先从书本开始的。无论结果怎样，从认识到实践的过程是免不了的。
敏捷软件开发之方法论篇
大家都知道敏捷软件开发方法包括了多种方法论，主要有：SCRUM，Crystal,特征驱动软件开发（FDD），自适应软件开发（ASD），以及最著名的极限编程(XP)。这些方法论分别在不同的著作上专门论述过：
SCRUM：《Agile Software Development with Scrum》 by Ken Schwaber, Mike Beedle，《Agile Project Management With Scrum》by Ken Schwaber
FDD: 《Java Modeling in Color with UML》by Peter Coad, 《A Practical Guide to Feature-Driven Development》(特征驱动开发) by Stephen R Palmer, John M. Felsing,
Crystal: 《Crystal Clear》by Alistair Cockburn
ASD: 《Adaptive Software Development》（自适应软件开发）by James A. Highsmith
其中尤以XP系列的书籍居多。人民邮电出版社的一系列极限编程系列丛书，在国内引进较早。在还没有统一敏捷词汇的情况下，引发了一批敏捷先锋人士的热情，是我国程序员的敏捷启蒙教材。这些书包括《Extreme Programming Explained》（解析极限编程），《Extreme Programming Examined》（极限编程研究），《Extreme Programming Installed》(极限编程实施)，《Extreme Programming Explored》（探索极限编程），《Extreme Programming Applied》（应用极限编程）《Extreme Programming in Practice》（极限编程实践），《Planning Extreme Programming》（规划极限编程）等，这些书有的是作者的XP实践论文，有些是对XP项目的介绍，其中，值得推荐的是下面两部著作。
《Extreme Programming Explained: Embrace Change》by Kent Beck
第一版中译版：《解析极限编程：拥抱变化》，唐东铭，人民邮电出版社
第二版中译版：雷剑文，电子工业出版社
作为XP的开山之作，目前已经出版了第二版。在第一版中，Kent Beck对XP作了详细的描述。从当前软件开发的现状和问题谈起，从需求的变化到如何拥抱变化，给出了XP的四项价值观和十二项实践。对于想了解敏捷的来龙去脉的人，此书属于必读之类。在第二版，Kent根据几年来的实践，为XP增加了一项价值观：尊重，并增加了原则的概念，同时增加和删改了一些实践。
该书第一版是程序员的宣言，这和Kent的背景很有关系。随后XP经历了五六年的发展和实践，Kent自己也逐渐意识到，这样的观点太狭隘了。因此就有了第二版，与其说这是技术书籍，到更像是纯粹意义的软工书籍。期间也可以看出XP的体系更加完备。这其中尤为突出的是把人放到了更为重要的地位。
《Extreme Programming in Practice》by James Newkirk, Robert C. Martin
中译版：《极限编程实践》，王钧，人民邮电出版社
读过了一些列的XP书籍，程序员们都会觉得XP非常好，但到底如何才能开始实施XP呢？还不是太清楚。本系列中的这本书用一个完整的小项目作例子，从头到尾教给人如何敏捷开发，是一本不可多得的实践教材。如果想直接实施XP开发，这本书可以给你很大启示。
敏捷软件开发之实践篇
一、极限编程最佳实践
由于极限编程是如此的流行，多数敏捷团队都会或多或少的借鉴一些XP中的敏捷实践，而XP的每一个敏捷实践也确实值得大书特书，而其中最著名的是测试驱动开发和重构实践：
《Test-Driven Development》 by Kent Beck
中译版：《测试驱动开发》，崔凯，中国电力出版社
测试驱动开发是Kent Beck另一部力作。“Clean Code That Works”是敏捷开发的目标之一，那么如何达到这个目标？TDD给出了一种方式。测试实质上是需求。由需求产生出的代码肯定是能够工作的功能代码，而要实现Class本身的可测试性，就不得不写出高度解耦合的Clean的代码。本书从一个Money的例子入手，从最初的一点需求开始，逐步增加需求，完成整个货币系统的代码。后面又给出了Unit Test中的一些最佳实践和模式供参考。
然而，本书的教导意义比其实践意义更突出。作为一本TDD的教程或入门教材，这本书无疑是最佳的，其中提出的一些最佳实践更是值得经常阅读来温习。本书面向的是单元测试，而实际开发中面对的数据库测试，Web测试等问题并不属于单元测试的范畴。因此读者并不能从中直接进入到实战。
另一本同名书《Test Driven Development: A Practical Guide》由Davis Astels撰写，他将该书看作是Kent著作的补充，重点阐述利用TDD开发所必要的技术和工具上，因此对实际开发更具实用性。
《Refactoring: Improving the Design of Existing Code》by Martin Fowler
中译版：《重构：改善既有代码的设计》，侯捷，熊节，中国电力出版社
重构这本书的意义在于，他提供了一种让你写出更加优美代码的能力。在测试的保证下，重构能够发挥强大的威力。敏捷团队中，不断的重构出简单且高效的代码才能够保持拥抱不断变化的需求。后来的一本书《Refactoring to Patterns》（从重构到模式）by Joshua Kerievsky，更是将重构的威力发挥到极限。
重构曾被称为软件开发图书的双璧，另一本书是《Design Patterns》(设计模式) by GoF。当然，对现在的软件开发这二者已经不是最重要的。ThoughtWorks的首席科学家Martin Fowler总结了朋友们的各种实践心得，写出了这本书。从几年后的目光来看，这本书中的多数实践都被各种IDE做到了操作菜单中。虽然IDE提供了大量重构功能，但仅靠IDE是无法写出简洁美妙代码的，多数的敏捷团队重构工作做得还是不够。
另外有一本专门介绍结对编程的书，《Pair Programming Illuminated》（结对编程技术）by by Laurie Williams and Robert Kessler，指出了为什么要结对？并从各种不同水平不同性格的程序员结对情况来讨论该实践的优劣。对此有兴趣的程序员不妨一读。
二、敏捷软件开发实践
自从2001年敏捷联盟成立以来，单独推广极限编程的书变少了，而统一口径推广敏捷的书变得越来越多。两本同名的敏捷软件开发都是不可多得的好书，
《Agile Software Development：Principles, Patterns, and Practices》by Robert C. Martin
中译版：《敏捷软件开发：原则，模式与实践》，邓辉，清华大学出版社
被业内人士称为Uncle Bob的Robert C Martin在沉寂几年后写出了这部书。该书可以算是从软件开发角度对敏捷方法阐述的最详细和全面的一本。之前的敏捷书籍多是关注于过程改进，而对如何从技术角度实施讲的比较少。本书一开始先介绍了敏捷联盟和敏捷开发过程。之后详细论述了面向对象设计的原则，这些原则是本书的精华之一。后面通过几个项目介绍了如何将设计模式应用于项目中。
Uncle Bob不愧是实践的大师，写出来的书也是拥有很强的实践意义。在敏捷团队的办公桌上，应当常备此书，一来可作为参考查询，二来可以作为新成员的必读书目。
《Agile Software Development》by Alistair Cockburn
中译版：《敏捷软件开发》，俞涓，人民邮电出版社
这本书更加适合管理者来阅读。Alistair从项目人数和交流难易程度，将敏捷的各种方法划分了其适用范围。人数多的或分布式项目就需要靠其他手段来加强交流，人数少的就可以靠pair programming等进行面对面的交流。交流和反馈是敏捷的核心。同时Alistair也介绍了一下他提出的Crystal方法族。
三.敏捷项目管理和敏捷需求分析
在推广敏捷一段时间后，敏捷社群也意识到，多数书籍更像是面向开发人员，过于技术化，难以吸引项目经理或主管。因此，一批面向管理者视角的书也开始浮出水面，这些书包括：
《Agile and Iterative Development》（敏捷迭代开发）by Craig Larman
《Lean Software Development》（敏捷软件开发工具—精益开发方法）by Mary Poppendieck
《Agile Software Development Ecosystems》（敏捷软件开发生态系统）by Jim Highsmith
书中从各种角度比较和分析各种敏捷方法的优劣，异同，起源，适用范围等。这些书对于一个项目主管决策使用何种过程来在自己的团队中实践敏捷有很好的参考作用。
近两年，人们开始逐渐意识到敏捷开发的侧重点不仅仅是开发过程和开发实践，还包括对需求和项目管理等其他相关方面的实践。一些相关的书籍也悄然出现在人们的视野：
《Agile Project Management》（敏捷项目管理）by Jim Highsmith
《User Stories Applied》by Mike Cohn
《Agile Estimating and Planning》by Mike Cohn
《Agile Requirements & User Stories》 by Louis Molnar
这些书不同于以往强调新方法，新过程的书目。敏捷项目管理类的书主要介绍如何管理敏捷团队，如何计划要开发的需求，如何为客户提供最大的价值。介绍敏捷需求分析的书主要帮助商务分析师或项目经理挖掘和分析用户需求，写出用户故事，评估和计划用户故事等。人们已经意识到，各种方法论的实质是相同的，都是提供商业价值，减少浪费，增加交流，快速反馈。因此不需要着重于区分是使用了那种方法。对项目经理来说，不同的项目或团队应当采用适应其特殊情况的方法，而这些方法的基本原则是相同的。
四.敏捷软件开发新方向
对架构师或程序员来说，近年来的技术进展，也使得敏捷开发有了新的研究方向：
《Agile Web Development with Rails》by Dave Thomas, David Hansson, Leon Breedt, and Mike Clark
该书是获得2006JOLT奖的书，讲得是采用Ruby on Rails这个Web开发工具新贵来快速开发Web项目，从而达到快速反馈拥抱变化的目的。
《Refactoring Databases》by Scott W Ambler
此书是Scott的新作，延续和继承了《Agile Modeling》（敏捷建模）和《Agile Database Techniques》（敏捷数据）的思想。在敏捷开发过程中，作为持久化最常见技术的数据库如果不能够敏捷，怎么能够适应一次次迭代和一次次发布的修改呢？书中介绍了如何进行数据库演化，如何保证升级后数据库数据的正确性，以及最佳实践。
我们可以看到，随着敏捷方法和市场的不断成熟，敏捷的书籍也从理论性转向了实用和最佳实践类型。然而，不可否认的是，一个团队的敏捷化很难仅靠阅读书本来完成，由成功实践过敏捷的开发者手把手的带领，才是最好的方法。
人和交流胜过过程和工具
可工作的软件胜过面面俱到的文档
客户协作胜过合同谈判
响应变化胜过遵循计划
虽然右项也有价值，但是我们认为左项更重要。”
—— Kent Beck，Mike Beedle，Arie van Bennekum，Alistair Cockburn，Ward Cunningham，Martin Fowler，James Grenning，Jim Highsmith，Andrew Hunt，Ron Jeffries，Jon Kern，Brian Marick， Robert C. Martin，Steve Mellor，Ken Schwaber，Jeff Sutherland，Dave Thomas
敏捷软件开发这个词在2006年的中国软件界听起来仍然显得有些陌生。自2001年敏捷联盟被发起以来，敏捷方法的实践经验和理论研究都在不断的更新。而我国的大多数程序员还是只能在书本上读到敏捷的好处，很难在项目中进行实践。这其中的原因，主要是缺乏拥有实际敏捷项目经验的人来带领实施敏捷。虽然敏捷开发是种实践行为，很难从书本上直接学习，不过多数程序员了解敏捷，却都是先从书本开始的。无论结果怎样，从认识到实践的过程是免不了的。
敏捷软件开发之方法论篇
大家都知道敏捷软件开发方法包括了多种方法论，主要有：SCRUM，Crystal,特征驱动软件开发（FDD），自适应软件开发（ASD），以及最著名的极限编程(XP)。这些方法论分别在不同的著作上专门论述过：
SCRUM：《Agile Software Development with Scrum》 by Ken Schwaber, Mike Beedle，《Agile Project Management With Scrum》by Ken Schwaber
FDD: 《Java Modeling in Color with UML》by Peter Coad, 《A Practical Guide to Feature-Driven Development》(特征驱动开发) by Stephen R Palmer, John M. Felsing,
Crystal: 《Crystal Clear》by Alistair Cockburn
ASD: 《Adaptive Software Development》（自适应软件开发）by James A. Highsmith
其中尤以XP系列的书籍居多。人民邮电出版社的一系列极限编程系列丛书，在国内引进较早。在还没有统一敏捷词汇的情况下，引发了一批敏捷先锋人士的热情，是我国程序员的敏捷启蒙教材。这些书包括《Extreme Programming Explained》（解析极限编程），《Extreme Programming Examined》（极限编程研究），《Extreme Programming Installed》(极限编程实施)，《Extreme Programming Explored》（探索极限编程），《Extreme Programming Applied》（应用极限编程）《Extreme Programming in Practice》（极限编程实践），《Planning Extreme Programming》（规划极限编程）等，这些书有的是作者的XP实践论文，有些是对XP项目的介绍，其中，值得推荐的是下面两部著作。
《Extreme Programming Explained: Embrace Change》by Kent Beck
第一版中译版：《解析极限编程：拥抱变化》，唐东铭，人民邮电出版社
第二版中译版：雷剑文，电子工业出版社
作为XP的开山之作，目前已经出版了第二版。在第一版中，Kent Beck对XP作了详细的描述。从当前软件开发的现状和问题谈起，从需求的变化到如何拥抱变化，给出了XP的四项价值观和十二项实践。对于想了解敏捷的来龙去脉的人，此书属于必读之类。在第二版，Kent根据几年来的实践，为XP增加了一项价值观：尊重，并增加了原则的概念，同时增加和删改了一些实践。
该书第一版是程序员的宣言，这和Kent的背景很有关系。随后XP经历了五六年的发展和实践，Kent自己也逐渐意识到，这样的观点太狭隘了。因此就有了第二版，与其说这是技术书籍，到更像是纯粹意义的软工书籍。期间也可以看出XP的体系更加完备。这其中尤为突出的是把人放到了更为重要的地位。
《Extreme Programming in Practice》by James Newkirk, Robert C. Martin
中译版：《极限编程实践》，王钧，人民邮电出版社
读过了一些列的XP书籍，程序员们都会觉得XP非常好，但到底如何才能开始实施XP呢？还不是太清楚。本系列中的这本书用一个完整的小项目作例子，从头到尾教给人如何敏捷开发，是一本不可多得的实践教材。如果想直接实施XP开发，这本书可以给你很大启示。
敏捷软件开发之实践篇
一、极限编程最佳实践
由于极限编程是如此的流行，多数敏捷团队都会或多或少的借鉴一些XP中的敏捷实践，而XP的每一个敏捷实践也确实值得大书特书，而其中最著名的是测试驱动开发和重构实践：
《Test-Driven Development》 by Kent Beck
中译版：《测试驱动开发》，崔凯，中国电力出版社
测试驱动开发是Kent Beck另一部力作。“Clean Code That Works”是敏捷开发的目标之一，那么如何达到这个目标？TDD给出了一种方式。测试实质上是需求。由需求产生出的代码肯定是能够工作的功能代码，而要实现Class本身的可测试性，就不得不写出高度解耦合的Clean的代码。本书从一个Money的例子入手，从最初的一点需求开始，逐步增加需求，完成整个货币系统的代码。后面又给出了Unit Test中的一些最佳实践和模式供参考。
然而，本书的教导意义比其实践意义更突出。作为一本TDD的教程或入门教材，这本书无疑是最佳的，其中提出的一些最佳实践更是值得经常阅读来温习。本书面向的是单元测试，而实际开发中面对的数据库测试，Web测试等问题并不属于单元测试的范畴。因此读者并不能从中直接进入到实战。
另一本同名书《Test Driven Development: A Practical Guide》由Davis Astels撰写，他将该书看作是Kent著作的补充，重点阐述利用TDD开发所必要的技术和工具上，因此对实际开发更具实用性。
《Refactoring: Improving the Design of Existing Code》by Martin Fowler
中译版：《重构：改善既有代码的设计》，侯捷，熊节，中国电力出版社
重构这本书的意义在于，他提供了一种让你写出更加优美代码的能力。在测试的保证下，重构能够发挥强大的威力。敏捷团队中，不断的重构出简单且高效的代码才能够保持拥抱不断变化的需求。后来的一本书《Refactoring to Patterns》（从重构到模式）by Joshua Kerievsky，更是将重构的威力发挥到极限。
重构曾被称为软件开发图书的双璧，另一本书是《Design Patterns》(设计模式) by GoF。当然，对现在的软件开发这二者已经不是最重要的。ThoughtWorks的首席科学家Martin Fowler总结了朋友们的各种实践心得，写出了这本书。从几年后的目光来看，这本书中的多数实践都被各种IDE做到了操作菜单中。虽然IDE提供了大量重构功能，但仅靠IDE是无法写出简洁美妙代码的，多数的敏捷团队重构工作做得还是不够。
另外有一本专门介绍结对编程的书，《Pair Programming Illuminated》（结对编程技术）by by Laurie Williams and Robert Kessler，指出了为什么要结对？并从各种不同水平不同性格的程序员结对情况来讨论该实践的优劣。对此有兴趣的程序员不妨一读。
二、敏捷软件开发实践
自从2001年敏捷联盟成立以来，单独推广极限编程的书变少了，而统一口径推广敏捷的书变得越来越多。两本同名的敏捷软件开发都是不可多得的好书，
《Agile Software Development：Principles, Patterns, and Practices》by Robert C. Martin
中译版：《敏捷软件开发：原则，模式与实践》，邓辉，清华大学出版社
被业内人士称为Uncle Bob的Robert C Martin在沉寂几年后写出了这部书。该书可以算是从软件开发角度对敏捷方法阐述的最详细和全面的一本。之前的敏捷书籍多是关注于过程改进，而对如何从技术角度实施讲的比较少。本书一开始先介绍了敏捷联盟和敏捷开发过程。之后详细论述了面向对象设计的原则，这些原则是本书的精华之一。后面通过几个项目介绍了如何将设计模式应用于项目中。
Uncle Bob不愧是实践的大师，写出来的书也是拥有很强的实践意义。在敏捷团队的办公桌上，应当常备此书，一来可作为参考查询，二来可以作为新成员的必读书目。
《Agile Software Development》by Alistair Cockburn
中译版：《敏捷软件开发》，俞涓，人民邮电出版社
这本书更加适合管理者来阅读。Alistair从项目人数和交流难易程度，将敏捷的各种方法划分了其适用范围。人数多的或分布式项目就需要靠其他手段来加强交流，人数少的就可以靠pair programming等进行面对面的交流。交流和反馈是敏捷的核心。同时Alistair也介绍了一下他提出的Crystal方法族。
三.敏捷项目管理和敏捷需求分析
在推广敏捷一段时间后，敏捷社群也意识到，多数书籍更像是面向开发人员，过于技术化，难以吸引项目经理或主管。因此，一批面向管理者视角的书也开始浮出水面，这些书包括：
《Agile and Iterative Development》（敏捷迭代开发）by Craig Larman
《Lean Software Development》（敏捷软件开发工具—精益开发方法）by Mary Poppendieck
《Agile Software Development Ecosystems》（敏捷软件开发生态系统）by Jim Highsmith
书中从各种角度比较和分析各种敏捷方法的优劣，异同，起源，适用范围等。这些书对于一个项目主管决策使用何种过程来在自己的团队中实践敏捷有很好的参考作用。
近两年，人们开始逐渐意识到敏捷开发的侧重点不仅仅是开发过程和开发实践，还包括对需求和项目管理等其他相关方面的实践。一些相关的书籍也悄然出现在人们的视野：
《Agile Project Management》（敏捷项目管理）by Jim Highsmith
《User Stories Applied》by Mike Cohn
《Agile Estimating and Planning》by Mike Cohn
《Agile Requirements & User Stories》 by Louis Molnar
这些书不同于以往强调新方法，新过程的书目。敏捷项目管理类的书主要介绍如何管理敏捷团队，如何计划要开发的需求，如何为客户提供最大的价值。介绍敏捷需求分析的书主要帮助商务分析师或项目经理挖掘和分析用户需求，写出用户故事，评估和计划用户故事等。人们已经意识到，各种方法论的实质是相同的，都是提供商业价值，减少浪费，增加交流，快速反馈。因此不需要着重于区分是使用了那种方法。对项目经理来说，不同的项目或团队应当采用适应其特殊情况的方法，而这些方法的基本原则是相同的。
四.敏捷软件开发新方向
对架构师或程序员来说，近年来的技术进展，也使得敏捷开发有了新的研究方向：
《Agile Web Development with Rails》by Dave Thomas, David Hansson, Leon Breedt, and Mike Clark
该书是获得2006JOLT奖的书，讲得是采用Ruby on Rails这个Web开发工具新贵来快速开发Web项目，从而达到快速反馈拥抱变化的目的。
《Refactoring Databases》by Scott W Ambler
此书是Scott的新作，延续和继承了《Agile Modeling》（敏捷建模）和《Agile Database Techniques》（敏捷数据）的思想。在敏捷开发过程中，作为持久化最常见技术的数据库如果不能够敏捷，怎么能够适应一次次迭代和一次次发布的修改呢？书中介绍了如何进行数据库演化，如何保证升级后数据库数据的正确性，以及最佳实践。
我们可以看到，随着敏捷方法和市场的不断成熟，敏捷的书籍也从理论性转向了实用和最佳实践类型。然而，不可否认的是，一个团队的敏捷化很难仅靠阅读书本来完成，由成功实践过敏捷的开发者手把手的带领，才是最好的方法。
