華爲敏捷/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

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

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

但願能幫助你們開一個開心，高效，信心滿滿的迭代會議。

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