In preparing for battle I have always found that plans are useless, but planning is indispensable - 德懷特·大衛·艾森豪威爾。
艾森豪威爾，在第二次世界大戰期間，擔任盟軍在歐洲的最高指揮官，同時也是美國第34任總統。他有不少經典的名言，這句話的意思翻譯過來就是：計劃書往往是無用的，但是計劃的過程是不可缺少的。
艾森豪威爾的這句話，是很多文章裏用來引述“計劃”的名言，我也不能免俗。
我個人對《人月神話》這本書有着很強的執念，早期堅信軟件天生就有易變性，不可見性，軟件的計劃都是沒有什麼實際意義的。但是時間累積後，我也終於悟出來，其實做計劃的過程是關鍵。
迭代計劃的初心
- 團隊全員對接下來的迭代要做哪些UserStory、每個UserStory的責任人達成一致
- 團隊成員對本輪迭代的完成標準，計劃的開始結束時間達成一致
- 團隊成員更認真的對待自己充分參與過的承諾。
一張圖看懂迭代計劃：
本文，我們使用產品經理和開發團隊Leader這兩個角色名。這兩個角色是目前互聯網企業和軟件產品企業常用的角色名。產品經理負責產品的定義、規劃和需求，開發團隊Leader負責帶領整個團隊完成需求的交付和上線。
迭代會議的預先準備階段
比較強烈的建議1:產品經理應提前將特性、大顆粒的需求細化爲單個迭代可以交付的多個UserStory。這是一個避免產品經理被拍磚的良心建議，你如果拿着“我要做一個社交功能”的所謂Story去迭代規劃，估計場景會有點尷尬。其實迭代Backlog裏面裝的只能是UserStory（有時候也可以裝上個迭代的遺留Bug）。
比較強烈的建議2：產品經理和開發團隊Leader，提前從產品Backlog中挑選接下來迭代可以交付的UserStory的備選。產品經理對需求的價值、優先級和期望交付的時間比較清楚，而開發團隊的Leader通常對於需求交付的技術依賴，團隊的能力，團隊的人力管道容量比較清楚。產品經理和開發團隊Leader互相交互意見，挑選出預期應該放到下個迭代交付的UserStory，也可以叫做備選的迭代Backlog。
這個階段，備選UserStory的工作量也應該做一個初略的估計，這個時候就是資深開發Leader和小白的區別了。同時產品經理也應該將備選的UserStory都標明優先級，比如使用Must-Could的方法，必須做的，可以做的，對應中文也也就是高優先級和中優先級。便於後面根據人力實際容量選擇最終的迭代交付內容。
一般的迭代會議指導中，並沒有特別提到這個預先準備階段。之所以筆者特別強調，是因爲，在華爲之前的實踐中，直接進入迭代會議，會出現產品經理和團隊成員耗費大量的時間，從產品Backlog中，確認哪些UserStory可以放到這個迭代中，迭代計劃會議通常是全員參加的，這樣會導致耗費全員大量的時間，特別低效。
之前在華爲內部，有過一種思路，覺得產品經理無需和進行溝通，直接指定優先級和計劃時間就可以了，開發團隊無條件執行。這是強產品經理導向的，但是正如網上經常看到的段子一樣，這樣容易導致產品經理和開發人員矛盾激化，“動手拍磚”。
我們還是認爲，產品經理和開發團隊應該有一個雙向的溝通和理解，有些需求可能確實存在技術的難度。
比較強烈的建議3：開發團隊Leader應該預先了解團隊接下來迭代的人力容量，是不是有同學可能要請假，是不是有同學要調動到其他工作等等。上個迭代團隊的人力容量是多少，接下來的迭代團隊是不是有一些架構、技術優化方面的工作要預留，預計可以有多少人力容量可以投入到業務需求上。我們也非常推薦，每個迭代裏面預留一定的人力容量用於技術，架構的改進，業務需求和架構技術優化保持一個比例，保持產品的的健康。這也是持續改進的體現。
大家要銘記一個事情：團隊的人力容量每個迭代一定是變化的，迄今爲止，軟件的開發活動還是個智力指導下的雙手活動，開發人員心情不好也是會影響人力容量的。
迭代會議的輸入
- 備選的迭代Backlog：一個經過產品經理和開發Leader預溝通的備選迭代Backlog，初步的需求優先級排序
- 迭代的目標：目標包括很多類型，是這個迭代的“教堂”，比如這個迭代要交付的重大特性，重大的市場發佈等，讓全員能夠感知自己在這個迭代完成的UseStory的價值，迭代目標通常由產品經理向全員傳遞。團隊自身架構、技術的重大優化，也可以是迭代的目標。團隊在質量、效率上的改進目標，比如缺陷下降多少都可以是這個迭代的目標。
迭代會議的過程
- 頒佈會議規則，比如限定會議時間，別人發言的時候，其他人禁止講話，每人發言限時多長時間，
- 產品經理首先給大家介紹備選的Backlog中，有哪些UserStory，這個迭代的重大特性及其價值，或者要交付的重大市場發佈，或重點客戶，介紹Must的UserStory有哪些。
- 開發團隊Leader給大家介紹一下技術、架構，研發環境，獲取其他的團隊自我改進的目標，
- 團隊成員全員參加，從Must UserStory開始進行Story的工作量估計，對於有些UserStory，還可以進一步拆分爲Task，給出每個Task的估計
- 團隊成員全員參加，看看當前計劃的UserStory重估計和人力容量是否相配，不能超出人力容量的100%。或者團隊根據情況，定一個範圍，90%，80%都可以，因爲畢竟工作量至少預估計。隨着團隊越來越默契，估計值越來越準，可以提升到100%。
- 如果有超出，產品經理和團隊成員一起，重新調整，首先去掉Could的UserStory。這時，基本上這個迭代要交付的UserStory範圍就確定了。
- 開發團隊Leader帶領團隊成員，開始分配認領UserStory，我們建議鼓勵團隊成員主動的Pull（認領） ，而不是被動的接收Leader的Push（被動接收）。當然有些UserStory可能需要某些成員開發更好，團隊Leader可以再調整，我們也可以叫做Pull&Push。
- 開發團隊Leader統一審視每個成員的實際工作量，避免對有些成員的工作量不均衡，並進行相應的調整。
- 進行簡單快速的頭腦風暴，團隊成員發表自己對於接下來迭代的風險，對於是一般性的風險問題，快速記錄，團隊Leader會後解決，避免耽誤大家時間
- 全員對這個迭代的目標進行信心投票，5分信心最高，1分信心最低，如果平均分低於3分，應該讓投比較低的成員再講講他們的考慮，看看要不要再調整需求的優先級。
- 會議結束，開始爲這個迭代的目標而衝刺。
迭代會中的一些雷和坑
- 迭代會議預先準備是非常關鍵的。團隊成員那麼多，如果預先不進行備選UserStory的識別和排序，拿一堆顆粒度很大的需求直接去迭代會議，大概率要失敗，會議也會及其冗長，那麼多團隊成員，時間嘩嘩的就流失了，研發不是請客吃飯，這是要讓你們老闆傾家蕩產啊。
- 工作量的估計方法。有絕對估值法（人時/人天），或者相對估值法（斐波那契數列的故事點，T恤 Size）。
- 業界在各種敏捷，DevOps培訓中，用的比較多的是相對估值法，而且通常有個故事點估計的卡片。但是從我們的實踐來看，早期的迭代，團隊剛剛成立，團隊成員的能力和容量沒有基線，團隊成員對於產品，架構、技術還在掌握中，研發環境和工具鏈剛剛搭建，還有些工作需要投入，這種狀況下用相對估值法更適合。當團隊磨礪一段時間後，團隊成員比較穩定，團隊成員的能力和對技術架構的掌握越來越好，團隊成員的估計越來越準，使用絕對值更接地氣，理解起來比較直接。
華爲雲DevCloud同時提供絕對估值法的人時/人天，用戶只需要選一個計量單位，系統會自動計算另一個計量單位的值，目前按不加班的1天=8小時的工作時間，是的，沒有算加班時間：），如下圖：
當然，我們也提供了相對估值法的故事點，如下圖：
- 關於Task的使用誤區。
a）把什麼都當Task。Task是爲這個迭代服務的，是必須有產出。學習了什麼這個不可以算作這個迭代的Task。
b）把有些不當做Task。搭建環境，準備代碼庫或代碼分支，驗收，刷新自動化測試用例，這些都是要算Task的，不是隻有寫代碼纔算Task。 - 準備會議時，Must的UserStory的總量不能超過備選Backlog總工作量的80%，如果備選Backlog都是Must的UserStory，失去了優先級排序的意義了。
- 準備會議時，Must的UserStory的總量不能超過團隊容量。
- 整個迭代會議，建議使用專業的敏捷協同管理工具，大家看到內容一致，大家刷新調整後的內容也一致並即刻生成，會議結束的同事，一份本迭代的UserStory/Task列表就生成了，也不用會後再去整理。下面是我們所在的團隊最近的一個迭代計劃列表例子：
寫在最後的要點總結
- 迭代會議事先準備很重要。
- 過程中鼓勵團隊成員自主Pull，而不是一味着的Push。
- 相信團隊，相信團隊對工作量的估算，給團隊以尊重，工作量不要壓得那麼慢，超出人力容量的迭代，質量很難得到必要的保證。
- 如上的三個原則其實不僅僅適用於迭代計劃會議，其實也適用於軟件開發過程中的很多活動和會議。
希望能幫助大家開一個開心，高效，信心滿滿的迭代會
議。