敏捷开发智慧三:每日立会开多久?

缘起

甲:“我们每日立会会开不起来。”

乙:“嘿,我们每日立会开起来了,而且越开越长了,一开就是1个小时,净是些技术细节。”

甲:“别人等着他们讨论,那多耽误时间啊……”

乙:“我也觉得是,但是看他们交流得那么热烈,讨论的也是正事,到底应该打断还是不打断呢……”

为什么每日立会只开15分钟?

我们说绝点:每日立会只能开5分钟,而不是15分钟。

这5分钟说点什么呢?应该说必须开会才能说明白的东西。

先看两个团队,他们有什么是需要开会说明白的。

第一个团队,10个人,平时分工细致,各干各的,谁也不干扰谁。

这个团队,开会的时间肯定不短,因为所有交互问题都需要开会解决。

第二个团队,10个人,平时分成三个小组,小组内随时沟通,小组间有需要就沟通。

这个团队,开会的时间肯定短,因为三个小组长发言总结自己组的进展就可以了,会上只需要碰碰组间的沟通。

敏捷开发实际上在假设大家平时像第二个团队一样一直在互相沟通(即使不分成三个小组),但是却很少以整个团队的形式沟通整体进展,所以才创造了15分钟的周例会,当然也能顺便把忘了沟通的人链接一下。如果这个本来作为补充性质的周例会变成了组内唯一的沟通渠道,就出问题了。

所以,开会时间长,往往不是沟通充分的表现,而是沟通不充分,只能赶在会上沟通的表现。

团队应该怎样沟通?

团队应该随时就技术细节进行沟通,而不需要等待开会。而对于3~5个人的团队,组长如果除了开会居然不知道整个组的进展,那么沟通是极其不顺畅的,要解决的不是每日立会的问题,而是平时沟通的问题,比如采用师徒制度、松结对编程等(请参考其他系列博文)。

这种会议甚至在更大的规模上,也能淡化。

我们曾经试图在一个由销售、市场、支持三个部门15个人的组中间开周会,开了大约几次后就取消了,原因是我们仔细安排了位置,使得总监和三个经理一起坐在中间的大桌上,而其他队员则坐在四周。因此组间的沟通在大桌上随时就完成了(做了个4个人都能看到的大屏幕),而组内的沟通则一回脸就完成了。所以发现几乎所有的事情大家都知道差不多了,会上也只是重新说说而已,开或不开都可。

因此,应理解每日立会、计划会、评审会、反思会这些会议,都只是沟通过程的仪式化的补充,若沟通本身不畅,而只是指望这些会议完成沟通,肯定会陷入两难的境地。

“每日立会”的常见做法

1~4人团队

这个规模的团队,优先使用139团队结构和松结对编程方法,即由师傅(小组长)密切地与徒弟们沟通。这会涉及到沟通管理、时间管理、过度沟通、有效生产率等问题,在链接的系列博客中有所详述,都不是问题。

这个规模的团队应该不开立会,而是更密切的交流方式。它的运行方式更像XP,而非Scrum。

5~9人团队

这个规模的团队,优先划分为2~3个小组,每个团队仍按松结对编程方法运行。

由于人多了,组间难以沟通,所以开个立会是必要的,主要目的是组间进度沟通,因此不会发生技术沟通(这是组内的事情),所以也不可能超时。

小组长应把握好应该如何与对方组沟通、沟通什么的问题。

更大型的团队

更大型的团队,则推荐组长+小组长参与开超级立会,组员不参加。

这类会议也是进度沟通会,所以不会涉及技术沟通。

为何不让ScrumMaster们开个会议?因为专职的ScrumMaster不负责技术、进度、质量这些事情,真正对这些熟悉的,是团队组长和核心骨干。

后面两种会议,很像是“ScrumofXPs”,而不是“ScrumofScrums”,前者的沟通性更强。

相关推荐