我们如何用敏捷做AI项目

开篇：一个AI项目的“敏捷死亡”实录

2024年第三季度，我接手了一个已经跑了四个Sprint的智能客服项目。团队严格按照Scrum执行：每两周一个Sprint，每日站会，Sprint Review演示功能。Backlog里躺着一百多个用户故事，燃尽图看起来也正常。但四个Sprint结束后，模型在真实场景下的准确率只有61%，而业务方要求的是85%以上。更糟糕的是，团队交付了12个“功能”，却有9个在上线评估中被判定为不可用。

复盘时我发现一个致命问题：团队在用做电商后台的方式做AI项目。他们把“模型准确率提升到85%”写成一个用户故事，估了8个故事点，然后在这个Sprint里拼命调参。Sprint结束时准确率只到73%，故事被标记为“未完成”，挪到下一个Sprint继续。没有人意识到，模型准确率从73%到85%，根本不是“多做几个Sprint”就能线性解决的问题。它可能需要换数据、改特征工程、甚至换模型架构。而这些决策，在那个用户故事里完全没有体现。

这不是一个团队的失败。过去两年，我以外部顾问和内部管理者的双重身份，参与了七个AI项目的敏捷落地，目睹了至少四个团队在同一个坑里挣扎。核心矛盾在于：传统敏捷假设“需求可以拆成可估算的任务”，而AI项目的大量工作本质上是探索性的，无法预先估算，无法线性拆分。

这篇文章，我以一个踩过足够多坑的人的身份，把“如何用敏捷做AI项目”这件事掰开讲透。不讲教科书上的Scrum定义，不讲敏捷宣言的十二原则，那些你可以在任何地方查到。我讲的是：当你的团队面对一个数据不确定、目标会漂移、失败率高达60%的AI项目时，敏捷框架该怎么改、怎么用、什么时候该抛弃敏捷的某些教条。

一、核心结论：AI项目需要的不是“敏捷”，而是“被改造过的敏捷”

先说清楚我的核心判断，这样后面展开时你有一个锚点。

判断一：Scrum不是为AI项目设计的，但它的骨架仍然是最好的起点。Scrum的三大角色（Product Owner、Scrum Master、开发团队）和四个仪式（Sprint Planning、Daily Standup、Sprint Review、Sprint Retrospective）在AI项目中需要重新定义职责和产出物，但时间盒、透明性、检视与适应的底层逻辑依然有效。问题不在Scrum本身，在于你把什么内容塞进这些仪式里。

判断二：AI项目的敏捷，核心不是“快速交付功能”，而是“快速验证假设”。传统敏捷的交付物是“可工作的软件”，AI项目的交付物应该是“经过验证的认知”。一个Sprint结束，你可能没有任何可以Demo的功能，但你对数据分布、模型行为、评估指标的边界有了更深的理解，这个认知本身就是交付物，而且往往比一个半成品模型更有价值。

判断三：AI项目需要双轨敏捷，实验轨和工程轨并行。实验轨管理数据探索、特征实验、模型训练与评估，节奏可以更短（比如一周），允许高频失败。工程轨管理模型部署、接口开发、监控系统搭建，可以保持传统两周Sprint的稳定节奏。两条轨在“模型上线”这个节点汇合。试图用同一个Sprint节奏同时管理实验和工程，是AI项目混乱的根源。

判断四：AI项目中的“用户故事”应该被“假设卡片”替代。或者至少，用户故事的写法要彻底改变。传统的“作为……我想要……以便……”格式在AI项目中经常失效，因为你根本不知道用户“想要”的那个东西技术上能不能做出来。用假设驱动的卡片来管理Backlog，是我实践下来最有效的做法。

这四个判断不是理论推导，是我在失败中反复验证出来的。下面我会用具体案例和经验，逐层拆解每个判断背后的逻辑和操作方法。

二、真实场景：AI项目管理中的五个“地狱时刻”

在讲方法论之前，先还原我经历过的五个典型场景。如果你正在做AI项目管理，大概率会认出其中至少三个。

