文档介绍：图 1
这两个圆圈表示不同的视角上的敏捷实践，包括开发者视角和项目管理的视角。接下来从里向外进行介绍，
因为有些实践我了解得不清楚，如果下面有哪些说得不对的地方也请大家指出。
Test-Driven Devctoring，重构。相信大家对它都很熟悉了，有很多很多的书用来
介绍重构，最著名的是 Martin 的《重构》，Joshua 的《从重构到模式》等。重构是在不改变系统外部行为下，对
内部结构进行整理优化，使得代码尽量简单、优美、可扩展。在以往开发中，通常是在有需求过来，现在的系统
架构不容易实现，从而对原有系统进行重构；或者在开发过程中有剩余时间了，对现在代码进行重构整理。但是
在敏捷开发中，重构贯穿于整个开发流程，每一次开发者 check in 代码之前，都要对所写代码进行重构，让代码
达到 clean code that works。值得注意的是，在重构时，每一次改变要尽可能小，用单元测试来保证重构是否引起
冲突，并且不只是对实现代码进行重构，如果测试代码中有重复，也要对它进行重构。Pair-Programming，结对编程。在敏捷开发中，做任何事情都是 Pair 的，包括分析、写测试、写实现代码或
者重构。Pair 做事有很多好处，两个人在一起探讨很容易产生思想的火花，也不容易走上偏路。在我们公司，还
有很多事都是 Pair 来做，比如 Pair 学****Pair 翻译，Pair 做 PPT，关于这个话题，钱钱同学有一篇很有名的文章
对它进行介绍，名为 Pair Programming (结对编程)。
Stand up，站立会议。每天早上，项目组的所有成员都会站立进行一次会议，由于是站立的，所以时间不会
很长，一般来说是 15-20 分钟。会议的内容并不是需求分析、任务分配等，而是每个人都回答三个问题：1. 你昨
天做了什么？2. 你今天要做什么？ 3. 你遇到了哪些困难？站立会议让团队进行交流，彼此相互熟悉工作内容，
如果有人曾经遇到过和你类似的问题，那么在站立会议后，他就会和你进行讨论。
Frequent Releases，小版本发布。在敏捷开发中，不会出现这种情况，拿到需求以后就闭门造车，直到最后才
将产品交付给客户，而是尽量多的产品发布，一般以周、月为单位。这样，客户每隔一段时间就会拿到发布的产
品进行试用，而我们可以从客户那得到更多的反馈来改进产品。正因为发布频繁，每一个版本新增的功能简单，
不需要复杂的设计，这样文档和设计就在很大程度上简化了。又因为简单设计，没有复杂的架构，所以客户有新
的需求或者需求进行变动，也能很快的适应。
Minimal Documentation，较少的文档。其实敏捷开发中并不是没有文档，而是有大量的文档，即测试。这些
测试代码真实的反应了客户的需求以及系统 API 的用法，如果有新人加入团队，