本书的第五章讲的是“敏捷反馈”，其作者主要从以下几个方面来阐述：
1、 守护天使
a、一些开发者会对单元测试有意见：毕竟，有“测试”这个词在里面，毫无疑问这应该是其他人的工作。从现在开始，忘掉“测试”这个词。就把它看作是一个极好的、编写能产生反馈的代码的技术。
b、使用自动化的单元测试。好的单元测试能够为你的代码问题提供及时的警报。如果没有到位的单元测试，不要进行任何代码设计和代码修改。
c、人们不编写单元测试的很多借口都是因为代码中的设计缺陷。通常，抗议越强烈，就说明设计越糟糕。
2、 先用它再实现它
a、设计的一个重点是：确定什么是成功地实现特定功能的最低成本。程序员很容易走向另一个极端——一些不必要的过于复杂的事情——测试优先会帮助我们，防止我们走偏。
b、先用它再实现它。将TDD 作为设计工具，他会为你带来更简单更有实效的设计。
3、 不同环境，就有不同问题
a、不同环境，就有不同问题。使用持续集成工具，在每一种支持的平台和环境中运行单元测试。要积极地寻找问题，而不是等问题来找你。
4、 自动验收测试
a、为核心的业务逻辑创建测试。让你的客户单独验证这些测试，要让它们像一般的测试一样可以自动运行。
5、 度量真实的进度
a、我们不应该去计算工作量完成的百分比，而应该测定还剩下多少工作量没有完成。不要用不恰当的度量来欺骗自己或者团队。要评估那些需要完成的待办事项。
b、在你最后真正完成一项任务时，要清楚知道完成这个任务真正花费的时间。在为下一个任务估计工作量时，可以根据这次经验调整评估。
6、 倾听用户的声音
a、不管它是否是产品的bug ，还是文档的 bug ，或者是对用户社区理解的 bug ，它都是团队的问题，而不是用户的问题。
b、每一个抱怨的背后都隐藏了一个事实。找出真相，修复真正的问题。
总结：编程的首要出发点是从客户出发，而不是从开发者本身出发，单元测试的目的是为了能够为代码问题作出及时的警报，促使好的代码设计产生。