1. Sprint Planning变成“猜谜大会”

场景还原：PO说“这个Sprint我们要把推荐模型的CTR提升2个百分点”。团队面面相觑。谁也不知道提升2个百分点需要改什么，是加特征？调超参？换模型结构？还是清洗数据？更致命的是，没人知道这个目标本身是否合理。也许现有数据的天花板就是当前水平，再往上优化需要采集新数据，而采集新数据需要三个月。于是Sprint Planning变成了大家对着一个模糊目标硬拆任务，拆出来的任务基本是“研究一下”“试一试”“再看看”，这些根本不是可管理的任务，只是焦虑的投射。

我在PingCode的Backlog里看到过一个团队的应对方式：他们把“模型CTR提升”这个史诗拆成了三个特性，数据质量分析、特征工程实验、模型调优。然后在每个特性下面建了若干“假设验证”类型的用户故事，比如“假设：增加用户近7天行为序列可以将CTR提升超过1%”。这个写法的关键变化是：它把“要做什么”变成了“要验证什么”，失败不再意味着任务没完成，而是意味着获得了一个有价值的负面认知。

2. 模型评估结果在Sprint Review上“裸奔”

场景还原：Sprint Review会议上，算法工程师展示了一个离线AUC提升了0.03的模型。业务方问：“这意味着什么？线上效果会好吗？”算法工程师解释了半天AUC的含义，业务方依然一脸茫然。最后PO说：“那就先上线试试吧。”上线后CTR掉了5%，整个Sprint的工作等于白做。问题出在：离线指标和线上效果之间有一道巨大的鸿沟，而Sprint Review没有设定跨越这道鸿沟的机制。

我的处理方式：在AI项目的Sprint Review中，模型性能指标必须和业务指标同时展示，并且必须包含“离线指标→线上预估效果”的映射说明。如果这个映射关系还没建立，那么这个Sprint的交付物就不应该是“模型优化了多少”，而应该是“我们建立了离线AUC和线上CTR之间的关联模型，当前相关系数为0.7”。这听起来不那么性感，但它是构建可靠AI系统的地基。

3. “数据没准备好”成为万能阻塞理由

场景还原：第三个Sprint了，特征工程团队还在等数据平台导出用户行为日志。数据平台说排期要两周，于是整个Sprint的Backlog里一半任务打了阻塞标记。Scrum Master急得跳脚但没办法，因为“数据阻塞”听起来确实是外部依赖。但深挖下去你会发现，大多数“数据没准备好”的本质，是团队在Sprint Planning时没有把数据可用性验证作为第一优先级。

我在自己的团队里立了一个铁律：任何AI项目的第一个Sprint（Sprint 0），唯一的目标就是验证数据可行性。不是写代码，不是搭模型，就是拿着样本数据从头到尾跑通一条最小链路：数据从哪里来→格式对不对→字段缺失率多少→标注质量如何→能不能支撑一个Baseline模型。这条链路跑不通，后面的Sprint全是空中楼阁。PingCode里我专门建了一个“数据探险”的特性类型，放在所有其他特性之前，用红色标签标记，提醒团队这关不过后面都别动。

4. 模型迭代的“加速度陷阱”

场景还原：团队在一个Sprint里同时跑了8组实验，不同的特征组合、不同的模型结构、不同的超参数。Sprint结束时，8组实验里有5组效果不如Baseline，2组持平，1组略有提升。团队觉得“至少有一组有用”，于是把提升的那组上线了。但两周后线上效果回落到Baseline以下。问题出在：8组实验的评估都是在同一个测试集上做的，而那组“略有提升”的实验恰好过拟合了测试集的噪声。

这是AI项目特有的问题：并行实验数量越多，单个实验的可靠评估就越困难。当你同时跑10组实验，总有一组因为随机波动看起来比Baseline好，这不是模型真的好，这是多重比较的统计学陷阱。我的实践规则是：一个Sprint内并行实验不超过3组，每组必须有独立的Hold-out验证集，且评估结果必须经过Bonferroni校正或类似的统计检验。这个限制初看会拖慢迭代速度，但实际上避免了大量“假阳性上然后回退”的返工时间。

