研发负责人视角：敏捷开发管理工具该盯哪 3 张表

敏捷开发管理工具里从来不缺报表。需求池、任务板、燃尽图、Bug趋势、工时统计，随手就能拉出十几张。但从研发负责人的角度看，日常真正需要稳定关注的只有三张表：需求表、任务表、Bug表。 它们分别回答做什么、做到哪、做得对不对，任意一张缺位，另外两张给出的结论都容易失真。

一、为什么恰好是这3张表

1.研发管理要回答的三个问题

研发管理绕不开三个问题：做什么、先做什么；谁在做、做到哪；做得对不对。这三类问题的颗粒度和责任主体不同，混进同一张表，每个问题都容易看不清。 需求按价值排序，回答方向问题；任务按执行拆分，回答进度问题；Bug按质量记录，回答交付问题。

现实中更常见的是三类记录各管一段：需求只沉淀在产品手里，进度只沉淀在项目组手里，质量只沉淀在测试手里。三个口径单独看都没问题，合在一起却拼不出完整结论。

2.三张表的分工

三张表的分工可以用一张表说明。

三张表的分工不重叠：需求表管价值输入，任务表管执行过程，Bug表管质量结果。

3.判断标准与框架依据

一张表能不能支撑管理，不取决于字段多少，而取决于能否从汇总数字点到具体单据、责任人和时间点。 Scrum指南（2020版，Ken Schwaber与Jeff Sutherland编写）把产品待办列表、冲刺待办列表和增量列为三大工件，对应需求与任务两条主线。Bug修复本身也可以作为待办事项的一个条目存在，只是为了让质量趋势单独可见，实践中通常会为它单独建表。

二、第一张表：需求表，看入口是否可控

1.该盯哪些内容

需求总量与流入速度、优先级分布、需求从提出到进入迭代的等待时长，以及变更次数与变更发生的阶段。迭代开始前先看这几项，能大致判断这一轮的范围是否已经超出团队产能。

2.什么信号算异常

需求积压持续增长，关闭速度长期慢于流入速度，或者变更集中在临近提测、临近发布的阶段，通常说明入口没有把关，后续排期容易被打乱。 同一需求被反复激活、优先级频繁反转，属于同类问题。

3.怎么验证

随机抽三条需求，把提出、评审、开发、测试、发布的时间点连成一条线。如果等待环节占用的时间超过实际开发时间，瓶颈在流程，而不在个人产能。 迭代评审上，负责人可以只追问一句：这条需求从提出到上线，有多少时间花在等待上。

三、第二张表：任务表，看节奏与阻塞

1.该盯哪些内容

任务状态分布、预估工时与实际工时的偏差、任务在某一状态的停留时长，以及按负责人统计的在办任务数。这几项放在一起看，能区分团队是真的在推进，还是任务在少数人手里原地打转。

2.什么信号算异常

任务长期停留在进行中，或者估时偏差逐迭代放大，一般说明任务拆分粒度过粗或依赖关系没有理清。 从交付结果看，个别成员同时承接过多任务时，整条链路的实际产出往往会下降。

3.怎么验证

用燃尽图或累积流图对照理想节奏，看曲线在哪个时间段趋于平缓。燃尽图反映剩余工作量随时间的变化，累积流图反映各状态任务的堆积情况。曲线平缓的时间段通常对应等待或阻塞，而不是工作不饱和。 如果连续两个迭代都在同一位置出现平缓段，就需要拆开依赖关系重新排期。

四、第三张表：Bug表，看质量与返工

1.该盯哪些内容

Bug的新增与关闭速率、严重程度分布、重开率、平均修复时长，以及Bug与需求、版本、用例的关联情况。重开率指已修复的Bug被重新打开的比例。这些数据按严重程度分开看，才不会被大量轻微问题掩盖住关键风险。

2.什么信号算异常

新增Bug长期多于关闭数量，或者重开率持续上升，常见原因是修复停在表面，没有处理根因。 Bug集中出现在迭代后期或少数几个模块时，常见情况是测试介入时机偏晚，或者改动集中在少数模块。

3.怎么验证

按版本观察Bug趋势，而不是只看当前未关闭的数量。如果发布前新增Bug仍在上升，质量风险很可能被推迟到线上。 负责人可以在发布评审前确认一件事：本次版本的Bug曲线是否已经向下。

五、三张表怎么联读

1.先保证关联键一致

在敏捷开发管理工具中，三张表能否联读，取决于一个前提：需求、任务、Bug与版本之间能否互相追溯。三类记录分散在不同系统、编号无法对应时，再精确的数字也无法定位到具体问题。

2.按交付顺序串起来

需求表看入口是否可控，任务表看过程是否顺畅，Bug表看质量是否守得住。三张表结论互相矛盾时，先核对统计口径与时间范围，再判断执行层面的问题。

3.固定查看节奏

不同查看频率对应不同决策，可以按下面的节奏分工。

三张表如果只在项目延期之后才被翻出来，预警作用就消失了，把查看动作固定下来才有意义。

4.三条使用原则

口径先统一，再谈改进。 同一个交付周期，从需求受理算起和从开发启动算起，结论可能完全不同。

数据用于改进流程，不宜直接用于个人考核。 指标一旦与个人绩效强绑定，数据的真实性就容易打折扣。

看趋势，不看单点。 单次波动不构成判断依据，需要连续几个周期观察同一方向的变化。

六、常见问题

1.小团队人手有限，三张表要同时上吗？

不必一次铺开。可以先跑需求表和任务表，Bug表先用最简字段记录严重程度、状态和关联版本。顺序可以分批，口径要一次定好。

2.需求表和任务表都在管工作项，能合并成一张吗？

不建议。两者粒度和责任主体不同，一条需求通常拆成多个任务，任务对交付负责，需求才对价值和范围负责。合并之后，优先级判断和进度判断会互相干扰。 需要的是编号关联，而不是两张表合并。

3.三张表里哪一类数据最容易失真？

通常是任务表。任务状态和工时依赖执行者主动更新，忙起来最容易漏填。可以先管住阻塞标记和状态流转，工时统计放到第二步。

4.这三张表一定需要管理工具承载吗？

表格也能起步，但关联关系和变更记录依赖人工维护，规模上来后容易失真。当需求、任务、Bug需要在同一套编号体系下互相追溯时，具备需求、任务、Bug与版本关联能力的研发管理软件会更省力，禅道项目管理软件即属于这一类承载方式。工具不是前提，稳定、统一、可追溯的记录才是前提。