Retrospective--The Way To Make Things Better

本文讨论回顾(Retrospective),使用英文做文章标题有两个方面原因:一个是回顾这个词现在很多人都在用,从中文字面上看可能对它并不感冒,觉得回顾是一件很简单可做可不做的事情,但事实上做回顾很难也很重要,所以用一个看上去很多人都不一定认识的英文单词来做强调;另一方面文章的副标题用的是“the way to make things better”,个人很喜欢这句话,觉得我们日常的工作、学习、为人处世不就是想把事情做好一点吗,所以用这句话和大家共勉。

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

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

在项目/产品研发过程中的某个时段,结合并不成熟的团队状况,或多或少会面临研发管理不合理的现状,比较典型的有:

  • 多项目交叉
  • 分布式、多部门协作
  • 开发资源、任务并行
  • 项目缺乏计划性
  • 产品缺乏创新点

这些现象导致的结果归根结底就是进度上的问题,无论是项目按计划验收还是产品根据市场快速做出反应,时间永远是软件企业最需要把控的一个核心要素,对互联网公司更是如此。但当因为研发过程中产生这种那种的问题导致进度不尽理想时,大家有想到要做些什么吗?

要做的事情有很多,个人认为首当其冲的就是“Stop And Thinking”,包括两个主要方面:

  • 检视(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“有充分的敏感性,能够推动回顾活动的正常运转;另一方面,我们也需要一种持续性的节奏,回顾是一项需要长期坚持的工作,这也是要取得过程改进成果的必要条件。

时间: 2024-10-26 09:10:19

Retrospective--The Way To Make Things Better的相关文章

Agile实践日志(2)-- Daily Stand up 和 Retrospective Session

Agile实践日志 (2) -- Daily Stand up 和 Retrospective Session 在Scrum开发过程中,会有三种会议: Grooming (详见Agile实践日志(1)) , Daily Stand up 和Retrospective Meeting Daily Stand up Sprint期间,每天早上小组成员需要在固定的时间地点进行,时间大约15分钟.主要介绍一下昨天做了什么,今天需要做什么,信心完成指数(1-10) Done 昨天完成的 ToDo 今天要做

敏捷开发

学习内容: 敏捷开发 Agile Development 是一种软件开发流程,开发方法,能够知道我们按照规定的环节一步步的去完成项目的开发任务,主要驱动核心是人,采用的是迭代式的开发. 是相对于瀑布开发模式的缺点改进的一种开发模式,就是把一个大项目切分成多个子项目,然后分别开发.测试. 是以用户的需求变化为核心,采用迭代和循序渐进的方式进行软件开发. 四句开发宣言: 个体和互动  胜过     流程和工具 可用的软件    胜过     详尽的文档 客户合作 胜过     合同谈判 响应变化  

什么是敏捷开发?(扫盲)

敏捷开发的4句宣言 个体与交互 胜过 过程与工具 可以工作的软件 胜过 面面俱到的文挡 客户协作 胜过 合同谈判 响应变化 胜过 遵循计划 最近一直听人说"敏捷开发",一脸懵逼,根本不知道什么是敏捷开发,然后百度了一下,上面四句是比较普遍的总结! 什么是敏捷开发? 敏捷开发(Agile Development)是一种以人为核心.迭代.循序渐进的开发方法. 怎么理解呢?首先,我们要理解它不是一门技术,它是一种开发方法,也就是一种软件开发的流程,它会指导我们用规定的环节去一步一步完成项目的

敏捷开发——杂记

春节回来后的第一个加班,不知道为了什么而加班,一头雾水.毕业到现在半年多,感觉什么也没学会,春节前一直强调的去敏捷开发,开了各种会,但我还是啥也没理解,尤其是团队的领导每次开会都是50%的英语,我完全没听懂,在这了感慨下英语的重要性,先进的理念.思想多是来自国外,不得不感慨英语的地位. 但前段时间发现一个网站,关于敏捷开发的,对于新手小白来说很值得看看.我暂时没有把网站分享给团队成员,想自己先悄悄学.这个从心理学上的角度来说,可以称作优越感,我能学到别人暂时学不到的东西,我若是先别人学会了,心里

Scrum-回顾会议

回顾会议要求每个人都发言.SM会事先将sprint过程中的主要事件节点和遇到的issue在白板中标出,同时也要求team成员列出做的最好的和需要改进的 具体:Retrospective会议的时候,发便帖给每个团队成员(包括Team Leader),给大家15-20分钟自己写下自己觉得过去迭代中做到好的事情,还有做的不好(或者待改进的事情),写完贴到白板上,对所有的事情归类汇总,大家一条一条过,并且进行讨论.最后选出TOP 3 GOOD THINGS和TOP 3 NEED IMPROVEMENT.

URBS:Non-Uniform Rational B-Splines

Maxim Shemanarev wrote: > Well, that's too big topic I suppose. Jens somehow right, we need to stop at > some point. I think that NURBS will be just the right case to stop. I didn't have  intention to go wild either. However, in order to understand 

隐匿性乙肝病毒感染:一种秘密行动

Journal of Viral Hepatitis Occult Hepatitis B Virus Infection: A Covert Operation F. B. Hollinger, G. Sood Disclosures Summary and Introduction Summary Detection of occult hepatitis B requires assays of the highest sensitivity and specificity with a

一步步学敏捷开发:5. Scrum的4种会议

在Scrum会议中包括:计划会议.每日站会.评审会议和回顾会议. 1.Sprint计划会(Sprint Planning) 在Scrum中,Sprint计划会议有两部分:1. 决定需要完成哪些工作?2. 决定这些工作如何完成? 第一部分:需要完成哪些工作?参会人员:Team.Scrum Master.Product Owner第一部分的会议,产品负责人向开发团队介绍排好序的产品待办事项,由整个Scrum团队共同理解这些工作.Sprint中需要完成的产品待办事项数目完全由开发团队决定.做多少工作只

谈谈我理解的敏捷开发

"敏捷开发" 几乎成了互联网家户喻晓的一个热门话题.每个人都在聊敏捷.Scrum.XP. 我对"敏捷"的认识还算是在一个正在探索的阶段.网上有非常多的资料,五花八门,对于初学者来说无形之中会设了很多的坎.刚好借此机会写个文章帮助自己进行知识的梳理和总结,另外一方面也希望对刚接触的人有所帮助. "敏捷开发" 知多少? 敏捷开发(Agile Development)是一种以人为核心.迭代.循序渐进的开发方式. 它并不是一门技术,而是一种开发方式,也就

(转) A Survival Guide to a PhD

A Survival Guide to a PhD Sep 7, 2016 This guide is patterned after my “Doing well in your courses”, a post I wrote a long time ago on some of the tips/tricks I’ve developed during my undergrad. I’ve received nice comments about that guide, so in the