作者：洪永潮｜云效研發效能專家、李田莉｜云效效能洞察負責人
在上一篇文章 3、如何做好迭代排期？中，我們已經了解到：
什么是雙周迭代；
如何高效地開展排期會；
如何在云效項目協作Projex 中落地排期會相關事宜。
接下來，我們來詳細介紹一下整個迭代跟進過程-從迭代排期確定到迭代交付的過程，同樣我們還是以雙周迭代為例。
有效地推進迭代計劃-每日站會
迭代進行的過程中，我們一般會采用每日站會（一種最先被落地的實踐）進行迭代的推進和跟進。為了方便大家，我們將每日站會的目標、事項等細則整理成了表格以供參考，如下表：
活動名稱 | 迭代跟進（每日站會） | ||||
活動目標 | 促進團隊有效協作和聚焦，促進價值順暢流動和交付，同時通過站會同步需求進展和暴露問題及風險，把可視化價值流實踐落地到位 | ||||
負責人 | 研發負責人 （站會主持人） | 主要職責 | 負責主持站會，同步需求進展，及時發現問題，并推動和跟進問題的解決。 | ||
參與人 | 產品、開發和測試 | 主要職責 | 及時更新需求的狀態，提前識別所負責需求的進展和問題，跟進和解決站會發現的問題 | ||
時長和頻率 | 15分鐘，三個相同：同一個團隊、同一時間（建議在上午）、同一地點（在看板前） | ||||
輸入 | 過程 | 輸出 | |||
|
|
| |||
我們會看到，上面表格中的輸入、過程、輸出環節有比較多的要求，這是為什么呢？這是因為，如果在輸入、過程、輸出環節，我們沒有要求，每日站會（迭代跟進）將會非常低效。
下面的幾點，就是我們在輔導敏捷開發團隊時，經常碰到的一些情況和注意點：
重點關注需求進展：很多研發團隊會重點跟進研發任務的完成情況，這容易導致需求無法及時測試和按時發布。一個需求拆解為研發任務后，通常各方對齊接口聯調后才能進行整體需求的測試和驗證，此外產品經理和用戶重點關注的也是需求的驗收和發布，這便需要研發團隊在迭代跟進時從需求出發，重點關注需求的整體進展。
每日站會前更新好需求的狀態：如果研發團隊基于在線工具進行協作，需求內容和進展已經在線化，團隊成員在每日站會前更新好狀態，大家同步進展時清晰明了，每日站會的開展就會比較高效。
聚焦迭代過程中問題：這個是和站會前更新需求狀態要互相配合的，需求狀態及時更新了，迭代進展在需求看板上可以一目了然，大家在每日站會時，便可以聚焦關注需求交付的阻塞、風險和問題即可。
行動項要及時同步相關方：每日站會通常會有當前的問題、跟進人和跟進方式等記錄，如果沒有及時同步給團隊，很容易遺漏，也會造成信息的不同步。所以通常將這些內容記錄成行動項（包含事項、負責人和期望完成時間），并在會后及時同步給團隊成員或其他相關方。
借助云效項目協作Projex 開展每日站會
一、每日站會輸入
團隊成員更新進展：按照實際情況更新需求和任務的狀態、關鍵時間節點，如提測時間、任務起止時間等。通常在實踐過程中，狀態更新很容易被遺忘，如果站會一般在早上進行，建議團隊成員在前一天下班前更新需求和任務的狀態；
站會負責人：上一次站會需跟進的問題列表。
二、開展每日站會
1.迭代跟進，關注每日站會“6+1”
通常我們在每日站會時，通過看板來同步需求進展，且會前已更新好需求狀態，所以在站會時需求的進展一目了然，只要重點關注問題即可，如站會的 “6+1” ：
6 指的是：“瓶頸隊列、關鍵的缺陷、重點關注的需求、阻礙和問題、到期或即將到期的需求、中斷”；
1 指的是：檢查是否存在“未反映在看板上的問題”，比如產品經理臨時插了一個需求卻沒有錄入系統。
2. 確認需求已經拆解完成
一般建議在需求排期時把需求拆解到研發任務（前端、后端和聯調），但時常會出現，需求拆解任務不到位的情況，所以站會的時候需要檢查，需求是否已拆分到研發任務，以及是否已指派到具體的開發人員，如下圖所示：
3. 明確需求關鍵時間點
需求的關鍵時間一般是指計劃提測日期、計劃完成時間等，已經和相關負責人明確定下來，并更新在需求卡片上。
可以通過自動化規則的方式，當需求快要到達特定關鍵時間點的時候，推送相關的字段信息提醒。如下圖，設置處于“待測試”狀態的“產品類需求”，當到達“計劃測時間”的前1天早上9點時，會通過釘釘群消息的方式進行提醒。
釘釘群中的消息提醒：
4. 跟進團隊缺陷解決進展
每日站會時，在同步完需求的進展和問題后，需要抽 1-2 分鐘時間查看一下缺陷解決情況，在云效項目協作Projex 的缺陷管理中，可以查看到遺留缺陷情況，并可根據訴求配置不同的查看視圖。如下圖，可以按照負責人分組進行查看缺陷情況。
此外，云效項目協作Projex 還提供了查看迭代缺陷統計報表，在迭代概覽中，可以查看當前迭代查看“缺陷趨勢圖”和“存量缺陷按成員排名”指標卡。
5. 跟進迭代進度和偏差
云效項目協作Projex 的迭代概覽中，可以通過“迭代工作項概覽”和“迭代工時概覽”卡片，查看迭代排期完成后的工作項和工時統計數據、迭代成員的工作量情況：
迭代工作項概覽：統計迭代中排序的需求、任務和缺陷的數量情況；
迭代工時概覽：展示迭代容量，統計迭代中需求的預計工時總和；
通過“工作項排名”和“迭代工時排名”卡片，查看迭代成員的工作量情況和工時情況：
工作項排名：按照團隊成員負責的工作項（包含需求、任務和缺陷）數量進行排名，凸顯前5名，方便對工作內容進行重新安排和調整；
迭代工時排名：按照團隊成員負責的工作項預計工時數排名，凸顯前 5 名，方便對工作內容進行重新安排和調整。
通過“迭代燃盡圖”和“工時燃盡圖”卡片，跟進迭代的進度和偏差：
迭代燃盡圖：按照迭代排期時的工作項數量進行燃盡（支持過濾需求、任務、缺陷），如下圖左側所示，存量曲線高高飄起，說明進度已經嚴重滯后；
工時燃盡圖：按照迭代排期時預估的工時進行燃盡，如下圖右側所示，剩余工時數量往上飄，說明排期是工作量評估不足或插入了新的需求。
6. 站會問題行動項跟進
在每日站會時，通常會有問題記錄和行動項，每次站會時可由專人負責進行記錄和跟進，同時也需要回顧一下上一次每日站會遺留行動項的完成情況。
三、每日站會輸出
需求更新到最新的狀態
雖然每日站會前團隊成員會更新好需求狀態，但站會過程中，也有可能需要更新需求和任務的狀態，研發團隊要保證每日站會結束時，看板上需求和任務狀態一定是最新的狀態。
站會行動項及時同步
把站會上發現的問題清單，包括問題、責任人和完成時間等，會后通過郵件、溝通群等及時同步給團隊成員或其他相關方。
總結回顧
現在我們都了解了每日站會是迭代跟進時的有效活動，我們需要：
每日站會前，更新迭代中需求的進展情況和上一次站會行動項情況；
每日站會時，關注站會的“6+1”，及時跟進偏差和問題；
每日站會后，及時將站會中記錄的問題和行動項同步給團隊成員和相關方。
在敏捷迭代中，雖然迭代周期比較短，但依然需要對迭代過程進行有效跟進。在這個過程中，不僅需要跟進需求、任務和缺陷等進展情況，也需要借助統計數據來幫助我們了解整體的進度和偏差情況。更多敏捷開發跟進數據解讀可參考 敏捷研發，我們如何跟進？