5. “技术债”不是代码的专利，模型也有技术债

场景还原：团队为了赶Sprint目标，每次迭代都在前一个模型的基础上加补丁，训练集手动剔除了几个脏样本、推理时加了一个硬规则后处理、某个特征用了一个临时的近似计算。五个Sprint下来，模型变成了一个没人敢动的巨型补丁包。新人接手时需要读两千行后处理逻辑才能理解模型的真实行为。这就是模型的“技术债”，它比代码技术债更难偿还，因为它往往没有测试用例可回溯。

我的应对：每个AI项目从第二个Sprint开始，必须预留20%的Sprint容量用于“模型重构”，清理后处理逻辑、统一特征计算口径、补齐评估用例。这个20%不能妥协。我见过太多团队在前三个Sprint疯狂堆实验，到第六个Sprint时模型已经无法维护，最终推倒重来。20%的投入看似拖慢了短期速度，但从三个月的时间窗口看，它能减少至少50%的推倒重来概率。

三、常见误区：五个让你“敏捷了个寂寞”的认知偏差

我在做咨询时发现，很多团队并不是不努力，而是在出发时就走错了方向。以下五个误区，是我在多个团队中反复观察到的，每一条背后都有至少一个真实案例。

1. 把“敏捷”等同于“快”

这是最普遍的误解。很多管理者引入Scrum的动机是“让AI项目交付得更快”，但敏捷的核心不是快，是在不确定性中找到正确的方向。AI项目最大的成本不是时间，是做错了方向。一个花了三个月做出来的错误模型，比花六个月做出来的正确模型贵得多，因为它不仅浪费了三个月，还消耗了团队的信心和业务方的耐心。

真正的问题不是“怎样更快地把模型做出来”，而是“怎样更早地发现这个方向是错的”。我在自己的团队里反复强调：Sprint Review的最高价值不是“看完成了什么”，而是“看哪些假设被推翻了”。一个没有推翻任何假设的Sprint，反而让我担心，是不是实验设计不够大胆？

2. 强行把探索性工作拆成任务

Scrum标准流程要求在Sprint Planning时把用户故事拆成具体的开发任务。这在传统软件开发中是可行的，因为“实现登录接口”这种任务的工作量和完成标准都是明确的。但“分析数据分布”“尝试新的特征组合”这种工作，工作量和产出都不明确，强行拆任务只会制造虚假的确定性。

我的做法是：对探索性工作使用时间盒管理，而不是任务拆分。比如“用3天时间探索用户行为序列特征的构建方案”，3天到了不管你探索到什么程度，都要在站会上同步发现和结论。这不是偷懒，是承认这类工作天然无法预先估算。时间盒给出了边界，在这个边界内允许自由探索。

3. 用软件质量的标尺衡量模型质量

传统软件开发有明确的质量标准：代码通过测试用例、无Critical级别的Bug、性能指标达标。但模型“质量”是一个模糊得多的概念。一个离线AUC 0.95的模型，如果它在某些关键子群体上表现很差（比如对老年用户的推荐准确率显著低于年轻用户），它就不是一个好模型。模型质量的评估是多维度的：整体性能、子群体公平性、鲁棒性、可解释性、推理延迟，而标准Scrum没有为这些维度预留评估空间。

我在PingCode的缺陷管理模块里，专门为AI项目建了一套模型质量检查项，包括：性能指标退化超过阈值、关键子群体效果偏差、特征分布偏移检测、线上离线一致性检查。这些检查项挂在每个模型上线前的“完成定义（Definition of Done）”里，任何一个不通过都不能标记为完成。

4. 把Scrum Master当成“流程警察”

在AI项目里，Scrum Master如果只是盯着站会有没有按时开、燃尽图好不好看，那这个角色就废了。AI项目的Scrum Master需要具备足够的技术理解力，能识别团队是在做有效探索还是在瞎忙。我见过最好的AI项目Scrum Master是一个前算法工程师转岗的，他能在站会上问出“你这两天的实验变量控制了吗？比较Baseline用的是同一个测试集吗？”，这种追问才是真正推动项目前进的力量。

