GitHub 问题规划与项目自动化提示

目标

扮演一位资深项目经理和 DevOps 专家，精通敏捷方法和 GitHub 项目管理。您的任务是获取完整的功能工件集（产品需求文档、用户体验设计、技术分解、测试计划），并生成一个全面的 GitHub 项目计划，包括自动化问题创建、依赖关系链接、优先级分配和看板式跟踪。

GitHub 项目管理最佳实践

敏捷工作项层次结构

• 史诗：跨越多个功能的重大业务能力（里程碑级别）
• 功能：史诗内可交付的面向用户的功能
• 用户故事：关注用户的需求，能够独立交付价值
• 使能器：支持用户故事的技术基础设施或架构工作
• 测试：用于验证用户故事和使能器的质量保证工作
• 任务：用户故事/使能器的实施级工作分解

项目管理原则

• INVEST 标准：独立的、可协商的、有价值的、可估算的、小的、可测试的
• 就绪定义：工作开始前有明确的验收标准
• 完成定义：质量门禁和完成标准
• 依赖管理：清晰的阻塞关系和关键路径识别
• 基于价值的优先级：用于决策的业务价值 vs. 工作量的矩阵

输入要求

在使用此提示之前，请确保您拥有完整的测试工作流工件：

核心功能文档

1. 功能产品需求文档：/docs/ways-of-work/plan/{史诗名称}/{功能名称}.md
2. 技术分解：/docs/ways-of-work/plan/{史诗名称}/{功能名称}/technical-breakdown.md
3. 实施计划：/docs/ways-of-work/plan/{史诗名称}/{功能名称}/implementation-plan.md

相关规划提示词

• 测试规划：使用 plan-test 提示词来制定全面的测试策略、质量保证规划和测试问题创建
• 架构规划：使用 plan-epic-arch 提示词进行系统架构和技术设计
• 功能规划：使用 plan-feature-prd 提示词来制定详细的功能需求和规范

输出格式

创建两个主要交付物：

1. 项目计划：/docs/ways-of-work/plan/{史诗名称}/{功能名称}/project-plan.md
2. 问题创建清单：/docs/ways-of-work/plan/{史诗名称}/{功能名称}/issues-checklist.md

项目计划结构

1. 项目概述

• 功能摘要：简要描述和业务价值
• 成功标准：可衡量的结果和关键绩效指标
• 关键里程碑：主要交付物的分解（不含时间线）
• 风险评估：潜在的障碍和缓解策略

2. 工作项层次结构

graph TD
    A[史诗: {史诗名称}] --> B[功能: {功能名称}]
    B --> C[用户故事 1: {用户故事}]
    B --> D[用户故事 2: {用户故事}]
    B --> E[使能器 1: {技术工作}]
    B --> F[使能器 2: {基础设施}]

    C --> G[任务：前端实现]
    C --> H[任务：API 集成]
    C --> I[测试：端到端场景]

    D --> J[任务：组件开发]
    D --> K[任务：状态管理]
    D --> L[测试：单元测试]

    E --> M[任务：数据库模式]
    E --> N[任务：迁移脚本]

    F --> O[任务：CI/CD 流水线]
    F --> P[任务：监控设置]

3. GitHub 问题分解

史诗问题模板

# 史诗：{史诗名称}

## 史诗描述

{来自产品需求文档的史诗摘要}

## 业务价值

- **主要目标**：{主要业务目标}
- **成功指标**：{关键绩效指标和可衡量的结果}
- **用户影响**：{用户将如何受益}

## 史诗验收标准

- [ ] {高级需求 1}
- [ ] {高级需求 2}
- [ ] {高级需求 3}

## 此史诗中的功能

- [ ] #{功能问题编号} - {功能名称}

## 完成定义

- [ ] 所有功能用户故事已完成
- [ ] 端到端测试通过
- [ ] 性能基准达标
- [ ] 文档已更新
- [ ] 用户验收测试已完成

## 标签

`epic`、`{优先级级别}`、`{价值层级}`

## 里程碑

{发布版本/日期}

## 估算

{史诗级的 T 恤尺码：XS, S, M, L, XL, XXL}

功能问题模板

# 功能：{功能名称}

## 功能描述

{来自产品需求文档的功能摘要}

## 此功能中的用户故事

- [ ] #{用户故事问题编号} - {用户故事标题}
- [ ] #{用户故事问题编号} - {用户故事标题}

## 技术使能器

- [ ] #{使能器问题编号} - {使能器标题}
- [ ] #{使能器问题编号} - {使能器标题}

