1. P3 在實作敏捷開發的程序中，團隊碰到的問題通常都很少用文字記載下來，所以每一個受挫的團隊都認為，自己遇到的問題比較特殊，而這些理念無法在他們的「現實世界」裡發揮作用。
2. P5 比爾·蓋茲說過：「在企業中應用任何一項技術時，首要的法則是，在有效率的系統中導入自動化，將使效率倍增。第二條法則是，在缺乏效率的系統中導入自動化工具反而導致他們的程序更於低效。」
3. P7 Eric Evans 跟別人爭論說敏捷作為一個術語已經失去了一切意義，因為現在什麼都可以稱為敏捷。(skillsmatter.com/event/design-architecture/ddd-exchange-2010)
4. P8 一個好的名稱能夠將預期的結果說明的更好，而且還能清楚指出這些實踐作法的關鍵差異。
5. P13 變化速率如此之高，說明文件總是很快就過時。不斷更新詳細的Spec.(Specification，需求規格)和測試計畫(Test Plan)需要投入大量精力，相當浪費。以此維生的人們(例如：業務分析師或測試人員)，在這個每周更新的環境中經常會無所適從。
6. P23 加快循環並不能避免錯誤。
7. P31 許多團隊在開始實作軟體之前(在此之前所發生的一切往往會被軟體開發團隊所忽略)，總期望客戶、產品負責人或商務使用者能先確定工作的範圍。...若軟體交付團隊依賴客戶給出使用者故事(user story)、使用案例(use case)清單或其他相關資訊，那麼他們其實是在『讓客戶設計解決方案』。但是商務使用者不適軟體設計師。如果我們讓客戶去界定範圍，專案就無法從交付團隊已有的知識中獲益。這樣開發出來的軟體是客戶所要求的，『卻步是他們真正想要的』。
8. P31 成功的團隊不會盲目地接受軟體需求，並將其當作是未知問題的解決方案，相反的，他們會從目標中獲取範圍。他們以客戶的業務目標為起始，接著經由協作來界定可以達成的目標範圍。團隊與商務使用者一起工作確定解決方案。商務使用者則專注於傳達所需功能中希望達到的目的，以及他們期望由此帶來的價值，這樣有助於所有人了解所需的功能。然後再由團隊提議一個解決方案，這要比商務使用者想出來的方案更實惠、更快，並且更容易交付或維護。
9. P31 設計Spec.的階段，如果開發人員和測試人員都沒有參與，我們就必須單獨將Spec.傳達給他們。這在實踐上會很容易造成一些誤解，尤其是資料遷移期間會遺失很多細節。...成功的團隊不會依賴某個獨自去收集正確的Spec.，而會與商務使用者一起協作制定解決方案。
10. P32 過多的細節會讓實例更難溝通和理解。有用的關鍵實例必須要精簡。...提煉好的實例可以當作交付的驗收標準。只有當所有實例在系統中都可以正常工作時，開發才算完成。
11. P36 可執行的Spec.可以很容易地驗證系統。如果能頻繁地驗證就能信任可執行的Spec.，就如同信任程式碼一般。
12. P36 最成功的團隊部會滿足於頻繁驗證一組可執行的Spec.。他們能確保Spec.清楚明確，便於尋找和獲取，而且還具有一致性。...Living documentation(活的說明文件)對於系統功能而言，是個可靠且權威的資訊來源，任何人都能夠讀取它。
13. P37 商業目標是專案或專案里程碑的潛在原因。它是指導企業專案關係人(無論是內部的還是外部的)決定是否投資軟體開發的因素。商業組織應當能清楚地看到這些目標能如何賺取、節省或保障財富。....可衡量的目標能夠確認專案的成敗、追蹤進度和改善優先順序的排序。
14. P39 當整個使用者故事完成時，需要進行首次驗證來確保其確實完成，並重組Spec.證實它和已時做功能的Spec.一致。
15. P43 注重編寫和執行測試的團隊往往會編寫出不易維護的測試。隨著時間的推移，許多問題會迫使這類型的團隊去尋求制定測試並將測試自動化的方法，以便讓測試更容易更新。
16. P84 從目標中獲取正確範圍的好方法之一，就是堅定不移地把提供解決方案的責任交付給開發團隊。
17. P85 我們應該詢問高層次的實例，來說明某個功能要如何產生實際價值，而不是去詢問技術上的功能Spec.。這才能指引我們找到真正的問題。
18. P86 有時候，要人們解釋某個功能的價值時，仍會發生困難(即便可能僅是要求提供實例)。更進一步，我會請他們舉例說明，如果系統不提供某個功能，他們該怎麼辦(臨時解決方案)。通常這會幫助他們表達出特定功能的價值。
19. P86 較低層次的Spec.和測試可以告訴我們已經交付部分的邏輯是否正確；而較高層次的驗收測試則可以告訴我們那些部分的元件是否按預期方式工作。
20. P93 讓團隊全體參加大型的『Spec.的Workshop』是建立共識並獲取可解釋功能之實例最有效的途徑之一。
21. P94 《Practices for Scaling Lean and Agile》一書中，Bas Vodde和Craig Larman建議PBR的Workshop應該佔每個Iteration中 5%~10%的時間。
22. P95 若領域的邏輯很複雜，程式設計師和測試人員需要頻繁釐清，...。《Agile Testing》一書中提到一個類似的協作模型，叫做「三個人的力量」。...舉辦小型的Workshop，由一個開發人員，一個測試人員和一個業務分析師參與。...想要有效地舉辦一場「神勇三劍客」會議，與會的三個人必須在該領域上有相似的理解。如果他們沒有達到相似的理解，可以考慮讓大家在會前做好準備，而不是隨時舉辦。...「神勇三劍客」會議的結果是一份實際的功能檔案--Given-When-Then。
23. P105 確定初始的實例能說明我們獲得Spec.的基本結構，並可以讓討論更有效率。
24. P113 舉例說明，範例必須精確、範例必須完整、範例必須真實、範例應該易於理解。
25. P129 Edward Jay Epstein，The Diamond Invention：「原鑽飾無光澤的、半透明的晶體，類似於玻璃碎片。為了加工成首飾，必須把它切割成特定的寶石形狀，再一面一面的拋光。」
26. P130 成功的團隊不會直接使用原始的例子，他們會從中提煉Spec.(Refining the specification)。他們會從關鍵實例中提取精華，將其轉化成清楚且明確的定義，並去除不相關的細節，讓實作變得完整。
27. P130 附帶實例的Spec.即為驗收測試。一個良好的Spec.，再與實例結合後，其實就是有效的驗收測試所描述的功能。
28. P142 Spec.只需列出關鍵且具有代表性的實例。這有助於Spec.保持簡短易懂。關鍵實例通常具備以下特點：
- 它是一個具有代表性的實例，其描述了業務功能中的每一個重要觀點。通常商務使用者、分析師或客戶會對其進行定義。
- 它會描述每個重要技術的邊緣情況，例如：技術上的邊界條件。通常當開發人員擔心功能分期或不一致時，他們會使用這類的範例。商務使用者、分析師或客戶則會對其定義正確的預期行為。
- 它會描述愈其實作中每一個棘手之處，例如，過去曾導致缺陷的情況，或以前的實例中未描述清楚的邊界條件。通常測試人員會列舉出這種範例，而商務使用者、分析師或客戶則會定義其正確的行為。
29. P144 在需求規則中使用「Given-When-Then」語言，目的為讓測試更容易理解。一般來說，一個Spec.應該要聲明背景環境，指定一個單一的動作，接著定義預期的後置條件。...Given-When-Then市定易系統行為的一種常見格式，它由早期關於BDD的文章推廣而來。它要求我們分成3個部份來編寫系統行為的場景：
- 假設(Given)一個前提；
- 當(When)某個行為發生時；
- 接著(Then)後置條件就會得到滿足。
