第一章 敏捷就是一個方法和方法論的集合 第三章 Big Requirements Up Front 預先最大需求是不好的 藉由時常交付價值，將變化是為對專案而言是件好事、時常交付軟體，這樣團隊和客戶便可以一邊調整、一邊合作 軟體可以能與原先設計的不同，不過這反而是件好事 獲得回饋的最好辦法就是透過及早交付，即便交付的東西只有一個功能可用，依然是雙贏 及早交付的缺點，交付到客戶手上的第一個版本距離完整版本還非常遙遠。有些用戶和關鍵關係人會真的很難適應 很常發生一個情況，就是某人在明確交代完某件事之後，又告訴你要改變。 竭誠歡迎改變需求的第一步，就是嘗試從客戶的觀點來看待事情。這通常不容易做到，但是非常有啟發性。 詳盡文件和追溯矩陣容易潛伏一些團隊問題，它鼓勵的是「推卸責任」(Cover Your Ass, CYA) 態度 進度報告本身不是那麼好的量測方法，靠可用的軟體來進度量測最好的方法 最大化未完成工作量意思就是，建構一套沒有太多相依性和無用程式碼的系統