mcpField
A
agile-review

agile-review

github.com/djalmajr生产力4122 次安装5 周前更新
代码仓库

关于 agile-review

一项整理冲刺交付记录与指标的评审技能，可生成客观的利益相关者评审和演示材料。它引导团队对比计划与实际交付、记录偏差，并收集反馈供下个周期使用。

主要功能

  1. 01汇总冲刺交付内容
  2. 02对比计划与实际交付
  3. 03按业务价值组织演示
  4. 04记录交付、质量和流程指标
  5. 05收集利益相关者反馈

适用场景

  1. 01准备冲刺结束时的利益相关者演示
  2. 02说明未交付事项及后续去向
  3. 03如实回顾冲刺指标
  4. 04将利益相关者反馈转为待办事项

安装

复制下面的命令，在终端中运行。

$npx skills add https://github.com/djalmajr/skills --skill agile-review

安装后在 Claude Code 中输入/agile-review确认已加载。

附带文件templates/review.md

详细介绍

Sprint 评审

使用此技能，将冲刺交付内容整合为清晰、客观的评审／演示材料，供相关方查看。

语言

使用用户的语言撰写产出。确保语法正确，并使用所需的变音符号或特定文字。若无法确定用户使用的语言，请先询问。模板为英文 — 请翻译标题和内容，使其与用户的语言一致。

项目根目录

此技能会将产出写入相对于项目根目录（开展工作的代码库）的路径，而不是相对于 Agent 当前的工作目录。

  • 如果在项目内调用，请使用此技能中所示的相对路径。
  • 如果从其他目录调用（例如，相邻的代码库，或项目位于其他位置），请在每个产出路径前添加 <project-root>/。
  • 如果项目根目录不明确，请在写入前通过交互工具向用户确认。

提示

遵循项目范围内的约定，参见 CLAUDE.md／AGENTS.md（“Skill Prompting Conventions”）。对于以下决策点，请使用交互工具的结构化提问功能 — AskUserQuestion（Claude Code）、ask_user_question（Codex）或 question（OpenCode）。

决策点使用结构化提问的原因建议选项
受众决定演示内容仅团队成员 · 相关方 · 混合
演示范围决定产出的内容仅已完成事项 · 包含进行中事项

自由形式提示（无需结构化工具）：

  • 相关方姓名
  • 演示旁白文本

无暂停模式：如果用户明确禁用了技能执行过程中的澄清步骤，请将每个结构化提示转换为“待确认事项”（或类似部分）中的一项，并继续执行，不要暂停。

目标

  • 整合本冲刺交付的内容
  • 将交付情况与冲刺规划承诺进行比较
  • 突出范围变更、偏差和已做出的决策
  • 准备客观展示已交付的价值
  • 收集相关方反馈，为下一个周期提供参考
  • 以量化的冲刺指标（交付、质量、流转、流程）为演示和后续回顾提供依据

适用场景

  • 冲刺结束时、回顾之前
  • 相关方需要了解交付成果时
  • 需要验证产品是否走在正确道路上时
  • 为冲刺规划与回顾之间的周期收尾时
  • 团队需要了解冲刺数据（速率、阻碍、完成率）时 — 在此处收集

流程

1. 整合交付内容

收集以下信息：

  • 冲刺中已完成的问题
  • 生成的状态关闭报告
  • 该期间的状态检查点和整合报告
  • 已登记的范围变更

对每项已交付内容，记录：

  • 预期内容（来自冲刺规划）
  • 实际交付内容
  • 相关偏差（如有）
2. 准备演示

按照业务价值而非技术顺序组织演示：

  • 从影响开始：“现在团队可以做到 X”
  • 展示实际运行的流程，而不是幻灯片
  • 如果有相关技术内容（性能、安全性），将其作为背景信息纳入
3. 确认未交付事项

对于每项未交付的计划事项：

  • 原因：受阻、优先级变更、范围超出预期
  • 去向：返回待办列表、纳入下一个冲刺、已弃用
4. 收集迭代指标

根据迭代产物（规划、状态检查点、收尾记录、问题、git）填写评审的指标部分。不要编造或取整数字。

  • 交付： 计划交付与实际交付、迭代中途新增、延期
  • 质量： 迭代期间／交付后的缺陷、收尾时的 lint／类型检查／测试情况
  • 流转： 阻塞项（数量和平均持续时间）、每个故事的平均耗时、重新打开的数量
  • 流程： 已举行与预期的状态检查点、收尾与交付的数量
  • 趋势： 有数据时，与上一迭代对比
  • 回顾重点： 一个积极点、一个需关注点、一项行动建议

精简评审（单人周）可以简短填写本部分，但仍须包含计划交付、实际交付和阻塞项。

5. 收集反馈

记录利益相关方的问题和反馈：

  • 必要的调整
  • 发现的新需求
  • 优先级变更
6. 生成产物

使用下方模板记录评审。保存到 planning/sprints/sprint-review-YYYY-MM-DD.md（或在精简的单人周期中直接内联呈现）。

模板

使用此技能中的 templates/review.md 作为产物的基础。

规则

  • 评审应展示已交付的内容，而非正在进行的内容。有关进行中工作的状态，请使用 /agile-status。
  • 诚实说明哪些内容未交付及其原因。隐瞒被砍掉的事项会破坏信任。
  • 演示结果必须可验证——利益相关方必须能够确认结果确实存在。
  • 收集到的反馈必须转化为待办事项或行动，不能只留在会议记录中。
  • 迭代评审为回顾提供输入。如果没有进行评审，回顾就会失去重要信息。
  • 此产物中的指标是用于反思的工具，而非评判工具。绝不要操纵数字来美化结果。

与流程的关系

flowchart LR
    A["/agile-sprint"] --> B[execution]
    B --> C["/agile-status"]
    C --> D["/agile-review"]
    D --> E["/agile-retro"]

在串联流程中，迭代评审将执行与反馈连接起来：规划 -> 执行 -> 状态 -> 评审（演示 + 指标）-> 回顾。

如需在迭代期间跟踪状态，请使用 /agile-status。迭代的量化数据记录在此评审产物中。

评论

支持 Markdown