回顾会议的反思 - Retrospectives(译)

Page content

retrospective-infoq

回顾会议是Scrum的一部分,用来反思完成的工作,从而帮助团队提高(自组织和定期调整)。然而,我目睹了许多团队的回顾会议,他们会议变得单调地重复或者变成“形同虚设的会议cribbing sessions。”回顾会议往往就得到扩展(不是在限定时间内完成),并且通常不产生任何实际的改变(业务价值),也不识别和解决问题。

如果回顾会议进入这种状态,那么是时候改变了,你应该引导团队并且关注于给出会议的方向 ,确保回顾会议在时间盒内并且最后有可量化的行动项。

为无方向的回顾会议给出方向

如果团队想要走出这种困境,通过建议讨论的主题而给出一个会议结构(日程),很可能是个不错的注意。下面是一些有用的建议:

  • Sprint planning: 我们的计划够好吗?在迭代中碰到问题了吗?
  • 每日站会: 我们如何有效的开每日站会?
  • 持续集成: 为了提高效率,还有哪些可以放到持续集成内的?
  • 时间盒交付: 我们能交付承诺的内容吗?
  • PO的反馈: PO在澄清需求方面是如何回应的?
  • 协作: 我们(团队)之间是如何协作的?
  • 回顾会议: 通过回顾会议我们有所经验和教训吗?

你可以根据自己的环境和需要调整上面的列表。

关注问题的数量而不是质量

为了避免主观或定型的发言,建议团队使用一个打分系统(从1-最低到10-最高)。调查结束后,团队就会得到一个当前迭代的平衡计分卡,因此很容易找出表现最好和最差的地方。

Retrospection Score Card

下面我们看一下

如上图,团队能够发现强项和弱项的地方,然后可以选择最好的(1或者2项)和最差的(1或者2项)进行讨论。(译者注:最好的1项和最差的1项,在上图中是协作和时间盒集成)这就是我们的回顾会议要做的事情,如何改善弱项,以及如何进一步提高强项。

持续地监控回顾会议

这些分数给了团队开会和讨论的结构化的方法。然而,做为ScrumMaster,定期监控会议的价值也是非常重要的。因此我建议你维护一个所有迭代对比的趋势报告。如下图:

Retrospective Trending

通过分析过去几个迭代的进展,你应该可以识别出以下点(译者注:参考上图的Trend列):

  • 低谷期: 持续得分很低的问题或者有下降趋势的问题。
  • 平台期: 相对稳定但还没有达到“绿色区”的问题。这可能表明团队中酝酿着停滞或漠不关心的情绪。
  • 顶峰期: 团队持续改进的方面,或者在相当长时间内维持在“绿色区”的方面。

在某些点,可以考虑从计分卡中移除“顶峰期”并引入新的主题,从而可以保持关注于低谷期和平台期。这会帮助你从不同的方面评估立足点以及帮助突破团队内单调的风险。

Project Health Chart

正确使用回顾会议时,它可以洞察团队的健康度并突出改进的范围。如果不满意你的回顾会议,那么改变它!

原文链接:https://www.scrumalliance.org/community/articles/2013/december/introspect-the-retrospectives