我的知识管理之路(3)—非敏捷团队的回顾会议

微软的MVP张逸先生在一篇文章中，将敏捷回顾比作“印第安人的灵魂”：“印第安人在赶了3天路之后，会停下来小憩一天，因为他要等着自己的灵魂跟上来。敏捷开发在经历了一次迭代或者冲刺后，也需要休整，以等待团队的灵魂跟上来，这一过程被称为敏捷回顾 (Agile Retrospectives)”。

在电影《云上的日子》里，有这样一句台词“我们走得太快了，灵魂还没有跟上”。印第安人赶着羊群，朝落日方向走去，他们行走的速度如飞一般，但是快速行走几天后，就会停下来。他们在夕阳映红的天空下跳舞，快乐的跳着，或者在原地咂口蓝色的烟草。过路的人问：“你们还在等什么？再不赶路，日落之前就到不了目的地了。”印第安人回答说：“我们慢下来，是在等我们的灵魂赶上来”。

我们在项目开发中，并没有实施敏捷开发。每个项目也都相对较小，一般由独立的开发人员承担，所以并不适合直接照搬敏捷回顾会议的方法。 不久前，我们的一个产品接到很多客户反馈，负责这个产品测试的同事也就不断的进行Bug复现，向客户反馈，以及对产品的操作方法进行解释等。为什么产品发布出去后，还会有这么多的客户问题？这个产品的问题是否也可以借鉴到其他产品的测试中，避免发生同类的问题。带着这些问题，从而萌生了将析错会议作为一个标准流程在组织内进行推行的想法。

析错会议，顾名思义是要对发生的错误进行分析，找出原因和改进措施。我们分别在QC Team和RD Team做了一次析错会议的尝试。

• 对于QC，析错的重点定位在“来自客户反馈的问题”；为什么会遗漏这个问题？客户为什么会遇到这个使用上的问题？我们可以做些什么从而避免再次遗漏，避免再次出现同类的问题？我们可以做些什么提升客户的满意度?

• 对于RD，析错的重点定位在“来自单元测试、系统测试的问题”；这个问题发生的原因是什么？这个问题的解决方法是什么？我有哪些可以分享给别人的经验？

在会前，我们请每个QC /RD书面准备不少于3个问题，在会上讨论。透过第一次尝试的析错会议，我想我们已经达到了经验分享，让知识流动的目的。

在QC的析错会议上我们发现了一些同类的客户反馈，这样可以帮助我们采取一致的行动应对；我们意识到除了软件功能本身，我们还需要从质量属性的各个方面进行改善，来提升用户体验。在RD的析错会议上，有一位资深的技术大侠进行点评和分析是非常必要的。有时候，RD在开发过程中，问题解决了，也就不会再和别人进行讨论。但通过析错会议我们发现，虽然问题得到了解决，但他未必已经弄清楚了问题的本质；或者解决方案不是最优的。资深技术人员在这个时候就又进一步加深了他在这个问题上的认识。

会后，我总结了一些第一次尝试的经验，又查阅了一些关于敏捷回顾的资料。将析错会议完善为回顾会议，具体如下：

回顾会议的目的/目标：

• 信息共享、经验分享，让知识流动。
• 回顾会议前请团队成员书面化Review Form，会后更新后纳入组织知识库，这样隐形知识就外化为了显性知识。
• 发现问题，找出改进方法。
• 反馈流程改善建议。我们不需要为了过认证专门、刻意的非要大家提出流程改善意见，但是如果改进方法涉及到流程改善，就可以反馈给SEPG处理。
• 找出成功的经验。这一点是我们在第一次尝试析错会议时所忽略的。我们只想到要找出问题，却忘记了肯定，忘记了分享成功的喜悦。因此，我将“析错会议”改为“回顾会议”。

回顾会议的执行过程：

1.      准备

提前给团队成员发出会议通知，包括目的、执行的流程、负责人（主持人、记录人等）、会议时间、预计时长、地点等。

请大家提前书面化Review Form，包括析错和成功的经验分享。要求每人分享不少于3个析错和1条成功的经验 。

2.      召开

大家轮流分享Review Form，由一个记录人员忠实记录整个讨论过程。针对问题，一起深入分析原因和解决以及改进。如果一个团队新人较多，一定要有资深技术人员进行深入的Review和点评。

轮流分享结束后，应对此次讨论的问题加以总结。特别是针对共性的问题，一定要做出明确的改进措施，并且分配责任到人或者组织层级 （有些问题属于组织层级，应该向上级主管或者SEPG提出解决）。

会议总结的结论例如：

有3个Bug属于操作系统的兼容性问题，特别是同一种操作系统，不同SP发生的问题；在这些情况下，系统测试时无法确保每一种OS，每一种SP都覆盖到。特别是，有一些虽然我们并没有明确说明支持的OS，客户也还是有可能使用。建议我们以后可以采取以下的改进措施：

1. 首先确保SRS中明确说明支持的操作系统，一定要进行兼容性测试

2. 尽量准备干净的多个操作系统平台。在发布前，测试安装程序，最基本确保程序能够运行（需要主管给予资源支持）

3. 积累客户反馈的关于兼容性的问题，作为FAQ发布在Manual中

3.      会后

团队成员根据讨论结果更新自己的Review Form，并纳入组织知识库中。换言之，回顾会议也是我们组织知识库中积累经验共享和品质案例的来源和手段之一。

会议记录人员发送会议记录给所有参与者。

4.      会议召开的频率

暂定一个月召开一次，建议单独召开。1.  每次会议注意控制时长在2个小时左右。如果团队成员觉得值得讨论的问题太多，可以考虑增加会议频率，或检视是否出现了其他异常需要解决。

 

几点注意和建议事项 ：

1.     在发言中少说“你”“你们”“你们组”“你们的产品”；我们同属于一个Team，一个公司，应该有同样的Ownership，我们只针对问题本身进行讨论，不要形成部门对立、产品对立。特别是针对QA部门的回顾会议。在这里，只要“我们”，没有“你们”和“他们”。

2.     建议会议可以由所有团队成员轮流主持、轮流记录。

3.     会议上每个人都要发言。

4.     为了控制会议时长，提高效率。如果团队成员比较多，可以提前请会议主持人员对回顾表做一个筛选。

 

名词解释：

隐性知识 (Tacit Knowledge)：隐性知识是高度个性化而且难于格式化的知识，主观的理解、直觉和预感都属于这一类。

显性知识 (Explicit Knowledge) ：显性知识是能用文字和数字表达出来，容易以硬数据的形式交流和共享，比如编辑整理的程序或者普遍原则。

 

参考文档：

印第安人的灵魂——敏捷回顾

http://www.agiledon.com/post/Agile/Agile-Retrospectives.html