本章节有不少可借鉴的方法集合
1、对编制文档的建议：
1》不要要求需求完美、设计文档与代码保持同步或项目计划与项目状态匹配。
2》反而要求需求收集者捕捉到足够与设计师沟通的需求。要求他们在可能的地方用较快的沟通媒介替代文档录入，包括亲自交谈和视频短片交流。
3》如果设计师碰巧都是专家并且能相互做得很近，那么应该要求在白板草图上分发设计文档，用相片或可打印白板保存草图。
4》要记住，会有另外的人加入到这个设计团队，这些人确实需要更多的设计文档。
5》让项目按照并行的资源竞争的线索进行，而不要强制它按照项目开发过程的线性路径进行。
6》对于充分达到这两个目标的方式，要尽可能地有创新精神，避开那种不切实际的追求完美。
7》找到用于这种情形的尽可能最轻最宽松的方法集。确保它只要足够严格足以沟通真正达到充分就行了。（P193）
2、把敏捷当作一种态度，而不要当作一个公式。（P210）
3、我们预料到了不确定性，而且通过迭代、预测和自适应来管理不确定性。（P217）
4、对于每个项目，计划不充分都会产生某种类型和数量的损害；而设计过度也会产生某种类型和数量的损害。（P235）
5、CMMI与敏捷方法集之间的关键差别：敏捷方法集关注于项目级，而CMMI关注于组织级。当然，另外还存在哲学上的可以讨论的差别，但我们必须首先重视的是它们在目标不同。
敏捷运动解决的问题是：我们如何让这个项目的软件能很好的交付出来？
CMMI运动解决的问题是：组织在做到它想要做到的程度如何？在那些他们认为应该共用的方面，不同小组共用的程度如何？他们是否培训那些新加入的人按照本组想要的方式做事，等等。
XP没有包含任何关于“如何培训XP教练”或“如何检测人们在结对编程或重构”的规则。而这些正是CMMI要求组织去考虑的问题。（P257）
6、人，作为一个装置，特别擅长于接受很多来自不同渠道的低品质的模拟信息，并用感觉或情绪的陈述来对它们进行总结。因此，当有人说他们对于项目状态感到“焦虑”或是最近一次迭代的沟通模式感到“不舒服”时，实际上他们说出了很多东西，即便是他们当时不能提供出数字值或细节。团队必须对感到不舒服这一事实予以关注。（P258~259）
7、Crystal的核心哲学是：把软件开发看成是创造和沟通的合作博弈会很有用，这一博弈的首要目标是交付有用、可工作的软件，次要目标是为下一次博弈做好准备。
这一哲学的两个结论：不同的项目需要按不同的方式运行，人们需要进行的建模数量和沟通数量就是它们共同使这一博弈向前发展所需的数量。（297）
8、Crystal方法集围绕的是频繁交付、紧密沟通和反思式的改进。（P309）
9、理论依赖于抓住真实世界中的情形和事件之间的某种类似性，这种依赖关系解释了为什么“某些拥有理论的人能够掌握某些知识，但他们却不能用规则的词汇把这些知识表达出来”。比如人脸，酒的滋味。（P344）