敏捷不是看板、燃尽图的简单堆砌，而是管理不确定性的认知闭环。本文从承诺单元迁移、三次对象重构到主流工具对比，剖析敏捷研发软件的本质：从计划驱动到反馈驱动，核心在于重新定义管理对象，而非功能清单的拼凑。

在设计内部项目管理软件时，最容易出现的一种产品需求，是“把敏捷能力补齐”：增加 Backlog，增加迭代，增加看板，再放上一张燃尽图。功能清单完成以后，产品似乎就从传统项目管理工具升级成了敏捷研发平台。

但做得越深，我越觉得这套判断把因果关系倒置了。

敏捷不是几种页面的组合。Backlog、Sprint、看板之所以会成为研发管理软件的标准能力，是因为互联网和游戏研发改变了项目成立的基本条件：需求无法在开始时一次性确定，方案需要通过真实反馈验证，专业分工又让任何局部调整都可能传导到整个交付系统。

这三个条件里，本文重点展开前两个：需求无法一次性确定，方案需要真实反馈验证。第三个条件——专业分工带来的协调与传导——同样是计划驱动失效的重要原因，但它主要作用在对象之间的关系上，我们留到关系模型那一篇再展开。

当计划本身不再足够可信，软件就不能只负责记录计划和追踪偏差。它还要帮助团队反复回答三个问题：现在最值得做什么，当前周期能承诺什么，刚刚获得的新事实是否要求我们改变下一步。

两种模式真正的分界，不是谁更“先进”，而是承诺单元：预测型把承诺锁在项目范围上，一次性定死；敏捷把承诺锁在时间盒的增量交付上，反复更新。承诺单元变了，软件用来承载承诺的对象就必须跟着变。所以，从计划驱动到敏捷研发，不只是管理方法变化，也是项目管理软件核心模型的一次扩展，而扩展的方向指向核心对象的重新定义——那是下一篇的主题。

01 不要先争论瀑布还是敏捷，先判断预测还有多少可信度

计划驱动并不落后。

当目标相对稳定、交付范围能够提前定义、技术路径已有成熟经验、资源和依赖可以被识别时，完整计划具有很高价值。团队可以先做范围分解，再形成任务网络、关键路径、里程碑和基线；执行阶段持续比较计划值与实际值，发现偏差后采取纠正措施。

这套方法管理的核心，是承诺与偏差 。计划提供共同承诺，基线保存承诺发生时的版本，进度和成本数据帮助组织判断现实偏离了多少。

工程建设、硬件制造、合规改造乃至软件中的数据中心迁移，都可能包含大量适合预测型管理的工作。即使在互联网研发中，机房下线日期、监管上线窗口、采购交付周期，也不会因为团队采用 Scrum 就自动变得灵活。

真正的问题不是瀑布“错了”，而是它依赖一组经常被忽略的前提：我们对目标、范围和实现路径已经知道得足够多，提前制定详细计划的收益，高于持续维护这份计划的成本。

一旦这个前提不成立，计划越详细，不一定越可控，也可能只是把未知伪装成确定。

所以，预测型与适应型方法的分界，不是有没有甘特图，也不是需求文档写得长不长，而是：团队面对的是以执行偏差为主的问题，还是以认知未知为主的问题。

前者需要把现实拉回承诺，后者需要用更短的反馈周期不断修正承诺。大型研发项目往往两者同时存在，只是不同阶段、不同对象的比例不同。

02 互联网与游戏研发，改变了“错误”的成本结构

传统软件交付常把“按计划完成”视为项目成功的重要条件。互联网产品却让另一类失败变得更常见：团队按期完成了最初定义的功能，用户却不需要；方案在评审时逻辑完整，上线后数据却证明核心假设错误。

互联网并没有让研发天然更快，而是让反馈更便宜、更频繁。埋点、灰度发布、A/B 测试、用户反馈和线上运营，使团队能够更早看到真实使用结果。与此同时，竞争变化也让等待成本上升：一个方向判断错三个月，比某个任务延期三天更加致命。

这时，管理对象就不能只是“已确认范围中的任务”。尚未被验证的需求假设、可以被排序的机会、实验结果和用户反馈，都开始影响下一轮交付。

