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