本章節有不少可借鑑的方法集合
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）