Retrospective--The Way To Make Things Better

标签：回顾   过程改进   

回顾这个词最近见得比较多的一个可能原因是因为敏捷开发的如火如荼，对敏捷领域而言，尤其是Scrum，回顾是作为整个框架中的一个步骤来执行的，很多学者认为回顾是敏捷开发中最需要做的一件事情，个人也深表赞同。尤其是在团队尚在成长期，面临研发过程中诸多问题的时候，回顾就是我们手中的武器，是要紧紧握在手里，时刻不能丢掉的。同时，因为回顾在敏捷领域受到的广泛关注，平时在团队中推行回顾的时候很大程度上参考了现有的一些著作和资料，其中受Esther Derby和Diana Larsen合著的《Agile Retrospectives: Making Good Teams Great》启发最大，本文中也大量参考和引用该书中的一些思路和做法。

一. 为什么我们要做回顾？

• 检视（Inspect）：检查和诊视。通过分析现状、收集数据、头脑风暴等方式总结和梳理团队目前存在的问题，包括需要量化的过程记录性数据作为过程改进的输入以及流程改进点本身存在的问题这两个主要方面。
• 调整（Adapt）：过程改进。有了量化的数据和流程改进的突破点，就可以确定调整策略和下一步的工作计划，并落实责任人。

“Stop And Thinking”体现的就是回顾思想，个人认为回顾是过程改进中诸多方法论和实践的一个集合体，也和质量管理领域中的主流思想是一致的，回顾本身也是如下PDCA环（戴明环）的一种具体体现：

二. 怎么做回顾？

怎么做回顾？答案是通过回顾会议。开会的目的是分析数据、剖析流程并在团队级别形成统一认识。回顾会议的相关主题有：

1. 会议的流程

回顾的流程可以分为5个部分，当然各个团队可以根据实际情况进行调整和裁剪，但会议的输入、输出和议程应该是一致的：

1. 确定目标：确定本次回顾会议中需要改进的目标，一般一次回顾会议1~2个目标是最合理的
2. 收集数据：为了对改进过程有量化的标准，需要进行数据收集。数据来自日常研发过程中与该改进目标相关的方方面面
3. 激发灵感：使用数据进行集思广益，通过各种激发灵感的工具和活动让团队成员提出自己的想法
4. 决定做什么：收集团队中的灵感并进行讨论和分析，最终确定下一步的目标
5. 总结收尾：总结本次回顾会议的过程和成果并落实行动计划和责任人

其中前两步需要在会议前完成，回顾会议的目的是对研发过程中的客观数据进行分析从而得出结论和行动计划。

2.会议召开的时机

在Scrum中，回顾会议召开的时间是在一个迭代结束之后，在《Agile Retrospectives》这本书中，两位作者也是提出类似的观点，但前提是团队正在使用基于迭代的敏捷方法进行研发管理。并不是所有团队都会采用敏捷方法，如果团队没有采用敏捷方法，个人认为以一定的节奏定期开展回顾会议是一项最佳实践，如果是不定期开展回顾活动，过程的节奏感和持续性上会大打折扣，可能导致后续大家都对回顾失去兴趣。关于回顾和传统周会本文后续还会有进一步阐述。

3. 参与者和持续时间

回顾会议的参与者不要太多，主要包括：

• 团队成员：执行过程改进的整个团队，确保需要参加的人员都到位
• 顾问：顾问很多时候是需要的，顾问可以来自其他职能团队，也可以是其他研发团队中有回顾和过程改进经验的同事

回顾会议的持续时间上会因为回顾目标和主题的不同而有所不同，但通常建议在半小时到一小时之间。

4. 背景和目标

回顾会议的背景和目标视具体的回顾主题而定，本文后续的场景分析中会提到几个具体的实例。

5. 活动和工具

回顾会议流程中的每一个环节都可以使用一些有效的活动和工具进行工作的展开，有些活动和工具来自传统质量管理领域，如鱼骨图；有些则在团队建设中被广泛使用，如头脑风暴。但无论使用那种活动或工具，都是围绕着具体目标的特点而定。个人平时使用比较多的活动和工具有：

6. 产出和行动

回顾会议的产出通常是团队对具体改进目标的统一认识和行动计划，这些行动计划有些面向具体一个工作点，则改进的效果相对比较容易衡量；有些则面向工作流程，而流程的改变通常需要一段时间，故这类行动计划的有效性需要在后续的回顾会议中时常进行总结和讨论以确定其推进的方向上是否还具有时效性和可行性。

三. 场景分析

本节将根据上文中的回顾会议流程进行一些场景分析，帮助大家了解和掌握回顾会议中的具体做法和注意点。文中的实例可能并不适合所有的团队，仅供参考。

1. 确定目标

确定目标有两个活动，分别是“聚焦”和“不良事件响应”。聚焦是主动地去关注研发过程中的某一个潜在需要改进的点，而不良事件响应通常是因为发生某个事故导致我们不得不被动的去应对这些事故并探讨是否有可以避免再发生该类事故的方法。从质量成本的角度讲，聚焦是一种一致性成本而不良事件响应是不一致性成本，日常研发过程中如果有条件的话应多采用聚焦的方法以降低质量成本。

