ContextQMD
Back to Imewlconverter

任务: [FEATURE NAME]

.specify/templates/tasks-template.md

3.3.110.0 KB
Original Source

任务: [FEATURE NAME]

输入: 来自 /specs/[###-feature-name]/ 的设计文档 前置条件: plan.md(必需)、spec.md(用户故事必需)、research.md、data-model.md、contracts/

测试: 以下示例包含测试任务. 测试是可选的 - 仅在功能规范中明确要求时才包含.

组织结构: 任务按用户故事分组, 以便每个故事能够独立实施和测试.

格式: [ID] [P?] [Story] 描述

  • [P]: 可以并行运行(不同文件, 无依赖关系)
  • [Story]: 此任务属于哪个用户故事(例如: US1、US2、US3)
  • 在描述中包含确切的文件路径

路径约定

  • 单一项目: 仓库根目录下的 src/、tests/
  • Web 应用: backend/src/、frontend/src/
  • 移动应用: api/src/、ios/src/ 或 android/src/
  • 以下显示的路径假设为单一项目 - 根据 plan.md 结构进行调整
<!-- ============================================================================ 重要说明: 以下任务仅为说明目的的示例任务. /speckit.tasks 命令必须根据以下内容替换为实际任务: - 来自 spec.md 的用户故事(及其优先级 P1、P2、P3...) - 来自 plan.md 的功能需求 - 来自 data-model.md 的实体 - 来自 contracts/ 的端点 任务必须按用户故事组织, 以便每个故事能够: - 独立实施 - 独立测试 - 作为 MVP 增量交付 不要在生成的 tasks.md 文件中保留这些示例任务. ============================================================================ -->

阶段 1: 设置(共享基础设施)

目的: 项目初始化和基本结构

  • T001 根据实施计划创建项目结构
  • T002 使用 [framework] 依赖项初始化 [language] 项目
  • T003 [P] 配置代码检查和格式化工具

阶段 2: 基础(阻塞前置条件)

目的: 在任何用户故事可以实施之前必须完成的核心基础设施

⚠️ 关键: 在此阶段完成之前, 无法开始任何用户故事工作

基础任务示例(根据你的项目调整):

  • T004 设置数据库架构和迁移框架
  • T005 [P] 实施身份验证/授权框架
  • T006 [P] 设置 API 路由和中间件结构
  • T007 创建所有故事依赖的基础模型/实体
  • T008 配置错误处理和日志记录基础设施
  • T009 设置环境配置管理

检查点: 基础就绪 - 现在可以开始并行实施用户故事

阶段 3: 用户故事 1 - [Title](优先级: P1)🎯 MVP

目标: [此故事交付内容的简要描述]

独立测试: [如何验证此故事独立运行]

用户故事 1 的测试（必需 - 符合章程测试优先原则）⚠️

关键：先编写这些测试，确保在实施前它们失败（红灯）

测试类型：

  • 集成测试：验证完整用户场景（章程要求）
  • 单元测试：验证各组件功能（60%覆盖率要求）
  • 合约测试：验证接口契约

测试任务：

  • T010 [P] [US1] 在 tests/Integration/[Feature]IntegrationTest.cs 中编写集成测试
  • T011 [P] [US1] 在 tests/Unit/[Component]Test.cs 中编写单元测试框架
  • T012 [P] [US1] 在 tests/Contract/[Interface]ContractTest.cs 中编写合约测试

验证测试失败：运行测试，确认全部失败（红灯），然后继续实施

用户故事 1 的实施

注意：实施时确保：

  • 遵循Microsoft C#编码规范（章程原则III）

  • 添加中文XML文档注释（章程原则II）

  • 考虑跨平台兼容性（章程原则IV）

  • T013 [P] [US1] 在 src/Models/[Entity1].cs 中创建 [Entity1] 模型（附中文注释）

  • T014 [P] [US1] 在 src/Models/[Entity2].cs 中创建 [Entity2] 模型（附中文注释）

  • T015 [US1] 在 src/Services/[Service].cs 中实施 [Service]（依赖于 T013、T014）

  • T016 [US1] 在 src/[Location]/[File].cs 中实施 [endpoint/feature]

  • T017 [US1] 添加输入验证和错误处理

  • T018 [US1] 为用户故事 1 操作添加日志记录

  • T019 [US1] 补充单元测试以达到60%覆盖率

  • T020 [US1] 运行所有测试，确认通过（绿灯）

检查点: 此时, 用户故事 1 应该完全功能化且可独立测试，测试覆盖率达标

阶段 4: 用户故事 2 - [Title](优先级: P2)

目标: [此故事交付内容的简要描述]

独立测试: [如何验证此故事独立运行]

用户故事 2 的测试（必需 - 符合章程测试优先原则）⚠️

  • T021 [P] [US2] 在 tests/Integration/[Feature]IntegrationTest.cs 中编写集成测试
  • T022 [P] [US2] 在 tests/Unit/[Component]Test.cs 中编写单元测试

用户故事 2 的实施

  • T023 [P] [US2] 在 src/Models/[Entity].cs 中创建 [Entity] 模型（附中文注释）
  • T024 [US2] 在 src/Services/[Service].cs 中实施 [Service]
  • T025 [US2] 在 src/[Location]/[File].cs 中实施 [endpoint/feature]
  • T026 [US2] 与用户故事 1 组件集成(如需要)
  • T027 [US2] 补充单元测试以达到60%覆盖率
  • T028 [US2] 运行测试确认通过

检查点: 此时, 用户故事 1 和 2 都应该独立运行，测试覆盖率达标

阶段 5: 用户故事 3 - [Title](优先级: P3)

目标: [此故事交付内容的简要描述]

独立测试: [如何验证此故事独立运行]

用户故事 3 的测试（必需 - 符合章程测试优先原则）⚠️

  • T029 [P] [US3] 在 tests/Integration/[Feature]IntegrationTest.cs 中编写集成测试
  • T030 [P] [US3] 在 tests/Unit/[Component]Test.cs 中编写单元测试

用户故事 3 的实施

  • T031 [P] [US3] 在 src/Models/[Entity].cs 中创建 [Entity] 模型（附中文注释）
  • T032 [US3] 在 src/Services/[Service].cs 中实施 [Service]
  • T033 [US3] 在 src/[Location]/[File].cs 中实施 [endpoint/feature]
  • T034 [US3] 补充单元测试以达到60%覆盖率
  • T035 [US3] 运行测试确认通过

检查点: 所有用户故事现在应该独立功能化，整体测试覆盖率≥60%

[根据需要添加更多用户故事阶段, 遵循相同模式]

阶段 N: 完善与横切关注点

目的: 影响多个用户故事的改进，确保符合所有章程要求

文档完善（章程原则II）

  • TXXX [P] 更新 README.md 中文文档
  • TXXX [P] 更新或创建 Wiki 页面
  • TXXX [P] 确认所有公共API有中文XML注释

质量保证（章程原则I）

  • TXXX 运行完整测试套件，确认所有测试通过
  • TXXX 生成测试覆盖率报告，确认 ≥60%
  • TXXX 修复测试覆盖率不足的模块

代码质量（章程原则III）

  • TXXX 代码清理和重构（符合C#编码规范）
  • TXXX 运行静态代码分析（如ReSharper、SonarQube）
  • TXXX 修复代码分析警告

跨平台验证（章程原则IV）

  • TXXX 在Windows上测试
  • TXXX 在Linux上测试
  • TXXX 在macOS上测试
  • TXXX 验证文件路径和编码处理

性能与安全

  • TXXX 跨所有故事的性能优化
  • TXXX 安全加固和输入验证
  • TXXX 运行 quickstart.md 验证

依赖关系与执行顺序

阶段依赖关系

  • 设置(阶段 1): 无依赖关系 - 可立即开始
  • 基础(阶段 2): 依赖于设置完成 - 阻塞所有用户故事
  • 用户故事(阶段 3+): 都依赖于基础阶段完成
    • 然后用户故事可以并行进行(如果有人员)
    • 或按优先级顺序进行(P1 → P2 → P3)
  • 完善(最终阶段): 依赖于所有期望的用户故事完成

用户故事依赖关系

  • 用户故事 1(P1): 可在基础(阶段 2)后开始 - 无其他故事依赖
  • 用户故事 2(P2): 可在基础(阶段 2)后开始 - 可与 US1 集成但应独立可测试
  • 用户故事 3(P3): 可在基础(阶段 2)后开始 - 可与 US1/US2 集成但应独立可测试

每个用户故事内部

  • 测试(如包含)必须在实施前编写并失败
  • 模型在服务之前
  • 服务在端点之前
  • 核心实施在集成之前
  • 故事完成后才移至下一个优先级

并行机会

  • 所有标记为 [P] 的设置任务可以并行运行
  • 所有标记为 [P] 的基础任务可以并行运行(在阶段 2 内)
  • 基础阶段完成后, 所有用户故事可以并行开始(如果团队容量允许)
  • 用户故事中所有标记为 [P] 的测试可以并行运行
  • 故事中标记为 [P] 的模型可以并行运行
  • 不同用户故事可以由不同团队成员并行处理

并行示例: 用户故事 1

bash
# 一起启动用户故事 1 的所有测试(如要求测试): 
任务: "在 tests/contract/test_[name].py 中为 [endpoint] 编写合约测试"
任务: "在 tests/integration/test_[name].py 中为 [user journey] 编写集成测试"

# 一起启动用户故事 1 的所有模型: 
任务: "在 src/models/[entity1].py 中创建 [Entity1] 模型"
任务: "在 src/models/[entity2].py 中创建 [Entity2] 模型"

实施策略

仅 MVP(仅用户故事 1)

  1. 完成阶段 1: 设置
  2. 完成阶段 2: 基础(关键 - 阻塞所有故事)
  3. 完成阶段 3: 用户故事 1
  4. 停止并验证: 独立测试用户故事 1
  5. 如准备好则部署/演示

增量交付

  1. 完成设置 + 基础 → 基础就绪
  2. 添加用户故事 1 → 独立测试 → 部署/演示(MVP! )
  3. 添加用户故事 2 → 独立测试 → 部署/演示
  4. 添加用户故事 3 → 独立测试 → 部署/演示
  5. 每个故事在不破坏先前故事的情况下增加价值

并行团队策略

有多个开发人员时:

  1. 团队一起完成设置 + 基础
  2. 基础完成后:
    • 开发人员 A: 用户故事 1
    • 开发人员 B: 用户故事 2
    • 开发人员 C: 用户故事 3
  3. 故事独立完成和集成

注意事项

  • [P] 任务 = 不同文件, 无依赖关系
  • [Story] 标签将任务映射到特定用户故事以实现可追溯性
  • 每个用户故事应该独立可完成和可测试
  • 在实施前验证测试失败
  • 在每个任务或逻辑组后提交
  • 在任何检查点停止以独立验证故事
  • 避免: 模糊任务、相同文件冲突、破坏独立性的跨故事依赖