摘要：如何開一場高效的迭代排期會，高效落地敏捷開發，先從這3個關鍵活動著手，通過本文你將了解到什么是敏捷開發、什么是雙周迭代、如何高效地開展排期會，以及如何在云效專案協作·Projex 中落地排期會相關事宜，
作為團隊的負責人，你希望將研發模式從瀑布式轉為敏捷，并進行持續改進，但卻不知道從哪里開始？
作為專案管理人員，你希望負責建立迭代機制，并進行規模化的推廣和度量，但卻不知道如何快速建立機制？
作為產品經理，需求排期后，你希望能方便地跟進需求進展，及時發現問題，但卻不知道怎么跟進方便？
接下來，我們將通過 3 篇文章，帶領大家逐步了解敏捷開發的全程序及高效落地指南，
敏捷開發之 Scrum 方法介紹
在敏捷開發落地的程序中，通常采用 Scrum 的方式，所以我們以 Scrum 為例來介紹敏捷開發的流程和場景（如上圖），在這個程序中：
1. 首先產品經理會進行：
○ 需求的收集、調研和分析，形成按優先級排序的產品待辦串列；
○ 對高優先級的需求，進行詳細設計和澄清；
○ 通過迭代排期會，形成按優先級排序的迭代待辦串列；
○ 排期完成后，需求從產品經理側流向技術同學側，
2. 在需求澄清的情況下，研發團隊來會：
○ 以 1～4 周的迭代周期進行持續開發和交付迭代待辦串列中的內容
○ 采用每日站會來跟進計劃和發現問題，并在迭代程序中持續或間歇性地交付可作業的軟體，
與此同時，產品經理會在這個階段，進行下一迭代的需求設計和澄清，
3. 迭代待辦串列開發完成后，產品經理和研發團隊一起進行迭代演示，交付可作業的軟體，
4. 最后，通過迭代復盤會活動驅動團隊持續改進，
在落地 Scrum 方法時，無論是阿里內部還是云效的企業客戶，通常采用雙周迭代的運作機制，下面我們以「雙周迭代」為例進行介紹，
雙周迭代的運作機制
雙周迭代時序圖
上圖是雙周迭代的運作流程：
● 在 N-2 和 N-1 周，業務和產品會持續做需求的分析和設計，會把要排入迭代的需求按優先級高低準備好，包括需求的分析、設計和澄清；
● 隨后開發和測驗同學在排期后的兩周內（ N 周和 N+1周），按優先級對需求進行開發、測驗、驗收和發布上線，注：排入迭代的需求在迭代排期前要已澄清清楚，并明確驗收標準，
● 迭代排期在雙周迭代中起著前后銜接的作用，每兩周進行一次，一般每次 1～2 小時，排期前，業務和產品同學需要準備好待排期的需求，排期后，開發和測驗同學需要按照計劃對需求進行開發、驗證和發布，
● 迭代節奏和發布頻率是要解耦的，迭代節奏可以是兩周或一周，而發布頻率可以是每兩周一次、一周一次、或一周多次等，有的企業或團隊會按照每個迭代進行一次發布來落地，也有可能按照一個迭代進行多次發布來落地，
至此，我們理解了敏捷開發的整體流程，及雙周迭代的運作機制，可以看到在雙周迭代的運作中，一個迭代中有 3 個非常重要的活動：迭代排期、迭代跟進和迭代復盤，本篇文章我們先從「如何開展一場高效的迭代排期會」聊起，
如何開展一場高效的迭代排期會？
想要開展一場高效的迭代排期會，需要相關同學做一些準備作業，我們將排期活動中的需要準備的事項、目標等整理在一起（如下表），供大家參考，
我們會看到，在排期輸入、排期程序、排期輸出環節的要求比較多，如果沒有要求的話，排期會將會比較低效，后續的迭代推進也會出現各種問題，如下，是我們在輔導敏捷開發團隊程序中總結的幾個注意點：
● 明確的迭代目標：迭代需要有比較明確的目標，沒有目標容易出現需求范圍蔓延的情況，導致團隊成員無法聚焦
● 需求唯一優先級：很多產品經理在提迭代需求時，會出現需求的優先級都是“緊急”的情況，其實這反映了需求的真正優先級是不明確的，我們需要明確出唯一優先級排序，這個程序不但能夠讓團隊深入思考、對優先級提出積極挑戰，也能梳理出優先級高、真正對業務有價值的需求；
● 需求已澄清且技術方案已確認：需求已澄清是排入迭代的基本要求，有些團隊會把未經過分析、設計和澄清的需求排入迭代，導致排期時無法給出準確的作業量預估，也無法快速進入開發，這會影響其他需求的進展和整個迭代的節奏；
● 需求已拆分：通常情況下，需求要拆分到在一個迭代內可以完成交付，方便快速驗證業務假設，縮短業務的回應周期；
● 明確需求負責人：需求進入開發時，一般會需要多位技術同學合作完成，如前端和后端，或多個后端，這時我們建議由其中一位同學擔任需求負責人，跟進需求到發布上線為止，這樣可以更好地協調開發內部協作，避免程序中的爭論或互相推脫，提升整體的協作效率，
● 明確關鍵時間點：需求排期時，往往會有 3 個時間點需要明確：
○ 聯調時間：需要聯調協作的開發同學會比較關注聯調時間；
○ 預計提測時間：測驗同學比較關注什么時候提測，這是開發與測驗協作需要明確的時間點；
○ 預計發布時間：產品經理比較關注的需求什么時候發布，
● 同步下一個迭代的需求：有的研發團隊會說不知道接下來要做什么，也有的團隊會出現需求斷檔，這里建議產品經理可以提前把下一迭代要做的需求同步給大家，讓大家了解近期規劃，以便更好地安排研發節奏，
敏捷開發落地往往需要平臺或工具支撐，下面我們以云效專案協作·Projex 為例，介紹如何使用工具來高效落地迭代排期活動，
借助云效專案協作·Projex 開展迭代排期
一、 排期輸入
正如前面所說，為了能夠開展一次高效的迭代排期會，需要準備一些內容，在云效專案協作·Projex 中，我們也提供了準備排期會相關的產品能力，
1.創建迭代，并明確的本次迭代需要達成的業務目標，負責人：產品經理或研發負責人
通常創建迭代由產品經理或研發負責人負責，此時需要明確迭代的名稱、負責人、迭代周期、迭代容量和迭代目標，需要注意：
● 迭代名稱：需要遵循一定的規范，如“迭代+迭代結束日期”；
● 迭代容量：團隊人數相對固定時，一個迭代內的工時容量也是相對固定的，如：雙周迭代，是10個作業日，如果團隊有 8 位同學，一天的有效工時按照 7 個小時計算，容量就是 560 個小時；
● 迭代目標：目標需要具體可衡量，且與業務目標有直接或間接的關系，
創建迭代
2.將產品待辦串列按優先級排序 ，負責人：產品經理
云效專案協作·Projex 的需求管理中，產品經理可以根據訴求使用過濾器，配置“產品代辦串列”公共視圖，視圖默認按照優先級排序，也可以設定成按照狀態、負責人等其他自定義屬性排序，
產品需求待辦串列
3.待排期的需求已澄清，并滿足準入排期的要求，負責人：產品經理
4.保證需求已拆分到可在一個迭代內完成交付，負責人：產品經理
5.各需求的技術方案已評審通過（包括但不限于各模塊間依賴關系、介面定義）負責人：研發負責人
產品經理一般通過開展需求評審會來澄清需求，在澄清程序中，產品經理會對需求內容進行講解，并將需求拆解到較小顆粒度（一個迭代內可以完成交付），同時，研發團隊會根據需求實作的復雜程度，來判定是否需要做技術方案或預研作業，對于需要做技術方案的需求，需要明確技術方案評審的時間點，以便可以盡快投入開發，
在云效專案協作·Projex 中，對于已澄清的需求，需求更改狀態到“已評審”狀態，技術方案已確認的需求，可以在需求上打上“技術方案已確認”的標簽，
注：團隊在云效專案協作·Projex 中創建專案時，可以定義需求的作業流，建議為「待處理-已選擇-設計中-已評審-已排期-開發中-待測驗-測驗中-待驗收-待發布-已發布」，在這個作業流下，僅對狀態為“已評審”的需求進行排期，
可排期的需求串列
6.提前梳理好下一迭代的需求串列，負責人：產品經理
為什么要在這個迭代中去講下一個迭代的需求串列呢？在輔導云效客戶的研發團隊程序中，我們發現有的研發團隊會出現，不清楚下一迭代會做什么或需求斷檔的情況，如果你們的團隊也有類似的問題，建議在迭代排期的時，邀請產品經理把下一迭代需要做的需求大致講一下，讓研發團隊提前了解并識別風險（如果你們團隊沒有類似的問題，可以跳過這個環節），
在云效專案協作·Projex 中，下一迭代的需求可以用兩種方式呈現，一種是給需求打上“下一個迭代需求”的標簽；另一種是直接把迭代欄位更新到下一個迭代，如下圖，是以標簽方式實作對下一迭代需求管理的方式：
下一個迭代需求串列
二、 排期程序
1. 研發負責人做上一迭代回顧
在排期會剛開始時，研發負責人可以在云效專案協作·Projex 的迭代模塊中，帶領大家回顧上一迭代需求的完成情況，需要重點關注未完成的需求情況，如果有未完成的需求，需要評估還需要投入多少作業量，并將其移入即將開始的迭代中，
上一迭代回顧
2. 產品經理講解和規劃需求
首先產品經理可以在迭代概覽中，看到創建迭代時設定好的迭代目標，并向研發團隊介紹，
概覽中的迭代目標
隨后，產品經理按優先級講解迭代待辦串列中的需求（需要通過評審和技術方案確認），在云效專案協作·Projex的迭代規劃中（如下圖），產品經理可以通過所需條件過濾需求（過濾條件可以保存），并按照優先級高低講解需求，講解程序中或之后，可以直接將排入迭代的需求拖拽迭代卡片中，
迭代規劃時講解需求
需求拖拽規劃
3. 研發團隊進行作業量評估
在排期的程序中，研發團隊需要評估各需求的作業量，根據團隊整體人力容量情況，確定本次排期的需求串列：
● 明確需求作業量：需求作業量是指各需求需要的人力工時數量，可在排期會前或會上進行估算；
● 確定迭代容量：迭代容量是研發團隊一個迭代所能投入到需求完成的工時總量；
在排期的時候，我們可以隨時在目標迭代的右上角查看排入需求與團隊工時容量的匹配情況，
迭代容量統計
4. 明確需求負責人和任務拆解
在排期會上很重要的一個事情時，對已排期的需求，明確需求負責人，拆分到技術開發任務，并給出各需求的關鍵時間點，譬如計劃提測日期和計劃上線日期，
● 明確需求的負責人：這里特指需求的開發負責人，需要負責需求從進入開發到發布上線的全程序；
● 需求拆分到開發任務：需求的開發負責人需要負責將需求拆解到各個開發任務，Web端、H5 或 客戶端的需求，往往需要前端和后端的聯合開發，或者一個需求要不同開發同學負責，還會涉及到聯調任務，這是便需要對需求進行任務的拆解，不過，對于特別小顆粒度的需求，也可不進行任務拆解，
需求拆分為多個開發任務
明確關鍵時間點：在迭代排期上，測驗同學會關心需求什么時候提測（提測日期），產品經理會關心需求什么時候上線（交付時間），如果有研發內部協作時，研發團隊也需要明確開發內部的聯調時間等，這些時間點建議在排期會上基本明確下來，如下圖，可以在迭代“作業項”頁面，設定需求的關鍵時間點，
明確需求的關鍵時間點
更新好需求狀態：需求排期確定后，需要的狀態要更新到“已排期”，
需求狀態更新到“已排期”
5. 明確已排期需求的發布視窗
這一點要看團隊的實際情況，有的團隊是固定發布視窗，有的是一個迭代一次發布，也有的是一個迭代多次發布，
● 如果是一個迭代發布一次，相對簡單，上一步的關鍵時間點可以選擇不填，
● 如果是一個迭代發布多次的，需要查看每個視窗發布的具體需求條目和數量，往往發布視窗的時間和需求的計劃完成時間是一致的，
● 如果是持續發布的，那這一條可以忽略，
6. 下一次計劃排期的需求講解
產品經理按照優先級和狀態講解下一次排期的需求情況，可以用標簽，也可以直接用迭代來標識；
下一個迭代的需求
三、 排期輸出
在迭代規劃會后，我們需要有明確的產出：
● 本次迭代的目標和已排期的需求串列；
● 已排期的需求用迭代標記，規劃入迭代；
● 各需求的負責人和關鍵時間點；
● 本次迭代內的發布視窗和對應的需求串列；
● 下一次計劃排期的需求串列；
● 輸出迭代排期會議紀要，同步給相關人員（包括團隊成員、業務方、依賴和被依賴方等），
前面 5 個點我們在云效專案協作·Projex 迭代詳情頁面的“作業項”中均可查看，包含需求名稱和各關鍵屬性，如下圖：
此外迭代“概覽”中，還可以通過“迭代作業項概覽”和“迭代工時概覽”卡片，查看迭代的排期完成后的作業項和工時統計資料、迭代成員的作業量情況：
● 迭代作業項概覽：統計迭代中排序的需求、任務和缺陷的數量情況；
● 迭代工時概覽：展示迭代容量，統計迭代中需求的預計工時總和；
● 作業項排名：按照團隊成員負責的作業項（包含需求、任務和缺陷）數量進行排名，凸顯前5名，方便對作業內容進行重新安排和調整；
● 迭代工時排名：按照團隊成員負責的作業項預計工時數排名，凸顯前 5 名，方便對作業內容進行重新安排和調整，
針對第 6 點-會議紀要部分，排期會的負責人在會前就需要指定好會議記錄的負責人，在結束后，把“排期輸出”以會議紀要的形成同步給相關人員，尤其是業務方、依賴方和被依賴方等，
總結回顧
當你打算落地敏捷開發方法時，我們建議一開始就要讓團隊成員理解敏捷迭代的落地程序，并共識雙周迭代的運作機制，這樣可以讓整個團隊都心中有數，并提前準備關鍵事宜，
而在整個敏捷開發方法運作程序中，迭代排期會至關重要，起到承上啟下的作用，相關負責人需要做到：
● 迭代排期會前，產品和研發團隊需要把待排期的需求準備好；
● 迭代排期會時，產品和研發團隊需要達成共識，明確排入迭代的需求串列，并做出相應的承諾；
● 迭代排期會后，需要對排期的計劃進行推動和跟進，直到需求完成開發、測驗和發布上線為止，
至此，我們已經了解了什么是敏捷開發、什么是雙周迭代、如何高效地開展排期會，以及如何在云效專案協作·Projex 中落地排期會相關事宜，后面2篇文章，我們將詳細介紹迭代跟進-每日站會、迭代復盤這兩個活動，期待大家的持續關注，
點擊下方鏈接，免費體驗云效專案協作·Projex ，
https://www.aliyun.com/product/yunxiao/project?channel=yy_yccb_yc
轉載請註明出處，本文鏈接：https://www.uj5u.com/gongcheng/465086.html
標籤：其他