00.釋出計劃很重要原因：

　　a.她可以幫助產品所有者和整個開發小組判斷他們在獲得一個可釋出的產品之前，必須花多長時間開發多少東西。產品越早釋出，開發公司就可以越早開始獲得他在此專案中投資的回報

　　b.釋出計劃傳遞了對於在多長時間內可能開發什麼內容的期望。很多公式需要這個資訊，因為它可以用於其他的戰略規劃活動

　　c.釋出計劃可以作為專案小組前進的路標。如果沒有釋出的概念，開發小組就會無止境地從一個迭代走向另一個迭代。

01.規劃一次釋出的部分工作是確定什麼時候可以完成多少功能。

02.在進行釋出規劃時，我們並不想建立一個計劃，指出將由哪個開發人員負責哪個使用者故事或哪項任務，或者支援迭代中按什麼順序完成任務。在釋出規劃時建立那種細節水平上的計劃是危險的，而且會產生誤導。

03.要記住釋出計劃中的物件是使用者故事，他們是對要交付的功能的說明，而不是要執行的獨立的開發任務。在進行釋出規劃時，要吧使用者故事分解成開發任務還為時過早，而且對某些使用者故事的理解也不充分。

04.日期驅動(date-driven)的專案就是必須在特定日期釋出，實現的功能可以協商的專案。而功能驅動(feature-driven)的專案則是我們希望能今早釋出，但是某組功能的實現更為重要的專案。

05.產品所有者必須確定他想開發的功能的優先順序。好的產品所有者會承擔確定優先順序的最終責任，但是會考慮開發小組的成員建議，尤其是有關開發順序的建議。

06.釋出計劃是一個很好的高層次檢視，顯示了開發小組如何試圖交付他們能夠完成的最有價值的產品。

07.迭代計劃是在迭代規則會議上制定的。產品所有者、分析員、程式猿、測試人員、資料庫工程師和使用者互動設計師等人都應該參加這個會議。把原始想法轉變成功能的工作中所需設計的所有人員都應該參加這個會議。

08.

09.在我們一起來看要在迭代規劃中完成的事情之前，重要的是先澄清一件不會完成的事。規劃一次迭代時，任務不會分配給特定的個人。在迭代開始時候，睡將負責哪項任務可能會顯而易見；但是，根據小組整體相對整個任務集的進度，一開始顯而易見的事也許不會在迭代中發生。

10.在小組成員抱有“我們是一個整體”的態度時（小組成員會相互彌補其他人為完成的工作，並且知道別人對自己也會這麼做），專案才會完成得最好。如果個人在迭代開始時就簽訂任務，這種做法與為達到迭代目標而做出統一的承諾是矛盾的。

11.釋出計劃是對整個產品釋出過程的展望，通常是從新專案啟動開始3-6個月的時間。與之相對，迭代計劃知識對一次迭代的展望，通常是2-4周的時間。在迭代計劃中，釋出計劃中的使用者故事分解成了任務。對迭代計劃中的使用者故事進行估計時採用的是故事點或者理想日，而對迭代計劃中的人物進行估計則是採用的理想小時。

12.迭代規劃的主要目標是對粒度較粗的釋出規劃中建立的嘉定進行細化。

13.通過這些討論，開發小組可以更好地理解應該和將要構建什麼東西，他們還會建立為了達到此次迭代ide目標所需完成任務的列表。

14.速度驅動迭代

15.使用者故事和主體的優先順序是根據它們對產品的經濟價值、它們的成本、小組可以學到的內容的量和重要性，以及減少的風險量來確定。

16.速度驅動的迭代規劃中的下一步是確定開發小組的目標速度。在得到了優先順序和目標速度之後，開發小組需要確定他們在迭代中想要達到的目標。這個目標簡要地說明了這次迭代期間他們想完成的工作。

17.儘量明確直到養成習慣

　　新的敏捷開發小組往往不熟悉或者不能熟練編寫自動化的單元測試。不過，在最初的幾次迭代中，他們就可以逐漸培養出這一技能。

　　您需要為與專案有關的會議確定、估計幷包含相應的任務。對會議進行估計的時候，一定要考慮所有參與者都需要花時間，還要考慮用於準備會議的時間。

　　敏捷開發小組的目標之一是在發現故障（bug）的迭代中就修復它們。

18.如果有負責這項工作的人做出估計，他的自豪感和自尊心可能會妨礙他在以後承認做出的估計不正確。如果估計是共同做出的，就不會存在這種對承認錯誤的不情願。

19.承諾驅動是規劃一次迭代的另一種方法。承諾驅動的迭代規劃包含許多與速度驅動的迭代規劃相同的步驟。但是，她不是使用“昨日天氣”的方法來確定子啊當前迭代中應該規劃多少個故事點理想日，而是要求開發小組吧使用者故事逐個新增到迭代中，直到他們無法承諾完成更多的故事。