开源敏捷管理平台怎么跑Scrum：迭代、看板、燃尽图的配置步骤

迭代第5天，燃尽图的实际剩余工作量突然高于理想线；同一时间，看板进行中列堆了12张卡，测试列只有2张。

站会上大家盯着屏幕，没人能说清是范围变了、估时偏了，还是看板列把等待时间藏了起来。问题通常出在三处：对象没有关联、列没有规则、图表没有统一口径。

下面按对象映射、迭代参数、看板列与WIP上限、燃尽图口径与异常判读、上线验收五个部分展开，说明在开源敏捷管理平台中把Scrum配置到可运行、可验证的具体做法，并给出可直接套用的字段、公式和阈值。

一、对象映射：先把四类数据关联起来

Scrum框架把产品待办、迭代待办、增量分别绑定产品目标、迭代目标、完成定义。

平台里对应四类对象：需求池、迭代、任务、版本。四类对象不关联，后面的看板和燃尽图就没有统一数据源。

1. 对象与必配字段

需求池存产品待办，迭代装本轮选中的需求，任务是最小执行单元，版本记录满足完成定义的增量。

一个需求只归一个迭代，跨迭代时拆分，不复制。

下表把Scrum对象、平台对象和必配字段对齐，建项目时可逐行核对。

字段名可随平台变化，但每个对象都要有可检查的完成信号。

建项目时先跑一遍表1，缺字段的项目不要进入迭代。

2. 三条关联规则

需求关联验收标准；任务关联负责人、估时和状态；版本关联本轮完成的需求。

这三条是数据可追溯的最低要求。缺少任一条，看板无法计算周期时间，燃尽图也无法区分完成与范围变化。

二、迭代配置：时间盒、容量、任务粒度

1. 时间盒与事件上限

Scrum Guide（2020）规定，Sprint固定长度且不超过1个月。

1个月Sprint的Sprint Planning上限8小时，Daily Scrum15分钟，Sprint Review上限4小时，Sprint Retrospective上限3小时；更短Sprint按比例缩短。

新团队可从2周起步，连续跑3到4个迭代再评估。迭代目标写成一句可验收的结果，例如新用户能在移动端完成下单并收到通知。

2. 容量公式

可用人天＝团队人数×迭代工作日×可用率。可用率先扣除请假、支持和会议，再乘专注系数；初始取0.6到0.7，跑完3个迭代后用实际完成量修正。

示例：6人×10天×0.65＝39人天，预留15%给插单和返工，可承诺约33人天。

容量是上限，不是必须填满的指标。

3. 任务粒度与完成定义

任务拆到1天以内。超过1天继续拆，直到每天站会能说清昨天完成什么、今天做什么、阻塞在哪。

完成定义要写成检查单：代码评审通过、单元测试通过、集成测试通过、Bug管理流程关闭、文档更新。

Scrum Guide（2020）明确，不满足完成定义的产品待办项不能发布，也不能在Sprint Review展示，只能退回产品待办。

图1：迭代配置的四类参数与循环关系

三、看板配置：列、WIP与流动指标

1. 列与进出规则

从5列起步：待办、开发中、评审中、测试中、已完成；有独立发布环节再加待发布。

列按工作项状态划分，不按前端、后端、测试分列。

每列写进入条件和退出条件。例如评审中的进入条件是开发自测通过，退出条件是代码合并并通过自动化检查。

规则写进工作流，卡片才能自动流转。

2. WIP上限与利特尔法则

在制品上限也就是WIP限制，是看板方法的核心实践。限制在制品的目标是缩短前置时间，不是提高个人利用率。

初始上限可按该列平均并行人数×1.5到2设置，运行2到3个迭代后再调。

利特尔法则给出定量关系：平均前置时间＝平均在制品数量÷吞吐率。若团队每周完成6个事项，看板平均有18个在制品，平均前置时间约3周；要把前置时间压到2周，在吞吐率不变时，WIP应降到12个左右。

