敏捷开发流程 - 精简版（实战版）
版本： v1.0 更新日期： 2025-10-11 适用场景： 中小型团队快速迭代开发
🎯 流程全景图
📋 5大阶段详解
阶段1：需求收集 → 业务需求文档
负责人： 项目经理
输入： 用户原始需求（口头/邮件/会议记录）
核心工作：
- 收集用户需求
- 整理为层级结构（一级-二级-三级）
- 组织需求评审会①（内部简单评审）
产出物：
- ✅ 业务需求文档（层级结构）
评审点：需求评审会①
- 参与人：项目经理、产品经理
- 目的：快速确认需求方向和范围
- 输出：确定需要进入阶段2的需求清单
示例结构：
生产计划系统（一级）
├── 月计划填报（二级）
│ ├── 生产指标预测（三级）⭐ 可拆解
│ └── 计划数据审核（三级）⭐ 可拆解
└── 季度计划统计（二级）
阶段2：业务需求 → 用户故事 → 原型设计 → PRD文档
负责人： 产品经理
输入： 业务需求文档
核心工作（按顺序）：
- 拆解为用户故事（将业务需求拆解为多个用户故事）
- 绘制低保真原型（基于用户故事快速规划页面布局）
- 补充为高保真原型/交互原型（完善原型设计）
- 编写PRD文档（详细说明每个用户故事的规则和字段）
- 组织需求评审会②（开发人员参与，多轮确认）
产出物（按顺序）：
- ✅ 用户故事列表（第一步：需求拆解）
- ✅ 低保真原型（第二步：快速规划页面，可不精美）
- ✅ 高保真原型/交互原型（第三步：最终原型设计）
- ✅ PRD文档（第四步：详细功能说明+功能点统计）
评审点：需求评审会②（多轮评审）
第一轮：原型评审
- 参与人：项目经理、产品经理、技术负责人、开发人员
- 评审内容：原型设计、交互流程
- 目的：确保功能可落地，明确技术可行性
- 输出：确定的原型设计
第二轮：PRD评审
- 参与人：项目经理、产品经理、技术负责人、开发人员
- 评审内容：PRD文档、功能点、业务规则
- 目的：确保需求清晰无歧义
- 输出：确定的PRD文档 + 功能点统计
完整工作流程：
业务需求
↓ 拆解
用户故事（US-001, US-002...）
↓ 基于用户故事设计
低保真原型（快速plan，规划页面布局）
↓ 补充完善
高保真原型/交互原型（最终原型设计）
↓ 详细说明
PRD文档（说明每个用户故事的详细规则）
注意：
- 现在有成熟的组件库和框架，原型不必过于精美
- 重点是清晰表达功能和交互逻辑
- 用户故事是基础，原型和PRD都是基于用户故事产出的
用户故事示例：
业务需求：生产指标预测（三级）
↓ 拆解为用户故事
US-001: 作为【生产经理】，我想要【查看月度指标列表】，以便【了解生产计划】
US-002: 作为【生产经理】，我想要【新增生产指标】，以便【制定计划】
US-003: 作为【生产经理】，我想要【编辑指标】，以便【调整计划】
US-004: 作为【生产经理】，我想要【删除指标】，以便【清理错误数据】
...
PRD中的功能点统计示例：
功能模块：生产指标预测
功能点统计：10个功能点
1. 查看指标列表
2. 新增指标
3. 编辑指标
4. 删除指标
5. 批量导入
6. 导出Excel
7. 数据校验
8. 审批流程
9. 二级Tab：历史记录
10. 历史记录查询
→ 对应后续10个测试用例
阶段3：PRD + 原型 → 技术设计 + 开发任务 + UI设计
负责人： 技术负责人
输入： PRD文档、原型设计、用户故事
核心工作：
- 编写技术设计文档（架构、模块划分、技术选型）
- 设计数据库表结构
- 拆解开发任务（前端任务+后端任务）
- （并行）UI设计师绘制UI设计稿
产出物：
- ✅ 技术设计文档
- ✅ 数据库设计（表结构/ER图）
- ✅ 开发任务列表（前端+后端）
- ✅ UI设计稿（可与开发并行，不阻塞开发）
注意：
- ❌ 不在此阶段编写接口文档（后端开发完成后，联调时再补充）
- ✅ UI设计稿可以和开发并行，不阻塞开发启动
任务拆解原则：
- 一个任务 = 一个Commit
- 任务粒度不超过3天
- 前后端任务分别创建
任务拆解示例（US-002：新增生产指标）：
| 任务ID | 任务描述 | 类型 | 预估 | 负责人 |
|---|---|---|---|---|
| TASK-101 | 设计数据库表结构 | 后端 | 0.5d | 张三 |
| TASK-102 | 实现新增指标API | 后端 | 1d | 张三 |
| TASK-103 | 添加数据校验逻辑 | 后端 | 0.5d | 张三 |
| TASK-104 | 后端单元测试 | 后端 | 0.5d | 张三 |
| TASK-105 | 创建新增表单组件 | 前端 | 1d | 李四 |
| TASK-106 | 实现表单校验 | 前端 | 0.5d | 李四 |
| TASK-107 | 前后端联调 | 联调 | 0.5d | 张三+李四 |
| TASK-108 | 补充接口文档 | 文档 | 0.5d | 张三 |
阶段4：开发任务 → 代码实现 → 前后端联调
负责人： 开发人员
输入： 开发任务、技术设计、原型设计
核心工作流程：
graph LR
A[开发任务分配] --> B[后端开发]
A --> C[前端开发]
B --> D[后端自测]
C --> E[前端页面绘制+逻辑开发]
D --> F[前后端联调]
E --> F
F --> G[补充完善接口文档]
G --> H[开发人员自测]
H --> I[提交测试]
后端开发流程：
- 实现API接口
- 添加数据校验逻辑
- 编写单元测试
- 后端自测
前端开发流程：
- 页面绘制（根据原型+UI设计稿）
- 前端逻辑开发
- 前端组件测试
前后端联调：
- 时机：后端API完成 + 前端页面完成
- 工作：对接接口、调试功能、处理异常
- 补充完善接口文档（此时才补充接口文档，避免提前设计后反复更新）
产出物：
- ✅ 功能代码（前端+后端）
- ✅ 单元测试
- ✅ 接口文档（联调时补充完善）
- ✅ Git Commit（一个任务=一个Commit）
Commit规范示例：
feat(api): 实现新增生产指标接口
- 添加POST /api/production/indicators接口
- 实现数据校验逻辑
- 添加单元测试
closes #TASK-102
任务状态流转：
待办 → 开发中 → 联调中 → 自测中 → 待测试
阶段5：开发完成 → 测试 → 部署上线
负责人： 测试人员、DevOps
输入： 自测完成的功能代码
核心工作：
5.1 测试阶段
测试用例生成规则：
- 依据：PRD文档中的功能点统计
- 数量：功能点数量 = 测试用例数量
- 示例：PRD中10个功能点 → 10个测试用例
测试用例内容：
- 功能测试（基于用户故事）
- 边界测试
- 非法输入测试
- 异常处理测试
测试用例与用户故事关联：
US-002: 新增生产指标
├── TC-001: 正常新增功能测试
├── TC-002: 必填字段校验测试
├── TC-003: 数据格式校验测试
├── TC-004: 边界值测试
└── TC-005: 重复数据校验测试
测试流程：
- 开发人员自测完成
- 提交测试环境
- 测试人员执行测试用例
- 发现Bug → 创建Bug任务 → 返回阶段4修复
- 测试通过 → 进入部署流程
5.2 部署上线
CI/CD自动化流程：
graph LR
A[Git Push] --> B[自动构建]
B --> C[自动测试]
C --> D[部署测试环境]
D --> E[测试通过]
E --> F[部署生产环境]
产出物：
- ✅ 测试报告
- ✅ Bug列表
- ✅ 构建产物
- ✅ 部署记录
📊 关键节点与产出物总览
| 阶段 | 负责人 | 关键节点 | 核心产出物 | 备注 |
|---|---|---|---|---|
| 阶段1 需求收集 | 项目经理 | 需求评审会① | • 业务需求文档（层级结构） | 内部简单评审 |
| 阶段2 需求分析 | 产品经理 | 原型评审 PRD评审 | • 用户故事列表（第1步） • 低保真原型（第2步） • 高保真/交互原型（第3步） • PRD文档（第4步） • 功能点统计 | 开发人员参与 多轮确认 |
| 阶段3 技术设计 | 技术负责人 | - | • 技术设计文档 • 数据库设计 • 开发任务列表 • UI设计稿（并行） | UI可与开发并行 |
| 阶段4 开发实施 | 开发人员 | 前后端联调 开发自测 | • 功能代码 • 单元测试 • 接口文档（联调时补充） • Git Commit | 一任务=一Commit |
| 阶段5 测试部署 | 测试/DevOps | 测试评审 上线审批 | • 测试用例 • 测试报告 • 部署记录 | 测试用例数=功能点数 |
🔗 关联关系图
graph TB
A[业务需求] -->|拆解| B[用户故事]
B -->|关联| C[PRD文档]
B -->|关联| D[原型设计]
B -->|拆解| E[开发任务]
E -->|实现| F[Commit代码]
F -->|触发| G[CI/CD]
C -->|依据| H[测试用例]
B -->|关联| H
F -->|联调时补充| I[接口文档]
style A fill:#fff9e6
style B fill:#e8f5e9
style C fill:#e8f5e9
style D fill:#e8f5e9
style E fill:#fce4ec
style F fill:#f3e5f5
style H fill:#e0f2f1
关联规则：
- 业务需求 ↔ PRD文档章节（一对一）
- 用户故事 ↔ 原型页面（一对多）
- 用户故事 ↔ 开发任务（一对多）
- 开发任务 ↔ Git Commit（一对一）
- 功能点 ↔ 测试用例（一对一）
- 用户故事 ↔ 测试用例（一对多）
⚙️ 关键规范
1. 任务粒度规范
- ✅ 一个任务 = 一个Commit
- ✅ 任务工作量不超过3天
- ✅ 超过3天必须拆分或拉Feature分支
2. Commit规范
<type>(<scope>): <subject>
<body>
closes #TASK-XXX
Type类型：
feat: 新功能fix: Bug修复docs: 文档更新refactor: 重构test: 测试
3. 接口文档规范
- ⏰ 时机：后端开发完成，联调时补充
- ❌ 不提前设计：避免反复更新
- ✅ 包含内容：接口地址、请求参数、响应格式、示例
4. 测试用例规范
- 📊 数量依据：PRD中的功能点统计
- 🔗 关联方式：关联到用户故事或PRD文档
- 📝 内容覆盖：功能测试+边界测试+异常测试
🎯 快速参考：谁在哪个阶段产出什么
| 文档/产物 | 产出阶段 | 负责人 | 用途 |
|---|---|---|---|
| 业务需求文档 | 阶段1 | 项目经理 | 定义需求范围和层级 |
| 用户故事 | 阶段2（第1步） | 产品经理 | 需求拆解+测试依据 |
| 低保真原型 | 阶段2（第2步） | 产品经理 | 快速规划页面布局（plan） |
| 高保真/交互原型 | 阶段2（第3步） | 产品经理 | 最终原型设计 |
| PRD文档 | 阶段2（第4步） | 产品经理 | 详细功能说明+功能点统计 |
| 技术设计文档 | 阶段3 | 技术负责人 | 技术方案+架构设计 |
| 数据库设计 | 阶段3 | 技术负责人 | 表结构设计 |
| 开发任务 | 阶段3 | 技术负责人 | 任务分配+工作量评估 |
| UI设计稿 | 阶段3（并行） | UI设计师 | 视觉设计 |
| 功能代码 | 阶段4 | 开发人员 | 功能实现 |
| 接口文档 | 阶段4（联调时） | 后端开发 | 前后端对接 |
| Git Commit | 阶段4 | 开发人员 | 代码版本控制 |
| 测试用例 | 阶段5 | 测试人员 | 功能验证 |
| 测试报告 | 阶段5 | 测试人员 | 质量评估 |
💡 核心要点
✅ 做什么
- 需求评审分两轮：阶段1简单评审 + 阶段2多轮确认（开发参与）
- 阶段2顺序：用户故事 → 低保真原型 → 高保真原型 → PRD文档
- 接口文档联调时补充：避免提前设计后反复更新
- 测试用例关联功能点：功能点数量=测试用例数量
- 一个任务一个Commit：粒度不超过3天
❌ 不做什么
- ❌ 不在阶段1过度评审细节
- ❌ 不追求低保真原型的精美度
- ❌ 不在阶段3提前编写接口文档
- ❌ 不在开发前编写测试用例
- ❌ 不创建超过3天工作量的任务
📌 常见问题
Q1: 需求变更怎么办？
- 评估变更影响范围（哪个阶段的产物需要更新）
- 更新相关文档（业务需求→PRD→原型→任务）
- 重新评估工作量
- 记录变更历史
Q2: Bug修复流程？
发现Bug → 创建Bug任务 → 关联到用户故事
→ 开发修复 → Commit（fix类型）→ 重新测试
Q3: 紧急需求如何处理？
- 可简化流程，但必须补充文档
- 至少保留：用户故事 + 开发任务 + Commit
Q4: 前后端联调失败怎么办？
- 检查接口文档是否准确
- 前后端共同调试
- 修复后更新接口文档
- 重新自测
📅 迭代周期示例（2周Sprint）
| 时间 | 阶段 | 工作内容 |
|---|---|---|
| 周一 | 阶段1+2 | 需求收集、原型设计、PRD编写 |
| 周二 | 阶段2 | 需求评审（开发参与） |
| 周三 | 阶段3 | 技术设计、任务拆解 |
| 周四-下周三 | 阶段4 | 开发实施+联调 |
| 下周四 | 阶段4 | 开发自测 |
| 下周五 | 阶段5 | 测试+部署 |
版本记录：
- v1.0 (2025-10-11): 初始版本，基于实际开发流程梳理
