站立会议变形记
 

2011-06-15 来源:网络

 

站立会议对于Scrum的意义,就像我们每天早上起来总是希望看看报纸,听听新闻,了解每日时事,关心国计民生。站立会议有助于Scrum Master以及整个团队了解项目进展情况,以便于控制项目进度,掌握团队成员的开发效率,促进成员之间的交流与沟通,并使所有成员对整个项目能有一个全面的认识。

站立会议的重要性不言而喻。如何遵循Scrum的原则开展好每天的站立会议呢?我在推行的Scrum实践中,发现站立会议总是会随着项目的进展,慢慢地发生变形,最后甚至会变得物事人非。幸运的是,每日的会议却没有理由地达成了Scrum的目的。那么,在Scrum开展站立会议是否一定要极为死板地遵循Scrum的原则?我认为未必。以下是我在推行Scrum过程中的一些粗浅认识。

1、站立会议一定要站立吗?

Scurm 要求会议的所有出席者都应站立,这样就可以保证会议能够在足够短的时间内结束。这似乎恶意地猜测了开发人员都是一群懒鬼,是一帮能够坐着就不愿站立的家伙(难怪Scrum对团队人员定义为“猪”的角色。虽然这表明猪在开餐馆过程中是全力参与者,不过在我们中国人的涵义里,其实还是懒惰的代名词。当然另外一种解释是幸福);同时又善意地帮助开发人员锻炼身体,有助于身体健康。

让我们看看在每日会议中要求站立的初衷是什么?没错,是要保持会议足够简短。那么换个角度来说,只要能够保证会议足够简短,谁还在乎参会的人员是站着,坐着,还是躺着呢?或许有人说,站立的要义不仅如此,实际上还能够要求参会人员能够比较清晰地看到任务墙上的内容,了解Burndown。没错,确乎如此。不过,如果与会人员能够围坐在一张大长桌的三面,同时看着另一面的任务板,似乎也不为过。尤其让我们想想,一旦参与站立会议的人数增多,而开发人员又是高矮不平,谁能保证个子矮小的开发人员一定能够站在前面。我发现,只要参加站立会议的人数增多,站立在外围的人员就会产生一种隔离感与孤立感,从而会抱着一种旁观者的角度,无法投入参与者的热情,最后呆站在那里人云亦云。会议结束,作鸟兽散。

所以,Scrum的每日会议最关键的不是开发人员的姿势,而是参与的热情,以及会议的效率。一个好的会议主持者(通常是Scrum Master),比站立会议的形式更重要。

2、一定要问完三个问题吗?

Scrum站立会议要求每个团队成员回答三个问题:

1)昨天你完成了哪些工作?

2)今天你打算做什么?

3)完成你的目标是否存在什么障碍?

这三个问题其实都与任务有关,我总结为三方面:任务回顾,任务分配以及任务障碍。任务回顾有助于帮助我们跟踪项目进度,并了解团队成员的开发效率。任务分配能够再次强调每日要完成的工作,从而产生一种紧迫感和成就感。开发人员在每天的工作中,能够带着目标开展工作,会比混乱无计划的开发方式提高数倍的效率。至于任务障碍,则能够让团队人员及时获得反馈的问题,并由Scrum Master决定是否需要进一步讨论,并制定解决的办法与解决的人。

但在实际操作中,我发现很多开发人员对这样的章程有些不以为然。久而久之,这样的问题与回答渐渐成了表面文章。说的人轻描淡写,听的人则报着“各人自扫门前霜”的态度。这样的站立会议会显得非常沉闷,拘于流程,最后慢慢消磨掉每个人的热情。

其实,只要有一面足够醒目的任务墙,那么完全可以将前两个问题从口述转变为行动。完成任务的,就在任务墙上移动一下任务;正在进行的,就去更新一下自己的进度。会议室会成为热热闹闹的蜂巢,开发人员行走其间,就像一群辛勤的工蜂。而Scrum Master则站在旁边,就像蜂皇一般,最后由他总结陈词。

效果如何?我没有明确的答案,不过大可以尝试。不要将站立会议搞得像婚礼教堂似的。神父与新郎、新娘每次都重复同样的问题,同样的答案。听过一次是心动,听过二次是感动,听过三次、四次以至于N次,那就是无动于衷了。

3、站立会议时间最好在早晨

Scrum 会议只要求会议在固定地点和每天的同一时间举行。但一般的实践还是建议在早晨举行。不是因为“一日之际在于晨”,而是因为早晨是工作日的开始,基本上也可以看作是上个工作日的结束。我因为工作时间的缘故,曾经在一个项目组担任敏捷教练时,要求将站立会议设定在下午两点钟。结果我发现很多开发人员在进行任务回顾和任务分配时,都找不到感觉。为什么?因为他需要把昨天下午和今天上午连接成一个工作日。这违背了我们的日常习惯。就好象我们在最初学二进制的时候,总是感觉那么的别扭。

安排在早晨还有一个好处。开发人员在开发过程中总希望找到一种状态,就像运动员走向赛场需要发挥自己的临场状态一样。每日清晨到公司上班,总要有一小段时间作为调节期。站立会议恰好是一次完美的“热身”。会议是壮行酒,会议结束,大家就该奔赴战场了。

唯一有个缺点是容易导致人员不齐。一般公司的工作时间是9点开始,只要不是需要严格考勤的公司,总会有个别员工出现迟到现象。如果安排在10点开始,通常不会出现人员不齐的情况。但对于习惯了在站立会议之后开始工作的开发者而言,这就意味着工作时间被不知不觉浪费掉了一个小时。所以,我们在对任务进行工作量评估时,不得不考虑种种看似不经意的损耗。当然,我们可以对迟到进行惩罚。不过前提是不要牺牲团队的团结。氛围很重要。



由外而内看敏捷软件开发
架敏捷开发中史诗故事与用户
看板任务管理
面向全球化的有效敏捷交付
小型团队快速开发方法
DevOps,不是一个传说!
更多...   


统一过程及应用
敏捷过程实践
基于XP/RUP的迭代开发
软件开发过程指南
SCRUM过程实践
敏捷测试-简单而可行


某博彩企业 产品经理与产品管理
北京 研发团队与工作管理
广东金赋信息 敏捷开发过程与项目管理
某支付平台 软件配置管理与发布管理
富士 软件外包项目管理与进度管理
塞孚耐 基于Scrum的敏捷开发
更多...   
 
 
 
 
 

组织简介 | 联系我们 |   Copyright 2002 ®  UML软件工程组织 京ICP备10020922号

京公海网安备110108001071号