第Ⅰ部分 敏捷開發 第3章 計劃

當你能夠度量你所說的，並且能夠用數字去表達它時，就表示你理解了它；若你不能度量它，不能用數字表達它，那麼說明你的知識是匱乏的、不能令人滿意的——凱爾文勳爵（英國物理學家）
★SLS：看來“可度量”並不僅僅是軟件工程重視的要素。所有科學的一個基本要求之一就是可度量。
下面的內容是對極限編程中計劃遊戲的內容的描述。其他敏捷方法都沒有XP描述如何做計劃詳細。

★3.1初始探索
項目開始會盡力確定真正需要的用戶素材，但不是所有用戶素材，客戶會不斷編寫新的用戶素材，直到項目結束。
開發人員對這些素材進行估算。估算是相對的不是絕對的。我們再素材上記錄單數。雖然不能確定單數代表的時間，但可以確定8點需要的時間是4點的兩倍。
★SLS：在餐飲2.0開始的時候，我就讓同事進行過這類估算。不謀而合啊。呵呵
★探究、分解和速度：
過大過小的素材都是難以估算的。對素材進行拆分和合並的原因就是爲了更好的估算。
估算僅僅是相對大小，如果需要絕對大小就需要一個速度(velocity)因子，既一個點數需要執行的天數。
由於可度量每次迭代完成的素材點數，所以速度的度量會越來越精確。開始可能需要一個猜測值，通過花費幾天的時間去原型化1到兩個用戶素材來了解團隊的速度計足夠了，這樣一個原型化過程稱爲探究(spike)
★SLS：這方面的工作我也坐過。我讓我的組長將所有的任務列出來，並標上因子。這樣我們就知道了我們需要做的所有的工作量，在執行過程中，隨時可以檢查我們的完成百分比。從過觀察執行速度，就可以預計完成時間。可惜，做的不是非常細緻。但基本的想法與這個是一樣的。

★3.2發佈計劃
知道了開發速度，客戶就知道了每個素材的成本。他們也知道每個素材的商業價值和優先級。
開發人員和客戶對項目的首次發佈時間達成一致，通常是2-4個月以後的事。選擇不斷優化選擇的素材，不斷精確度速度因子。

★3.3迭代計劃
開發人員和客戶決定迭代順序一般需要2周。
迭代期間的實現順序屬於技術範疇由開發人員決定是並行實現還是穿行時間，以及順序。
一旦迭代開始，客戶就不能再改變迭代範圍內的需要實現的素材。
即使沒有完成所有的用戶素材，迭代也要在實現指定的日期結束。根據所有素材的估算值，計算出速度因子。這個速度會用於下一次迭代。每次迭代的速度就是前一次測算出來的開發速度。
這個樣的速度反饋有助於保持計劃與團隊實際狀況相同步。專業知識和工作技能提高，系統架構優化，速度會加快。有人離開速度會降低。

★3.4任務計劃
用戶素材->開發任務(4-16小時能夠完成的)=任務計劃。
選擇的任務與其專長無關，從而保證知識的官方傳播。
早完成則多要任務，晚完成則要求去掉任務。
★迭代的中點
迭代進行到一半時，團隊召開會議，檢查是否有一半的任務被完成。如果沒有完成一半，則要求用戶去掉素材，或劃分優先級，先做重要的。

★3.5迭代
兩週一迭代，結束既開始下次迭代。迭代結束要給客戶演示，客戶對外觀、感覺和性能進行評價。以用戶素材的方式提供反饋。
客戶可以看到項目進展，度量開發速度。預測進度，安排優先級。總之他們擁有所有數據和控制權，可以按照他們的意願管理項目。

★3.6結論
★SLS：從時間規模上看發佈計劃(2-4個月)>迭代計劃(2周)>任務計劃(4-16小時)
通過一次次迭代和發佈，項目進入可以預測的、舒適的開發節奏。涉衆經常看進展，獲得可工作的軟件並提供反饋。而不實圖表記事本。
開發人員看到基於自己估算並且由自己度量的開發速度的合理計劃。
管理人員從每次迭代中獲得數據，使用數據控制和管理項目。他們不必採用強制、威脅、懇求開發人員達到一個武斷的不切實接的目標。
雖然這聽起來很美好，但實際並不是這樣。涉衆對產生的數據並不滿意，特別是初期。這只不過意味着他們能夠控制着團隊以最小的代價獲得最大的商業價值。
★SLS：本章要點：速度因子的計劃方式，發佈計劃，迭代計劃，任務計劃的計劃體系。