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