标签：
36 需求之坑
不为收集需求，挖掘它们。
有一种能深入了解用户需求，却未得到足够利用的技术：成为用户。与用户一同工作，以像用户一样思考。
描述需求文档时，要使用项目术语表。
用WEB来收集和管理需求。
37 解开不可能解开的谜题
遇到不可能解决的问题时，退一步问问自己如下问题：
1）有更容易的方法吗？
2）你是在设法解决真正的问题，还是被外围的技术问题转移了注意力？
3）这件事情为什么是一个问题？
4）是什么使它如此难以解决？
5）它必须以这种方式完成吗？
6）它真的必须完成吗？
38 等你准备好
一件事没有开始，是谨慎？还是在拖延？
39 规范陷阱
需求文档写上几百页不成问题，但是一旦用户看到了实际运行的系统，你就会被各种变更要求淹没。
对有些事情“做”胜于“描述”
40 圆圈与箭头
有些设计图是给程序员看的，对最终用户没有意义，不要认为用上了UML等形式化描述图形就能制作出好的设计。
41 注重实效的团队
不要留破窗户，不要重复你自己，按功能划分团队
42 无处不在的自动化
持续集成的概念
43 无情的测试
早测试，常测试，自动测试
44 全都是写
嵌入在代码中的注释，注释应该讨论为何要做某事、它的目的和目标。
45 极大的期望
给他们的东西要比他们期望的多一点。
46 傲慢与偏见
在你的作品上签名。
第一章 注重实效的哲学
第二章 注重实效的途径
第三章 基本工具
第四章 注重实效的偏执
第五章：弯曲或折断
第六章：当你编码时
第七、八章
标签：
原文地址：http://www.cnblogs.com/timdes/p/4824129.html
