第3章 計劃3.1 初始探索 在項目開始時，開發人員會和客戶商討一下關於新系統的情況，以確定出所有真正重要的信息。然而，他們不會試圖去確定所有的特性。隨著項目的進展，客戶會不斷的發現新的特性。特性發現的過程會一直持續到項目完成。 當識別出一個特性時，會把它分解成一個或者多個用戶故事，並把這些用戶故事 ...
第3章 計劃
3.1 初始探索
在項目開始時，開發人員會和客戶商討一下關於新系統的情況，以確定出所有真正重要的信息。然而，他們不會試圖去確定所有的特性。隨著項目的進展，客戶會不斷的發現新的特性。特性發現的過程會一直持續到項目完成。
當識別出一個特性時，會把它分解成一個或者多個用戶故事，並把這些用戶故事寫在索引卡片之類的東西上面。除了用戶故事的 名字之外，無需記錄其他任何內容（比如Login，Add User，Delete User 或者Change Password）。此時，我們不會試圖記錄細節。我們只是希望有些東西能夠提醒我們想起曾經談論過這些特性。
開發人員共同對這些故事進行估算。估算是相對的，不是絕對的。我們在記錄故事卡片上寫上一些“點數”來表示這個故事所需要的相對時間。我們也許不能確定一個“點”代表多少時間，但是我們知道，實現8個點故事所需要的時間是實現4個點的兩倍。
探索、分解和速度
過大或者過小的故事都是難以估算的。開發人員往往會低估那些大的故事而高估那些小的故事。任何過大的故事都應該分解成小一點的部分，任何過小的故事都應該和其他小的故事合併。
例如，考慮下麵的用戶故事：“用戶能夠安全的地進行存款、取款、轉賬活動。”這是個大的故事。對它進行估算將會很困難，有肯能還不准確。然而，我們可以把它分解成以下幾個更容易估算的故事：
- 用戶可以登錄
- 用戶可以退出
- 用戶可以向其賬戶存款
- 用戶可以從其賬戶取款
- 用戶可從其賬戶向其他賬戶轉賬
在分割或合併一個故事時，應該對其重新進行估算。簡單的加上或者減去估算值是不明確的。對用戶進行分解或者合併完全是為了使其大小適於被準確的估算。當一個估算為25點的故事分解為幾個點數總和達到30點的故事時，不要覺得奇怪！30點是更精確的估算。
每周，我們都會實現一定數量的故事。這些已經實現了的故事的估算之和是一種度量，稱為速度。如果我們在上周實現的故事的點數之和為42，那麼我們的速度就是42.
3或4周後，我們就會比較瞭解我們的平均速度。我們可以使用這個平均速度來預測在後面幾周內能夠完成多少工作。在XP項目中，跟蹤速度是最重要的管理手段之一。
在項目開始時，開發人員對他們的速度沒有很好的認識。他們必須給出一個初始的猜測值，在猜測時，可以採用他們感覺會帶來最好結果的任何方式進行。此時並不需要非常準確，所以他們無需在上面花費過多的時間。事實上，做到和保守的憑直覺測試（SWAG）一樣好就足夠了。
3.2 發佈計劃
如果知道了開發速度，客戶就能夠瞭解每個故事的成本及其商業價值和優先順序別。據此，客戶就可以選擇那些想最先完成的故事。這種選擇不是單純依據優先順序別進行的。一些重要的但是實現起來代價高昂的故事可能會被推遲實現，而會先去實現，而會先去實現一些不那麼重要但是代價要低廉得多的故事。此類選擇屬於商務決策範圍。由業務人員來決定哪些故事會給他們帶來最大利益。
開發人員和客戶對項目的首次發佈時間達成一致，通常也就是2~4個月後的事情。客戶挑選在該發佈中他們想要實現的故事，並大致確定這些故事實現順序。客戶必鬚根據當前的開發速度來選擇要實現的故事的數量。由於開發速度開始時並不准確，所以選擇也是粗略的。但是測試選擇的準確性不是非常重要。當開發速度變得準確時，可以在對發佈計划進行調整。
3.3 迭代計劃
接著，開發人員和客戶決定迭代規模，一般是1到2周。同樣的，客戶選擇他們想要的首次迭代中的故事，但是不能選擇與當前開發速度不符的更多的故事。
迭代期間用戶故事的實現順序屬於技術決策範疇。開發人員採用最具技術意義的順序來實現這些故事。他們可以串列的實現，完成一個在完成下一個；或者他們可以分攤這些故事，然後一起並行地開發。這完全有開發人員來決定。
一旦迭代開始，客戶就不能再改變該迭代期內需要實現的故事。除了開發人員正在實現的故事，客戶可以任意改變或重新安排項目中的其他任何故事。
即使沒有實現所有用戶故事，迭代也要在先前指定日期結束。他們會合計所有已經實現的故事的估算值，並計算出本次迭代的開發速度。這個速度會用於計划下一次的迭代。規則很簡單：為每次迭代做計劃時採用的開發速度就是前一次迭代中測算出來的開發速度。如果團隊在最近一次迭代中完成了31個故事點，那麼他們應該計劃在下一次迭代中也完成31個點。他們的開發速度是每次迭代31個點。
這樣的速度反饋有助於保持計劃和團隊實際狀況同步。如果團隊在專業知識和工作技能反面有所提高，那麼開發速度也會得到相應提高。如果有人離開了團隊，開發速度就會降低。如果系統架構朝有利於開發的方向演化，那麼開發速度就會提高。
3.4 定義“完成”
除非所有的驗收測試都通過，否則不能說一個故事實現完成了。這些驗收測試是自動執行的。驗收測試是由客戶、業務分析師、質量保證專家、測試人員甚至包括程式員，在每次迭代開始一起編寫的。這些測試定義了每個故事的細節，並且是判斷故事的行為方式正確與否的決定性依據。
3.5 任務計劃
在新的迭代開始時，開發人員和客戶共同定製計劃。開發人員把故事分解成開發任務。一個任務就是開發人員能夠在4~16小時之內實現的一些功能。開發人員在客戶的幫助下對這些故事進行分析，並儘可能地列舉出所有的任務。
可以在活動掛圖、白板和其它方便的媒介上列出這些任務。接著，開發人員逐個簽訂他們想要實現的任務，並以以隨意的任務點數對每項任務進行估算。
開發可以簽訂任意類型的任務。資料庫專家並非必須要簽訂資料庫相關的任務。如果願意，精通GUI的人員也可以簽訂資料庫相關的任務。看起來好像無法人盡其能，不過會使用一種方法對這種狀況進行管理。這樣做的好處是顯而易見的：開發人員對整個項目瞭解的越多，那麼團隊就會越健康、越有知識。我們希望項目的知識能夠傳遞給每一個團隊成員，即使這種知識是和他們的專業無關的。
每一個開發人員都知道上一次的迭代中所完成的任務點數；這個點數就是開發者的預算。沒有人會簽訂超出他們預算的點數。
任務的選擇一直持續到所有的任務都被分配出去，或者所有的開發人員都已經用完了他們的預算時為止。如果還有任務沒有分配出去，那麼開發人員會相互協商，基於各自的專長交互相應的任務。如果這樣做都不能分配完所有任務，那麼開發人員就要求客戶從本次迭代中去掉一些任務或者故事。如果所有的任務都已經被分配，並且開發人員仍然具預算空間去完成更多的任務，那麼他們會想客戶要求更多的故事。
在迭代進行到一半的時候，團隊會召開一次會議。在這個時間點上，本次迭代中所安排的半數故事應該被完成。如果沒有完成，那麼團隊會設法重新分配沒有完成的任務和職責，以保證在迭代結束時能夠時能夠完成所有的故事。如果開發人員不能實現這樣這重新分派，則需要告知客戶。客戶可決定從迭代中去掉一個任務或故事。至少，客戶可以指出那些最低優先順序別的任務和故事，這樣開發人員可以避免在其上花費時間。
例如，假設在本次迭代中客戶選擇了8個故事，總共24個故事點。同樣假設這些故事被分解成42個任務。在迭代的中點，我們希望應該完成21個任務即12個故事點。這12個故事點代表的必須是全部完成的故事。我們的目標是完成故事，而不僅僅是任務。如果迭代結束的時候90%的任務已經完成，但是沒有一個故事是完成的，這將是惡夢一般的情景。在迭代的中點，我們希望看到擁有一半故事點數的故事被完成。
3.6 迭代
每兩周，本次迭代結束，下次迭代開始。在每次迭代結束時，會給客戶演示當前可運行的程式。要求客戶對項目程式的外觀、感覺和性能進行評價。客戶會以新用戶故事的方式提供反饋。
客戶可以經常看到項目的進展。他們可以度量開發速度。他們可以預測團隊工作快慢，並且可以在早期安排實現高優先順序別的故事。簡而言之，客戶擁有按照他們意願進行管理所需的所有數據和控制權。
3.7 跟蹤
對於XP項目來說，跟蹤和管理就是記錄每次迭代的結果，然後使用這些結果測試後面幾次迭代的內容。
3.8 結論
通過一次次的迭代和發佈，項目進入了一種可以預測、舒適的開發節奏。每個人都知道將要做什麼，何時去做。利益相關者經常地、實實在在地看到項目進展。他們看到的不是畫滿了圖、寫滿了計劃的記事本，而是可以接觸到、感覺到的可以工作的軟體，並且他們可以對這個軟體提供自己的反饋。
開發人員看到的是基於自己估算並且由自己度量的開發速度控制的合理計劃。開發人員選擇自己感覺舒適的任務，並保持高的工作質量。
管理人員在每次迭代總獲取數據。他們是使用這些數據來控制和管理項目。他們不必採用強制、威脅或者懇求開發者的方式去表達武斷的、不切實際的目標。
這聽起來是美好輕鬆的，其實不是這樣。利用相關者對過程產生的數據並不總是滿意，特別是剛剛開始時。使用敏捷開發方法並不意味著利益相關者就可以得到他們想要的。它只不過意味著他們將能夠控制團隊以最小的代價獲得最大的商業價值。