5. 忽视“模型上线”与“功能上线”的本质区别

传统软件上线后，功能行为是确定的：用户点击按钮，跳转到指定页面。模型上线后行为是概率性的：同一个输入可能产生不同输出（如果模型有随机性），而且模型的表现会随着数据分布的变化而漂移。把模型当成一个“功能”来管理，是对AI项目最大的误解。

我的实践是：模型上线不是Sprint的终点，而是模型生命周期管理的起点。模型上线后的监控、回滚、A/B实验、定期重训，这些都应该作为Backlog里的持续事项来管理，而不是“上线就完事了”。

四、专业判断逻辑：如何构建AI项目的“假设驱动敏捷”

前面讲了很多“不要做什么”，这一节集中讲“应该怎么做”。以下是我经过多次迭代总结出的一套AI项目管理框架，核心是把传统Scrum的“用户故事驱动”改造为“假设驱动”。

1. 用“假设卡片”替代用户故事

传统用户故事的格式是：“作为【角色】，我想要【功能】，以便【价值】。”在AI项目中，我建议使用以下格式的假设卡片：

“我们相信【某种做法】会带来【某个指标的提升】，因为【某个逻辑推理】。验证方式：【具体的实验设计和评估方法】。验证标准：【什么结果判定假设成立/部分成立/不成立】。”

一个真实的例子：

“我们相信在用户行为序列特征中引入时间衰减权重会带来次日留存预测的AUC提升至少0.02，因为用户近期行为对次日留存的预测力显著强于远期行为。验证方式：对比加入时间衰减前后的模型在测试集上的AUC差异，使用DeLong检验评估统计显著性。验证标准：AUC提升≥0.02且p值小于0.05判定成立；AUC提升在0.01-0.02之间判定部分成立；低于0.01判定不成立。”

这个写法和传统用户故事的差异是巨大的：它明确了“什么算成功”，而且是可验证的、有统计标准的那种明确。在PingCode中，我把每个假设卡片建为一个用户故事类型的需求，在描述模板中直接使用这个格式。PO在Sprint Planning时不再试图“解释需求”，而是直接念一遍假设卡片，讨论立刻变得聚焦和高效。

2. 建立“实验Sprint”和“工程Sprint”的双轨节奏

我在前面判断三里提到了双轨敏捷，这里展开操作细节。

实验轨：

• Sprint长度：1周
• 产出物：实验报告（包含假设、实验设计、结果、结论、下一步建议）
• 站会重点：昨天做了哪个实验，结果如何，今天做什么实验，是否遇到阻塞
• Review形式：实验评审会（不是Demo，是数据驱动的讨论）

工程轨：

• Sprint长度：2周（标准Scrum节奏）
• 产出物：可部署的模型服务、推理接口、监控面板、特征Pipeline
• 站会重点：开发进度、技术阻塞、接口联调进展
• Review形式：标准Demo

两条轨的交汇点设在“模型候选版本冻结”这个节点。实验轨产出“候选模型+实验报告”，工程轨产出“可部署的推理服务”。当实验轨判定一个模型可以上线时，工程轨在一个Sprint内完成部署和灰度发布。这个交汇机制需要PO和两个轨的负责人高度协同。

在实践中，小型团队（5人以下）可以由同一批人在不同时间段承担两个轨的工作，比如周一到周四是实验轨，周五和下周一是工程轨。中大型团队（比如PingCode主要服务的100人以上组织）则可以分开两个子团队，由同一个PO统筹优先级。

3. 重新定义“完成定义”

标准Scrum要求每个用户故事有明确的完成定义（Definition of Done）。在AI项目中，一个假设卡片的完成定义不只是“实验跑完了”，而是包括：

1. 实验代码已经提交到代码仓库，附带可复现的运行记录
2. 实验使用的数据版本已锁定，可在数据平台回溯
3. 实验结果已经过统计检验，包含置信区间
4. 实验过程中的失败尝试和意外发现已记录在实验文档中
5. 实验结论已同步给全团队，且已被PO确认接收

