BMAD-METHOD/bmad-core/checklists/story-draft-checklist.md

5.3 KiB
Raw Blame History

故事草稿清单

Scrum Master 应使用此清单来验证每个故事是否包含足够的上下文,以便开发代理成功实施,同时假设开发代理具有合理的能力来解决问题。

[[LLM: 初始化说明 - 故事草稿验证

在开始使用此清单之前,请确保您能访问以下内容:

  1. 正在验证的故事文档(通常在 docs/stories/ 中或直接提供)
  2. 父级史诗的上下文
  3. 任何引用的架构或设计文档
  4. 如果此工作建立在先前工作的基础上,则需提供以前的相关故事

重要提示:此清单在实施开始前验证单个故事。

验证原则:

  1. 清晰性 - 开发人员应了解要构建什么
  2. 上下文 - 为什么要构建它以及它如何融入整体
  3. 指导 - 要遵循的关键技术决策和模式
  4. 可测试性 - 如何验证实施是否有效
  5. 自包含性 - 所需的大部分信息都在故事本身中

请记住:我们假设有能力的开发代理可以:

  • 研究文档和代码库
  • 做出合理的技术决策
  • 遵循既定模式
  • 在真正遇到困难时请求澄清

我们正在检查的是足够的指导,而不是详尽的细节。]]

1. 目标与上下文清晰度

[[LLM: 没有明确的目标,开发人员会构建错误的东西。验证:

  1. 故事说明了要实施什么功能
  2. 业务价值或用户利益是明确的
  3. 解释了这如何融入更大的史诗/产品
  4. 依赖关系是明确的(“需要故事 X 完成”)
  5. 成功看起来是具体的,而不是模糊的]]
  • 故事目标/目的陈述清晰
  • 与史诗目标的关系显而易见
  • 解释了故事如何融入整个系统流程
  • 确定了对先前故事的依赖关系(如果适用)
  • 业务背景和价值清晰

2. 技术实施指导

[[LLM: 开发人员需要足够的技术背景才能开始编码。检查:

  1. 提到了要创建或修改的关键文件/组件
  2. 在不明显的地方指定了技术选择
  3. 确定了与现有代码的集成点
  4. 定义或引用了数据模型或 API 合约
  5. 指出了非标准模式或例外情况

注意:我们不需要列出每个文件 - 只需要重要的文件。]]

  • 确定了要创建/修改的关键文件(不一定详尽无遗)
  • 提到了此故事特别需要的技术
  • 充分描述了关键的 API 或接口
  • 引用了必要的数据模型或结构
  • 列出了所需的环境变量(如果适用)
  • 注意到了标准编码模式的任何例外情况

3. 参考有效性

[[LLM: 参考应该有帮助,而不是制造寻宝游戏。确保:

  1. 参考指向特定部分,而不是整个文档
  2. 解释了每个参考的相关性
  3. 故事中总结了关键信息
  4. 参考是可访问的(不是损坏的链接)
  5. 如果需要,总结了先前故事的上下文]]
  • 对外部文档的引用指向特定的相关部分
  • 总结了先前故事中的关键信息(而不仅仅是引用)
  • 提供了为什么参考相关的上下文
  • 参考使用一致的格式(例如,docs/filename.md#section

4. 自包含性评估

[[LLM: 故事应尽可能自包含,以避免上下文切换。验证:

  1. 核心需求在故事中,而不仅仅是在参考中
  2. 领域术语已解释或从上下文中显而易见
  3. 明确陈述了假设
  4. 提到了边缘情况(即使已推迟)
  5. 无需阅读 10 个其他文档即可理解该故事]]
  • 包含了所需的核心信息(不过度依赖外部文档)
  • 明确了隐含的假设
  • 解释了特定领域的术语或概念
  • 解决了边缘情况或错误场景

5. 测试指导

[[LLM: 测试确保实施真正有效。检查:

  1. 指定了测试方法(单元、集成、端到端)
  2. 列出了关键测试场景
  3. 成功标准是可衡量的
  4. 注意到了特殊的测试注意事项
  5. 故事中的验收标准是可测试的]]
  • 概述了所需的测试方法
  • 确定了关键测试场景
  • 定义了成功标准
  • 注意到了特殊的测试注意事项(如果适用)

验证结果

[[LLM: 最终故事验证报告

生成一份简洁的验证报告:

  1. 快速摘要

    • 故事准备情况:准备就绪 / 需要修订 / 受阻
    • 清晰度得分 (1-10)
    • 识别出的主要差距
  2. 填写验证表:

    • 通过:需求明确满足
    • 部分:有些差距但可行
    • 失败:缺少关键信息
  3. 具体问题(如有)

    • 列出要修复的具体问题
    • 提出具体的改进建议
    • 确定任何阻塞性依赖关系
  4. 开发人员视角

    • 您能按书面形式实施这个故事吗?
    • 您会有什么问题?
    • 什么可能导致延误或返工?

要务实——完美的文档不存在,但必须足以提供开发代理完成工作所需的极端上下文,并且不会造成混乱。]]

类别 状态 问题
1. 目标与上下文清晰度 待定
2. 技术实施指导 待定
3. 参考有效性 待定
4. 自包含性评估 待定
5. 测试指导 待定

最终评估:

  • 准备就绪:故事为实施提供了足够的上下文
  • 需要修订:故事需要更新(见问题)
  • 受阻:需要外部信息(指明需要什么信息)