tasks-template.md 8.39 KB

Raw Blame History Permalink



description: "功能实现的任务清单模板"


任务清单：[功能名称]

输入：来自 /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 的结构调整


阶段 1：准备（共享基础设施）

目标：项目初始化与基础结构搭建


 T001 按实现计划创建项目结构

 T002 初始化 [language] 工程并安装 [framework] 依赖

 T003 [P] 配置 lint 与格式化工具


阶段 2：基础（阻塞性前置条件）

目标：核心基础设施（任何用户故事开始前必须完成）

⚠️ 关键：在本阶段完成前，不允许开始任何用户故事的工作

基础任务示例（请根据项目实际情况调整）：


 T004 建立数据库结构与迁移机制

 T005 [P] 实现认证/鉴权框架

 T006 [P] 建立 API 路由与中间件结构

 T007 创建所有故事依赖的基础模型/实体

 T008 配置错误处理与日志基础设施

 T009 建立环境配置管理


检查点：基础设施就绪——用户故事实现可以并行推进


阶段 3：用户故事 1 - [标题]（优先级：P1）🎯 MVP

目标：[简述该故事交付内容]

独立验证：[如何单独验证该故事可用]


用户故事 1 的测试（可选：仅在明确要求测试时）⚠️


注意：先写测试，并确保在实现前测试会失败


 T010 [P] [US1] 为 [endpoint] 编写契约测试：tests/contract/test_[name].py

 T011 [P] [US1] 为 [用户旅程] 编写集成测试：tests/integration/test_[name].py


用户故事 1 的实现


 T012 [P] [US1] 创建 [Entity1] 模型：src/models/[entity1].py

 T013 [P] [US1] 创建 [Entity2] 模型：src/models/[entity2].py

 T014 [US1] 实现 [Service]：src/services/[service].py（依赖 T012、T013）

 T015 [US1] 实现 [endpoint/feature]：src/[location]/[file].py

 T016 [US1] 增加校验与错误处理

 T017 [US1] 为用户故事 1 的关键操作补充日志


检查点：此时用户故事 1 应完整可用，且可独立验证


阶段 4：用户故事 2 - [标题]（优先级：P2）

目标：[简述该故事交付内容]

独立验证：[如何单独验证该故事可用]


用户故事 2 的测试（可选：仅在明确要求测试时）⚠️


 T018 [P] [US2] 为 [endpoint] 编写契约测试：tests/contract/test_[name].py

 T019 [P] [US2] 为 [用户旅程] 编写集成测试：tests/integration/test_[name].py


用户故事 2 的实现


 T020 [P] [US2] 创建 [Entity] 模型：src/models/[entity].py

 T021 [US2] 实现 [Service]：src/services/[service].py

 T022 [US2] 实现 [endpoint/feature]：src/[location]/[file].py

 T023 [US2] 与用户故事 1 的组件集成（如需要）


检查点：此时用户故事 1 和 2 应都能独立工作


阶段 5：用户故事 3 - [标题]（优先级：P3）

目标：[简述该故事交付内容]

独立验证：[如何单独验证该故事可用]


用户故事 3 的测试（可选：仅在明确要求测试时）⚠️


 T024 [P] [US3] 为 [endpoint] 编写契约测试：tests/contract/test_[name].py

 T025 [P] [US3] 为 [用户旅程] 编写集成测试：tests/integration/test_[name].py


用户故事 3 的实现


 T026 [P] [US3] 创建 [Entity] 模型：src/models/[entity].py

 T027 [US3] 实现 [Service]：src/services/[service].py

 T028 [US3] 实现 [endpoint/feature]：src/[location]/[file].py


检查点：此时所有用户故事都应可独立运行


[如需要，可按同样格式继续添加更多用户故事阶段]


阶段 N：打磨与横切关注点

目标：影响多个用户故事的改进项


 TXXX [P] 更新 docs/ 内的文档

 TXXX 代码清理与重构

 TXXX 跨故事的性能优化

 TXXX [P] 在 tests/unit/ 增加单测（如需）

 TXXX 安全加固

 TXXX 验证 quickstart.md


依赖与执行顺序


阶段依赖


准备（阶段 1）：无依赖，可立即开始

基础（阶段 2）：依赖准备阶段完成——阻塞所有用户故事

用户故事（阶段 3+）：均依赖基础阶段完成


之后可并行推进（若有人力）
或按优先级串行推进（P1 → P2 → P3）


打磨（最终阶段）：依赖所有目标用户故事完成


用户故事依赖


用户故事 1（P1）：基础阶段后可开始——不依赖其他故事

用户故事 2（P2）：基础阶段后可开始——可能与 US1 集成，但应保持可独立验证

用户故事 3（P3）：基础阶段后可开始——可能与 US1/US2 集成，但应保持可独立验证


每个用户故事内部顺序


测试（如包含）必须先写，且在实现前应失败
先模型，再服务
先服务，再接口/端点
先核心实现，再集成
完成当前故事后再进入下一个优先级


并行机会


阶段 1 中标记 [P] 的任务可并行
阶段 2 中标记 [P] 的任务可并行（在阶段 2 内）
基础阶段完成后，所有用户故事可并行开始（若团队容量允许）
用户故事内标记 [P] 的测试可并行
用户故事内标记 [P] 的模型可并行
不同用户故事可由不同成员并行推进


并行示例：用户故事 1

# 一次性启动用户故事 1 的所有测试（如需要测试）：
任务: "为 [endpoint] 编写契约测试：tests/contract/test_[name].py"
任务: "为 [用户旅程] 编写集成测试：tests/integration/test_[name].py"

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


实施策略


MVP 优先（仅用户故事 1）


完成阶段 1：准备
完成阶段 2：基础（关键：阻塞所有故事）
完成阶段 3：用户故事 1

停止并验证：独立验证用户故事 1
如已就绪则部署/演示


增量交付


完成准备 + 基础 → 基础设施就绪
增加用户故事 1 → 独立验证 → 部署/演示（MVP）
增加用户故事 2 → 独立验证 → 部署/演示
增加用户故事 3 → 独立验证 → 部署/演示
每个故事都应在不破坏既有能力的前提下增量交付价值


多人并行策略

多人协作时：


团队协作完成准备 + 基础
基础完成后：


开发 A：用户故事 1
开发 B：用户故事 2
开发 C：用户故事 3


各故事独立完成并独立集成


备注


[P] 任务：不同文件、无依赖，可并行
[Story] 标签：将任务映射到具体用户故事，便于追溯
每个用户故事都应可独立完成与独立验证
实现前先确认测试会失败（如有测试）
每完成一个任务或合理的任务组再提交
在任意检查点都可以停下来做独立验证
避免：任务描述模糊、同文件冲突、跨故事强耦合导致无法独立交付