按理說，敏捷隔一段時間就應該回顧，每個迭代都應該進行，我們團隊三個月來第一次大規模團隊回顧，亡羊補牢，爲時未晚。對敏捷項目來說，規劃、站會、回顧是最重要的，在回顧中成長，從流程、技術、人（心智）等領域，從需求、開發、測試、上線、運營等全階段分析，確保團隊能從中學習，持續成長。
N年前在我的團隊裏，我採用過回顧方法主要包括心情回顧法、好的/需要改進的/哪些行爲/TOP問題跟進/改進Backlog、應該保持的/應該停止的/應該開始的。關於回顧，書籍也比較多，最重要的是有機會讓大家抒發感受，並把改進落實到位。
說回本周的回顧，好的點比如團隊協作、持續奮鬥、問題響應等。這裏，我從各個階段列下的一些改進點，更好地指導後續的項目推進。大家反映的問題包括產品需求評審前才發出，未能做到提前預習，評審時提不出來問題、產品需求變更未體現到是wiki、需求來自多方，主要業務方不曉得團隊具體忙的需求，爲啥她們的一個需求排那麼久、開發週期和測試周期分別做什麼，怎樣高效利用時間&讓領導感受我們的努力、測試環境和線上環境配置不同步、開發迭代中休假任務丟失，交接郵件並不能反映全貌、產品和開發未能就落地方案達成一致，開發按自己想法實現，產品一開始沒反對，後來驗收時反水、開發拆解任務沒時間學習需求，還要支持測試、項目趕進度沒有時間寫單元測試和進行比較好的架構設計、開發提測質量不高，反覆多次導致測試時間變長、架構方案難以完全落地，到新域上線確實需要架構支持、產品驗收環境多次，需要快速而不是簡單重複三套環境、排期不統一，聯調節奏待加強，對外無長期規劃，郵件定版、上線後沒有運營效果和數據反饋。
需求相關：至少提前1小時發出需求、需求變更管理、緊急需求管理、測試周期小需求伺候、產品固定功能和線上環境驗收、需求評審前可以跟技術溝通產品方案可行性等。
項目相關：排版郵件、季度或半年迭代版本計劃、按需排小版本支持、休假交接安排、更多可視化和週報、郵件羣組避免遺漏人、多點預留時間給開發做需求學習和任務拆解等
開發相關：線上問題支持、技術需求處理、拆解工作量工時、開發質量保證—單元測試和自測用例、儘量能做到開發專職在某段時間支持一個項目、開發提測文檔要寫清楚，小變化也要文檔承載、需求變更時，產品開發討論出方案後同步測試（取決於測試時間和主動貢獻度）等
測試相關：不同環境變量可移植、差異覆蓋率、測試周期、開發自測部分需求、測試環境管道化、聯調主導，對齊上下游時間等
運營相關：線上問題收集、運營數據反饋、定期同步項目節奏和優先級、定期提交需求內容和內部確認優先級等
本次覆盤，團隊負責人提了多次，作爲項目經理的我，平時只顧自己覆盤，未能更早地帶領團隊覆盤，實屬不應該。一方面大家都忙，畢竟從零到一，不止是說說而已。