TOC
1. 初始探索
- 專案開始時，開發人員和客戶只會商討系統的重要的特性，隨專案的進展，客戶會不斷地發現新的特性。當識別出一個特性時，會把它分解成一個或許多個使用者故事，除了故事的名字之外，無須記錄其他內容。
- 探究、分解和速度
- 過大或過小的故事都難以估算，過大的故事應該很解成小故事，過小的應該和其他的合併。
- 例如: 使用者能夠安全地進行存款、取款、轉帳活動。 分解成以下故事
- 使用者可以登入
- 使用者可以登出
- 使用者可以向其他帳戶存款
- 使用者可以從其他帳戶取款
- 使用者可以從其他帳戶向其他帳戶轉帳
- 對使用者故事進行分解或合併完全是為了使其他小適用於"被準確地估算"
2. 發布計畫
- 如果知道了開發速度，客戶就能夠了解每個故事的成本及其商業價值和優先順序。根據這些，客戶就可以選擇那些想要最先完成的故事。此類選擇屬於商業決策範疇，由業務人員決定哪些故事會帶給它們最大的利益。
3. Iteration 計畫
- 規則很簡單: 每次的iteration作計畫時採用的速度，就是前一次iteration中測量出來的開發速度
- 如果團隊在最近一次iteration中完成了31個故事點，那他們應該計畫在下一次iteration中也完成31點。開發速度(velocity)就是31 points/iteration
4. 定義完成 (Demo)
- 除非所有的驗收測試都通過，否則就不能說一個故事實現完成。
- 這些驗收測試是自動執行的，驗收測試是由客戶、業務分析師、品質保證專家、測試人員甚至包括程式設計師，在每個iteration開始時一起撰寫。
5. 任務計畫
- 一個任務(task)就是一個開發人員能夠在4~16小時內實現的一些功能
- 開發人員逐一簽訂他們想要實現的任務，並以點數對每項任務進行估算
- 在iteration進行到一半時，團隊會召開一次會議，此時iteration所安排的半數應該要被完成。如果半數故數沒有被完成，那麼團隊會設法重新分配沒有完成的任務和職責，以確保在能完成所有的故事。
- 如果在iteration結束時，90%任務已完成，但沒有一個故事是全部完成的，這是惡夢一般的情景。
6. 追蹤 (Tracking)
- 對XP專案來說，追蹤和管理就是紀錄每次iteration的結果，然後使用這些預測後面幾次iteration的內容。
- 速度圖 (velocity chart)，顯示在每週結束時，一共完成了多少個故事點。
- 餘量圖 (burn-down chart)，顯示每一周後，還有多少點數需要在下個主要的里程碑或發布中完成。
7. 總結
- 透過一次次iteration和發布，專案進入一種可預測、舒適的開發狀態。每個人都知道將要做什麼，以及何時去作。
- 利益相關者能頻繁且實際地看到專案的進展，他們看到的不是畫滿了圖、寫滿了計畫的記事本，而是可接觸到、感覺得到的可工作軟體，並且對這個軟體提供回饋。
- 開發人員看到的是，基於自己估算並且評估的開發速度控制合理的計畫，選擇自己感到舒適的任務，並保持工作品質。
- 使用敏捷方法並不意味著利益相關者就能得到他們想要的，而是意味著他們將能夠控制團隊以最小的代價獲得最大的商業價值。