AI辅助的Sprint Planning：如何在不丢失责任的前提下加速准备

这是关于AI如何改变跨职能开发团队经典会议系列文章的第二篇。在第一篇文章中，我分析了 Backlog Refinement 并得出了核心结论：AI加速的不是团队本身的共识，而是为达成共识所做的材料准备。现在顺理成章地进入下一步——Sprint Planning——看看如何在不丢失团队对冲刺目标、范围和现实性所负责任的前提下，加速其准备工作。

乍看之下，经过良好的refinement之后，planning似乎应该几乎变成技术性的形式流程。待办事项的元素已经细化，验收标准已经草拟，风险已经列出，开放问题已部分关闭，技术方案的选项已经准备好。剩下的只是把任务选进冲刺并分配到人。

但这恰恰是陷阱。

Scrum中的Sprint Planning不是一次任务分配会议。它是团队回答三个更重要问题的活动：为什么这个冲刺有价值、冲刺期间实际能完成什么，以及选定的工作将如何完成。如果从这个框架来看AI，关键就显而易见了：AI确实可以帮助团队更快地汇集计划方案、突出依赖关系、提出分解建议并准备问题。但它无法承担Sprint Goal的责任，也无法单凭自身让计划变得现实。

“AI帮助汇集一份看起来现实的计划。只有团队才能让它真正现实。”

在我看来，主要转变正在于此。AI加速Sprint Planning的准备，但并不取代Sprint Planning本身作为团队就目标、范围和交付方式达成的共识。

为什么Sprint Planning不只是“往冲刺里塞任务”

在2020版Scrum Guide中，Sprint Planning被描述为启动冲刺的活动。其成果由整个开发团队的协作产生。

Sprint Planning围绕三个主题展开

• 为什么这个冲刺有价值？
• 这个冲刺中能完成什么？
• 选定的工作将如何完成？

这是一个重要的顺序。首先不是任务列表，而是价值。不是“我们能关闭什么”，而是“到冲刺结束时我们希望获得什么改变”。正因如此，Sprint Goal不是Jira里的装饰性字符串，也不是所选任务的漂亮简短摘要。它是冲刺的统一目标，即为团队提供焦点、并在冲刺内出现新事实时允许做出决策的统一目标。

Sprint Backlog由三部分组成：作为“为什么”的Sprint Goal、作为“什么”的所选待办事项元素，以及作为“如何”的可执行计划。尤其重要的是，Sprint Backlog是由开发者创建、为开发者服务的计划。产品负责人帮助准备讨论并将所选工作与Product Goal关联，Scrum Master帮助活动变得有用且高效，但执行计划以及对工程部分现实性的责任仍留在开发团队内部。

由此得出一个简单但非常重要的结论，用于讨论AI：工具可以提出Sprint Goal的措辞、初步的待办事项元素列表、依赖关系、风险和分解方案。但它不能成为团队承诺的载体。它不能替团队说：“我们确实准备好承担这些了。”

AI在planning中真正改变了什么

先明确证据边界。迄今为止，关于真实Scrum团队中AI辅助Sprint Planning的强研究基础很少。相关主题的研究要多得多：需求工程、用户故事质量、工作量估算、测试生成、人与AI协同决策以及AI风险管理。因此更准确的说法不是“AI规划冲刺”，而是“AI加速汇集可供讨论的草稿计划，并帮助团队更早看到部分缺口”。这是一个重要的区别。

在AI出现之前，Sprint Planning的准备往往相当手工化。产品负责人提前查看优先级并尝试汇集初步的工作量。分析师检查待办事项元素是否准备好讨论。开发者回忆技术限制和类似任务。QA提出测试风险。Scrum Master确保会议不会变成关于本应更早澄清的细节的混乱争论。

有了 AI，这个准备层可以明显加快——前提是团队有高质量的输入上下文和清晰的结果验证流程。模型可以帮助生成几个 Sprint Goal 的备选方案，围绕目标对 backlog 条目进行分组，突出验收标准中的薄弱之处，提出依赖清单，在历史记录中查找相似任务，草拟风险，并为 QA、后端、前端和设计准备问题。但这并不能证明最终的 planning 一定会更快或更准确：一部分收益可能会消耗在人工核对、来源核实和修正草稿错误上。

当团队在 AI 辅助的 refinement 之后进入 planning 时，这一点尤其有用。在上一篇文章中，我展示了 AI 如何帮助更快地将原始请求转化为更成熟的 backlog 条目。但现在出现了下一个问题：如果 backlog 条目看起来更好了，是否意味着计划也变得更好了？

