项目回顾，作为项目管理的一大机制，可以帮助我们识别出项目过程中的不足和优点，从而，通过“改进不足，保持优势”，让团队今后在类似项目中更为高效顺畅。本文，首先回顾《敏捷回顾——团队从优秀到卓越之道》所介绍的方法体系，然后，结合具体实践，谈谈方法落地和应用效果，最后是总结与展望。

---

一、相关术语

Retro（Retrospective），译为敏捷回顾，在敏捷方法论中，格外突出了敏捷回顾会这个仪式。在中文中，Retro有两种含义，一是项目回顾，一是项目回顾会。前者体现了项目全程的良好过程改进意识和习惯，后者特指项目结束中召开的那个会议。

---

二、再读《敏捷回顾——团队从优秀到卓越之道》

近期，我重翻《敏捷回顾——团队从优秀到卓越之道》（Agile Retrospectives: Making Good Teams Great）。该书由Scrum祖师爷之一Ken Schwaber作序推荐，作者是两位女性，被冠以敏捷检视女神之称，分别是Esther Derby和Diana Larsen。

1、全书总览

一级目录结构如下：

全书一级目录图.jpg

回顾检视会的标准步骤，包括了5步，对应上述第4至第8章。

回顾检视会标准流程.jpg
其中，各步骤目标为：

• 预设会议基调：重温目标、议程、工作协议和签到等；
• 收集数据：从不同角度共享和整合迭代/版本/项目周期内的数据；
• 激发灵感：评估数据和有益信息，诠释分析数据，产生灵感并揭示隐含变化；
• 决定做什么：形成行动计划，并确定最重要的行动，明确owner，并明确可衡量目标；
• 总结收尾：给团队机会，可继续改进，表达感谢和反思在回顾会上的全过程。

---

2.方法框架及特色方法回顾

1）方法框架

针对上述的五步，全书提供了丰富的方法：

方法框架.jpg

在上图中，择选两条较具特色的方法，来回顾方法的具体要素。

2）ESVP

应用阶段：预设会议基调阶段
术语解释：

E：Explorer（探索者）；
S：Shopper（采购者）；
V：Vocationer（度假者）；
P：Prisoner（囚徒）；

综述：
每名与会者匿名汇报他对于回顾会持哪种态度。检视会主持人收集大家的反馈，并通过图表展现数据，与大家讨论这意味着什么，并有针对性的开展后续会议。
应用要点：
匿名
收益：
总体上掌握参会人是带着什么心情来参会的，有助于针对性的开展会议。

3）定位优势

运用阶段：数据收集阶段
术语解释：
无
综述：
两人一组进行访谈，时间到了后，再互换角色继续访谈。
使用要点：
小组的两人尽量不熟悉彼此工作。访谈者做访谈时，不要打断讲诉人的说话加入自己的故事。
收益：
发挥参会者相互的力量消化掉负面情绪，对于即使很差的项目也有信心，同时，促进相互理解，消除怨恨。

---

三、敏捷回顾实践

下面，以一年半前我主持引导的一次敏捷回顾实践为例，从背景目标、议程安排、方法运用、效果分析、SWOT分析改进等角度描述如下。

1.背景与目标

背景

• 这是我作为Scrum Master，跟进该安卓团队的第1个完整版本；
• 该版本跨度达3个多月（5月召开了需求评审会，直到9月召开回顾会）；
• 项目同学来自5个组（PM、UE、CRD、SRD、QA），共计66人。为了让每位参会同学都有机会表达，我们仅邀请了经理、leader和高工等core成员参会，共15人；（备注：CRD、SRD分别指客户端RD和服务器端RD）
• 会前，累计已收集了17条不足点和17条经验点。
• 各方都非常希望召开版本回顾会；

目标
通过keep well & improve not well，针对性的解决一直困扰跨职能协同的一些流程机制问题，让各方收益。

---

2.议程安排

会议最终定为3小时，会议总体流程为：

回顾实战会议分阶段.jpg

会议议程安排如下：

