3~5 人小团队 — Start / Stop / Continue,45 分钟
使用场景: 小 Scrum 小组做轻量回顾
这样组织的原因: 小团队不需要专职 facilitator——每次轮值能让所有人共同拥有这项实践。3 张卡片的限制防止会议被低优先级问题拖长。
使用场景: 小 Scrum 小组做轻量回顾
这样组织的原因: 小团队不需要专职 facilitator——每次轮值能让所有人共同拥有这项实践。3 张卡片的限制防止会议被低优先级问题拖长。
使用场景: 标准 Scrum 团队,想要比 3 列更全面的反思
这样组织的原因: 4L 能同时显现正向(Liked、Learned)和缺口(Lacked、Longed for)。只问「哪里做得不好」的团队会错过刻意保持优势的机会。
使用场景: 跨多个团队的部门/项目级回顾
这样组织的原因: 30+ 人的直接讨论无法扩展。先在小组内收敛,只有 top clusters 会上升到主白板。Sailboat 隐喻能把跨团队边界的系统性问题可视化。
使用场景: 跨时区分布式团队
这样组织的原因: 异步输入保证安静的成员平等参与,同步时间用于讨论而不是打字。140 字的限制让所有人在笔记本屏幕上都能一眼扫过。
使用场景: 刚组建的团队做第一次 retrospective
这样组织的原因: 第一次 retro 的元目标是让团队愿意再做一次。从正向(Liked、Learned)开始再谈问题(Lacked、Longed for),能在真正用它揭示困难问题之前建立对流程的信任。
使用场景: 刚经历人际冲突或艰难 sprint 后的团队
这样组织的原因: Mad-Sad-Glad 适合团队需要发泄,但 facilitator 必须主动引导向「原因和行动」,不能停留在情绪。「描述事件不评人」的规则防止会议变成人身攻击。
回到模板页,直接替换成你的课程主题、章节和复习重点,就可以继续使用这套结构。
使用这个模板: /editor/new?template=sprint-retrospective
使用这个模板