Beck全家似乎都弥漫着技术的味道。生长在硅谷, 有着一个对无线电痴迷的祖父，以及一个电器工程师父亲。从小就引导Kent Beck成为了业余无线电爱好者。在俄勒冈州大学读本科期间，Kent Beck就开始研究起模式。然而在他最终拿到计算机学位之前，他却是在计算机和音乐中交替学习。似乎Java大师都能够有这样的能耐，另一Java大牛Rod Johnson同样也拥有音乐学的博士学位。Kent Beck一直倡导软件开发的模式定义。早在1993年，他就和Grady Booch（UML之父）发起了一个团队进行这个方面的研究。虽然著有了《Smalltalk Best Practice Patterns》一书，但这可能并不是Kent Beck最大的贡献。他于1996年在DaimlerChrysler启动的关于软件开发的项目，才真正地影响后来的软件开发。这次的杰作就是XP（极限编程）的方法学。和软件开发大师Martin Fowler合著的《Planning Extreme Programming》可谓是关于XP的奠基之作。从此，一系列的作品如《Test Driven Development: By Example》，《Extreme Programming Explained: Embrace Change》让更多的人领略到了极限编程的精髓，也逐步导致了极限编程的流行。Kent Beck的贡献远不仅如此。对于众多的Java程序员来说，他和Erich Gamma共同打造的JUnit，意义更加重大。也许正是这个简单而又强大的工具，让众多的程序员更加认可和信赖极限编程，从而引起了Java敏捷开发的狂潮吧。
摘要: Kent Beck和Martin Fowler撰写了《规划极限编程》（Planning Extreme Programming）一书专门详细阐述了在极限编程（XP）中如何来规划和计划Project，有兴趣的朋友可以在此下载并阅读。在阅读过程中，我也把一些重要的Notes记录了下来，供大家参考。 阅读全文
l 在TDD中，按照Failed -> Passed –> Refactoring的步骤进行，写完Test Case并在写Code或改Code前，应该先运行一下Test Case，这时应得到一个Failed或Error的结果，以确保Test Case不是在任何情况下都会Pass，以确保它确实能验证程序的结果。
l 最好用小步伐的节奏进行TDD。
如果要写的程序有10个function要完成，应该按照以下的方式进行：
写function1的Test Case -> 写function1的Code并使Test Case通过 -> Check-in -> Code Review/FingBug/Refatoring -> Check-in -> 写function2的Test Case…
这样的好处是：
n 每步的范围越小，测试、查错和Roll Back越容易，也有利于最简设计和最简实现。
n 完成的部分完全可交付。
l 以Iteration为单位进行计划（Planning）、开发和跟踪（Tracking）。定义Iteration的原则是：
n Simple：一个Iteration不应能被拆分为Task，如果可以拆分，应考虑继续拆分为若干个Iterations。
n Clear：Iteration的需求/User Story应该是清楚的、确定的。如果一个Requirement Point部分确定，部分未确定，而已确定的部分已可独立开发，应该把确定的部分定义为一个Iteration，减少未确定部分对整个进度的影响。
n Independent：一个Iteration应相对独立，不应与其他部分有太多的依赖。
n Short：一个Iteration不应超过3周。
我们应该结合这4个原则进行Iteration定义。
l 不管是auto test还是manual test，都是testing的手段而已，Testing的有效性取决于Test Case的质量和覆盖率。可以通过以下方法提高Testing的有效性：
n 邀请Customer提供或者和他们一起制定Functional Test Case。
n Pair Programming
n 如果不能进行Pair Programming，也必须在前期和中期与其他同事Walk Through或讨论Test Case，减少遗漏。
l 如果Customer不能配合我们进行短Iteration开发，不妨把Release分为Internal Release和External Release。对外发布按照Customer的要求和步伐，而内部我们按照自己的步伐进行持续集成和测试。
l XP Planning的一个重要原则：
One of the most important principles in planning for Extreme Programming is that the dates are hard dates, but scope will vary.
当Deadline临近，我们已确定无法完成本Iteration计划的全部时，应该及时和Customer沟通，把剩下的部分进行Prioritize，把最重要的、可在Deadline前完成的部分先完成，按时交付，把未完成的部分定义为新的Iteration，并把它和其他所有未开始的Iteration一起进行Prioritize。这样可避免一味延时带来的恶性循环，也可确保整个Project最重要的部分被优先完成，因为很有可能，未完成的部分并不那么重要。