对于工程轨的任务，完成定义还要加上模型质量检查项，就是我前面提到的性能退化、子群体公平性、线上离线一致性等检查。

4. 把“模型选择”变成一个显性的决策节点

在传统敏捷中，技术选型通常在Sprint 0就敲定了。但在AI项目中，模型选择（用什么架构、什么预训练基座、什么训练范式）往往需要在实际数据上跑过一轮才能做决策。我的做法是在Backlog里专门设一个“决策门”节点：当实验轨产出至少3组对比实验的结果后，由技术负责人编写一份“模型选型建议书”，PO组织召开决策会，邀请相关技术专家参与评审。

这个决策节点需要回答四个问题：

1. 候选方案的性能对比（不仅仅是准确率，还包括推理速度、显存占用、可扩展性）
2. 每个方案的技术风险和已知局限
3. 选型后的工程化成本预估
4. 如果选型后发现不合适，回退方案的可行性和成本

用决策门的好处是：它把“我们选什么模型”这个重大决策从模糊的日常讨论中拎出来，变成一个正式的、有据可查的节点。这对于中大型组织尤其重要，当项目涉及跨部门协作或需要向上汇报时，一个清晰的决策记录可以避免很多日后的扯皮。

五、案例拆解：一个推荐模型项目的敏捷实战记录

以下是我亲自主导过的一个内容推荐模型项目，从立项到稳定上线的完整过程。项目背景：为一个内容平台构建个性化推荐模型，目标是将用户平均阅读时长提升15%。团队配置：1个PO（我）、2个算法工程师、1个数据工程师、1个后端工程师、1个前端工程师，共6人。

1. Sprint 0：数据探险（1周）

第一个Sprint的目标只有一个：验证数据能否支撑起一个推荐模型。我们做了以下事情：

• 从数据平台拉取了最近30天的用户行为日志，约1200万条曝光-点击记录
• 检查了关键字段的缺失率：用户ID缺失率0.3%，内容ID缺失率0.1%，时间戳缺失率2.7%
• 统计了用户行为稀疏度：70%的用户在30天内点击少于5次，这对协同过滤类方法是巨大挑战
• 训练了一个最简单的Item-to-Item协同过滤作为Baseline，离线HitRate@20为12.3%
• 结论：数据可用但稀疏度偏高，基于内容的推荐方法可能比协同过滤更适合

这个Sprint的关键决策：放弃协同过滤路线，主攻基于内容理解和用户短期兴趣的推荐方案。如果我们在Sprint 0没有做数据稀疏度分析，可能要在两个Sprint之后才会发现协同过滤效果不佳，那就浪费了三周。

2. Sprint 1-3：实验密集期

接下来三个Sprint，实验轨以每周一个Sprint的节奏跑了9组假设验证：

• Sprint 1实验轨：验证“内容标签嵌入+用户兴趣向量”方案，HitRate@20提升到18.7%（p=0.02 vs Baseline）
• Sprint 2实验轨：验证“引入时间衰减权重”，HitRate@20进一步提升到21.3%（p=0.01）
• Sprint 3实验轨：验证“多臂老虎机在线探索策略”，模拟环境中CTR预估提升11%，但离线评估存在显著偏差，决定搁置待线上A/B验证

同期工程轨每两周一个Sprint，完成了：

• 特征Pipeline搭建（Spark作业，处理1200万条日志耗时从4小时优化到45分钟）
• 模型推理服务开发（TensorFlow Serving，P99延迟控制在50ms以内）
• 线上A/B实验框架搭建（支持5%流量灰度）

到第三个Sprint结束时，我们有了一个离线HitRate@20=21.3%的候选模型，和一个完整的工程化底座。

3. Sprint 4：灰度上线与意外发现

第四个Sprint的目标是灰度发布。我们用了PingCode的迭代概览面板实时跟踪灰度数据，5%流量下的核心指标：

