morning-start 项目全流程管理
任务目标
- 本 Skill 用于: 软件项目全生命周期管理，从需求澄清到正式发布
- 能力包含: 六大阶段标准化流程、状态管理、决策检查点
- 触发条件: 新项目启动、项目中途介入、阶段性问题诊断
核心流程
需求拆解 → 任务排期 → 技术设计 → 编码测试 → 测试验收 → 发布部署
子技能索引
| 阶段 | 子技能 | 核心职责 | 参考文档 |
|---|---|---|---|
| 规划 | planning/1-roadmap-planner | ROADMAP/OKR/里程碑 | 详情 |
| 规划 | planning/2-todo-planner | TODO/优先级/MoSCoW | 详情 |
| 需求 | requirement-decomposition | 澄清→拆解→验证 | 详情 |
| 计划 | task-scheduling | 工时评估、任务认领 | 详情 |
| 设计 | tech-design | 数据库、API、UI | 详情 |
| 开发 | coding-unit-test | 开发规范、单元测试 | 详情 |
| 测试 | testing-acceptance | 提测、Bug、UAT | 详情 |
| 发布 | release-deployment | 灰度、回滚、监控 | 详情 |
操作步骤
阶段推进流程
标准流程:
- 进入阶段: 根据项目当前状态进入对应阶段
- 调用子技能: 调用该阶段的子技能执行具体任务
- 阶段评审: 执行关键决策点检查
- 状态更新: 确认通过后进入下一阶段
阶段1：需求阶段
- 触发条件: 用户提出模糊需求（如"做一个商城系统"）
- 使用技能: requirement-decomposition
- 操作: 澄清需求 → 拆解需求 → 验证需求
- 输出: 用户故事列表、验收标准、任务清单
- 决策点: 需求评审 - 需求是否清晰无歧义？
- 下一步: 通过 → 阶段2；未通过 → 继续澄清
阶段2：计划阶段
- 触发条件: 需求已确认，准备进入开发
- 使用技能: task-scheduling
- 操作: 工时评估 → 任务认领 → Sprint规划
- 输出: 工时评估表、Sprint计划
- 决策点: 计划评审 - 任务分配是否合理？
- 下一步: 通过 → 阶段3；未通过 → 重新调整
阶段3：设计阶段
- 触发条件: Sprint计划已确定，开发前准备
- 使用技能: tech-design
- 操作: UI设计 → 技术架构 → 接口约定
- 输出: ER图、API文档、技术选型表
- 决策点: 技术评审 - 技术方案是否可行？
- 下一步: 通过 → 阶段4；未通过 → 重新设计
阶段4：开发阶段
- 触发条件: 设计文档已确认
- 使用技能: coding-unit-test
- 操作: 并行开发 → 单元测试 → Code Review
- 输出: 源代码、测试报告
- 日常流程: 每日站会同步进度
- 决策点: 代码评审 - 代码是否符合规范？
- 下一步: 通过 → 阶段5；未通过 → 修复
阶段5：测试阶段
- 触发条件: 开发完成，准备提测
- 使用技能: testing-acceptance
- 操作: 提测 → 系统测试 → Bug修复 → UAT
- 输出: 测试用例、Bug记录、UAT报告
- 决策点: 测试评审 - 测试是否全部通过？
- 下一步: 通过 → 阶段6；未通过 → 继续修复
阶段6：发布阶段
- 触发条件: 测试全部通过
- 使用技能: release-deployment
- 操作: 发布准备 → 灰度发布 → 正式发布 → 监控
- 输出: 发布checklist、回滚方案、监控报告
- 决策点: 发布评审 - 是否满足发布条件？
- 下一步: 通过 → 项目完成
状态管理
项目状态矩阵
项目状态:
☐ 需求阶段 - requirement-decomposition 已完成
☐ 计划阶段 - task-scheduling 已完成
☐ 设计阶段 - tech-design 已完成
☐ 开发阶段 - coding-unit-test 已完成
☐ 测试阶段 - testing-acceptance 已完成
☐ 发布完成 - release-deployment 已完成
当前阶段: [根据实际进度标记]
状态转换规则
| 当前状态 | 可转向 | 条件 |
|---|---|---|
| 需求阶段 | 计划阶段 | 需求评审通过 |
| 计划阶段 | 设计阶段 | 计划评审通过 |
| 设计阶段 | 开发阶段 | 技术评审通过 |
| 开发阶段 | 测试阶段 | 代码评审通过 |
| 测试阶段 | 发布阶段 | 测试评审通过 |
| 任意阶段 | 需求阶段 | 重大需求变更 |
决策检查点
| 决策点 | 评审问题 | 通过标准 | 负责人 |
|---|---|---|---|
| 需求评审 | 需求是否清晰无歧义？ | 验收标准已定义 | 产品经理 |
| 计划评审 | 任务分配是否合理？ | 工时评估完成 | 技术负责人 |
| 技术评审 | 技术方案是否可行？ | 架构设计通过 | 技术负责人 |
| 代码评审 | 代码是否符合规范？ | Review通过 | 技术负责人 |
| 测试评审 | 测试是否全部通过？ | P0/P1 Bug已清零 | QA负责人 |
| 发布评审 | 是否满足发布条件？ | Checklist全部通过 | 项目经理 |
资源索引
- 子技能文档: 见上方子技能索引表
- 需求拆解参考: requirement-decomposition
- 任务排期参考: task-scheduling
- 技术设计参考: tech-design
- 编码测试参考: coding-unit-test
- 测试验收参考: testing-acceptance
- 发布部署参考: release-deployment
注意事项
- 阶段推进必须经过决策检查点，不可跳过
- 重大需求变更时允许回退到上一阶段
- 每个阶段产出物必须归档后再进入下一阶段
- 阻塞问题应在每日站会中及时暴露
使用示例
示例1：新项目启动
用户: 帮我做一个奶茶店点单系统
1. 进入【需求阶段】
→ 调用 requirement-decomposition
→ 输出: 用户故事、验收标准、任务清单
2. 进入【计划阶段】
→ 调用 task-scheduling
→ 输出: Sprint计划、任务分配
3. 后续阶段按需调用对应子技能...
示例2：项目中途介入
用户: 项目卡在测试阶段，不知道怎么推进
1. 诊断当前状态
→ 项目状态: 测试阶段
2. 调用对应子技能
→ 调用 testing-acceptance
→ 继续测试流程
3. 推进到下一阶段...
示例3：问题诊断
用户: 开发效率低，总是返工
1. 诊断问题阶段
→ 可能是设计阶段或开发阶段问题
2. 检查对应阶段产出物
→ tech-design: 接口文档是否清晰？
→ coding-unit-test: Code Review是否执行？
3. 针对问题调用子技能优化