## 依赖关系

**阻塞**：{此功能阻塞的问题列表}
**被阻塞**：{阻塞此功能的问题列表}

## 验收标准

- [ ] {功能级需求 1}
- [ ] {功能级需求 2}

## 完成定义

- [ ] 所有用户故事已交付
- [ ] 技术使能器已完成
- [ ] 集成测试通过
- [ ] 用户体验评审已批准
- [ ] 性能测试已完成

## 标签

`feature`、`{优先级级别}`、`{价值层级}`、`{组件名称}`

## 所属史诗

#{史诗问题编号}

## 估算

{故事点数或 T 恤尺码}

用户故事问题模板

# 用户故事：{故事标题}

## 故事陈述

作为 **{用户类型}**，我想要 **{目标}** 以便 **{益处}**。

## 验收标准

- [ ] {具体的可测试需求 1}
- [ ] {具体的可测试需求 2}
- [ ] {具体的可测试需求 3}

## 技术任务

- [ ] #{任务问题编号} - {实施任务}
- [ ] #{任务问题编号} - {集成任务}

## 测试要求

- [ ] #{测试问题编号} - {测试实施}

## 依赖关系

**被阻塞**：{必须首先完成的依赖项}

## 完成定义

- [ ] 满足验收标准
- [ ] 代码审查已批准
- [ ] 已编写并通过单元测试
- [ ] 集成测试通过
- [ ] 用户体验设计已实现
- [ ] 满足可访问性要求

## 标签

`user-story`、`{优先级级别}`、`frontend/backend/fullstack`、`{组件名称}`

## 所属功能

#{功能问题编号}

## 估算

{故事点数：1, 2, 3, 5, 8}

技术使能器问题模板

# 技术使能器：{使能器标题}

## 使能器描述

{支持用户故事所需的技术工作}

## 技术要求

- [ ] {技术要求 1}
- [ ] {技术要求 2}

## 实施任务

- [ ] #{任务问题编号} - {实施细节}
- [ ] #{任务问题编号} - {基础设施设置}

## 启用的用户故事

此使能器支持：

- #{用户故事问题编号} - {故事标题}
- #{用户故事问题编号} - {故事标题}

## 验收标准

- [ ] {技术验证 1}
- [ ] {技术验证 2}
- [ ] 性能基准达标

## 完成定义

- [ ] 实施完成
- [ ] 已编写单元测试
- [ ] 集成测试通过
- [ ] 文档已更新
- [ ] 代码审查已批准

## 标签

`enabler`、`{优先级级别}`、`infrastructure/api/database`、`{组件名称}`

## 所属功能

#{功能问题编号}

## 估算

{故事点数或工作量估算}

4. 优先级和价值矩阵

5. 估算指南

故事点数标度（斐波那契数列）

• 1 点：简单更改，<4 小时
• 2 点：小型功能，<1 天
• 3 点：中型功能，1-2 天
• 5 点：大型功能，3-5 天
• 8 点：复杂功能，1-2 周
• 13+ 点：史诗级工作，需要分解

T 恤尺码（史诗/功能）

• XS：总共 1-2 个故事点
• S：总共 3-8 个故事点
• M：总共 8-20 个故事点
• L：总共 20-40 个故事点
• XL：总共 40+ 个故事点（考虑分解）

6. 依赖管理

graph LR
    A[史诗规划] --> B[功能定义]
    B --> C[使能器实施]
    C --> D[故事开发]
    D --> E[测试执行]
    E --> F[功能交付]

    G[基础设施设置] --> C
    H[API 设计] --> D
    I[数据库模式] --> C
    J[身份验证] --> D

依赖类型

• 阻塞：在此项完成之前无法进行的工作
• 相关：共享上下文但不阻塞的工作
• 先决条件：所需的基础设施或设置工作
• 并行：可以同时进行的工作

7. 冲刺规划模板

冲刺容量规划

• 团队速度：{每个冲刺的平均故事点数}
• 冲刺周期：{推荐 2 周冲刺}
• 缓冲分配：为意外工作和错误修复预留 20%
• 专注因子：总时间的 70-80% 用于计划工作

冲刺目标定义

## 冲刺 {N} 目标

**主要目标**：{此冲刺的主要交付物}

**冲刺中的故事**：

- #{问题} - {故事标题} ({点数} 分)
- #{问题} - {故事标题} ({点数} 分)

**总承诺**：{点数} 个故事点
**成功标准**：{可衡量的结果}

8. GitHub 项目看板配置

列结构（看板）

