讨论:Scrum 回顾会议怎么开最有效?

发布于:2009 年 6 月 8 日 03:24

Scrum 中的回顾会议到底怎么召开更加有效?大家又遇到了什么样的问题?最近在 Google

敏捷中国邮件组中,网名克强的网友发了名为“

Scrum 中的回顾会议如何开?”的帖子,其中他提出了关于 Scrum 回顾会议的 8 个问题和大家进行讨论。这八个问题是:

  • 领导要参加,怎么办?
  • 会议达成的共识要不要以书面形式写下来?
  • 以 MSN 形式开回顾会议,有没有人实践过?
  • 是不是强制要求每个人都要发言?
  • 有什么典型的议程没有?
  • 时间长度上面,真的需要 3 小时吗?
  • ScrumMaster 在回顾会议时有没有特别不恰当的行为,应当避免的?
  • 还有其它问题?

网友们对于“领导要参加,怎么办?”这一问题异议最多。有网友抱着无所谓的态度,只要领导有兴趣来,就由他们来。而网友 Alsor Zhou 对领导的参与表示了坚决反对:

拒绝,一定要拒绝,特别是跟团队有直接从属关系的。否则,很容易造成“绩效考评”。

部分网友则有着完全不同的看法,网名为 Andy 的网友这么认为:

我们欢迎领导(特别是负责研发的副总)参加,希望他可以通过这个机会了解我们下一步会如何改进,为什么要改进,同时也更有机会获得管理层的支持。

对于其他几个问题,网友们的看法却都是惊人的一致:大家都同意把会议共识记录下来;都觉得不能强制每个人发言,但需要引导让每个人来发言;都觉得议程主要谈做得好的和需要改进的地方;都认为会议 1-2 小时足够了,这样不容易跑题。

大家同时还指出,对于回顾会议需要有一种开放的讨论环境,不能有人太强势,而且会议的结论是整个团队做出的,而不是个人。于是领导的话题再次被提出,当 Raymond 谈到“有没有特别不恰当的行为,应当避免的” 的时候,他指出:

最后一个发言,否则下属会被影响 。

在 Esther Derby 和 Diana Larsen 的《敏捷回顾》一书中,作者也提到了关于邀请项目以外的人(包括领导)来参与回顾会议的问题。他们认为迭代中的回顾会议大部分应该集中在团队内部,而对于一个正式发布或者项目结束时候所做的回顾会议应该邀请些对项目有所付出的编外人员,其中可能包括项目管理层和客户。作者认为

发布一个产品所涉及的人比一个增量开发要多得多。适时地停下来,深入并且发散地想想你是怎么跟他们一起合作的。你可以选择有助于达到你回顾会议目的的人来参加。你要去寻找那些在项目中也扮演重要角色,同时愿意分享他们观点的人。

各位 InfoQ 的读者,你对这些问题又是怎么看的呢?欢迎加入讨论。

阅读数:2059 发布于:2009 年 6 月 8 日 03:24

更多 敏捷、Scrum、文化 & 方法 相关课程,可下载【 极客时间 】App 免费领取 >

评论

发布
暂无评论
  • 你的敏捷组织应该关注什么?

    采用敏捷并不容易。许多组织通常努力想从Scrum或XP实践中抽取些实践,运用到他们的工作中去。Mike Cottmeyer提醒这些组织,在敏捷的实施方式上关注太多可能并不是条明智的路。

    2009 年 6 月 18 日

  • 图书摘录:敏捷开发者实践

    想要成为更好的开发人员吗?本书收集整理了一些成功的敏捷软件开发者的个人习惯,想法和开发方式,并把它们组织成简短、易于理解的提示呈现给读者。

    2007 年 4 月 30 日

  • 向上沟通:你必须要注意的三个误区

    优秀的向上管理能力,不只是对你个人有利,对于项目和团队,都是福音。

    2019 年 12 月 5 日

  • 特别放送(二)| 一篇文章带你了解参与开源社区的全部流程

    参照着这套最佳实践,你能够轻松地参与到社区的日常开发中,甚至是成为社区Contributor中的一员。

    2020 年 5 月 12 日

  • 客户应该在意敏捷吗?

    在敏捷项目中,客户的参与被视为理所当然,然而,很多时候(自觉或不自觉地),客户可能对这个敏捷实践有所抵触。在极限编程讨论组有个很有趣的讨论,试图解释这种情况,并找到可能的解决方法。

    2008 年 3 月 18 日

  • 第 15 讲 | 定制高效研发流程

    当我们的研发团队组织架构搭建完毕后,接下来需要思考的是,如何让这个架构跑起来、跑得快、跑得稳。

    2018 年 5 月 9 日

  • 特别放送(一)| 经典的 Kafka 学习资料有哪些?

    借着这个特别放送的环节,我专门为你搜罗了各种Kafka学习资料,并把它们做成了清单,一起分享给你。

    2020 年 4 月 25 日

  • 【架构思维学习】 week02

    依赖倒置原则指的是高层模块不应该依赖底层模块,而依赖底层模块的抽象接口,同时,底层模块的实现依赖于抽象接口,而不是抽象接口依赖于底层模块的实现。

    2020 年 6 月 17 日