从产品模型看，互联网敏捷开发实际建立了一条持续运行的反馈链：需求先以假设进入 Backlog，团队只对当前迭代作出短期承诺，再通过灰度发布和真实数据决定下一步是继续、修改还是停止。

这条链路管理的不只是交付速度。它更重要的作用，是把“用户到底需不需要”从项目结束时的验收问题，提前变成每一轮迭代都要重新回答的产品问题。

游戏研发把这种不确定性进一步放大。

玩法是否有趣、美术风格能否成立、操作手感是否符合预期，很难只靠文档和评审证明。它们需要原型、可玩版本和反复测试。这里的不确定性和互联网的埋点不是同一类：埋点回答的是“用户要不要”，属于环境不确定，可以靠数据验证；好不好玩、美不美是评估性不确定，只能靠试玩和版本迭代逼近，数据很难直接回答。两种不确定性的软件响应也不同，前者依赖数据闭环，后者依赖实验对象和轻流程。进入大规模生产后，角色、场景、关卡、动画、程序和音频又形成复杂的内容生产管线；上线运营以后，版本活动、玩家反馈、数值平衡和线上故障开始共同决定优先级。

Clinton Keith 对游戏研发的一个很有启发的划分，是把预制作阶段理解为探索，把生产阶段理解为内容流动，把上线运营理解为持续响应。它们面对的约束不同：预制作最重要的是尽快“找到好玩”，生产阶段要减少跨工种等待和在制品，上线后则要缩短从玩家信号到修复或内容调整的周期。

游戏研发的完整结构同样不能只画一条从需求到发布的直线：产品方向先被拆成版本目标，版本再包含多个短迭代；程序与内容并行推进，在集成测试与发布处汇合，玩家反馈随后重新进入下一版本排序。

图中的两层机制不能互相替代。上层的阶段门决定项目是否继续投入，以及何时从探索转入量产；下层的版本循环负责把程序、美术和测试组织成可以反复试玩、集成和发布的可玩版本。只有迭代而没有阶段判断，团队可能更快地生产错误内容；只有阶段评审而没有短反馈环，玩法和体验判断又只能停留在文档里。

这也解释了为什么同一款游戏不能从立项到长线运营只使用一套固定流程。探索阶段需要容纳试错，生产阶段需要稳定节奏和依赖管理，运营阶段需要快速分流事件、缺陷和内容需求。所谓敏捷，不是所有阶段都使用同一个看板，而是让管理机制适应不确定性的来源。

03 敏捷真正重构的，是组织处理未知的方式

《敏捷宣言》强调尽早、持续交付有价值的软件，欢迎变化，频繁交付，并以可工作的软件作为进展的重要衡量。Scrum 则把这套思想组织成一个经验主义循环：保持透明，频繁检视，根据新事实及时调整。

这意味着，敏捷不是放弃计划，而是改变计划的颗粒度、有效期和更新机制。

计划驱动倾向于先建立相对完整的范围，再据此安排时间和资源；敏捷把较远的未来保留为有序选项，只对接近执行的部分持续澄清。计划驱动强调控制已经承诺的范围变化；敏捷承认部分变化来自学习，关键是让学习尽早发生，并把错误决策的损失限制在较短周期内。

我更愿意把这种变化概括为三个转向——它们是前文三个问题的管理侧表述：

1. 从追求一次预测正确，转向控制一次判断错误的代价；
2. 从追踪每个人是否按任务执行，转向验证团队是否形成可用增量；
3. 从把变化视为计划外事件，转向把反馈视为下一轮排序的正常输入。

因此，敏捷管理的核心不是”快”，而是用透明、检视和适应建立一个更短的认知闭环。

但把节奏切细，并不自动等于反馈变短。如果两周完成的仍是半年后才能整体验证的局部模块，项目只是把大计划切成小排期，并没有真正缩短反馈周期。

04 三次对象迁移，让项目管理软件改变了形态

当管理思想变化，软件最先变化的不是报表，而是管理对象。把前面的三个问题翻译成软件，需要长出对应的对象：回答“现在最值得做什么”，需要一个可持续排序的工作池，也就是 Backlog；回答“当前周期能承诺什么”，需要一个承载目标与完成定义的时间盒，也就是迭代；再加上一个面向流动与在制品的执行视图，让团队看到工作卡在哪里。这就是本节要讲的三种对象迁移。

