Skip to main content
← 返回资料库方法

Scrum

Scrum是一种敏捷框架,通过固定的角色、活动和工件,帮助团队以短周期迭代的方式处理复杂工作。

Scrum是一种用于开发和管理复杂产品的敏捷框架,最初在软件开发领域成形,如今已被广泛应用于众多行业。它基于经验式流程控制的理念:团队不会预先从头到尾规划好一项任务,而是在被称为Sprint的短暂、固定时间盒内工作,通常持续一到四周。每个Sprint都以一项可用的工作增量结束,这为获取反馈创造了空间,也让团队能够调整下一步的行动。透明性、检视和适应性的结合,使Scrum非常适合需求不确定或可能发生变化的工作。

Scrum规定了三个固定角色。产品负责人(Product Owner)负责产品的价值,并维护产品待办列表(一份按优先级排序、列出所有待完成事项的清单)。Scrum主管(Scrum Master)确保团队在该框架内运作,排除障碍,并促进协作,但不直接分配任务。开发团队则自主规划并执行工作。四项周期性活动构成了每个Sprint的结构:开始时的Sprint计划会议、用于快速同步的每日站会、用于展示成果的Sprint评审会议,以及用于改善团队协作方式的Sprint复盘会议。

Scrum最适合那些在一开始范围或解决方案尚不完全明确的任务,例如产品开发或涉及众多利益相关方的复杂项目。它与Kanban的区别在于固定的时间盒和明确定义的角色,而Kanban更多依赖于没有固定迭代周期的持续流动。与传统瀑布式规划相比,Scrum的优势在于定期检视:误判能够及早暴露出来,而不是只在项目结束时才被发现。在实践中,Scrum失败往往不是因为框架本身,而是因为执行不彻底,例如跳过复盘会议或不维护待办列表。

实用示例

一家中型机械制造企业正在开发用于监控其生产设备的新软件。这个五人团队以两周一次的Sprint方式工作:每个Sprint开始时,从约40个未完成的待办事项中挑选出10个最重要的条目,并通过每天15分钟的每日站会(Daily Scrum)保持同步。经过十个Sprint、历时五个月后,第一个可用版本就绪,而不是团队最初计划的、历时九个月且没有任何阶段性成果的开发周期。复盘会议(Retrospective)显示,需求不明确导致团队在前三个Sprint中损失了约20%的产能,自此产品负责人(Product Owner)开始撰写更加精确的待办事项描述。

Leanshift 如何提供帮助

归根结底,Sprint复盘会议(Retrospective)就是一次周期性的Kaizen循环:团队停下脚步,坦诚审视刚刚完成的工作,并在继续前进之前,有意识地对工作方式做出改善。这契合Leanshift的观点:改善不是一次性的项目,而是融入日常工作的常规习惯。以这种方式实践的团队,改善的不仅是产品本身,更培养出更多懂得如何自己改善事物的人。

常见问题

Scrum只适用于软件开发吗?

不是。Scrum起源于软件领域,但如今已被应用于市场营销、产品开发、教育等多个领域,适用于任何工作复杂且需求可能在过程中发生变化的场景。

Scrum与Kanban有什么区别?

Scrum在被称为Sprint的固定时间盒内运作,拥有明确定义的角色和活动,而Kanban则以可视化的方式呈现没有固定迭代周期的持续工作流,并侧重于限制同时进行中的工作量。

小团队真的需要一名专职的Scrum主管吗?

并不一定需要作为全职角色存在。在小团队中,这一角色通常由某人在常规工作之外兼任;重要的是促进作用和框架本身能够被真正落实。