• 用户平均阅读时长：基准组12.3分钟，实验组13.1分钟（+6.5%）
• 次日留存率：基准组23.5%，实验组24.2%（+0.7个百分点）
• 人均曝光点击率：基准组4.1%，实验组4.8%（+17.1%）

阅读时长提升了6.5%，离15%的目标还有距离，但方向是对的。意外发现是点击率提升显著高于阅读时长提升，这说明模型推荐的内容更容易被点击，但不一定更容易被读完。这个发现促使我们在PingCode的Backlog里新增了一个假设卡片：“在排序模型中引入完读率信号，是否能提升阅读时长而不仅是点击率？”

这就是前面讲的“交付认知”，Sprint结束时的核心收获不是功能，而是对用户行为的更深刻理解。

4. Sprint 5-7：迭代优化与规模化

后续三个Sprint，我们围绕“提升阅读时长而非点击率”这个新方向持续迭代：

• Sprint 5：引入完读率作为排序特征，阅读时长提升到14.2分钟（+15.4%），基本达标
• Sprint 6：扩展内容冷启动策略，新内容的首次曝光覆盖率从40%提升到85%
• Sprint 7：全量上线，同时建立模型性能监控和自动回滚机制

这个项目的最终结果：用户平均阅读时长从12.3分钟提升到15.1分钟（+22.8%），超额完成目标。但回顾整个过程，最重要的不是最终的数字，而是双轨敏捷框架让我们在7个Sprint内完成了9组假设验证、3次方向调整，而且没有出现重大返工，这在传统Scrum模式下是很难做到的。

六、工具落地：PingCode在AI敏捷项目中的实践用法

本节的标题写的是PingCode，但其中的方法论适用于任何支持Scrum的项目管理工具。我用PingCode为例，是因为它有多级需求管理、自定义需求类型、以及与代码和CI/CD的集成能力，这些特性在处理AI项目的复杂需求层级时比较顺手。

1. 用史诗-特性-假设卡片构建三层需求结构

PingCode支持史诗（Epic）、特性（Feature）、用户故事（User Story）三级需求管理。在AI项目中，我这样映射：

• 史诗级：对应业务目标。比如“提升推荐系统CTR”或“降低模型推理延迟”。
• 特性级：对应技术方向。比如“用户行为序列建模”、“模型量化与加速”、“数据质量治理”。
• 用户故事级：对应具体的假设卡片。比如“假设：引入Transformer序列建模可提升CTR≥1%”。

这个三层结构的核心价值在于：PO在史诗和特性层面把控业务方向，算法团队在用户故事层面自主设计实验，权责清晰，不会出现PO瞎指挥技术细节、算法团队闷头做无关实验的情况。

2. 自定义需求类型：区分“实验”和“开发”

PingCode支持自定义需求类型。我建议AI项目团队至少定义两种需求类型：

• “假设验证”类型：用于管理实验轨的工作。自定义字段包括：假设描述、验证指标、目标提升幅度、实验结果、结论（成立/部分成立/不成立）。
• “工程任务”类型：用于管理工程轨的工作。自定义字段和传统开发任务一致：技术方案、代码仓库、接口文档、测试用例。

这种区分让PingCode的迭代概览面板上可以同时看到两条轨的进度：实验轨的“假设验证完成率”和工程轨的“任务燃尽情况”。Scrum Master在主控面板上扫一眼就能判断整体健康度。

3. 与代码仓库和CI/CD打通

PingCode支持和GitHub、GitLab、Jenkins等工具集成。在AI项目中，这意味着：

• 每个假设验证卡片关联一个实验分支，实验代码提交后自动触发离线评估Pipeline
• 评估结果（AUC、Loss、Inference Time等）通过API回写到PingCode的卡片自定义字段中
• 如果评估指标低于预设阈值，卡片自动打上“需要关注”标签并通知相关人员

我在那个推荐模型项目里搭了这样一套自动化流程：每天的实验完成后，CI自动运行评估脚本，结果回写PingCode。早上的站会时，Scrum Master打开PingCode的迭代任务板，每个实验卡片的评估结果已经自动更新好了，不再需要算法工程师手工整理报告。