不一定。

AI 可以让规划产物看起来更整齐。它可以营造出一种一切都已经串联起来的感觉：这里是 Sprint Goal，这里是工作量范围，这里是风险，这里是依赖，这里是测试备注。但这还不是计划。这是计划的草稿。而 Sprint Planning 的价值恰恰在于团队要拿这份草稿去对照现实进行检验。

AI 帮助更快地汇总 Sprint Goal 的备选方案、工作量范围、依赖和风险，但不能替代团队对计划现实性的检验。

继续同一个案例：B2B LMS 和邮件提醒

为了避免空泛，我继续第一篇文章中的案例。

有一个用于企业培训的 B2B LMS 平台。大客户为员工分配合规、安全和内部规章方面的必修课程。业务方希望为未在截止日期前完成必修课程的员工增加自动邮件提醒。

在 refinement 上，团队已经发现这个任务只是看起来简单。实际上需要就以下事项达成一致：

• 谁算符合提醒条件；
• 是否只针对必修课程；
• 要考虑哪些状态： not_started, in_progress, expired；
• 如何排除 archived 和已停用用户；
• 时区存储在哪里；
• 语言设置和语言 fallback 如何工作；
• 如何在调度任务重复运行时防止重复；
• 是否需要历史日志 / 审计日志；
• 客户支持团队应该能看到什么；
• 第一版的最小工作量范围到哪里为止。

经过一次好的 refinement 之后，团队可以带着相当扎实的底稿进入 Sprint Planning。例如，AI 帮助汇总了用户故事的草稿、验收标准、边界情况清单、技术方案备选和待解决问题。但在 planning 上需要做出另一类决策：团队在最近这个 sprint 中究竟要做什么，以及以什么为目标。

对于这个案例，一个糟糕的 Sprint Goal 可能长这样：

“做 scheduler、邮件提醒和历史日志。”

形式上可以理解，但这只是组件清单。它没有说明这个 sprint 的价值何在、应该出现的最小结果是什么、哪些妥协是可以接受的。

更有力的表述是：

“系统向未在截止日期前完成必修课程的活跃员工发送一条正确的提醒，并保存可验证的发送历史。”

这个表述更好，因为它已经包含了价值和边界。我们不承诺完整的客户面板。不承诺复杂的提醒逻辑。不立即解决围绕 expired的所有争议。不构建扩展分析。但我们承诺一个最小有价值的结果：目标员工收到正确的提醒，团队可以核查邮件发给了谁、何时发的以及为什么发。

没有 AI 时 planning 会是什么样

没有 AI 时，这样的会议往往从恢复上下文开始。产品负责人重述业务请求。分析师复述 refinement 上弄清楚的内容。后端澄清通知服务如何工作。前端询问是否需要设置界面，还是后端逻辑就够了。QA 开始抛出关于截止日期、时区、重复和状态的问题。设计师试图弄清楚第一版工作量范围里到底有没有 UI。

会议的一半时间不是用来选择现实的计划，而是用来把材料重新装回团队的脑子里。到某个时刻，就会忍不住想干脆“把所有重要的都拿进来”：条件匹配、scheduler、邮件模板、去重 / 消除重复、历史日志、语言 fallback 设置、时区、客户支持团队的信息可见性、对 expired, 的处理、客户设置，还有另外几个边界情况。

这样的工作量在常识层面看起来可能合理：毕竟一切都有关联。但正是在这里，planning 开始膨胀。团队似乎是在谈论一个整体结果，但实际上却引入了几个相互独立的不确定性方向。某处产品语义不清楚，某处技术实现不清楚，某处测试不清楚，某处 UI 不清楚，某处支持不清楚。

结果，到会议结束时可能会出现一个看起来完整、但依然脆弱的 Sprint Backlog。它建立在一种希望之上：所有有争议的地方都会在冲刺过程中得到解决。有时确实如此。但很多时候，团队正是这样得到未完成工作的结转、隐藏的工作量蔓延，以及一种不舒服的感觉：“我们不是好像什么都讨论过了吗”。

planning 如何随 AI 变化

有了 AI，同一场会议可以从另一个层面开始。

