InfoQ

新闻

每日站立会议怎么开?

作者 Amr Elssamadisy译者 徐毅 发布于 2008年5月29日 下午9时34分

社区
Agile
主题
敏捷技术
标签
采纳,
自组织团队,
Scrum

在那些最简单也最常谈起的敏捷实践中,每日站立会议(又称作每日例会)就是其一。Jeff Martin 在scrumdevelopment Yahoo! 邮件组中问道:

我搜索过相关知识却一无所获,我想我一定是用错了词。谁能给我一个每日例会的范本?我们遇到些困难,导致有些团队成员想取消会议,或是一周只开两次会。
这个问题得到了很多回复。Marcie Jones认为原因在于(缺乏)推动会议进行的技巧
1)你自己千万别迟到(呃……)。作为Scrum Master,这不但是个坏榜样,还将你不重视团队的时间或每日例会这样的信息传递给他们。如果他们没感受到你对每日例会的重视,为什么他们得照做?

2)按时开始。不在乎团队的时间人才会说“我事情刚做到一半,再等我五分钟好吗?”。如果因为这些原因频繁推迟会议,这就又一次告诉大家会议是不重要的,但其实它真的应该是一天中最重要的部分。

3)如果前两条都做不到,那么试试换个时间举行每日例会。不过你得清楚改变时间并不会解决根本的态度问题。

4)中止不合时宜的讨论。即使你整天都在扮演“团队成员”角色,每日例会的时候,作为Scrum Master你就得站出来主持会议。你有权要求人们不要在会议上讨论,或是保留到会议结束后再继续。这可不容易,你得保持立场坚定才行。

5)要是汇报的状况不够清楚,就要多问些问题。不要只是告诉他们“要更新任务的信息”或“你做错了”。要是你一直在跟他们交流,那就通过在每日例会上问一 些引导性的问题,例如,“这件事情有什么新情况?”,“你决定如何处理那件事情?”,“你有没有曾经因如此这般的方法得到如此这般的结果?”。或是从人们 问的问题中学习,或是从困难中汲取教训,团队最终会发现信息应该详细到什么地步为妙。

6)尝试解决这些问题时,先征求团队的同意,在下次迭代中继续保留每日例会。向他们保证如果情况没有任何改善,就变成一周两次。然后信守承诺。先这样做再说。反正只要有回顾会议,你总有机会可以选择变回来。

Artem Marchenko认为每日站立会议的规则很简单,范本没什么用

把每日例会最简化以后,它就变得非常简单,僵化的范本恐怕没什么用。手势、眼神、语调以及信任感可能更是你想要的,在有需要的时候,这些才是Scrum Master(以及团队成员)可以真正发挥作用的地方,但范本很难反映这些要素。
下面是Scott Weber推荐的一个范本(顺便说一句,很多人都不同意Scott,认为这个建议太过倾向于命令控制方式)
Scrum Master :Scot,昨天你都完成了些什么?
Scot :我把任务X和Y做完了,但是在Z上遇到了困难。我想我需要Jon来帮助我。
《假设Jon有否时间是问题》
Scrum Master :Scot,你今天都准备干嘛呢?
Scot :和Jon一起完成Z任务,然后开始做AA。
[[如此循环直到团队最后一个人完成讲话]]

稍后Scott指出:
自我组织团队是Scrum梦寐以求要实现的目标之一,那表明开发团队成员(不见得都是工程师)已经具备有效参与并融入团队的能力。
在讨论中,有些人提到了几篇讨论每日例会的精彩文章:Simon Baker从整体上讲述了每日例会(包括鸡和猪的经典笑话);Mishkin Bertig讲了一些问题现象;Jason Yip则通过模式的形式来讲解。

从概念上讲,每日例会非常简单,但往往团队要采用却并非易事。如果要将我们的敏捷规则应用到每日例会上(敏捷的变种),我 们必须非常清楚每日例会的目标,这样才能“验证”各种特殊情况下每日例会是成功还是失败。可惜大多数讨论都没有把这个目标讲清楚。在这个主题里,会议的目 的也只是被一笔带过,却从未被直接拿来讨论。

你怎么理解每日例会的目标?以上这些实现能否帮助你达到目的?

查看英文原文What Makes a Good Stand Up Meeting?

3 条回复

回复

国内原来的项目经理,总想着把项目进度抓牢,这种会议尝试开过很多,只是不要走入形式就成. 发表人 deshi xiao 发表于 2008年5月30日 上午7时56分
Re: 国内原来的项目经理,总想着把项目进度抓牢,这种会议尝试开过很多,只是不要走入形式就成. 发表人 Junyin Wu 发表于 2008年6月2日 下午9时35分
一周1-3次的讨论会议更合适,每次10-30分钟。 发表人 远 刘 发表于 2008年6月4日 上午1时46分
  1. 结合这篇文章,确实对改进在国内管理项目的尝试方法.

  2. > 只是不要走入形式就成. 很赞同这句,其实站立会议的目标就是让项目成员相互了解对方的工作,然后去发现有什么问题,以及如何解决问题,只要能够了解进度,发现问题,至于那种形式应该是次要的问题。

  3. 返回顶部

    一周1-3次的讨论会议更合适,每次10-30分钟。

    2008年6月4日 上午1时46分 发表人 远 刘

    一周1-3次的讨论会议更合适,每次10-30分钟。

独家内容

从卓越工程角度看微软中国开发团队的成长

开发团队的成长离不开优秀的人才,简捷有效的流程和高效率工具这三个卓越工程系统中的重要因素。本文作者从这三个因素分析了微软中国开发团队是如何“从优秀到卓越”的。

利用Ruby简化你的Java测试

本文是Productive Java with Ruby系列文章的第一篇,我将从单元测试这个话题开始,让Java的开发人员能够在实际工作中利用Ruby提高工作效率。

与赵进聊SaaS

InfoQ中文站有幸与阿里软件的首席架构师赵进在一起探讨了SaaS的相关话题,包括SOA和ASP与SaaS的异同、云计算、SaaS的前景、它的关键技术、技术瓶颈等等。

在ESB中选择路由还是编配?

在这篇文章中,Adrien Louis和Marc Dutoo在一个典型的ESB场景中讨论了编配和路由的区别和优缺点。他们讨论了几种连接服务的方法,从使用如自定义路由这样的低级别方法,到使用如工作流和编配这样面向业务的高级别方式,并总结说不存在“一边倒”的解决方案。

分布式系统中的一致性和可用性

本文是根据7月26日InfoQ中文站在杭州举行的QClub活动(第三期)后半程小组讨论总结而成。主要内容包括如何在SOA系统中实现服务编排,如何保证分布式系统中的一致性和可用性,以及如何在实施SOA的过程中控制接口的粒度等。

虚拟化导论

人们很容易想当然的以为虚拟化技术仅仅应用于服务器。而在现实中,虚拟化这一苏醒的概念正被运用于各个层面,其中包括网络,存储以及应用基础架构。在这篇导论中,InfoQ将深入每个方面,详尽向您描述虚拟化技术的运用以及其优点与不足。

用户故事估算技巧

作为开发者,同时也是ThoughtWorks的咨询师,Jay Fields总结了自己估算用户故事的有效技巧。

InfoQ案例研究:纳斯达克市场回放

在这篇案例研究中,InfoQ对Adobe AIR和Amazon的简单存储服务(Simple Storage Service ,S3)在NASDAQ市场回放程序(NASDAQ Market Replay)中的应用进行了详细的分析。