从固定范围，迁移到有序 Backlog

传统计划中的范围清单，重点是确认“哪些内容属于项目”；Product Backlog 的重点，则是维护“为了产品目标，接下来可能做什么，以及什么更值得先做”。

Scrum Guide 把 Product Backlog 定义为一个不断涌现、有序的产品改进清单。这里最重要的不是“清单”，而是“不断涌现”和“有序”。它允许内容被增加、删除、拆分和重新排序，也要求 Product Owner 对排序负责。

所以 Backlog 不是需求仓库。仓库解决有没有收录，Backlog 解决有限能力应该先投入在哪里。一旦产品只支持创建而不支持稳定排序、筛选、澄清和淘汰，Backlog 很快就会退化成永远清不完的许愿池。

从完整项目计划，迁移到时间盒与增量

Sprint 不是日期分组字段，而是一段固定长度的承诺窗口。Scrum 将 Sprint 约束为一个月以内，是为了至少按月产生一次检视和调整机会；更短周期还能进一步限制风险暴露。

迭代模型至少要表达四件事：一个周期为什么有价值，选择了哪些 Backlog 条目，团队准备用什么计划完成，以及最终是否形成满足完成定义的可用增量。

很多系统只保存“开始时间、结束时间和若干任务”，实际上只是把工作按时间装进容器。缺少迭代目标，团队会同时推进互不相关的事项；缺少完成定义，状态“已完成”也无法形成可信交付。

从个人任务分配，迁移到团队承诺与流动

计划驱动系统习惯先把任务分到人，再计算每个人是否按期完成。敏捷团队仍然需要负责人，但承诺的基本单位逐渐从个人任务转向团队对增量的共同责任。

看板由此成为一种重要投影：它不是把 Excel 行换成卡片，而是让工作状态、等待位置和在制品数量变得可见。当大量卡片停在测试列，问题未必是测试人员“不够努力”，而可能是开发批量过大、进入标准不清或环境资源不足。

这三次迁移共同改变了产品架构：项目不再只有一棵任务分解树，还需要一个可排序的工作池、一组反复运行的时间盒，以及面向流动的执行视图。

05

Backlog、迭代、看板和燃尽图，到底分别管理什么

如果只按功能命名，敏捷模块很容易成为一组互相重复的页面。产品经理需要继续追问，每种能力究竟支持什么管理判断。

这里尤其需要警惕故事点。它是团队围绕相对规模建立共识的工具，不是工时的另一种写法，更不是横向比较团队产能的统一货币。团队改变拆分方式、完成定义或技术基础后，速度变化并不天然等于生产率变化。

燃尽图也不是“项目健康度的真相”。范围在迭代中增加，曲线可能上升；条目长期不关闭，曲线可能在最后陡降；团队即使贴合理想线，也可能交付了没有价值的功能。图表的价值是触发对话，不是替代判断。

从产品模型看，一个真正支持敏捷的系统还要同时保存三类事实。

第一类是当前事实 ：Backlog 的最新顺序、工作项当前状态、迭代剩余范围。它们支持团队今天采取行动。第二类是承诺快照 ：迭代开始时选择了什么、目标是什么、估算和范围如何。没有快照，系统只能看到最新结果，无法判断过程中发生了什么。第三类是变化事件 ：谁在何时增加、移除、拆分或重新估算了工作项，以及变化基于什么反馈。这三类事实，正好是前文三个问题的数据倒影：当前事实对应”现在最值得做什么”，承诺快照对应”当前周期能承诺什么”，变化事件对应”新事实是否要求改变下一步”。

只保存当前值，最容易做，却会让“适应”失去证据。团队看到迭代最终完成了二十个工作项，却不知道其中十个是在中途替换进来的；看到 Backlog 第一名，也不知道一次用户验证为什么改变了排序。敏捷允许改变承诺，不代表改变不需要被理解。

因此，敏捷平台并不是比传统计划系统更少控制，而是把控制从“禁止变化”转向“缩短变化周期、保留变化依据并限制影响范围”。

06 Jira、TAPD 和 ONES，如何把敏捷思想产品化

主流研发管理软件都提供 Backlog、迭代和看板，但它们并不是同一个产品模型换了三套皮肤。