回顾会议议程.jpg

---

3.方法运用

《敏捷回顾——从优秀到卓越》中大量的方法，给我们敏捷教练提供了丰富的武器。结合团队协同情况，在运用上做了灵活处理。

• “感谢环节”前置到会议启动之初，并且这次感谢专注在跨职能之间的感谢，例如PM感谢RD、RD感谢QA等，这对于在会议讨论之初就缓和各方之间相对紧绷的情绪，以“怎样做的更好”的更为open心态，而不是“指责与辩解”的对抗，来启动会议后续讨论；
• 收集数据的工作部分提前到会前进行。项目时间跨度较久，各角色在项目过程中已经积累了一些不错过程改进习惯和数据，会前各角色做系统总结成本不大；会上人数较多，会前提前坐系统回顾，有利于把握方向，使改进的重点更早形成；

工作协议、头脑风暴、排优先级、+/Delta、领任务等，我们灵活运用在上述的会议全过程。

---

4.效率分析

通过头脑风暴的形式，我们共收集到14条改进点建议，经与会前整理的17条待改进点归并后，形成了6大类（产品、质量、流程、外部协作、内部共享机制、代码分支管理）共11条改进点。会上，大家主动要求不裁剪，承担所有的11条改进点。

在下个版本的回顾会（约两个月后召开）上，我们实现所有改进点的100%闭环，符合预期。

---

5.SWOT分析改进

组织召开版本回顾会，对于引导者的要求是挺高的。以下以我为例，通过SWOT分析，找到改进的方向和重点。从下图可以看出，优势与不足并存，机会和威胁同在。抓住机遇、发挥和拓展优势，比如准备更充分、不怯场，这可以勤能补拙；而识别和回避威胁，弥补不足，则可以让我们持续进步，越做越好。

SWOT分析.jpg

---

四、总结与展望

每个人其实都是回顾大师。在人生的不同阶段，通过回顾自己的学习、工作、情感、人生，实现不断的进步。正如曾子曰：“吾日三省吾身。”
落到项目的回顾，应该也是自然而然的事情，即项目的团队如果今后遇到类似的项目时，如何做的更好更顺畅。怎样更好更顺畅？

• 技术上改进：例如原先技术架构复用性差、拓展性弱，若采用新架构，可实现快速开发，开发效率提高不止一倍，团队间开发工作可解耦、老代码技术债务多等等；
• 工具上改进：例如可新上一套自动化测试工具及脚本、交付流水线可实现DevOps、项目管理工具平台的升级让需求管理及状态迁移更为方便、各类开发测试环境准备可前置并优化等等；
• 管理上改进：例如多团队协同的整体流程及若干机制建设、跨团队的沟通机制、需求及其变更管理管理机制、需求优先级对齐、风险管理及升级机制、单团队内部的新老梯队建设及知识传递等；

其中，管理类的改进，是回顾会要解决的重点。技术类和工具类可以作为一个改进点提出来，但一般需要在单独的技术topic会议上做专题研究。技术topic会上，会重点关注可行性、收益成本和具体落地计划。

既然项目回顾会，本应是件自然而然的事情，那么为何要有这多玲琅满目的方法呢？我遇到的较为典型的原因有：一是版本一个接一个，无瑕召开回顾会；二是跨团队跨地域下，单团队召开回顾会，不如放在周例会上进行；三是项目相关多团队，存在强烈的自我保护，潜意识把回顾会等同于问责会，所以会上无法全情投入到回顾改进本身；四是一些高优需解决的改进项，却因涉及高层或其他团队，让无法推动，团队同学因此存挫折感，并对回顾会的价值产生质疑。

项目回顾会，需要很好的引导，让项目成员都能获得激活，在无压力的前提下，去回顾，去发现，去反思，去认领，去改进。回顾会上，只有感激，没有指责，也无需自责。

路漫漫其修远兮，吾将上下而求索。期待今后服务更多的团队和项目，通过自然而然的回顾活动，帮助更多团队从优秀走向卓越！