第 1章 為什么需要有計劃？ 1
我們希望始終在做最重要的事情, 能很好地和其他人合作, 并且能快速地對意外事件作出反應.
第 2 章 擔心 7
軟件開發(fā)是有風險的, 有關人員非常擔心什么可能會出錯. 為了有效地進行開發(fā), 我們必須承認這一事實（這些擔心）.
第 3 章 控制軟件開發(fā) 11
我們用開車來比喻開發(fā)軟件. 開車不是簡單地把車對準一個方向, 然后保持方向不變, 開車需要時不時地做些小調整.
第 4 章 平衡職權 13
我們的計劃過程取決于能否明確地把業(yè)務人員和軟件開發(fā)人員的作用區(qū)分開來. 這樣確保由業(yè)務人員做出所有的業(yè)務決策, 由軟件開發(fā)人員做出所有的技術決策.
第 5 章 概 述 19
XP過程不盡相同, 有的版本需要幾個月的時間, 有的需要分為若干個為期兩周的迭代, 有的需要分為若干個為期幾天的任務. 計劃能根據(jù)開發(fā)工作的實際情況, 把各個故事（功能集合）分配到不同的版本和迭代中.
第 6 章 任務太多 23
當你超負荷工作時, 不要想沒有足夠的時間, 而要想要做的事情太多. 你無法給自己更多時間, 但是你可以讓自己少做一些, 至少目前如此.
第 7 章 四個變量 25
我們使用四個變量來幫助我們考慮如何控制一個項目：成本. 質量. 時間和范圍. 它們互相聯(lián)系, 但是以奇特的方式彼此影響.
第 8 章 昨天的天氣 33
作為計劃的基礎, 假定你這周要做的工作同上周一樣多.
第 9 章 劃定項目的范圍 37
若要快速知道項目的大小, 請對計劃過程進行大致的分解.
第 10 章 發(fā)布計劃 43
在發(fā)布計劃過程中, 客戶選擇幾個月的故事, 并且通常集中于公開發(fā)布的那部分.
第 11 章 編寫故事 49
在XP項目中故事是功能的單位, 我們通過交付經(jīng)過測試并集成的用于實現(xiàn)故事的代碼來說明進度. 故事對于客戶和開發(fā)人員應該是可以理解的. 可測試的. 對客戶有價值的. 并且應足夠小以便程序員可以在一次迭代中生成半打故事.
第 12 章 估 算 61
將故事估算建立在已完成的相似故事的基礎之上, 該故事與可比故事花費的時間相同.
第 13 章 對故事進行排序 67
首先執(zhí)行的最重要的故事是那些包含最高商業(yè)價值的故事, 注意在對故事進行排序時應以技術依賴關系為依據(jù). 通常情況下, 依賴關系的重要性低于價值的重要性.
第 14 章 發(fā)布計劃事件 75
各種事情的發(fā)生使得團隊不得不制訂一個小型的發(fā)布計劃. 客戶添加和更改故事的優(yōu)先級, 開發(fā)人員對故事進行評估, 而團隊則應注意要做的事情太多還是太少.
第 15 章 第一個計劃 79
第一個計劃是發(fā)布計劃中最困難, 精確度最低的部分. 不過好在這樣的計劃只需制訂一次.
第 16 章 發(fā)布計劃變化 85
對發(fā)布計劃做一些局部的變化就是較短發(fā)行周期. 較長發(fā)行周期和較短故事.
第 17 章 迭代計劃 89
每次迭代都是通過將迭代的故事分解為任務來計劃的. 任務是這樣調度的：讓程序員申請自己想要的任務, 再讓他們評估自己的任務, 如有必要, 再重新衡量.
第 18 章 迭代計劃會議 93
在迭代開始時, 團隊創(chuàng)建迭代計劃. 這個計劃將迭代分解為幾個數(shù)天的開發(fā)任務, 每個任務都有專門的程序員來負責.
第 19 章 跟蹤迭代 103
跟蹤者一周檢查兩次迭代的進度情況, 看看事情進行得如何.
第 20 章 站立會議 115
每天都開一個短會, 讓每個人都知道哪些事情正在進行, 哪些還沒有進行.
第 21章 可視圖 117
任何人都可以通過查看關于團隊工作內容的一些圖表來了解項目所處的狀態(tài).
第 22 章 處理錯誤 123
將錯誤修復安排在故事中, 因此客戶可在修復錯誤和添加更多功能之間進行選擇.
第 23章 團隊的變化 127
團隊的改變將如何影響你的計劃呢？
第 24 章 工 具 131
堅持使用簡單工具, 如鉛筆. 紙和白板. 對成功而言, 溝通比奇才更重要.
第 25 章 商業(yè)合同 133
如果你準備用XP來計劃并執(zhí)行一個項目, 就要對傳統(tǒng)的商業(yè)合同稍加調整.
第 26章 危險信號 139
這里有一些我們不只一次見到并希望解決的危險情況.
第 27 章 你自己的過程 143
不要期望任意兩個XP會作完全相同的事, 只要你熟悉了它的基本過程, 就會使其漸漸變得更加適合你自己的情況.
鄂公網(wǎng)安備 42010302001612號 