Published
- 7 min read
当 AI 加入 Sprint：Agile项目管理正在经历什么
引言
在最后一个学期的毕业设计项目中，我们使用 Jira 管理一个 IT 系统开发项目。流程本身是标准的 Scrum 实践：收集 user story，整理 backlog，定义 epic，规划 sprint，评估 story point，跟踪 team velocity。这套框架我们并不陌生，它已经足够成熟，有清晰的工具和方法论支撑。
但在这个项目里，我们大量使用 AI 协助完成开发工作。这个决定看似只是引入了一种新工具，实际上却引发了一系列对项目管理方式的根本性冲击。不是流程坏掉了，而是流程赖以运转的一些底层假设开始动摇。
这篇文章记录我在这个项目中观察到的三个具体变化，以及它们共同指向的一个更大的问题：当 AI 介入生产过程，Agile 的坐标系需要如何重新校准？
一、Story Point 衡量的不再是同一件事
传统 story point 估算有一个隐含的前提：任务的执行者是人，工作量主要来自人类的认知投入和编码劳动，而在能力水平相近的团队成员之间，这种估算的误差在可接受范围内。正是基于这个前提，Planning Poker 和 T-shirt sizing 才能运作——每个人对任务有直觉性的感受，可以给出有意义的估算。
AI 介入之后，这个前提开始松动。最直接的变化是：以往 story point 较高的编码类任务，大量可以交由 AI 快速完成，工作量骤降。与此同时，一些过去被认为权重较低的任务，比如阅读技术文档、进行调研访谈、与利益相关者沟通确认需求，这些只能由人完成、无法外包给 AI 的工作，其相对权重反而上升了。
这不只是需要调整几个数字的问题。Story point 的参照系本身发生了位移。以往”这个任务值 5 点”意味着大约需要多少人类劳动时间；现在同样说”5 点”，它指向的实际内容已经完全不同。Velocity 的计算基础改变了，但我们还在用旧的单位衡量新的生产力。
二、能力方差扩大：谁能和 AI 一起干活？
Story point 失准，背后有一个更深的原因：与 AI 协作的能力本身，成为了一个新的、差异巨大的变量。
在传统项目管理的估算模型里，有一个默认假设：团队成员的能力相对均质，个体差异在统计上可以被平均化处理。这也是为什么 velocity 作为团队层面的指标能够稳定运转——它预设了一个相对稳定的”平均人”。
AI 改变了这一点。不同的人与 AI 协作工作，效率差异极大。这个差异来自很多因素：是否熟悉 prompt 工程，是否有能力快速评估 AI 输出的质量，是否能准确判断何时应该信任 AI、何时需要介入调试。这些能力目前既没有成熟的评估基准，也很难通过简单培训在短期内拉平。
关于这种方差，有两点值得区分。第一，它目前很大，因为 AI 工具对大多数人来说仍然是新事物，使用经验的差距直接造成了效率的悬殊。随着 AI 工具的普及，这种差距会收窄。第二，但即便收窄，这种方差也不会消失，因为 AI 协作能力本身会持续迭代，它永远是一个需要持续学习的动态能力，而不是一个可以一次掌握的静态技能。因此，AI 时代团队成员之间的能力方差，在结构上将长期大于 AI 出现之前的个体方差。
这对 sprint planning 和 velocity 预测的影响是持续的，不是过渡期现象。
三、AI 把元任务推到了台前
AI 带来的第三个变化，是改变了工作任务的结构本身。
以前，一个 story 的边界是清晰的：一个人，一个任务，一段代码。Story point 衡量的是这个原子单位的体量。现在，当 AI 介入，原来一个完整的 story 裂变成了一个小型工作流。以一个编码任务为例，它现在通常包含三个阶段：前置的 prompt 优化（明确任务边界，约束输出格式，选择合适的模型），AI 的执行，以及后置的人工验证和调试。这三个阶段之间是强顺序依赖，不能并行，也不能省略。
这里有一个概念值得命名：元任务。元任务是关于”如何使用工具完成任务”的任务，而不是直接产出 deliverable 的任务。传统项目管理里也有元任务，比如讨论技术方案、评审代码，但它们通常是隐性的，内嵌在 story 的工时估算里，不会单独作为 sprint 条目出现。AI 把元任务显性化了——prompt 工程、AI 输出验证，这些现在是真实的、需要时间和精力的工作，它们应该出现在 backlog 里，应该被估算，应该被追踪。
这个显性化过程在短期内会带来管理摩擦，原因是认知不对称。Planning Poker 能够运作，前提是每个人对任务都有直觉性的感受。但当团队里五个人中只有两个人真正用过 AI 完成编码工作，另外三个人根本没有这种直觉，估算就会出现系统性偏差——不是因为工具不对，而是因为大家对”要做什么”的认知不在同一个层面上。
从长远来看，元任务的显性化是有益的。它迫使团队把隐性的认知负担搬到台面上讨论，也让个体之间的能力差距变得可见，从而有机会被处理。但在过渡期，这需要团队投入更多精力建立共同语言，让每个人真正理解这些新任务意味着什么。
四、Agile 需要重新校准，而不是重新发明
面对这三个变化，一个自然的问题是：Agile/Scrum 这套框架本身是否需要被替换？
我的观察是：不需要，但需要认真校准。
Agile 并不是第一次面对生产力的结构性升级。DevOps 和 CI/CD 的普及是一个有参考价值的案例。自动化部署的出现，使得”部署”这个任务从数天压缩到分钟级，也催生了一批新的元任务，比如编写 pipeline、维护 infrastructure as code。Agile 当时的应对方式，不是修改 sprint 或 backlog 的定义，而是重新校准什么算一个合理的 story 边界，逐步把 DevOps 相关任务纳入正常的估算和追踪流程。
AI 带来的冲击在量级上更大，渗透的范围更广，但应对的路径是相似的：框架本身保持稳定，重新定义框架内部的参数和边界。Story point 仍然有意义，只是参照系需要更新。Velocity 仍然是有价值的团队指标，只是估算方法需要把 AI 协作能力的方差纳入考量。Sprint 规划仍然成立，只是元任务需要从隐性变成显性。
这个校准过程不会是一次性的。AI 工具本身在持续迭代，团队的 AI 协作能力也在持续变化，这意味着对 velocity、story point、sprint 结构的理解，需要作为一种持续学习和持续更新的实践，而不是一次调整后就能固定下来的结论。
对 Scrum 团队来说，这可能是 AI 时代带来的最实质性的新要求：不只是学会使用新工具，而是建立一种能够持续校准自身认知框架的集体能力。
本文基于本人在毕业设计项目中的实践观察与反思，结合 Agile/Scrum 项目管理框架展开讨论。