AI团队的敏捷开发实践
原创
灵阙教研团队
C 参考 进阶 |
约 14 分钟阅读
更新于 2026-02-28 AI 导读
AI团队的敏捷开发实践 将敏捷方法论适配AI/ML项目的不确定性，覆盖迭代规划、实验管理与交付节奏 一、AI项目与传统软件的差异 1.1 核心差异对比 传统软件项目 vs AI/ML项目 ========================= 传统软件 AI/ML项目 ---------------------------- ----------------------------...
AI团队的敏捷开发实践
将敏捷方法论适配AI/ML项目的不确定性，覆盖迭代规划、实验管理与交付节奏
一、AI项目与传统软件的差异
1.1 核心差异对比
传统软件项目 vs AI/ML项目
=========================
传统软件 AI/ML项目
---------------------------- ----------------------------
需求明确，可提前定义 需求模糊，目标可量化但路径不确定
线性开发流程 实验探索+工程开发双轨并行
代码决定行为 代码+数据+模型共同决定行为
Bug是确定性的 "Bug"可能是统计性的
交付物是可执行软件 交付物是模型+服务+数据管线
测试覆盖率可量化 模型效果评估有噪声
回滚明确可控 回滚涉及模型+数据+配置
1.2 AI项目失败的常见原因
| 失败原因 | 占比 | 具体表现 | 敏捷可解决 |
|---|---|---|---|
| 问题定义不清 | 25% | 不知道什么指标算"好" | 是 - Sprint 0明确 |
| 数据质量差 | 20% | 标注噪声、分布偏移 | 部分 - 数据Sprint |
| 实验管理混乱 | 15% | 无法复现、对比困难 | 是 - 实验看板 |
| 工程化能力不足 | 15% | 模型好但无法上线 | 是 - MLOps Sprint |
| 目标频繁变更 | 10% | 指标反复修改 | 是 - Sprint评审 |
| 团队协作问题 | 10% | 研究与工程脱节 | 是 - 跨职能团队 |
| 技术选型失误 | 5% | 方向性错误 | 部分 - Spike |
1.3 为什么标准Scrum不适合AI项目
标准Scrum的AI适配问题
=====================
问题1: 用户故事难以描述模型任务
标准："作为用户，我希望xxx，以便xxx"
AI版："作为系统，我需要在xxx数据上达到xxx指标"
--> 需要引入"实验假设"作为补充
问题2: Story Point估算不可靠
模型训练时间不确定（可能2小时也可能2天）
实验成功率无法预测
--> 需要引入"时间盒(Timebox)"替代估算
问题3: Sprint内完成承诺不可行
实验可能全部失败
--> 需要接受"负面结果也是成果"
问题4: 定义Done困难
"模型准确率达到90%"不一定一个Sprint能实现
--> 需要分层DoD（实验Done vs 工程Done）
二、AI敏捷框架设计
2.1 AI-Scrum框架
AI-Scrum框架（适配AI项目的Scrum变体）
=====================================
Sprint 0: 问题定义与数据准备（1-2周）
|-- 明确业务目标与成功指标
|-- 数据可用性评估
|-- 技术可行性研究(Spike)
|-- 建立评估基线
|
v
Sprint N: 实验迭代（1-2周/Sprint）
|-- 实验规划 --> 实验执行 --> 结果评估 --> 决策
|-- 每日站会（含实验进展）
|-- Sprint评审（展示实验结果）
|-- Sprint回顾（改进实验流程）
|
v (达到目标指标)
Sprint M: 工程化交付（1-2周）
|-- 模型打包与部署
|-- API开发与测试
|-- 监控与告警
|-- 上线与验收
|
v
持续运营
|-- 模型性能监控
|-- 数据漂移检测
|-- 定期模型更新
2.2 双轨制：实验轨与工程轨
双轨制运行模式
==============
实验轨(Research Track) 工程轨(Engineering Track)
+--------------------+ +--------------------+
| 目标：探索最优方案 | | 目标：可靠落地交付 |
+--------------------+ +--------------------+
| 节奏：1-2周实验周期 | | 节奏：2周Sprint |
| 产出：实验报告+模型 | | 产出：可部署的服务 |
| 衡量：指标提升幅度 | | 衡量：SLA/可用性 |
+--------------------+ +--------------------+
| |
| 模型交接 |
+------------>-----------------+
|
交接检查清单：
[ ] 模型指标达标
[ ] 训练代码可复现
[ ] 数据管线文档化
[ ] 推理性能达标
[ ] 测试用例覆盖
时间分配建议：
早期（探索阶段）：实验70% + 工程30%
中期（收敛阶段）：实验40% + 工程60%
后期（交付阶段）：实验10% + 工程90%
2.3 实验假设卡片
替代传统用户故事，使用实验假设卡片驱动AI Sprint：
实验假设卡片模板
================
[假设ID]: EXP-2026-042
[假设描述]:
如果我们 [采取某个行动/尝试某种方法]
那么 [预期会发生什么]
因为 [我们相信的原因]
[成功标准]:
主指标：准确率从 82% 提升到 88%
副指标：推理延迟 < 50ms
底线：不低于当前基线(82%)
[时间盒]: 3天
超时策略：记录当前结果，决定是否继续
[数据需求]:
训练集：10万条标注数据
验证集：2万条（与训练集无交集）
测试集：1万条（hold-out）
[资源需求]:
GPU：2x A100，预计训练24小时
存储：500GB
[风险]:
- 数据分布可能与生产环境不一致
- 模型可能过拟合小样本
[结果记录]:
实际指标：___
结论：假设成立/不成立/部分成立
下一步：___
[实验者]: @张三
[审阅者]: @李四
三、Sprint规划与执行
3.1 Sprint 0：问题定义
Sprint 0 CheckList（必须在正式开发前完成）
==========================================
[业务对齐]
[ ] 业务目标明确且可量化
[ ] 成功标准已与利益相关方对齐
[ ] ROI预期评估完成
[ ] 明确"够好"的标准（不追求完美）
[数据评估]
[ ] 数据源已识别并可访问
[ ] 数据量级评估（是否充足）
[ ] 数据质量初步评估
[ ] 标注方案设计（如需标注）
[ ] 数据合规性确认（隐私/版权）
[技术可行性]
[ ] 相关论文/方案调研完成
[ ] Baseline模型已建立（简单方案）
[ ] 指标体系定义完成
[ ] 评估管线搭建完成
[ ] 硬件资源需求估算
[团队准备]
[ ] 团队角色分工明确
[ ] 工具链选型完成
[ ] 实验管理平台就绪
[ ] 代码仓库+CI/CD就绪
3.2 实验Sprint执行
实验Sprint典型时间线（2周）
===========================
Week 1:
Day 1 (Mon): Sprint规划
- 从Backlog中选取实验假设
- 分配实验任务
- 确认数据/资源就绪
Day 2-3 (Tue-Wed): 实验执行
- 数据预处理
- 模型训练/微调
- 初步结果评估
Day 4 (Thu): 中期检查
- 分享初步结果
- 决定：继续/调整/放弃
- 必要时调整实验方向
Day 5 (Fri): 迭代优化
- 根据中期结果调整
- 超参数调优
- 错误分析
Week 2:
Day 6-7 (Mon-Tue): 深入优化
- 最有前景方案的深入优化
- 消融实验(Ablation Study)
- 鲁棒性测试
Day 8-9 (Wed-Thu): 收尾与文档
- 实验结果整理
- 可复现性验证
- 实验报告撰写
Day 10 (Fri): Sprint评审+回顾
- 向利益相关方展示结果
- 回顾改进点
- 规划下一Sprint方向
3.3 每日站会（AI版）
AI团队每日站会模板（15分钟）
============================
标准三问（每人2分钟）：
1. 昨天做了什么实验/工作？
2. 今天计划做什么？
3. 有什么阻碍？
AI团队额外关注（团队层面5分钟）：
4. GPU资源使用情况？
- 当前利用率
- 是否有资源排队
- 预计完成时间
5. 实验指标走向？
- 指标在改善/持平/恶化
- 是否需要调整方向
6. 数据问题？
- 数据质量告警
- 标注进度
- 新数据到位情况
站会工具：
实验看板(Kanban)替代传统Sprint Board
列：假设池 | 实验中 | 评估中 | 已结论 | 待工程化
四、实验管理
4.1 实验跟踪工具链
| 工具 | 定位 | 核心功能 | 适合团队 |
|---|---|---|---|
| MLflow | 开源实验管理 | 实验追踪+模型注册 | 中小团队 |
| Weights & Biases | 商业实验平台 | 可视化+协作+报告 | 中大团队 |
| Neptune.ai | 商业实验管理 | 元数据管理+比较 | 大团队 |
| DVC | 数据版本控制 | 数据+管线版本化 | 数据密集型 |
| ClearML | 开源全栈平台 | 实验+管线+部署 | 全栈需求 |
4.2 实验记录规范
# 实验记录标准化
class ExperimentRecord:
"""每个实验必须记录的信息"""
required_fields = {
# 元信息
"experiment_id": "唯一标识",
"hypothesis_id": "关联的实验假设卡片ID",
"author": "实验者",
"date": "实验日期",
"status": "running/completed/failed/abandoned",
# 输入
"dataset_version": "数据集版本hash",
"model_architecture": "模型架构描述",
"hyperparameters": "超参数配置",
"training_config": "训练配置(batch/lr/epochs等)",
"random_seed": "随机种子（可复现性）",
# 执行
"hardware": "GPU型号+数量",
"training_time": "训练耗时",
"gpu_hours": "GPU时数",
# 输出
"metrics": {
"primary": "主指标值",
"secondary": "副指标值",
"baseline_comparison": "与基线对比",
},
"artifacts": {
"model_checkpoint": "模型文件路径",
"training_logs": "训练日志路径",
"evaluation_report": "评估报告路径",
},
# 分析
"error_analysis": "错误案例分析",
"conclusions": "实验结论",
"next_steps": "建议的下一步",
}
4.3 实验决策框架
实验结果决策流程
================
实验完成
|
v
主指标是否达标？
|
+---+---+
| |
是 否
| |
| 有改进空间吗？
| |
| +---+---+
| | |
| 是 否
| | |
| v v
| 继续 放弃该
| 优化 方向
| | |
| v v
| 新假设 记录负
| 卡片 面结果
| |
v v
进入工程化 分享给
流程 团队学习
决策原则：
1. 快速失败（Time-box严格执行）
2. 负面结果有价值（记录并分享）
3. 不要沉没成本谬误
4. 数据驱动决策（不靠感觉）
五、团队结构与角色
5.1 AI敏捷团队组成
AI敏捷团队推荐结构（7-9人）
===========================
Product Owner (PO) ---- 1人
职责：业务目标定义、优先级排序、验收
AI特殊：需要理解ML指标与业务指标的关系
Scrum Master (SM) ----- 1人
职责：流程教练、障碍清除、持续改进
AI特殊：需要理解实验流程的不确定性
ML Engineer ----------- 2-3人
职责：模型开发、实验执行、特征工程
AI特殊：核心产出力量
Data Engineer --------- 1-2人
职责：数据管线、数据质量、特征存储
AI特殊：数据是AI项目的基础
MLOps Engineer -------- 1人
职责：模型部署、监控、CI/CD
AI特殊：研究到生产的桥梁
Backend/Frontend ------ 1人
职责：API开发、前端集成
AI特殊：将模型能力产品化
5.2 角色职责矩阵(RACI)
| 活动 | PO | SM | ML | Data | MLOps | Dev |
|---|---|---|---|---|---|---|
| 业务目标定义 | A | C | I | I | I | I |
| 数据需求定义 | C | I | R | A | I | I |
| 实验规划 | C | I | A | C | I | I |
| 模型开发 | I | I | A | C | I | I |
| 数据管线 | I | I | C | A | C | I |
| 模型部署 | I | I | C | I | A | C |
| API开发 | C | I | C | I | C | A |
| 监控告警 | I | I | C | I | A | C |
| Sprint评审 | A | R | R | R | R | R |
R=负责执行 A=最终负责 C=咨询 I=知会
六、工具与实践
6.1 AI看板设计
AI项目看板（Kanban）
====================
| 假设池 | 数据准备 | 实验中 | 评估中 | 已结论 | 待工程化 |
| (Backlog) | (Data) | (Exp) | (Eval) | (Done) | (Deploy) |
|-------------|-----------|----------|----------|-----------|-----------|
| EXP-045 | EXP-042 | EXP-041 | EXP-040 | EXP-039 | EXP-038 |
| 尝试LoRA | 数据清洗 | 训练中 | 对比基线 | 假设成立 | 模型打包 |
| 微调方案 | 进度60% | GPU: 2h | 指标: +5%| +8% acc | ETA: 3天 |
| | | | | | |
| EXP-046 | EXP-043 | | | EXP-037 | |
| 数据增强 | 标注审核 | | | 假设不成立| |
| 策略对比 | 进度80% | | | -2% acc | |
| | | | | (已记录) | |
WIP限制：
实验中：最多3个（受GPU限制）
评估中：最多2个
待工程化：最多2个
流动效率目标：
假设从进入看板到得出结论：< 5天
得出结论到部署上线：< 10天
6.2 实验复盘模板
Sprint回顾 - 实验复盘模板
==========================
日期：YYYY-MM-DD
Sprint：#N
参与者：团队全员
一、实验成果总结
完成实验数：X
成功实验数：Y
指标最佳提升：+Z%
当前最优指标：XX%
二、本Sprint学到了什么
| 学习点 | 来源实验 | 可操作建议 |
|--------|---------|-----------|
| 数据增强对X有效 | EXP-041 | 后续默认启用 |
| 学习率>1e-3导致不收敛 | EXP-042 | 设为超参搜索范围上限 |
三、做得好的
- [列出]
四、可以改进的
- [列出]
五、改进行动项
| 改进项 | 负责人 | 截止日期 |
|--------|--------|---------|
| 自动化超参搜索 | @张三 | 下Sprint |
| 数据管线加速 | @李四 | 下Sprint |
六、下Sprint方向
- 优先假设：EXP-045, EXP-046
- 工程化任务：EXP-038部署
6.3 定义完成(DoD)标准
AI项目分层DoD
=============
[实验Done]
[ ] 实验假设有明确结论（成立/不成立/部分成立）
[ ] 实验结果可复现（固定种子+环境记录）
[ ] 实验记录完整（参数/指标/分析）
[ ] 错误分析已完成（至少10个bad case）
[ ] 同行评审已通过
[模型Done]
[ ] 模型指标达到验收标准
[ ] 模型在测试集上评估完成
[ ] 推理延迟/吞吐量达标
[ ] 模型大小在部署限制内
[ ] 模型卡(Model Card)已填写
[工程Done]
[ ] API开发完成+单元测试覆盖
[ ] 集成测试通过
[ ] 性能测试通过（压测）
[ ] 监控+告警+日志配置完成
[ ] 部署流水线就绪
[ ] 回滚方案验证
[产品Done]
[ ] PO验收通过
[ ] 用户测试通过（如适用）
[ ] 文档更新完成
[ ] 发布说明准备好
七、度量与持续改进
7.1 AI团队敏捷度量指标
# AI敏捷团队度量指标
agile_metrics = {
"流动效率": {
"description": "假设从提出到得出结论的平均时间",
"target": "< 5天",
"how_to_measure": "看板流动分析",
},
"实验吞吐量": {
"description": "每Sprint完成的实验数",
"target": "5-10个/Sprint",
"how_to_measure": "看板完成列统计",
},
"假设成功率": {
"description": "实验假设被验证为成立的比例",
"target": "30-50%（太高说明假设不够大胆）",
"how_to_measure": "实验记录统计",
},
"指标进步率": {
"description": "每Sprint主指标的提升幅度",
"target": "持续正向",
"how_to_measure": "指标趋势图",
},
"实验到生产时间": {
"description": "模型从实验完成到生产部署的时间",
"target": "< 2周",
"how_to_measure": "部署记录",
},
"GPU利用率": {
"description": "GPU资源的有效使用率",
"target": "> 70%",
"how_to_measure": "GPU监控面板",
},
"技术债务比例": {
"description": "用于还技术债的时间占比",
"target": "< 20%",
"how_to_measure": "Sprint任务分类统计",
},
}
7.2 持续改进循环
AI团队持续改进循环（季度）
==========================
Q1: 评估当前状态
- 收集团队满意度调查
- 分析Sprint度量趋势
- 识别瓶颈与痛点
|
v
Q2: 确定改进主题
- 投票选择1-2个改进主题
- 设定可衡量的改进目标
- 分配改进负责人
|
v
Q3: 实施改进
- 在Sprint中嵌入改进实验
- 小步尝试，快速反馈
- 记录改进效果
|
v
Q4: 沉淀标准化
- 有效改进纳入团队规范
- 更新DoD/看板/模板
- 分享给其他团队
八、实践清单
AI敏捷开发实践自检
==================
[框架层面]
[ ] 采用适配AI的敏捷框架（非照搬Scrum）
[ ] 建立双轨制（实验轨+工程轨）
[ ] Sprint 0明确定义问题与基线
[ ] 使用实验假设卡片替代用户故事
[团队层面]
[ ] 跨职能团队组建完成
[ ] 角色分工明确(RACI)
[ ] 每日站会包含实验进展
[ ] Sprint评审展示实验结果
[实验管理]
[ ] 实验跟踪工具部署就绪
[ ] 实验记录规范已执行
[ ] 实验决策框架已建立
[ ] 负面结果有记录和分享
[工程实践]
[ ] CI/CD管线就绪
[ ] 模型版本管理
[ ] 数据版本管理
[ ] 自动化评估管线
[度量与改进]
[ ] 关键度量指标已定义
[ ] 度量数据自动采集
[ ] 定期回顾与改进
[ ] 改进成果标准化沉淀
Maurice | maurice_wen@proton.me