Jira 的入口是 Work Item。在 Scrum Backlog 中，工作项被组织在 Backlog 和多个 Sprint 之间，可以排序，也可以被规划到 Epic、Version 和 Sprint。它的优势不是提供一张敏捷清单，而是同一个工作项还能进入类型、层级、工作流和版本模型。敏捷规划建立在稳定对象之上。

TAPD 更强调互联网研发的完整节奏。需求进入产品 Backlog，经过排序和拆分后规划进迭代；需求、任务和缺陷在迭代中被统一跟踪，并通过故事墙、燃尽图、发布计划和质量数据连接起来。它把腾讯研发实践沉淀成了更明确的场景路径，团队更容易沿着“需求—迭代—发布”开始工作。

ONES 更强调敏捷与企业规划并存。规划组件可以定义纳入计划的工作项类型，再从待办池规划到迭代，同时向上连接史诗、发布和项目计划。基线、甘特图与迭代组件可以在同一个项目中组合，适合既要保持团队节奏、又要承担跨团队里程碑和外部承诺的组织。

三种设计背后是不同的产品取向，也是同一个推导的不同落点：迭代这个时间盒，各自挂在哪类对象上、承担什么承诺。Jira 的迭代挂在工作项之上，可以继续规划到 Epic 和 Version，模型组合自由；TAPD 的迭代绑定需求—任务—缺陷—发布这条链，承诺落在完整的研发场景里；ONES 让迭代与史诗、发布、基线并存，承诺既在团队节奏里，也在企业治理里。

产品经理不能只比较谁有燃尽图。更关键的问题是：Backlog 中允许出现哪些对象，排序由谁负责，迭代与版本是什么关系，跨项目依赖如何显现，远期计划与当前执行如何保持一致。

07 敏捷产品最常见的失败，是只改变界面，没有改变反馈回路

不少团队已经拥有标准的敏捷界面：两周一个迭代，每天站会，卡片在看板上移动，结束时输出速度和燃尽图。项目仍然没有变得更可控。

原因通常不是少了某个功能，而是模型仍然服务于旧的控制逻辑。

例如，季度范围早已被全部锁死，迭代只是把任务按两周切片；所有卡片必须一开始分到个人，团队没有调整工作方式的空间；故事点进入绩效排名以后，估算会自然膨胀；看板状态越配越细，却没有任何在制品限制；回顾会上发现的问题，也从未转化为下一轮可执行的改进。

这类系统拥有敏捷名词，却没有建立“事实出现—共同检视—改变下一步”的闭环。

另一种失败，是把敏捷误解为不需要长期规划。大型互联网和游戏项目仍然需要产品目标、版本节奏、关键里程碑、预算约束和跨团队依赖。只是远期内容应该保持较粗粒度和较低承诺，接近执行后再逐步澄清。

一个成熟平台通常需要同时容纳三种时间尺度：

• 目标与路线图回答较长周期准备创造什么价值；
• 版本与里程碑表达对外部协作方和经营节奏的关键承诺；
• Backlog 与迭代管理近期优先级、团队容量和交付反馈。

这不是在瀑布和敏捷之间折中，而是承认同一个研发系统里同时存在可预测工作和探索性工作。产品设计的责任，是让不同确定性水平使用不同的计划精度，同时保持目标、范围和交付证据可以连接。

08 敏捷之后，为什么核心对象不再可能只有 Task

走到这里，另一个问题会自然出现。

Backlog 里等待排序的，可能是用户故事、缺陷、技术债、风险、实验和运营需求；迭代里被承诺的，既有需要交付的需求，也有为了完成需求拆出的开发任务和测试任务；版本还要汇总多个迭代形成的发布内容。

如果系统把这些内容全部压成 Task，优先级虽然可以排序，业务语义却会逐渐消失。一个“已完成”到底代表代码写完、缺陷修复、需求验收还是风险关闭，系统无法回答；不同对象需要的字段、流程、权限和统计口径，也只能被塞进同一张越来越臃肿的表。

敏捷把工作从静态计划中释放出来，也迫使项目管理软件重新定义它所管理的基本单元。

下一篇，我们就从这个单元开始：为什么 Task 足以管理动作，却不足以管理研发；Jira、TAPD 和 ONES 又如何围绕 Work Item 建立一套真正可扩展的对象模型。