敏捷其实很简单(15) 回顾会议

版权声明:本文为博主原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接和本声明。
本文链接:https://blog.csdn.net/superkunkun/article/details/54293240

其实个人以为,回顾会议在scrum所有的events中是最重要的一个
这里写图片描述

正如上图所示,我们可以看到在整个scrum的价值流上,每个会议都有不同的对应意义:

planning meeting用来将目标分解并给团队,standupmeeting 则用来对team每天的工作进行跟踪,review meeting则是检视和调整目标,以适应当前的工作状态,而retrospective meeting则是team用来进行持续改进的一个过程。

所以从敏捷的核心价值–持续改进来说,回顾会议也是相当重要的一个环节。

关于回顾会议的意义,内容等,笔者在这里就不在多说了,因为很多文章和书籍都已经讲述了这个会议的重要性。那么在这里,笔者希望从个人的经验来阐述一些点,能够更好的进行回顾会议,从而让这个会议更好的为团队持续改进而服务。

这里写图片描述

1. 回顾会议不仅仅是回顾,更重要的是着眼于未来

很多团队在召开回顾会议的时候,更容易把它变成一个lession learn,找出做的不好的地方,然后总结经验等。这样做并没有什么不好,但是要注意的是,回顾会议更注重的是在下一个迭代我们要如何做才能做的更好,而不仅仅是总结以前失败的经验教训。团队要带有一定的目的性,就是在回顾会议上要形成真正的“决议”,这些“决议”能够对即将到来的迭代有更好的正面促进作用。这样才能使得回顾会议真正的成为一个不断推进团队进步的催化剂。

2. 回顾会议不能解决所有事情,它应该注重在最迫切的一些需求上

笔者在辅导过的一些团队中,往往在回顾会议上,大家打开了话匣子,气氛非常热烈,也有很多中肯的建议和看法,但是,我们要知道,一个迭代只有1-2个小时的回顾会议,实际上是解决不了很多的事情的,所以教练在这里要辅导团队,把视野看的更高远一些,让团队成员的思路更high level一些,找出2,3个点用来让团队在下个迭代做的更好,这样也可以更好的集中团队资源来进行一些改进。

3. talk is cheap, show me the action

回顾会议很容易转变成吐槽大会,因为团队会在开发过程中发现很多问题,但是有一些问题却不是团队自己能够处理或者搞定的,或者大家只是提出问题,并没有提出解决方法等,这样长期下来,回顾会议就会变成一种形式主义,大家的参与度也不会很高。所以团队要在每个迭代会议之后,列出一些迫切要解决的问题,并且提出一些切实可行的解决方案,并且指定owner,这样来保证在下个迭代,这些方案能够执行并起到效果。同时如果是团队无法解决的问题,也要记录下来,反馈出去,找相关负责人,看看能否尽快解决。

当然了,要做好回顾会议还需要很多工作要做,这里我只是提出了一些自己在这方面的一些经验之谈,如果大家有兴趣,我们还可以进一步的讨论这个话题。
最后一句话送给那些总是说太忙了,无法参加或者召开回顾会议的人们:

是的,他们是太忙了没有时间,他们总是忙于把时间用来生产错误的产品上。。。

展开阅读全文

没有更多推荐了,返回首页