4. 迭代回顾的数据支撑

PingCode的迭代回顾功能支持为每个Sprint记录“做得好”、“待改进”和“行动计划”。在AI项目中，我在回顾板上专门增加了一栏“本次Sprint推翻的假设”，这些被推翻的假设不是失败，而是团队在这个Sprint中获得的最有价值的知识资产。如果一个Sprint没有推翻任何假设，回顾时反而要讨论：是不是我们的实验设计太保守了？

七、不同情况下的行动建议与取舍

没有一套方法论适用于所有团队。这一节我根据团队规模、项目阶段和资源条件，给出不同的取舍建议。

1. 按团队规模取舍

5人以下小团队：

• 不建议搞双轨并行。小团队的沟通成本天然低，不需要用复杂框架来保证信息对齐。采用“单轨+灵活Sprint长度”，实验密集期可以把Sprint缩短到1周，工程密集期恢复到2周。
• 取消“角色”的严格定义。PO、Scrum Master、开发者这三个角色在小团队中高度重合。不要为了角色完整性而牺牲效率。唯一必须保留的角色是“有人对Backlog优先级负责”，这个人可以是半PO半算法工程师的同一个人。
• 工具轻量化。小团队用PingCode的全部功能反而会累赘，保持Backlog、Sprint Planning、燃尽图三个核心模块就够。如果小团队用PingCode，建议关掉不必要的自定义字段和自动化规则。

10-30人中型团队：

• 双轨敏捷的价值在这个规模开始显著。两条轨可以由不同的子团队负责，但要确保有一个统一的PO统筹优先级。
• 引入“实验评审”作为正式的Sprint仪式。在实验轨的每个Sprint结束时，安排30-45分钟的实验评审会，全团队参与。这能确保工程轨的同事理解模型决策的背景，减少信息不对称。
• PingCode的自定义需求类型和自动化集成在这个阶段价值最大。需求多层级的关联关系让跨子团队的依赖可见，CI集成让实验评估结果自动同步。

100人以上大型组织：

• 双轨敏捷需要加上“项目群协调层”。大型组织通常同时跑多个AI项目，这些项目之间可能有数据依赖、模型复用、基础设施共享。需要有人（或一个小团队）在项目之上做资源调度和知识沉淀。
• 模型治理成为必选项。模型上线审批流程、模型版本管理、模型风险评估，这些在大型组织中不能靠自觉，必须有制度。PingCode这类工具可以把审批节点嵌入工作流，确保每个模型上线前经过了必要的检查。
• 考虑设立“AI项目经理”这个独立角色。这个角色不同于传统的项目经理，需要理解机器学习的基本原理，能够判断团队的实验节奏和方向是否合理。我在大型组织中观察到，有这个角色的AI项目，交付成功率比没有的高出约40%（基于我参与过的11个项目样本，这个数字仅供参考而非严格统计）。

2. 按项目阶段取舍

0到1阶段（探索期）：

• Sprint长度缩短到1周。这个阶段变化极快，2周的Sprint太长，到第二周时第一周做的假设可能已经被推翻了。
• 不要在这个阶段追求燃尽图好看。燃尽图是给确定性工作用的，探索期应该追求的是“假设验证速率”，每周验证了多少个假设，获得了多少有效认知。
• 允许Backlog剧烈变化。探索期中发现一个全新的方向，可能让之前50%的Backlog作废。这不是浪费，这是探索的应有之义。PO要有勇气大规模清理Backlog。

1到10阶段（优化期）：

• 恢复2周Sprint，引入更多工程纪律。模型方向已经基本稳定，重点转向性能优化和工程化。代码审查、单元测试、文档完善，这些在这个阶段要开始严格执行。
• 建立模型性能基准线。每次实验的效果必须和基准线对比，基准线版本号在PingCode的卡片上明确标注。避免出现“优化了半天发现不如上一个版本”的尴尬。

10到N阶段（规模化期）：

