計畫遊戲。
作為乙個最不專業的解釋，計畫遊戲就是在現場客戶、開發人員、相關負責人員的參與之下，分解、分配和估計任務的活動。之所以可以稱之為遊戲，因為這個活動充滿了遊戲性：由客戶編制一些「故事卡片」，並初步標明一些優先順序，用於描述自己的需求，然後開發人員估計它們；客戶可以選擇自己最想要實現的「故事」是哪些，並和開發人員一起商定能夠實現的時間，開發人員通過不斷的優化對故事的任務分解和協調每個人具體的任務來盡可能滿足客戶的要求。每個開發人員都有選擇任務的權利，實際上，任務在最開始都應該是自主選擇的，而不是強制指定的，就算選擇任務的人並不是「最適合」的人。不過為了滿足客戶的一些急切的願望，引導者應該能夠兼顧興趣和效率之間的關係。
根據比較官方的說法，計畫是持續的、循序漸進的，每2周，開發人員就為下2周估算候選特性的成本，而客戶則根據成本和商務價值來選擇要實現的特性。不過實際操作中，到底要計畫到什麼程度倒可以由引導者來指定，例如，發現任務提前快完成了，當然應該就可以準備下一步要做的事情了。
在演練計畫遊戲中，我是作為現場客戶存在的，我今天說的故事比較簡單，就是我們專案中的一些前期分析的工作（嗯，其實準確來說，我不是在說故事，而是直接開始指定任務並要求分解了，但作為演練應該還是夠了）。大家分解這個任務，並把小的任務寫在白板上，每個人每選乙個任務就對它進行一次估計，一會就分解完成。xp裡面推薦的估計方法是通過「點數」來算的，但這個似乎比較難操作，所以我們是通過「
理想工作小時數」來估計的。每個人每天有4個小時的理想小時，然後想想自己如果專心致志的做這個任務需要多少個小時。這個演練要持續一天，所以每個人能夠做的就只有4個小時的事情，當選完4個小時之後也就是用完自己所有可用的時間，這樣也就不能再多選了。另外，還需要為任務分級，這是從開發的角度上進行的估計，分為任務的
架構意義、
風險和重要性三項，每項有1到3的權值，3為最高。當所有任務分解完畢，而大家手上還有空閒時間，那麼我們就可以請求客戶增加任務（嗯，這種情況比較少）；當所有時間分配完畢，而還有任務沒人認領，那麼我們就要考慮重新調整任務的認領人來獲得更多空餘時間，或需要和客戶交流適當把一些低優先順序的任務刪減掉，保證總時間點在忍受範圍內。
由於這只是乙個演練，所以事情很簡單也很順利，我們恰好分解完所有任務，然後興致勃勃準備投入到明天的工作中去。（噢，原來今天結束了啊！
）[1] craig larman，敏捷迭代開發：管理者指南，中國電力出版社，2004
[2] alistair cockburn，敏捷軟體開發，人民郵電出版社，2003.11
軟體開發中的理想與現實（引子）
軟體開發實在不應該是乙個令人厭惡的工作，而更應該像一種藝術家的創作，充滿新意和樂趣。可是，我看過不少軟體開發者卻一直在寫另自己都厭惡的 做連自己都不敢正視的測試，最後在專案完成時長嘆一口氣，將自己的成果束之高閣 不敢再碰。造成這種窘境的根源在 是誰讓開發人員做出連自己都感到厭惡的東西？答案是多樣的，...
軟體開發中的理想與現實（十三） 新的培訓即將開始
2月25日是非常值得紀念的，我們花了乙個星期實現了乙個最小的系統。雖然一切的設計還都非常原始，很明顯有不少值得改進的地方，但我們確實已經實現程式的框架，並能夠生成一些小東西了。這真的很令人振奮！大家都從測試先行和迭代開發中嘗到了甜頭，每日會議也不會那麼拘束了，每天都會感覺有所收穫。這種感覺令人著迷，...
軟體開發中的理想與現實（三） 用重構來清掃戰場
2月17日的早晨非常寒冷，就算躲在被子裡也可以清楚地感覺到，不過到實驗室就不會覺得冷了 嗯，有空調就是好啊 所以，我很早就來了。重新檢查大家的 我有種想重寫的衝動 呵呵 不過這正合我意，因為今天的工作就是清掃戰場，做清掃的人當然是大家。首先我把需要修改的內容列一下 在算prime的時候沒有採用最優化...