【AICon】 如何构建高效的 RAG 系统?RAG 技术在实际应用中遇到的挑战及应对策略?>>> 了解详情
写点什么

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

  • 2009-05-11
  • 本文字数:1401 字

    阅读完需:约 5 分钟

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

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?

2009-05-11 04:461744
用户头像

发布了 479 篇内容, 共 151.2 次阅读, 收获喜欢 47 次。

关注

评论

发布
暂无评论
发现更多内容

EOS系统合约总体介绍

BSN研习社

区块链 EOS

2023 IoTDB Summit:Dr. Julian Feinauer《Apache IoTDB 在德国工业和关键基础设施中的应用》

Apache IoTDB

EMQ 发布MQTT over QUIC 白皮书:下一代车联网消息传输标准协议

新消费日报

车内语音识别技术:重塑智能驾驶的未来

来自四九城儿

高德地图携手HarmonyOS NEXT,开启智能出行新篇章

Geek_2d6073

听GPT 讲Rust源代码--compiler(33)

fliter

听GPT 讲Rust源代码--compiler(34)

fliter

MQTT over QUIC 白皮书:下一代车联网消息传输标准协议

EMQ映云科技

车联网 mqtt QUIC QUIC协议 mqtt broker

Argo CD 可观测性最佳实践

观测云

ArgoCD

对接50+快递商,快递鸟电子面单API助力商家多平台批量打单发货

快递鸟

快递物流 快递

车内语音识别数据在智能驾驶中的应用与挑战

来自四九城儿

万界星空科技注塑行业MES解决方案

万界星空科技

mes 万界星空科技 注塑MES 注塑行业

车内语音识别技术:智能驾驶的革新之源

来自四九城儿

您有一份OpenHarmony开发者论坛2023年度总结,请查收~

OpenHarmony开发者

OpenHarmony

这么做,开发打造高水平国际体育赛事直播观看平台

软件开发-梦幻运营部

智慧工地建设与低代码开发: 优化建筑行业的效率与安全

不在线第一只蜗牛

低代码 项目开发 智慧工地 数智转型

爆火《幻兽帕鲁》被指用AI缝合宝可梦,开发者自曝传奇经历:是人类的奇迹

Openlab_cosmoplat

车内语音识别技术:智能驾驶的核心要素

来自四九城儿

云手机哪一款好用?

Ogcloud

云手机 海外云手机 云手机海外版 国外云手机

构建以平衡计分卡为框架的全面预算管理体系

智达方通

全面预算管理 平衡计分卡 全面预算管理体系

一次开发,多端部署︱小红书携手HarmonyOS NEXT引领行业新风向

Geek_2d6073

小游戏选型(一):游戏化设计助力直播间互动和营收

音视频开发_AIZ

音视频开发 小游戏 小游戏开发 小游戏运营 直播间

低代码助力企业转型可视化

EquatorCoco

低代码 数字转型

海外云手机三大优势

Ogcloud

云手机 海外云手机 云手机海外版 国外云手机

小游戏选型(二):第三方社交小游戏厂家对比,即构/声网/融云/云信等

音视频开发_AIZ

游戏开发 音视频开发 小游戏 小游戏开发 直播间

微服务架构与低代码开发:加速应用开发的完美结合

快乐非自愿限量之名

架构 微服务 低代码 应用开发

左耳听风 - 技术领导力「读书打卡 day 17」

Java 工程师蔡姬

读书笔记 程序员 个人成长 职业发展 技术领导力

车内语音识别技术在智能驾驶中的应用与前景

来自四九城儿

聚道云软件连接器助力某半导体行业公司实现访客管理自动化

聚道云软件连接器

案例分享

史上最全知识图谱建模实践(上):本体结构与语义解耦

机器智能社区

深度学习 nlp 知识图谱 NLP 大模型

车内语音识别数据在智能驾驶中的价值与应用

来自四九城儿

大型团队能使用站立会议实践么?_研发效能_Vikas Hazrati_InfoQ精选文章