《重構極限程式設計》CH01

進度沖突：

開發人員宣稱進度表太過理想化，以緻他們無法在許諾的時間完成，管理人員們設定了富有挑戰性的傳遞日期，導緻開發團隊會錯過進度，而要客戶取消釋出時間科就是白日做夢。

真正的問題不是經理人沒有把問題做好，而是整個産業還沒有明白如何将軟體項目管理好。

真正的原因是其中存在着巨大數量的不确定因素，系統非常複雜的。如何複雜？

進度安排的規則：

特征讓步于進度，進度讓步于品質，我們可以因為保證品質而錯過進度，但決不因為增加功能而導緻錯過進度。保證進度時可以削減掉軟體的特征，而為了保證軟體的品質可以讓進度讓步。

品質的含義就是可以精确的定義品質，如項目進度，我們将更好的了解必須完成的東西，當我們進行代碼的編寫工作時，将根據可接受的關鍵缺陷數、重大缺陷數以及次要缺陷數（依次對每一個進行詳細的定義來确定品質水準）。

僅僅說明高品質是不夠的，必須通過這些項的值來精确地說明，必須使用可以被度量的事物來描述你的定義。更多的度量可以有更多的收益。通過對産品的魯棒性的度量，可以獲得更健壯的産品。

《重構極限程式設計》CH01

XP在其本質上是高風險和脆弱的。并且易于導緻某些失敗的模式，隻适合用于非常少量的項目。

何為"更安全的過程"？

XP的中心前提：由XP的作者提出Kent Beck："軟體工程的一個通用假設就是變更項目的成本将随時間指數地上升"。使用XP的軟體開發商試圖更早地得到設計需求和設計權利。

XP的中心技術前提是由于變更成本曲線被平坦化；所有XP的實踐将有效的工作。

這個理論旨在解決下面的問題：對于傳統的軟體工程項目，項目中的變更越遲發生，變更的代價越高。

從理論上來說，如果XP能夠解決上述問題，那麼XP在後期添加新功能會降低成本，是以XP應當可行。

XP由四個事件集定義：價值、實踐、活動和角色。

四個價值如下：溝通，XP認為口頭交流是最具表現力的溝通形式；簡單，總是嘗試做可能使工作最簡單的事，但是簡單并不總是最佳的解決方案，非功能性需求（如高可用性）極大地影響設計；回報，使用格雷發明計算機的例子，一點點回報能替換大量的分析工作。這裡強調的是開發人員與客戶的雙向回報，這樣客戶可以操縱項目；勇氣。

十二個實踐清單：測試驅動的開發（單元測試和使用者測試（即代碼接受測試））、計劃遊戲、整體團隊（現場客戶）、小型釋出、隐喻、簡單設計、毫不寬容地重構，集體所有權、結對程式設計、持續內建、可持續進度（每周工作40小時）、編碼标準。

其它沒有提及的XP實踐包括緊急結構設計，和同處一地的團隊。