解读

面试官想知道三件事：

1. 你是否真的跑过“算法-数据-工程”并行的AI项目，而不是只做过互联网功能迭代；
2. 能否把“算法不确定性”翻译成团队可执行、可度量的流程；
3. 在合规、成本、国产算力受限等中国语境下，如何取舍敏捷宣言里的“快速响应”与“可控风险”。
   回答时要先指出Scrum在AI场景下的“结构性冲突”，再给出“可落地的本土化补丁”，并辅以量化结果，避免空谈“敏捷价值观”。

知识点

1. 不确定性层级差异：软件需求是“业务逻辑不确定”，AI是“数据分布+算法效果+算力约束”三重不确定。
2. 迭代单元差异：Scrum 以“可交付软件”为增量，AI 应以“可上线模型”为增量，但模型效果不可压缩到两周内保证收敛。
3. 角色边界差异：PO 无法像传统场景一样在 Sprint0 就锁定 PRD，需让算法、数据、标注、法务、成本五方共同决策。
4. 国产合规要求：数据出境审批、算法备案、算力配额，导致“随时可发布”不可行，必须预留“合规闸门”。
5. 国内团队文化：开发习惯“大瀑布+冲刺”，盲目照搬每日站会容易流于形式，需要把“站会”拆成“数据晨会+模型午会+工程夕会”。

答案

“我在上一家公司负责金融风控AI平台，从0到1落地了8条模型管线。传统Scrum遇到的核心冲突有三点，并针对性做了四项本土化调整，最终把模型上线周期从平均14周降到6周，模型AUC提升窗口缩短30%。”

冲突1：两周Sprint无法承载“数据-标注-训练-评估”闭环
调整：把Scrum的“固定节奏”改成“双轨节奏”——
a. 数据轨道：按“数据版本”发版，采用3周一个Data Iteration，包含采集、清洗、标注、合规审核四环节，输出一份“可训练数据集版本号”；
b. 模型轨道：以“模型版本”为增量，采用“弹性Sprint”，长度=算法工程师估算的“收敛预期+2天缓冲”，最短1周、最长4周，由技术负责人+我在规划会后24小时内共同敲定；
c. 工程轨道：保持2周Scrum，确保特征平台、推理服务、监控看板持续交付。
三条轨道用“模型效果评审会”同步：只有当Data Iteration输出≥95%标注一致性且模型轨道在验证集上达到预设基线，才合并进主干，进入工程轨道发布。

冲突2：PO无法提前锁定Backlog优先级
调整：引入“不确定性系数”量化排序。每季度召开一次“模型战略对焦会”，用二维矩阵打分：横轴业务价值（0-10分，由风控损失金额换算），纵轴技术可行度（0-10分，由数据可得性×算法成熟度×算力成本系数计算）。得分≥60的模型才进入Backlog；Sprint Planning时，再用“最近一周数据采样验证”重新校准可行度，避免PO拍脑袋。

冲突3：每日站会无法暴露算法阻塞
调整：把15分钟站会拆成“三段式”——

1. 数据晨会（5分钟）：标注组长汇报昨日新增样本、异常标签、合规卡点；
2. 模型午会（10分钟）：算法同学展示昨夜训练Loss曲线、验证指标，提出“需调参/需数据/需算力”三类阻塞；
3. 工程夕会（5分钟）：后端同步推理延迟、GPU配额、灰度策略。
   用飞书多维表格自动汇总，生成“AI阻塞看板”，次日早上推送给全员，减少口头对齐成本。

冲突4：合规闸门与“随时可发布”矛盾
调整：在CI/CD里增加“合规Stage”，包含三项自动检查：
a. 数据出境白名单校验；
b. 算法备案号与模型版本号一致性校验；
c. 算力配额余量校验。
任何一项失败即阻断发布，并自动创建JIRA工单给法务与运维，确保“敏捷”不触碰监管红线。

结果：运行四个季度后，我们累计发布模型版本42个，生产AUC平均提升4.7%，合规事件0起；团队满意度调研中，85%成员认为“节奏可预测、阻塞透明”，高于业务线平均20个百分点。

拓展思考

如果面试官继续追问“如何进一步压缩模型迭代周期”，可补充：

1. 引入“小样本+主动学习”双轮驱动，把标注量降到原来的30%，让Data Iteration从3周缩短到1周；
2. 用国产GPU池化平台（如华为MindCluster）做动态配额，训练任务按需弹性伸缩，把排队时间从平均2天降到2小时；
3. 在Sprint Review引入“线上Shadow A/B”机制，模型只要离线提升≥1%且合规通过，即可灰度5%流量做Shadow，真实业务标签回流后再决定全量，从而把“效果验证”并行化，节省一到两周。