敏捷开发Scrum工具高频问答：初学者最常问的8个问题

敏捷开发Scrum工具这个说法，容易让人误以为Scrum是一种软件。更准确地说，Scrum是一套轻量框架，工具只是它的承载方式。框架规定角色、事件和工件，工具负责把这些规则变成每天可执行、可追溯的记录。 先分清这两层，后面的疑问大多能自己推导出来。

下面按初学者最常问的顺序整理出8个问题，覆盖角色与节奏、工件与流程、工具落地三个环节。每个问题都给出可以判断的标准，不停留在名词解释。

一、Scrum工具与Scrum框架是什么关系

1. 框架管规则，工具管承载

Scrum框架定义了三个角色，即产品负责人、Scrum Master和开发团队；三个工件，即产品待办列表、Sprint待办列表和产品增量；五个事件，即Sprint本身、Sprint计划会议、每日站会、Sprint评审会议和Sprint回顾会议。其中Sprint是一个固定时长的迭代周期，团队要在这段时间内交付出可用的产品增量。在通行实践中，这些事件都设有时间盒，也就是为活动预设一个固定的时长上限，到时即止。

框架只回答做什么、谁来做、什么时候做，并不规定用什么记录。工具的作用在于把待办事项、任务拆分、进度数据、Bug和测试结果放进同一套结构里，让每个迭代都可查、可比、可复盘。

下图是一个Sprint内部的推进节奏，从计划会议依次走到回顾会议。

2. 什么时候需要引入Scrum工具

团队规模小、只跑一个迭代时，白板和便签也能维持。出现下面几种情况，说明手工方式已经不够用：

• 并行迭代超过一个，团队之间的依赖靠口头同步；
• 人员发生变动后，进度上下文接不上，接手的人找不到依据；
• 迭代结束复盘时，交付数据只能靠回忆拼凑。

判断标准很直接：当谁在做什么、做到哪一步、被什么卡住这三件事需要靠反复追问才能说清时，就该考虑引入工具了。

二、角色与节奏：谁来做、多久一轮

1. 三个角色分别做什么，小团队可以兼任吗

三个角色的职责，以及初学者最常见的误解，可以参考下表。

从表中可以看出，判断依据是关注点不同，而不是级别高低。小团队可以兼任，但产品负责人与Scrum Master尽量由不同的人承担：前者负责范围和优先级的取舍，后者负责检查流程有没有被绕开，两种判断由同一人完成时，容易在两种立场之间失去平衡。

2. 一个Sprint多长合适

通行做法是把Sprint的上限设为一个月，实践中更常见的是1到4周。周期短，反馈快、变更成本低，但计划会和回顾会占用时间的比例会上升；周期长，交付节奏更稳，但需求发生变化的可能性更大。

判断标准主要看一点：团队能否在这个周期内交付一个已满足完成标准的可用增量。 做不到就缩短周期，把每个迭代的承诺范围缩小，而不是靠加班硬撑。周期一旦确定就尽量保持固定，团队才能用历史数据做估算，燃尽图这类趋势信息也才有参考意义。

3. 每日站会15分钟不够用怎么办

站会的目的在于同步进展、暴露阻碍，而不是向管理者交代工作。在通行实践中，每日站会的时间盒通常定为15分钟，但15分钟经常不够，多数时候不是时间问题，而是信息结构没设计好：每人完整叙述工作日志，很容易超过两分钟。

保持节奏的办法是只回答三个问题，每个回答控制在半分钟左右，即昨天为达成Sprint目标做了什么、今天准备做什么、遇到什么阻碍。超出这三个问题的技术讨论，会后由相关人员单独处理，不要占用全员时间。 如果使用Scrum工具，成员会前更新看板状态，会上只对齐目标和阻碍，效率会明显提升。

三、工件与流程：从需求池到迭代承诺

1. 产品待办列表和Sprint待办列表有什么区别