下面是一个聚焦的例子，我们关注Jenkins使用情况，发现有若干次构建失败的场景，根据团队工作的规则，可能就需要触发我们去召开回顾会议看看是什么原因导致Jenkins构建工作会经常性的出现问题。通过回顾我们通常会得出代码提交、系统集成方面流程上的不规范性，从而进一步确定相关规则：

关于不良事件响应的例子也很多，下面就是一个内部服务发布缺少配置导致相关功能测试失败的例子，从这个不良事件中我们也可以看出服务发布的流程上缺乏相应进行服务器配置的校验工作，所以也可以在回顾会议上展开流程方面的讨论：

2. 收集数据

收集数据一个有效的活动就是”时间表“，如果团队维护着这么一份时间表，则每天发生的问题都会有一个明确的记录，这些记录就为我们的回顾活动提交了无可辩驳的回顾数据，通过对这些数据进行分析，我们就能进行灵感的触发，从而找出解决问题的思路。下面是一个服务发包失败记录的时间表实例：

数据也可以在日常研发过程中各种非正式场合下进行收集，如每日例会和各种团队交流等。

3. 触发灵感

“头脑风暴“是我们经常使用的一种触发灵感的活动，下面是需求和UI界面匹配问题团队成员之间一次简单的头脑风暴，通过讨论大家就工作流程做了一项改进：

表现端端开发人员：需求文档中的界面和UI效果图中的界面不是很一致，我处理起来要返工。
服务器端开发人员：我是参考需求文档中的界面设计的接口
需求分析师：嗯，两者应该尽量统一
项目经理：那我们以后UI效果图出来之后，BA和UED碰一下头之后再发布给开发

“5个为什么“也是敏捷领域比较推崇的一个过程改进实践，原理很简单但确实很有效。下面是对某项目服务器部署失败而进行的“5个为什么“分析，并最终确定开发人员在服务发布之前与发布人员进行沟通和确认是保证该流程正确执行的一项有效实践：

下面是一张”鱼骨图“，鱼骨图又叫因果图、石川图，是质量控制领域最具代表性的分析工具之一，也被广泛使用到过程改进中。图中从研发团队的各个方面出发找出导致开发效率低的原因，从而为我们后续的行动计划指明方向：

“学习矩阵”相对比较少用，但在有些场景下也是我们可以用来进行灵感触发的有效工具。如下图，针对分布式协作下的团队开发，我们首先总结做得好的和做得不好的方面，再看看有没有新的想法，如果实现不行我们也可以看看找谁帮忙，这些过程性成果都可以通过类似的学习矩阵进行细化和明确：

4.  决定做什么

关于决定做什么，虽然后续工作安排取决于具体的目标，但个人认为有两个方面我们需要注意：

• 关注流程：从点覆盖到面是我们梳理流程的一个目标。例如，从Jenkins打包失败这个点提出在流程上需要进行提交代码前先本地打包这一覆盖到面的改进；再如，从测试环境部署失败看流程问题的话就需要我们先搭建开发环境然后在发布前先部署开发环境。
• 使用SMART原则：SMART原则是指具体（Specific）、可衡量（Measurable）、可实现（Attainable）、相关性（Relevant）和有时间限制（Time-bound），是目标管理领域的一个核心原则。我们在指定行动计划时如何判断改进工作安排是否合理和可行很大程度上可以参考这一原则。

5. 总结收尾

当回顾会议接近尾声时，我们需要做会议总结，可以采用“+/?“方法。通过分析目前做的比较好的工作（+，代表需要进一步加强）和尚待改进的工作（?，代表需要进一步改进），团队成员在意识形态上达成一致有助于改进工作的顺利开展。下面是一个示例：

四. 关于周会

讲完回顾，讲一讲周会。传统型周会的议程和目的实际上就是进行团队信息同步，会议本身无可厚非，但通常大家都是把自己本周的工作像过流水账一样过一遍，往往流于形式而不能真正解决存在的问题。如果团队已经采用了类似Stand-up Meeting这样的工程实践、也使用Jenkins、Redmine这样的团队协作工具，又有规范的内部开发流程，个人认为通过这些流程和工具，团队信息同步的目的已经达到，传统型周会意义不大。周会如果要开，使用回顾会议的方式通常是更加高效的做法，回顾型周会的召开方式如下：

五. 小结

回顾是我们的武器，个人在推行回顾的过程中觉得一方面作为管理者要对研发过程中的“Smell“有充分的敏感性，能够推动回顾活动的正常运转；另一方面，我们也需要一种持续性的节奏，回顾是一项需要长期坚持的工作，这也是要取得过程改进成果的必要条件。

Retrospective--The Way To Make Things Better

标签：回顾   过程改进   

原文地址：http://blog.csdn.net/lantian08251/article/details/39943161