• Agility捷行
  • 2026-03-18
  • 来源:

16种Scrum实践模式语言(收藏版)

本合集源自《Scrum实践模式语言》,浓缩 Scrum 核心实践模式,下面详细介绍每个Scrum模式实践, 附有生动的案例分析....

点击下方标题 即可阅读

【Scrum 模式语言1】Scrum团队(Scrum Team)

Scrum团队的构建模式揭示了高效产品组织的核心逻辑——它绝非不同职能的简单拼凑,而是一个以共同目标驱动的有机整体。通过融合产品负责人的业务洞察、开发团队的交付能力与Scrum Master的流程专长,团队形成了能够自主决策、快速响应的“价值交付单元”

【Scrum 模式语言2】跨职能团队(Cross-Functional Team)

重点探讨了“跨职能团队”这一核心模式。跨职能团队的优势在于强调团队自治、持续学习与快速反馈,减少对外部依赖,缩短产品开发周期,而这正是帮助组织提升效率与响应能力的关键。

【Scrum 模式语言3】Sprint计划( Sprint Planning)

本文用简单易懂的方式,讲述了Sprint计划的核心要点和实际做法。它表达的关键是:做好Sprint计划,绝不是简单从待办列表里挑任务就行 —— 本质上,这是团队在 “确定的目标” 和 “不确定的变量” 之间找平衡,最终为实现共同目标做出靠谱承诺的重要协作环节。


【Scrum 模式语言4】紧急程序( Emergency Procedure)

文章使用“停下生产线”来揭示,隐藏问题才是最大的风险,真正的效率源于暴露并解决根本障碍。它生动地阐释了敏捷核心,不是盲目追赶进度,而是要有勇气直面问题、快速响应。文章提供了Scrum紧急程序的清晰行动框架。


【Scrum 模式语言5】Sprint评审( Sprint Review)

本篇关于“Sprint评审会议”的阐述,揭示了评审的核心价值 – 它不是一次简单的成果演示或验收仪式,而是一个校准方向、凝聚共识、构建信任的关键节点。


【Scrum 模式语言6】Sprint 回顾( Sprint Retrospective)

常看到举例Sprint是Scrum的心跳或节奏,而Sprint回顾就像人体内自我检查与反应机制,依据现实状况反思与调整追求进步。文中列出不适合做反思活动的时间点,也正好是Scrum新手容易犯错的地方。允许失败并修正是TPS的精神,也是Scrum的重点。非常适合用作Scrum教练做Sprint回顾活动的时长及参与者设计参考指南。


【Scrum 模式语言7】产品自豪感( Product Pride)

本译文基于《Scrum模式语言》的第二章产品组织模式语言,探讨产品自豪感。篇首以圣家族大教堂的宏伟提醒我们,卓越源于对价值的执着。它深入探讨了Scrum团队如何通过“信任社区”来激发这份自豪,并借鉴了建筑大师克里斯托弗·亚历山大关于“无名之质”的追求。真正的产品匠心,是团队对每一份交付物负责到底的骄傲。愿此译本能激发您和团队,将这份自豪融入日常工作,共同打造有生命力的杰作。


【Scrum 模式语言8】愿景(Vision)

提到愿景,过去总是把它和史诗级的战略放在一起,好像离每个个体有些遥远的距离。随着创业的兴起,这个概念的多样化呈现,让它与每个创业者团体和个体都密不可分。随着科技的发展,愿景到产品实施的距离更短了,让它与普通消费者都产生了联系。而现在,用户体验占据高度的时期里,提到产品,如果没有系统性思维从愿景拉动全员的思路,方向和行动法则,就会很快被市场抛弃。愿景,离每个人都越来越近,尤其是Scrum团队和相关干系人们。


【Scrum 模式语言9】基于集合的设计( Set-Based Design)

在敏捷开发实践中,“基于集合的设计”代表了一种重要的开发范式转变--从过早锁定单一方案转向并行探索多种可能。本译文深入解析了这一源自丰田的创新方法,它通过有意识地保持设计选项的开放性,为团队在复杂问题面前提供了更灵活的策略。这种方法与Scrum所强调的“持续改进”的思维高度契合,它教会我们“延迟决策”的智慧--不是回避选择,而是通过系统化的探索让最终决策更加稳健,让产品为客户带来更大的价值。


【Scrum 模式语言10】免费变更( Change for Free)

“拥抱变化”不仅仅是敏捷开发的口号,而是一种可以落地的机制设定。这种机制在保持固定价格(总开发投资)的前提下,坚持高价值优先的原则,通过开发(Scrum)团队对最终交付价值的相对准确估算,再与客户的密切合作下,在Sprint中合理替换或移动代办事项。这样,既未因变更(替换/移动待办事项)额外增加开发成本,又因为持续的迭代开发增加了对开发的洞察并以此增加了定期产品增量的价值,真正实现“免费变更”。


【Scrum 模式语言11】 无事也付费(Money for Nothing)

开发合作关系是客户与开发供应商之间风险共担、合作共赢的基础和保证。一味坚持固定价格的合作协议往往有可能损害双方的互信,导致低效或者无效开发。因为一方面客户可能会提前终止合作置供应商于“空窗期”风险;另一方面在开发尾期,供应商可能会利用“非完美的不可预见性”假装继续努力开发实际并未增加客户价值,以此来保留最初的固定收益。可能的解决方案就是设定“无定期产品增量价值即终止”的合作机制。避免合作双方刻意的损人利己或者不劳而获。


【Scrum 模式语言12】估算点数(Estimation Points)

本章聚焦产品待办列表工作量估算,强调可靠估算对项目规划与客户期望管理的核心作用。文中指出绝对时间估算的局限性,提出相对估算与估算点数方法,介绍了基于斐波那契数列的规划扑克工具。同时明确估算需覆盖全部工作、全员参与等要点,阐明其在需求梳理、速度衡量、流程改进及发布计划制定中的价值,为敏捷工作量管理提供实操方案。

【Scrum 模式语言13】Sprint待办列表(Sprint Backlog)

本文是对 Scrum 中“Sprint Backlog”(Sprint待办列表)这一核心概念的详细阐述。原文深入探讨了其在 Sprint 计划、每日站会、进度跟踪及团队自组织中的关键作用,并强调了其作为动态工作计划和团队承诺的重要性。

【Scrum 模式语言14】Sprint待办列表事项(Sprint Backlog Item)

文章说明了产品待办列表并不能代替Sprint待办列表,解释了Sprint待办列表的必要性,并阐述了实施Sprint待办列表时可结合看板一起使用。

【Scrum 模式语言15】依赖优先( Dependencies First)

文章说明了重大风险常常源于产品待办列表与Sprint待办事项列表之间的依赖,并可能导致Sprint失败致使团队违背对Sprint的承诺。为尽早的暴露潜在的可能造成风险的依赖,应该最先处理最难的工作事项与最可能产生依赖的工作事项。一次性对齐依赖项,并运用5S技术(整理、整顿、清扫、清洁、素养)来深度审查Sprint待办事项列表中的依赖来解决依赖对于成功交付的风险的程度。


【Scrum 模式语言16】定期产品增量(Regular Product Increment)

本文揭示了Scrum团队在固定周期内交付价值的真实挑战:真正的“完成”在于交付完整价值,而非孤立组件。产品的生命力源于市场真实反馈,而非内部各种指标。这是给陷于敏捷形式主义团队的一剂清醒良药,旨在帮助有困扰的朋友重拾对价值本质的敏锐感知。

扫码联系课程顾问,咨询认证课与企业内训, 报名即赠《Scrum实践模式语言》电子版新书。

企业敏捷认证路径