在 planning 之前，AI 帮助产品负责人准备几个 Sprint Goal 方案：狭窄的第一版、更宽的客户工作量、技术上安全的工作量、扩展的雄心勃勃的工作量。分析师请 AI 把 backlog 条目与每个目标方案关联起来，并显示哪些条目并不直接支持目标。后端通过 AI 运行通知架构描述，并请它标出调度器、去重和幂等性任务的风险。前端和设计师检查第一个冲刺是否需要 UI，还是可以只做最小的历史记录展示。QA 请 AI 准备负面场景、边界场景和与时间相关的场景清单。

团队来到 planning 时不是面对一张白纸，而是带着一组方案：

• 最小工作量：必修课程、 not_started / in_progress、排除 archived 和已停用用户、一次提醒、消除重复、历史日志；
• 扩展工作量：加上语言 fallback 设置和更精细的时区策略；
• 扩展的雄心勃勃工作量：加上客户支持团队的可见性；
• 工作量之外： expired、复杂的周期性规则、扩展分析、按客户定制的个人日程。

这大大节省了认知劳动。现在团队不再把会议的大部分时间花在第一次表述方案上。他们讨论的是：哪个方案现实可行，哪个方案更好地支持 Sprint Goal，以及哪些风险不能保持隐含。

但正是在这里出现了新的陷阱。AI 组装的计划可能看起来如此工整，以至于团队开始不去检查它，而是去编辑它。不再问“我们真的能做到吗？”，而只是改进措辞。不再争论团队可用容量，而是信任漂亮的分解。不再检查依赖关系，而是认为既然它们进了表格，就意味着已经被考虑到了。

于是 AI 并没有帮助 planning。它只是让一个过度乐观的计划变得更有说服力。

主要陷阱：计划的虚假现实感

在 refinement 中，主要风险是虚假的清晰感：任务看起来清楚，是因为 AI 把它排版得很漂亮。在 Sprint Planning 中，风险不同——虚假的现实感。

虚假的现实感出现在计划看起来连贯、完整、合乎逻辑，却没有针对团队的真实约束进行检验的时候。它有 Sprint Goal、任务清单、估算、依赖关系和风险。但没有人真正检查过：团队可用容量是否足够，是否有上个冲刺的未完成工作，QA 是否过载，需要的专家是否可用，是否真的能达到 Definition of Done，以及最困难的部分是否藏在“集成”、“添加支持”或“考虑边界情况”这些词下面。

这个风险很好地对应了几个已知问题。

第一是规划谬误。团队本来就倾向于低估未来工作的复杂性，尤其是当他们“从内部”看计划并专注于期望场景时。如果 AI 能调取历史数据、相似任务、过去的延迟和未完成工作结转的典型原因，它可能有所帮助。但如果它编造出一个流畅而有说服力的故事：“一切看起来连贯，所以一切都很现实”，它也可能加剧规划谬误。

第二是自动化偏见。当系统提出一个工整的计划时，人更容易从主动检查模式转入被动认可模式。团队不再主动寻找矛盾，因为“AI 都组装好了”。这在 planning 中尤其危险，因为决策质量不取决于文本的完整性，而取决于对约束讨论的诚实程度。

第三是模型幻觉或虚构 / 自信地编造。AI 可能自信地编造出一个并不存在的依赖关系。或者引用一个“相似任务”，而它实际上只是表面相似。或者对状态、时区、语言 fallback 设置或架构约束做出错误结论。问题不在于这类错误总是很粗糙。恰恰相反，最危险的错误看起来都很可信。

第四——伪精确性。如果AI给出漂亮的评估、整齐的范围或自信的步骤序列，团队可能会产生一种精确感。但规划的精确性并非源于一张漂亮的表格。关于敏捷工作量估算的研究表明，估算质量取决于许多因素：团队经验、过往经验、任务规模、信息质量、估算实践、项目管理以及业务影响。因此，写下或认为AI“本身就能改善估算”是危险的。更诚实的表述是：AI可以帮助识别遗漏的信息、相似案例和不稳定的假设，但估算仍然必须由团队来验证。

因此，在Sprint Planning中成熟地使用AI，不是从“它给我们拼出了什么计划？”这个问题开始，而是从“这个计划中哪些地方可能是错的、不完整的或过于顺滑的？”开始。优秀的团队不只是改进AI草稿，而是特意试图反驳它：检查来源、假设、依赖关系、团队可用容量、Definition of Done，以及模型可能自信地概括超出事实所允许范围的地方。

各角色有何变化

产品负责人

产品负责人借助AI能更快获得Sprint Goal的选项和工作范围。他可以要求模型展示多个场景：最小、安全、进取、拉伸。可以更快看到哪些待办项元素真正支持目标，哪些只是“也有用”。

