写点什么

如何更好地进行每日立会?

  • 2010-02-05
  • 本文字数:1795 字

    阅读完需:约 6 分钟

如何运作好一次每日立会?有哪些最佳的技巧和方法? 很多敏捷团队都实行每日立会实践,但是 Joakim Karlsson 认为:“坦白讲,大多数每日立会都很乏味无趣。”它们变成了每个人都必须被迫参加的会议,更糟糕的是:以前每周一次类似的会议,现在却每天都有。

Paul Wynia 提供了一个项目的实例,其中项目带头人没有敏捷培训以及相关经历,每日立会因此变成了每日进度报告会议:

她会让每个人详细讲述各个功能特性、bug 和前一天与别人的交流,还有自己的工作,包括对于马上开展的这一天的工作的估算。然后,她会与每个人讨论几乎所有的工作条目。发展到后来,人们会带着笔记本参加会议,其中写满了所有的工作细节,还要记录她分配的新任务。这个团队只有 5 个人,她竟然能将每日立会延伸为每天 30 到 45 分钟的会议,人们感觉无聊至极。

Paul 接下来建议:立会应该限制在 10 分钟之内,最多不能超过 15 分钟。对于他自己指导的团队召开的立会,如果时间超出了,他允许团队成员自行离开,这等于给 Scrum Master 一个信号,说明会议的运作方式有问题。

Joakim 推荐:

  • 关注目标——与资深团队成员分享信息,他们会帮助整个团队在迭代中完成工作。
  • 关注团队——与所有人分享信息,而不是只告诉管理人员。
  • 在其他时候讨论——不要在立会中解决问题,可以安排后续时间解决,而且允许感兴趣的人参与。
  • 有准备而来——要是不想拉长立会时间,团块成员需要知道你的工作成果和待完成任务。
  • 关注成果—— Joakim 发现:“相比告诉别人自己正在完成系统的哪个部分,讨论成果能够提供更为积极的态度。”
  • 做出承诺——他让人们向其他团队成员承诺自己要完成的工作,而不仅仅是机械地说接下来的 24 小时要做些什么。
  • 指出障碍——你是不是要接触 60 多份文件才能完成某些细小的变更?

Mike Cohn 推荐团队在任务板前举行立会,询问发言的人他们在开发哪个故事。同时,Mike 指出:团队规模如果超出 9 个人,成员会很容易对他人正在着手的工作失去了解。

Drew Stephens 指出:他的团队使用“以用户故事为中心的每日立会”。想很多敏捷团队一样,Drew 也是从相对传统的立会开始的,但是当团队规模变大时,他却陷入了困境。

已经没有哪个故事的工作量能够占用整个团队的工作能力了,因此我们开始并行开发多个故事。我们也注意到:很多故事处于活跃状态的时间更长,而且开始出现被我们称为“任务尾巴”的东西(也就是一个故事陷于停滞,有一些属于该故事的、未经验证的任务连续多日处于低优先级状态)。出现任务尾巴,我们发现两个主要原因: 1. 代码质量低下导致 QA 人员发现奇特却稳定出现的 bug 流。
2. 当一个故事看起来接近“完成”状态时,开发人员转而开发其他故事,可之前的故事并没有完全完成。

作为这些因素的结果,我们的立会变得令人困惑:一个人谈到的故事与上一个人提到的完全不同,要想确定一个故事的进度变得很困难。人们关注的不再是要完成什么任务才能结束当前活跃的故事,而是每个人在做什么或是要做什么。个中区别并不是很大,但是带来的问题却越来越严重。

他们的解决方案是:把正在进行中的故事过一遍,每个开发该故事的人针对该故事回答 Daily Scrum 的三个问题。如果人们同时开发多个故事,他们就要跟大家说明多个故事的情况(这可能是个“异味”)。Scrum Master 会追踪谁已经发过言,如果有人说完一个用户故事后又提到另一个故事,这可能就是个障碍了。

Artem Marchenko 有如下建议

  • 不许打字——如果有人在笔记本电脑(或其他设备)上做记录,他们就获得了(本不应获得的)重新阐释团队成员发言的权力。
  • 如果团队在向 Scrum Master 汇报,那么 Scrum Master 就应该移开眼光,不与团队成员对视,极端情况下甚至可以转过身去。

在与 Henrik Larsson 的访谈中,Jason Yip(文章《光站起来还不够——每日立会的模式》的作者)指出了立会的视角发生的变化:

我曾更多地将其视为进度报告会议。然后我发现立会更关注的是承诺,主要感谢 Mike Cohn 的著作。近来,我更多将其视为解决问题的过程。现在,我最钟爱的形式是“走到板前”的风格,当然要有任务板 / 故事板。我希望更多地强调完成工作的重要性,而不仅仅是让人们尝试着忙起来。 说过这些,立会还是有些方面是这些年没有变化的,比如保证“仪式”气氛高昂的重要性,还有要与团队共同分享,而不是向领导报告。

你的团队使用了哪些有成效的方法呢?

InfoQ 之前的类似内容:好立会的标准是什么?

查看英文原文: Daily Standup Tips - a Roundup

2010-02-05 00:273308
用户头像

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

关注

评论

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

【架构设计】你的应用该如何分层呢?

JAVA旭阳

Java 架构

云时代,最好用的MySQL客户端工具推荐

NineData

MySQL 数据库 GUI

Rancher RFO 正式 GA

openEuler

Linux 开源 Kubernetes 操作系统 rancher

一文教会你mock(Mockito和PowerMock双剑合璧)

京东科技开发者

测试 powermock Mock pom 企业号 1 月 PK 榜

经常会采坑的javascript原型应试题

loveX001

JavaScript

基于ERNIELayout&pdfplumber-UIE的多方案学术论文信息抽取

汀丶人工智能

nlp 信息抽取 2022年终总结 2023新展望

ARM 算子性能优化上手指南

MegEngineBot

深度学习 开源 性能优化 MegEngine

尚硅谷&腾讯云EMR实时数仓教程发布

小谷哥

群晖NAS设置Calibre个人电子图书馆

刘旭东

群晖 Calibre 个人图书

Koordinator v1.1发布:负载感知与干扰检测采集

阿里巴巴云原生

阿里云 云原生 Koordinator

谈谈你在面试中遇到的一面、二面、三面有什么区别?

风铃架构日知录

Java java面试 程序员面试 面试‘’ 面试流程

国内首款支持gRPC+WebSocket调试的工具——Apipost

不想敲代码

JavaScript刷LeetCode拿offer-树的遍历

js2030code

JavaScript LeetCode

用javascript分类刷leetcode13.单调栈(图文视频讲解)

js2030code

JavaScript LeetCode

web前端技术应该怎么规划学习?

小谷哥

React的useLayoutEffect和useEffect执行时机有什么不同

beifeng1996

React

每个人都必须为2023年的十大基本技术趋势做好准备

超自动化

AI 超自动化

4天带你上手HarmonyOS ArkUI开发——《HarmonyOS ArkUI入门训练营之健康生活实战》

HarmonyOS开发者

HarmonyOS

小心被坑死!如果你还在用 Zookeeper 做注册中心

风铃架构日知录

Java zookeeper 程序人生 后端 注册中心

2023我的前端面试小结

loveX001

JavaScript

前端培训机构如何学习开发技术

小谷哥

一体化运维,降本增效!秒云助力海富通基金打造智能运维平台

MIAOYUN

运维 金融 智能运维 IT解决方案

2023我的前端面试小结

loveX001

JavaScript

深入理解JS作用域链与执行上下文

loveX001

JavaScript

Reids的BigKey和HotKey

小小怪下士

Java redis 程序员

AIGC最近很火,给大家推荐一个已经有1000位开发者使用的中文aigc开源模型,包括ai画图、ai聊天

AIGC布道者

人工智能 机器学习 AI AIGC AI绘画

OpenHarmony系统使用gdb调试init

OpenHarmony开发者

openha

SPL 实现电力高频时序数据实时存储统计

石臻臻的杂货铺

SPL

贴吧低代码高性能规则引擎设计

百度Geek说

低代码 规则引擎 平台化 企业号 1 月 PK 榜

JavaScript刷LeetCode拿offer-栈相关题目

js2030code

JavaScript LeetCode

深圳大数据培训机构怎么选

小谷哥

如何更好地进行每日立会?_研发效能_Mark Levison_InfoQ精选文章