1. 待办事项：已排序并准备好规划
2. 冲刺就绪：已详细说明和估算，准备好开发
3. 进行中：当前正在处理
4. 审查中：代码审查、测试或利益相关者审查
5. 测试中：质量保证验证和验收测试
6. 已完成：完成并已接受

自定义字段配置

• 优先级：P0、P1、P2、P3
• 价值：高、中、低
• 组件：前端、后端、基础设施、测试
• 估算：故事点数或 T 恤尺码
• 冲刺：当前冲刺分配
• 负责人：负责的团队成员
• 史诗：父级史诗引用

9. 自动化和 GitHub Actions

自动化问题创建

name: 创建功能问题

on:
  workflow_dispatch:
    inputs:
      feature_name:
        description: '功能名称'
        required: true
      epic_issue:
        description: '史诗问题编号'
        required: true

jobs:
  create-issues:
    runs-on: ubuntu-latest
    steps:
      - name: 创建功能问题
        uses: actions/github-script@v7
        with:
          script: |
            const { data: epic } = await github.rest.issues.get({
              owner: context.repo.owner,
              repo: context.repo.repo,
              issue_number: ${{ github.event.inputs.epic_issue }}
            });

            const featureIssue = await github.rest.issues.create({
              owner: context.repo.owner,
              repo: context.repo.repo,
              title: `功能: ${{ github.event.inputs.feature_name }}`,
              body: `# 功能: ${{ github.event.inputs.feature_name }}\n\n...`,
              labels: ['feature', 'priority-medium'],
              milestone: epic.data.milestone?.number
            });

自动化状态更新

name: 更新问题状态

on:
  pull_request:
    types: [opened, closed]

jobs:
  update-status:
    runs-on: ubuntu-latest
    steps:
      - name: 移至“审查中”
        if: github.event.action == 'opened'
        uses: actions/github-script@v7
        # 将相关问题移至“审查中”列

      - name: 移至“已完成”
        if: github.event.action == 'closed' && github.event.pull_request.merged
        uses: actions/github-script@v7
        # 将相关问题移至“已完成”列

问题创建清单

创建前准备

• 功能工件已完成：产品需求文档、用户体验设计、技术分解、测试计划
• 史诗已存在：父级史诗问题已创建，并带有适当的标签和里程碑
• 项目看板已配置：列、自定义字段和自动化规则已设置
• 团队容量已评估：冲刺规划和资源分配已完成

史诗级问题

• 已创建史诗问题，包含全面的描述和验收标准
• 已创建史诗里程碑，包含目标发布日期
• 已应用史诗标签：epic、优先级、价值和团队标签
• 史诗已添加到项目看板的相应列中

功能级问题

• 已创建功能问题，链接到父级史诗
• 已识别并记录功能依赖关系
• 已完成功能估算，使用 T 恤尺码
• 已定义功能验收标准，包含可衡量的结果

故事/使能器级问题记录在 /docs/ways-of-work/plan/{史诗名称}/{功能名称}/issues-checklist.md 中

• 已创建用户故事，遵循 INVEST 标准
• 已识别并确定技术使能器的优先级
• 已分配故事点估算，使用斐波那契数列
• 已映射故事和使能器之间的依赖关系
• 已详细说明验收标准，包含可测试的要求

成功指标

项目管理关键绩效指标

• 冲刺可预测性：每个冲刺完成 >80% 的承诺工作
• 周期时间：从“进行中”到“已完成”的平均时间 <5 个工作日
• 前置时间：从“待办事项”到“已完成”的平均时间 <2 周
• 缺陷逃逸率：<5% 的故事需要发布后修复
• 团队速度：跨冲刺的故事点交付保持一致

流程效率指标

• 问题创建时间：创建完整的功能分解 <1 小时
• 依赖解决时间：解决阻塞依赖 <24 小时
• 状态更新准确性：>95% 的自动化状态转换正确工作
• 文档完整性：100% 的问题具有必需的模板字段
• 跨团队协作：解决外部依赖 <2 个工作日

项目交付指标

• 完成定义合规性：100% 已完成的故事满足完成定义标准
• 验收标准覆盖率：100% 的验收标准已验证
• 冲刺目标达成：>90% 的冲刺目标成功交付
• 利益相关者满意度：完成的功能获得 >90% 的利益相关者批准
• 规划准确性：估算与实际交付时间之间的差异 <10%

这种全面的 GitHub 项目管理方法确保了从史诗级规划到单个实施任务的完整可追溯性，并为所有团队成员提供了自动化跟踪和明确的责任。