但产品负责人的责任并未消失。相反，它变得更加明显。如果AI建议把看起来相关的一切都纳入冲刺，产品负责人必须守住价值问题：用户或利益相关者真正需要的最小结果是什么？现在可以不做什么？什么会破坏Sprint Goal，什么只是锦上添花？

业务分析师

对分析师来说，AI是有用的连贯性检查工具。它有助于快速发现验收标准中的遗漏、待办项元素之间的矛盾、隐含假设以及值得在规划会上提出的问题。

但分析师仍然是那个区分形式上漂亮的需求与实际上经过验证的需求的人。在LMS案例中，正是分析师必须注意到“未完成的课程”并不是一个显而易见的术语。它涉及具体状态、例外情况、截止日期、客户规则和系统中的数据。

后端开发人员

后端从AI获得对技术风险的快速首轮梳理：调度器任务、幂等性、去重键、审计日志、重试逻辑、与通知服务的集成。这加快了准备工作。

但AI并不像团队那样了解整个真实架构。它可能提出一个合理的方案，却没有考虑遗留限制、不稳定的队列、数据特性或服务之间的约定。因此，后端不应“接受”AI的技术分解。他应当批判它。

前端开发人员

前端可以更快检查首轮工作范围中是否需要UI、需要展示哪些状态、用户将如何看到发送历史、是否需要设置管理，还是只读可见性就足够了。

但规划会必须诚实回答：UI对Sprint Goal真的必要，还是已经是扩展？如果目标是正确发送提醒并保存可验证的历史记录，也许第一个冲刺并不需要完整的客户端界面。AI可以帮助拟定选项，但团队必须做出取舍。

质量工程师 / QA工程师

QA从AI中获得的收益可能比想象中更大。模型能快速生成负面场景、边界场景、与时间相关的场景、时区检查、语言回退、已归档和已停用用户、调度器任务的重复运行以及去重。

但正是QA必须保护团队免于伪覆盖。一长串测试想法并不意味着计划是可测试的。只有当验收标准明确、数据可用、可观测性清晰，并且团队理解如何证明Definition of Done已完成时，计划才是可测试的。

UX/UI设计师

设计师借助AI能更快收集UI方案的选项：提醒设置、发送历史、错误状态、面向客户支持团队的提示。但在规划会上，他的任务不是用漂亮的界面功能扩大工作范围，而是帮助区分必要与期望。

在我们的案例中，完整的dashboard可能有用，但对第一个Sprint Goal并非必需。如果设计师帮助在不损失价值的情况下收窄用户路径，他就提高了计划的现实性。

Scrum Master

在AI辅助规划中，Scrum Master不再是“会议组织者”，而是团队承诺质量的守护者。他的任务是确保AI草稿本身不会成为权威。

Scrum Master在这里提出的好问题如下：

• 我们真的理解这个冲刺为什么有价值吗？
• 开发人员认为这个Sprint Backlog是他们自己的计划吗？
• AI草稿中哪些地方我们用事实验证过？
• 计划在哪里看起来过于顺利？
• 如果出现新信息，我们会首先移除什么？
• Sprint Goal 是否变成了任务清单？

对比：无 AI 与有 AI 的 Sprint Planning

规划领域	无 AI	AI 带来的变化
Sprint Goal	在实时讨论中形成，有时在选定任务之后才形成	AI 快速提出多个目标方案
工作范围选择	团队依次讨论 backlog 条目，并经常就边界争论	AI 汇总简短清单、备选工作范围方案以及范围外建议
团队可用容量	根据人员、休假、支持和未完成工作结转手动计算	AI 可以汇总历史信号和日历限制
依赖关系	通过团队记忆和经验浮现	AI 更快地从文本和历史中提取初步依赖关系
分解	由开发者自行拆分工作	AI 更快、更详细地提出分解方案
测试	QA 手动提出关键场景	AI 生成负面和边界场景的初步方案
风险管理	风险常常只是零散地被提及	AI 快速形成风险清单和假设登记表
团队承诺	在讨论后由团队共识产生	AI 生成更精致的计划，更容易被接受
文档	常常在会后手动补写	AI 快速记录决策、假设和后续行动

新风险及需要人工检查的内容

