BT

如何利用碎片时间提升技术认知与能力? 点击获取答案

大型团队能使用站立会议实践么?

| 作者 Vikas Hazrati 关注 0 他的粉丝 ,译者 郑柯 关注 3 他的粉丝 发布于 2009年5月12日. 估计阅读时间: 4 分钟 | GMTC大前端的下一站,PWA、Web框架、Node等最新最热的大前端话题邀你一起共同探讨。

每日立会能够帮助团队看到对于迭代目标的进展情况。它的目的是要为团队成员奠定坚实的基础,让大家知道彼此承诺当天要完成哪些工作,并识别前进道路上存在的任何障碍。虽然传统的站立会议给敏捷团队带来很多好处,然而很多敏捷专家相信:传统的站立会议将会随着团队人数的增多而马上失去作用。

Dave Nicolette提到:

只要团队数目不是太多,层次不超过一层,scrum-of-scrums就能起到很好的效果。一旦项目人员到了差不多25~30个人,就得切分成多个敏捷团队,每个团队的人数也要适合;不过这时我们就会遇到后勤准备上的问题,交流效果也会下降。Scrum-of-scrums方式的倡议者们说它可以线性扩展,不过我的经验却不是这样。实际上,随着scrum-of-scrums会议层级的增加,管理耗费成本的相对数目会增加。如果有团队需要其他团队的信息,这样的结构就会将这样的团队推得越来越远。我们就会开始遇到敏捷出现之前的那种沟通问题,许多交流也都变成了间接方式。

Jason Yip提到了 较大团队会遇到的类似问题,在他看来:

在较大的团队中,每日立会很容易出现士气低落与投入感不够的问题。会议很快会拖得越来越长,而人们在人多的场合也变得缺乏热情。

David J. Anderson提到即使无法阻止大型团队开展站立会议,然而这并不等于说:在scrum每日立会中出现的团队精神和同事之间的压力就会完全消亡。

Dave同时指出:在较大的团队中,关于工作任务的讨论很难把条理弄清楚。实际上,任务的具体情况与团队成员的发言顺序有关。结果就是,话题的焦点很快就偏离了具体任务。

Corey Ladas同样表达了自己的担心,他担心较大团队使用的scrum of scrums在沟通策略方面会出现问题 。他还提到scrum of scrums的层次会随着人员的增加而不断增多,这其实是不能扩展的,而且也不够精益。

那么大型团队应该如何开站立会议才能取得最好的效果?

Dave建议使用 ‘’‘Walk the task board’ 式的站立会议。根据他的说法,他会为团队设立一个任务板。团队不必再回答那三个标准的问题。团队成员会根据自己对进度和问题的理解,移动任务板上故事卡的位置。这将工作的完成状况保持在了故事的层面,而且能展示出项目的进度。 InfoQ上有个类似的帖子 提到了以故事为核心的站立会议,指出这可以用来替代以人为核心的站立会议。

Jason Yip提到一个供大型团队主办站立会议使用的鱼缸式对话方式。他指出:

在这种[鱼缸式的对话]方式中,每个小团队出一个代表,围成一圈;其他各个团队站在周围观察。真正发言的参与者数目很小,这可以加快速度;而团队代表受到团队其他人的监督,这就很难出现信息传递错误或是掩盖的情况。

在实践中,这种形式仍然无法阻止任何大型团队中的某个团队从流程中脱离开来,不分享任何信息。但是相对于一大堆人开站立会议来说,我仍觉得这么做让人更有力量,参与感更强。

Brian Marick建议使用行动者网络理论式的站立会议,该形式同样以故事为中心。在这种形式中,不是一个人一个人地发言,而是团队会把相关的用户故事过一遍。对于每个故事,会有一个团队成员出来说昨天针对这个故事发生了什么,今天要对它做什么,以及要完成该故事会有哪些风险。

因此,有些敏捷专家相信scrum of scrum这样的实践只能扩展到某种范围。大型团队需要另一种方式举行快速而有效的站立会议。基于故事的站立会议听起来很适合大型团队使用。您在大型团队中采取了哪些策略?

查看英文原文: Do Stand-ups Stand Up for Larger Teams?

评价本文

专业度
风格

您好,朋友!

您需要 注册一个InfoQ账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

疑问 by Liang Vincent

其实scrum是否适合大型团队的协作项目呢?

担心敏捷有向大方法论靠近的倾向 by He Yiding

也许管理方面的问题从来就没有简单的解决方式。

立会? by uno tom

我还是喜欢坐沙发开会

大型项目/团队 与 敏捷 by Chan Jackei

当团队逐渐变大,项目也越来越复杂时,通过会议方式来了解和管理进度就变得不切实际。因为考虑到每个 team 最好控制在5-8人──如果多了 team leader 的管理可能就流于形式了──那么一个200人的项目,很容易变成30-40个小team,如果再将此根据职能不同分为5-8个 feature team 或 function team,function team 之上再设置一个 PMO,那么整个项目团队就变成了4个 levels,而function team leader 和 PMO 的大部分时间,可能都会被消耗在了解工作进度和开会上,而不是关心项目中需要解决的突出问题──并不是说开会不重要,但是估计这种情况下,只能是参与会议,而缺少足够的时间思考和行使职责了。
所以,大型项目就需要有一些更好的流程/方法/工具,来简化工作汇报、任务进度同步、计划任务通知 以及 资源使用情况统计协调 方面的时间。

对于大型项目和人数众多的团队,详细的任务分解 和 对每项工作的质量标准,是保证进度和交付质量的最关键因素。当然,这很大程度上依赖于公司或 项目管理人员以往对类似项目的经验积累。

所以,敏捷并非不能适用于大型目,而是敏捷不能完全替代目前大型项目中的其他做法。敏捷可以继续在大型项目中的各个小team中应用,但是不用强求一层层的推到 PMO 这一层。

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

4 讨论

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT