2天时间,聊今年最热的 Agent、上下文工程、AI 产品创新等话题。2025 年最后一场~ 了解详情
写点什么

为敏捷回顾会议添加目的和假设

  • 2014-01-09
  • 本文字数:1717 字

    阅读完需:约 6 分钟

经常召开敏捷回顾会议会帮助团队了解并改善自身。为之设定目的并且使用假设来验证你的回顾会议是否带来改善,可以让回顾会议更加有效。

正如 Thomas Cagley 在回顾会议的障碍一文中所说,缺少跟踪是有时回顾会议无法带来改善的主要原因之一。

团队犯的最严重的错误就是,召开回顾会议,但对结果置之不理。尽管讨论本身可能令人鼓舞且通畅,但最后团队只是浪费了时间。

为了确保能够采取行动,Thomas 建议要让所需要做到的改善显而易见:

每次回顾会议都应该至少确定一个改善的目标或想法。那个目标应该被添加到 sprint backlog 中,并强调那是团队需要交付的一项工作。

在博文《摇滚的回顾会议(retrospectives that rock)》中,Dave Sharrock 说明你可以通过给会议赋予目的,让回顾会议更加有效。

(……)想要为回顾会议注入活力,最简单的方式就是在开始的时候提出一个清晰的问题来确定方向,然后围绕它来进行回顾。

为了让方向有价值,所有人都应该对其很清楚,并且都与其相关,而不要让它成为一个人的问题。这可能是专注于一个未发现的特定问题,而它与 sprint 本身的成功完全无关(例如,想要让团队在同样的时间内交付两倍的故事点,应该做出那些改变?)或者把目标定为团队忽略的组织上的问题(例如,我们如何减少甚至消除对监管合规部门为新特性签字的等待时间?)

Bob Marshall 在《回顾会议——更错误还是更正确(retrospectives – wronger and righter)》一文中说明了为什么他认为 PDCA 循环——从假设开始——是回顾会议的根本所在:

如何把普通的回顾会议变得不同寻常呢? 那就要回归根本。特别是 PDCA(Shewhart 循环)。很多人都看到了在简单的情境下——Sprint 计划会议和发布计划(Scrum)——的“计划(Plan)”这个词。但在 PDCA 中,由于它来自于 Francis Bacon 的“科学方法(Scientific Method)”,所以“计划”意味着 _ 假设 _:

  • “假设”——计划
  • “实验”——实施
  • “评估”——检查
  • (控制——最新增加的内容)——改进

在上面的理论中,所有回顾会议都不会有目的,_ 除非 _ 它回答了问题“做什么才能够让我们期望发生的事情——假设——真正发生?” 如果是那样的话,为什么呢? 如果不是,为什么不是呢? 缺少最初的假设,我们永远都不会自问这个问题。

Marc Löffler 发布了一篇博文《把目的加入到回顾会议中(inject purpose into retrospectives)》,其中他提到,想要更好地做回顾会议,一定不能缺少目标。

任何没有目的的回顾会议完全都是在浪费时间。(对任何其他会议都是这样)。只要没有目的,那么定期改变你的回顾会议并引入新的想法也没有任何意义。

他以与精益创业中使用的类似的方式使用假设,并采纳了 Diana Larsen 和 Esther Derby 在《敏捷回顾会议》一书中所提到的回顾会议流程。Marc 对“决定要做什么”步骤做了扩展,加上了“增加假设”,并引入了一个“检查假设”步骤,它会在搜集数据之后执行:

(……)而不要从你检查上一次回顾会议的假设得到深入的观点。这非常有用,因为它让你可以检查上次回顾会议的任务是否达到了期望的效果(你的假设)。在大多数情况下,你会发现假设是错误的。你不能只是检查是否完成了上次确定的各项任务,还要检查它们是否有用,并有积极的效果。如果你的假设都是错误的,那么就应该检查为什么它们没有得到期望的效果。

据 Marc 所说,增加假设并在下一次回顾会议中进行检查,会为你的回顾会议赋予目的。并且有助于检查你的回顾会议行动是否有价值:

你需要对所确定的所有任务添加假设,否则就无法检查任务是否有用。正如科学方法中所描述的,你要确保假设是可测试的。如果不可测试,那就没有意义。

Bob Boyd 提供了使用科学验证做回顾会议的八步过程。遵循精益创业的概念,这些步骤会帮助你验证回顾会议的行动是否得到了期望的改进效果。

1. 清晰地声明改进所要解决的问题
2. 清晰地声明改进之后的结果是什么样子
3. 为改进创建可以检验的假设(这是实验总结)
4. 确定要搜集的指标和度量数据
5. 确定如何搜集指标
6. 确定如何展现搜集的数据
7. 确定团队如何知道假设已被验证正确,而不会产生合理的怀疑
8. 确定团队会如何知道假设被验证错误,而不会产生合理的怀疑

查看英文原文: Adding Purpose and Hypotheses to Agile Retrospectives

2014-01-09 02:082264
用户头像

发布了 340 篇内容, 共 144.8 次阅读, 收获喜欢 13 次。

关注

评论

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

从小程序容器和微服务架构的结合,看未来应用程序开发的主流方式

没有用户名丶

汇率市场大幅波动,用友BIP全球司库助力企业外汇避险

用友BIP

金融 外汇避险

瓴羊Quick BI真心不错,已获得官方认可!

对不起该用户已成仙‖

探索ChatGPT技术在文本生成、机器翻译领域的简单应用 | 社区征文

兴科Sinco

人工智能 机器翻译 OpenAPI openai ChatGPT

3 月 9 日「融云 2023 政企数智办公新品巡展 · 北京站」邀您入席!

融云 RongCloud

产品 数字化 政企

大咖说·阿里研究院|数实融合的第三次浪潮

大咖说

百度智能云首批通过信通院MLOps旗舰级评测 全面加速文心一言产业落地

极客天地

【物联网开发实战】- 设备上云方案详解——设备接入类

阿里云AIoT

物联网 传感器

解密数仓高可用failover流程

华为云开发者联盟

数据库 后端 华为云 华为云开发者联盟 企业号 3 月 PK 榜

车载小程序发展现状:使用环境、用户体验、应用场景及未来趋势

没有用户名丶

小程序化

如何判断多账号是同一个人?用图技术搞定 ID Mapping

NebulaGraph

图数据库 风险控制 安全控制

CNStack 多集群服务:基于 OCM 打造完善的集群管理能力

阿里巴巴云原生

阿里云 云原生 kubenetes 集群管理

如何规范 RESTful API 的业务错误处理

江湖十年

Go 后端 Error RESTful API

瓴羊Quick BI数据大屏真不错,优势尽显!

流量猫猫头

及刻周边惠:拥抱HarmonyOS原子化服务

HarmonyOS开发者

HarmonyOS

IoT物联网设备OTA固件升级开发实践——设备管理运营类

阿里云AIoT

物联网

Meta Force佛萨奇2.0合约开发系统源码部署

薇電13242772558

智能合约

开放下载丨云原生架构容器&微服务优秀案例集

阿里巴巴云原生

阿里云 容器 微服务 云原生

CNStack 助推龙源电力扛起“双碳”大旗

阿里巴巴云原生

阿里云 云原生 CNStack

bucket表:数仓存算分离中CU与DN解绑的关键

华为云开发者联盟

数据库 后端 华为云 华为云开发者联盟 企业号 3 月 PK 榜

直播预约丨 微服务x容器开源开发者 Meetup 北京站回顾 & PPT 下载

阿里巴巴云原生

阿里云 容器 微服务 云原生

MASA MAUI Plugin (十)iOS消息推送(原生APNS方式)

MASA技术团队

blazor MASA MAUI Xamarin

携程 x TiDB丨应对全球业务海量数据增长,一栈式 HTAP 实现架构革新

PingCAP

数据库 TiDB

如何通过C#/VB.NET代码在Word中插入或删除脚注

在下毛毛雨

C# .net word 脚注

博睿“她”力量 :这份专业值得信赖

博睿数据

博睿数据 节日祝福

ChatGPT 未来发展趋势 | 社区征文

魏铁锤

ChatGPT

2023年2月国产数据库大事记-墨天轮

墨天轮

数据库 opengauss TiDB oceanbase 国产数据库

科技和女性的今天,《赛博格宣言》半个世纪前就预言了

脑极体

赛博格 女性

秒懂算法 | DP概述和常见DP面试题

TiAmo

算法 DP算法

2023两会看点:SaaS

ToB行业头条

为敏捷回顾会议添加目的和假设_文化 & 方法_Ben Linders_InfoQ精选文章