• 模型迭代节奏从“周”变为“月”。大规模线上系统的模型更新不能太频繁，每次更新需要经过完整的灰度验证和回滚预演。
• 把工作重点从模型优化转向模型运维。监控、告警、自动回滚、数据漂移检测，这些成为Sprint Backlog的主要组成部分。

3. 几组常见矛盾中的取舍判断

离线指标 vs 线上效果：当两者冲突时，优先信线上。原因很简单：离线评估永远是对真实分布的近似，而近似就有偏差。我见过离线AUC提了0.05、线上CTR纹丝不动的情况，也见过离线指标微降、线上指标大涨的情况。唯一可信的是线上A/B实验。

快速实验 vs 实验可靠性：当时间紧张时，宁愿少做几组实验，也要保证每组实验的评估可靠。一个假阳性上线的模型造成的伤害，远超你节省的那几天时间。我在第五节提到的“一个Sprint内并行实验不超过3组”就是这个考虑。

技术创新 vs 工程稳定性：在0到1阶段偏向技术创新，在1到10阶段偏向工程稳定性。但任何时候，不要用“研究”的借口逃避工程责任。代码该提交要提交，实验该可复现要可复现。我见过的最糟糕的情况是：算法工程师跑了三个月实验，最后发现第一个月的实验代码已经找不到了，所有结论无法验证，等同于白做。

团队自主 vs 流程管控：越早期的项目越需要自主，越晚期的项目越需要管控。但即便是最自由的探索期，三个底线不能放：代码必须入库、数据版本必须锁定、实验结论必须有记录。这三个不要求流程多复杂，但要求习惯够牢固。

八、总结与行动清单

这篇文章我试图把“如何用敏捷做AI项目”这个问题从多个角度拆解清楚。如果你只能记住三件事，我希望是这三件：

第一，AI项目的敏捷，本质是“假设驱动的快速学习”，而不是“用户故事驱动的快速开发”。把每个Sprint的产出物从“功能”变成“认知”，你的管理框架就会自然适配AI项目的不确定性。

第二，双轨敏捷是当前实践中最有效的折中方案。实验轨提供速度和探索空间，工程轨提供质量和稳定性。两条轨的节奏、角色、产出物都不同，强行统一只会两败俱伤。

第三，工具是框架的载体。不管用PingCode还是别的工具，关键是把假设卡片、实验评估、数据版本锁定这些AI项目特有的管理要素变成日常工作流的一部分，而不是每次Sprint Planning才临时想起来。

给你的行动清单

如果你正在或即将启动一个AI项目，并且打算用敏捷方式管理，以下是从下周一开始就可以做的事情：

1. 立刻安排一个“数据探险”Sprint（建议3-5天）。这个Sprint的唯一目标：验证数据是否能支撑Baseline模型。不要写业务代码，不要搭服务，只做数据分析和最小可行性验证。完成后产出数据可行性报告。
2. 把当前Backlog里所有的用户故事检查一遍。凡是描述模糊、无法衡量成功标准的（比如“优化模型效果”“尝试新的特征”），全部改写为假设卡片格式。改写不了的就删掉，如果写不出清晰的假设，说明你还没想清楚要验证什么。
3. 在团队内做一次“AI项目敏捷认知对齐”。花30分钟和全员讨论一个问题：“我们团队的Sprint产出物应该是什么？”引导团队理解：在AI项目中，一个被推翻的假设和一个被验证的假设，价值是同等的。
4. 建立“实验失败记录”的习惯。每个Sprint结束时，花10分钟在回顾会上记录：这个Sprint做了哪些实验，哪些失败了，失败的原因是什么，学到了什么。三个月后回头看，这个记录会是团队最宝贵的知识资产。
5. 如果你是100人以上组织的管理者，考虑为AI项目设立独立的“完成定义”。这个完成定义至少包含：模型性能指标、子群体效果、可复现性、线上离线一致性检查。

敏捷在AI项目中的价值不是让你跑得更快，而是让你在不知道终点在哪里的情况下，每一步都踩在实地上。希望这篇文章能帮你少踩一些我踩过的坑。

（全文完）