第七章 在项目开始之前

36 需求之坑
不为收集需求，挖掘它们。
有一种能深入了解用户需求，却未得到足够利用的技术：成为用户。与用户一同工作，以像用户一样思考。
描述需求文档时，要使用项目术语表。
用WEB来收集和管理需求。

37 解开不可能解开的谜题
遇到不可能解决的问题时，退一步问问自己如下问题：
1）有更容易的方法吗？
2）你是在设法解决真正的问题，还是被外围的技术问题转移了注意力？
3）这件事情为什么是一个问题？
4）是什么使它如此难以解决？
5）它必须以这种方式完成吗？
6）它真的必须完成吗？

38 等你准备好
一件事没有开始，是谨慎？还是在拖延？

39 规范陷阱
需求文档写上几百页不成问题，但是一旦用户看到了实际运行的系统，你就会被各种变更要求淹没。
对有些事情“做”胜于“描述”

40 圆圈与箭头
有些设计图是给程序员看的，对最终用户没有意义，不要认为用上了UML等形式化描述图形就能制作出好的设计。

第八章 注重实效的项目

41 注重实效的团队

不要留破窗户，不要重复你自己，按功能划分团队

42 无处不在的自动化
持续集成的概念

43 无情的测试
早测试，常测试，自动测试

44 全都是写
嵌入在代码中的注释，注释应该讨论为何要做某事、它的目的和目标。

45 极大的期望
给他们的东西要比他们期望的多一点。

46 傲慢与偏见
在你的作品上签名。

第一章 注重实效的哲学
第二章 注重实效的途径
第三章 基本工具
第四章 注重实效的偏执
第五章：弯曲或折断
第六章：当你编码时
第七、八章