超过上限就不再拉新卡，先处理阻塞。列上限和总上限都要设，否则卡片会在列间转移，总量仍然失控。

3. 看板读法

每日站会15分钟，从右向左走，先看接近完成的卡片，再看超过周期时间P85的卡片。

累积流图用来定位瓶颈：某一状态带区持续变宽，说明上游流入大于下游流出，瓶颈在该状态或其下游。

把看板数据接入研发效能度量，可以同时看周期时间、吞吐率和在制品数量。

图2：看板列、在制品上限与阻塞标记

四、燃尽图配置：口径、公式、异常

1. 口径与公式

剩余工作量可以用故事点或小时，但同一张燃尽图只能选一种。

迭代内执行看小时更细，跨迭代预测看故事点更稳。剩余工作量＝承诺总量减去已完成量，理想线＝承诺总量÷迭代工作日数。每天更新实际剩余量，至少每个工作日一次。

中途新增需求要单独标注，或重画基线，不能静默加进总数。

燃尽图不是Scrum Guide规定的工件，它只显示剩余工作量，不反映范围变化。范围变化要用燃起图或变更记录单独呈现。

2. 三种异常

实际剩余量连续3个工作日高于理想线，且没有范围变更记录：查阻塞、外部依赖和任务粒度。

实际线走平：先查看看板卡片的最后更新时间，再查任务是否拆得过大。多数情况是数据没有每天更新。

实际线上扬：通常是新增范围或估时上调。在图上标注原因和日期，Sprint Review时决定砍范围、换需求还是调整迭代目标。

实际线长期低于理想线也要检查：可能是估时虚高，也可能是测试和验收工作没有纳入任务。

3. 使用边界

燃尽图是团队级趋势工具，不适合按个人拆分考核。按人追责会让成员延迟更新或拆分数据，曲线失去解释力。

更稳的做法是同时看三个指标：迭代目标达成情况、完成定义符合率、计划完成率。

计划完成率＝实际完成故事点÷承诺故事点；低于80%时，先复盘估算和范围控制，再谈提高速率。

图3：理想线、实际线与范围上扬的判读

五、上线验收：一轮迭代的检查表

1. 配置验收

第1天：100%任务有负责人和估时；迭代目标有验收条件；完成定义已发布。

每日：看板在站会前更新；燃尽图当天更新；每个阻塞有跟进人。

迭代中：记录范围变更次数、WIP超限次数和超限处理结果。

评审与回顾：核对增量是否满足完成定义，统计逃逸Bug数和周期时间P85。

2. 结果验收

南京大学DevOps+实验室《2023中国软件研发效能年度调查》把部署频率、交付周期、变更失败率等纳入效能度量。

单看燃尽图无法判断交付质量，需要和Bug、周期时间、计划完成率一起看。

Scrum与看板并不互斥，平台配置应允许迭代和看板列共存。

一轮迭代后只调三个参数：周期、WIP上限、任务粒度；连续3轮稳定后再固化为模板。

六、常见问题

1. 两周迭代的燃尽图，按小时还是故事点更合适？

执行层用小时，预测层用故事点。同一张图不要混用；两周迭代建议按工作日更新，任务粒度控制在1天以内。

2. 看板列设到7列以上，为什么反而更难管？

列越多，卡片停留点和等待时间越难统计。只保留有明确交付状态和退出条件的列，一般5到7列；纯等待环节合并为阻塞标记。

3. 迭代回顾会总是变成吐槽，议程怎么设？

先核对目标达成和范围变更，再按范围、流动、质量分三类，每类只留一个改进项，责任人和完成时间当场确认。

4. 跨时区团队，每日站会怎么保证看板同步？

站会前各自更新卡片和剩余工作量，站会只处理阻塞和依赖；无法同时在线时用异步文字补充，但阻塞必须在24小时内指定跟进人。

资料来源：Scrum Guide（2020）；南京大学DevOps+实验室《2023中国软件研发效能年度调查》。