華為敏捷/DevOps實踐：產品經理如何開好迭代計劃會議

大家好，我是華為雲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

相信團隊，相信團隊對工作量的估算，給團隊以尊重，工作量不要壓得那麼慢，超出人力容量的迭代，質量很難得到必要的保證。

如上的三個原則其實不僅僅適用於迭代計劃會議，其實也適用於軟體開發過程中的很多活動和會議。

希望能幫助大家開一個開心，高效，信心滿滿的迭代會議。

至此，軟體迭代開發中三個最基本的活動：迭代計劃會議，每日站立會議，迭代回顧會議，都介紹完了。感興趣的朋友可以到 華為雲社群 看相關的文章。