规划领域	新风险	需要人工检查的内容
Sprint Goal	Sprint Goal 变成工作范围的精美简短摘要	目标中是否包含“为什么”，而不仅仅是“我们做什么”
工作范围选择	虚假的完整感和工作范围过度塞满	每个条目是否确实对 Sprint Goal 必要？哪个可以最先移除？
团队可用容量	遗漏真实的干扰、bug、支持和会议	是否考虑了休假、支持负载、未完成工作、强制会议以及等待外部依赖
依赖关系	模型可能虚构不存在的依赖，或遗漏组织层面的依赖	所有外部依赖是否已由人员确认并有负责人
分解	团队被动接受他人的拆分逻辑	拆分是否反映团队的架构、风险和 Definition of Done
测试	伪覆盖：测试很多，但没有覆盖失败模式	是否有可验证的验收标准、可观测性和测试数据
风险管理	清单看起来完整，仿佛已经覆盖全部	哪些风险尚未被事实确认？哪些现在就可以降低？
团队承诺	所有权/责任被稀释：“计划已经组装好了”	开发者是否明确确认 Sprint Backlog 是自己的计划
文档	会议记录中写入的是模型有说服力的表述，而不是达成的约定	所有关键决策、事实和开放问题是否已由参与者确认

这张表的重点不是 AI“把 planning 做得更好”。更准确的想法是：AI 几乎在所有地方都加速了草稿、清单、备选方案和会议记录的组装。但它几乎在任何地方都没有取消最后一道人工检查循环——对事实性、现实性和所有权/责任的检查。

数据治理与卫生：哪些内容不能不加思考地交给模型

在 planning 中，常常会出现把所有东西都塞给 AI 的诱惑：Jira 中的任务、Slack 中的讨论串、客户请求、支持日志、文档片段、团队日历、事件历史、与利益相关者的通信。从 planning 质量的角度看，这可以理解：上下文越多，草稿越好。

但从治理的角度看，这很危险。

如果团队使用 AI 来准备 Sprint Planning，就需要事先约定哪些数据可以传给模型、哪些不可以，谁检查结果，以及如何记录有争议的地方。这里一个简单的治理方法很有效：明确指定负责检查的人，区分事实与假设，记录未知项，保留团队在 AI 建议之上做出的重要人工覆盖，并核查关键陈述的来源。不应不加思考地放入提示词/对模型的请求中的内容：

• 真实客户姓名；
• 用户和员工的电子邮件地址；
• 生产数据；
• 安全事件细节；
• 凭据、令牌、API 密钥；
• 完整审计日志；
• 法律文件和合同条款；
• HR 信息；
• 与 planning 无关的商业敏感细节。

更安全的做法是使用最小化且去标识化的上下文：用去标识化的替代值替换真实标识符，使用删除敏感数据的编辑/匿名化，传递聚合的历史模式而不是原始导出数据，区分事实与假设，并记录在 planning 准备中实际使用了哪些提示词/对模型的请求以及模型的回答。

这不是官僚主义。这是一种方式，避免让 AI 辅助的 planning 变成数据泄露渠道，也避免给模型超过具体决策所需的上下文。

检查清单：AI 组装的 Sprint Plan 可以讨论，如果……

这份检查清单不是官方的 Scrum 工件。它是一个实用的过滤器，帮助团队不要把 AI 草稿误当成真正的计划。

如果满足以下条件，就可以讨论 AI 生成的 Sprint Plan：

• Sprint Goal 被表述为用户/利益相关者获得的价值或状态的改变，而不是任务列表。
• 对于每个选中的待办事项，团队都能解释它如何支持 Sprint Goal。
• 团队可用容量不是抽象计算的，而是考虑了休假、支持、缺陷修复、未完成工作的结转、入职培训和必须参加的会议。
• 上一个冲刺的未完成工作已被明确梳理：哪些结转、哪些取消、哪些需要重新估算。
• 外部依赖被明确列出，每个都有负责人和清晰的状态。
• 对于选定的工作量，团队能看到通往 Definition of Done 的路径，而不只是“代码差不多完成”的状态。
• 计划是可测试的：有验收标准、负面场景、边界场景、可观测性和清晰的验证数据。
• 团队能用一句话说出冲刺的最小有价值工作量。
• 团队事先明白，如果出现新信息，首先可以从工作量中移除什么。
• AI 草稿中的重要事实性陈述已人工核实：状态、依赖、历史数据、架构约束、截止日期规则、本地化、去重。
• 有参与者专门尝试反驳 AI 草稿，而不只是改进它。
• 团队专门检查了计划在哪里过于平滑、过于精确或可疑地“理所当然”。
• 开发者明确确认 Sprint Backlog 是他们的计划，Sprint Goal 是团队对冲刺的承诺。
• 规划结果被记录下来，清楚说明：决定了什么、假设了什么、还有什么未知、什么被排除在工作量之外。