产品待办列表是产品级的、持续存在的需求集合，由产品负责人排序，随时可以调整。Sprint待办列表则是从中挑选出的、当前迭代要完成的部分，再加上完成它所需的拆解任务。

关键差别在变更规则：产品待办列表随时可动，Sprint待办列表在迭代内应尽量保持稳定。 把两者混成一张表，团队就分不清哪些属于本次承诺的范围，估算和交付统计也会跟着失真。这也是工具里要把需求池与迭代范围分开维护的原因。

下图是三个工件之间的层级关系：需求从产品待办列表筛选到Sprint待办列表，最终形成产品增量。

2. 什么是完成的定义，要不要写进工具里

完成的定义是团队对交付标准的共同约定，比如代码提交并通过评审、相关用例执行完毕、结果可部署到测试环境。缺少这层共识，完成就只能是口头说法，迭代末统计出的交付数量会失真。

建议把它固化为工具里的检查项或状态流转条件。 例如把关联用例执行通过、相关Bug处理到位，设为任务流转到已完成状态的前提。规则落在系统里，就不依赖某个人是否记得住。

3. Sprint进行到一半插入新需求，怎么处理

先判断它是否威胁Sprint目标。如果只是同等替换，挪出一件工作量相当的待办事项，由产品负责人和开发团队协商调整，是可行的。如果直接扩大范围，团队既要完成原目标又要多做，风险实际上被推给了交付质量。

处理这类变更的原则是：先评估影响范围，再决定是否调整范围，最后留下变更记录。 记录的价值在复盘时才会体现，它能帮助团队判断一次延期是否与中途插单有关。

四、工具落地：方法与链路的匹配

1. Scrum和看板该选哪一个

选择方法不取决于行业，而取决于工作形态。Scrum适合可以被规划成阶段性目标的工作，比如版本开发、功能上线；看板方法强调把工作流可视化、限制同时进行的任务数量，不要求固定周期，更适合任务随时进入、优先级频繁调整的工作，比如线上问题处理与运维支持。

判断方法看症状：如果痛点是节奏混乱，优先考虑Scrum；如果痛点是任务堆积、流转堵塞，优先考虑看板。 两者并不互斥，多数研发管理平台同时提供Scrum与看板模型，团队可以按项目类型分别使用。

2. 工具要覆盖到哪条链路

只把任务搬到线上，收益有限。研发场景的完整链路是需求、任务、Bug、测试、发布、复盘，缺一环就会出现信息断点：需求与任务不关联，变更就说不清影响范围；任务与用例不关联，测试覆盖就无法核对；发布与需求不关联，版本内容只能靠人工整理。

下图对应这条链路的六个环节。

以禅道项目管理软件商业版为例，需求、任务、Bug、用例、版本被放在同一套数据中，变更影响范围可以直接追溯；配合燃尽图、看板与效能统计，迭代过程的数据能自动沉淀，为复盘提供依据。判断一套方案是否值得投入，可以先看数据能否打通，而不是先比功能条目多少。

五、常见问题解答

1. 迭代计划总是估不准，换工具能解决吗

换工具解决不了根本问题。估算偏差通常来自两点，一是历史数据不足，二是任务拆分粒度太粗。先按固定周期运行两到三个迭代，积累实际工时数据，再把任务拆到一天以内可完成，估算才会逐步收敛。 工具的作用是让这些数据可查、可比。

2. 站会上没人愿意说问题，怎么处理

多数情况下，原因在于发言被当成工作汇报，暴露阻碍的人会感到压力。把阻碍当成待处理事项而不是个人失误，并把每条阻碍记录成可跟踪的条目，是改善参与度的前提。 主持人先带头说明自己遇到的困难，通常能带动其他人开口。

3. 多个Scrum团队同时推进，怎么对齐依赖

单团队的看板难以呈现跨团队依赖。可行的做法是统一各团队的迭代周期长度，再建立一份跨团队依赖清单，明确每个依赖的提供方和验收时间。 规模化场景下，多数平台会提供项目集或跨团队视图，把多个团队的进度放在同一时间轴上对照。