在实践中，这份检查清单可以不作为正式的管控关卡，而是作为规划结束时简短的思维纪律来使用。有两个问题特别有用：“这份 AI 草稿中可能有什么是不对的？”和“如果现实比预期更复杂，我们首先会移除什么？”。

我会给团队的建议

第一，在 Sprint Planning 之前使用 AI，不是为了让它“规划冲刺”，而是让它为良好的人类讨论准备材料。让它收集选项、依赖、假设、风险、边界情况、工作量的替代方案和问题。但决定权必须留在团队手中。

第二，始终把计划草稿与团队承诺分开。AI 草稿可以是很好的底稿，但只有当开发者把它理解为自己的计划时，Sprint Backlog 才成为真正的计划。

第三，不要仅仅因为 AI 生成的估算看起来结构清晰，就认为它们更客观。关于自动化评估/AI 辅助工作量评估的复现研究和综述提供了足够的理由保持谨慎：复杂模型不会仅仅因为复杂就比简单的基线模型更好。在估算中，危险的不仅是错误，还有过度自信。最好用 AI 来识别不确定性，而不是制造精确的假象。

第四，明确记录工作量之外的内容。在良好的 AI 辅助规划会议中，价值往往不仅来自团队选择了什么，还来自团队有意识地没有采纳什么。在 LMS 案例中，这可能是 expired、客户支持团队的完整仪表板、提醒周期性的复杂细分以及高级分析。

第五，指定验证负责人。业务含义由产品负责人验证，需求一致性由分析师验证，架构可实现性由开发者验证，可测试性由 QA 验证，用户体验边界由设计师验证，团队约定质量由 Scrum Master 验证。AI 可以准备通用草稿，但不能拥有验证权。

结论

如果在 Backlog Refinement 中 AI 帮助更快地收集和整理讨论材料，那么在 Sprint Planning 中它帮助更快地收集计划选项。它可以提出 Sprint Goal、对待办事项分组、突出依赖、草拟分解、准备测试场景、列出假设，甚至漂亮地记录会议结果。

但这并不能让计划变得现实可行。

现实的 Sprint Plan 只有在团队诚实地验证了价值、工作量、团队可用容量、依赖、Definition of Done、可测试性以及自己接手这项工作的准备程度之后才会出现。AI 可以加速这一验证，但不能替代它。它可以帮助看到更多选项，但不能替人做出团队承诺。

因此，我会这样表述 AI 在 Sprint Planning 中的主要效果：它降低了准备计划选项的成本，但提高了人工验证的代价。创建漂亮计划变得越容易，理解它是否是真正的团队计划就变得越重要。

在成熟的团队中，AI不会把Sprint Planning变成Sprint Backlog的自动生成。它会把Sprint Planning变成一场关于目标、约束和权衡的更具体的对话。而这也许正是自动化最有用的形式：不是把人从planning中移除，而是把他们的注意力解放出来，用于那些工具无法替他们做出的决策。

来源与参考

• Scrum Guide 2020 ——Sprint Planning、Sprint Goal、Sprint Backlog、职责范围。
• NIST人工智能风险管理框架1.0 ——管理/规制、可问责性/责任、人机交互配置。
• NIST生成式AI概况 ——虚构/自信编造、过度依赖、隐私与风险管理。
• ChatGPT as a tool for User Story Quality Evaluation ——用户故事质量任务中适度证据基础的一个示例。
• Large Language Models for Software Engineering: Survey and Open Problems ——LLM在软件开发/软件工程中的综述。
• 敏捷软件开发中的工作量估算：系统性文献综述 ——敏捷估算的质量因素。
• Reasons and Approaches for Accurate Effort Estimations in Agile Iterative Development ——信息质量、团队、估算实践、项目管理、业务影响。
• GPT2SP replication report ——story points中AI估算的局限，以及与简单基线模型/基准的比较。
• 通过预测工作项文档变更实现可靠的迭代式敏捷规划 ——文档变更与planning脆弱性之间的联系。
• The Planning Fallacy ——关于低估工期的经典著作。
• Automation Bias in Intelligent Time Critical Decision Support Systems ——自动化偏见、遗漏错误与行动错误。
• Generalization bias in large language model summarization ——大语言模型生成的摘要中过度概括的风险。
• OWASP Top 10 for LLM Applications ——敏感信息、过度依赖、提示与安全风险。