Scrum 敏捷开发流程规范
版本： v1.0 更新日期： 2025-10-11 适用范围： 全项目通用
📋 目录
流程概览
完整流程图
graph TB
A[用户原始需求] -->|需求收集| B[业务需求/用户需求]
B -->|需求分析与拆解| C[研发需求/用户故事]
C -->|任务拆解| D[开发任务]
D -->|开发实施| E[代码提交/Commit]
E -->|自动触发| F[CI/CD 流程]
F -->|测试/打包/发布| G[部署上线]
B -.关联.-> H[PRD 文档]
C -.关联.-> I[设计文档/原型]
D -.关联.-> J[技术设计/接口文档]
E -.更新.-> D
F -.关联.-> C
style A fill:#e1f5ff
style B fill:#fff9e6
style C fill:#e8f5e9
style D fill:#fce4ec
style E fill:#f3e5f5
style F fill:#e0f2f1
style G fill:#c8e6c9
五大阶段
| 阶段 | 输入 | 输出 | 负责角色 | 产出物 |
|---|---|---|---|---|
| 1. 需求收集 | 用户原始需求 | 业务需求文档 | 项目经理 | 业务需求层级结构 |
| 2. 需求分析 | 业务需求 | 研发需求/用户故事 | 产品经理 | 用户故事 + PRD + 原型 |
| 3. 任务拆解 | 研发需求 | 开发任务列表 | 技术负责人 | 开发任务 + 技术设计 |
| 4. 开发实施 | 开发任务 | 代码提交 | 开发人员 | Commit + 功能代码 |
| 5. 自动化流程 | 代码提交 | 测试/打包/发布 | DevOps | 部署记录 + 测试报告 |
角色定义
1. 项目经理（PM）
职责：
- 收集并整理用户原始需求
- 创建业务需求层级结构
- 协调跨团队资源
- 跟踪项目整体进度
关键产出：
- 业务需求文档（分层级）
2. 产品经理（PO）
职责：
- 将业务需求拆解为研发需求（用户故事）
- 编写 PRD 文档
- 设计产品原型
- 确定优先级和迭代计划
关键产出：
- 用户故事列表
- PRD 文档
- 原型设计（Axure/Figma）
3. 技术负责人（Tech Lead）
职责：
- 将研发需求拆解为开发任务
- 评估技术方案和工作量
- 分配任务给开发人员
- 进行技术评审
关键产出：
- 开发任务列表
- 技术设计文档
- 接口文档
4. 开发人员（Developer）
职责：
- 完成分配的开发任务
- 编写代码和单元测试
- 提交规范的 Commit
- 参与 Code Review
关键产出：
- 功能代码
- 单元测试
- Git Commit
5. DevOps 工程师
职责：
- 维护 CI/CD 流水线
- 配置自动化测试
- 管理部署流程
- 监控系统运行状态
关键产出：
- 自动化脚本
- 部署记录
- 测试报告
阶段详解
阶段 1：用户原始需求 → 业务需求
角色
项目经理 / 业务分析师
核心任务
将用户的模糊需求整理为结构化的业务需求文档
业务需求层级结构
一级业务需求（系统级）
├── 二级业务需求（模块级）
│ ├── 三级业务需求（功能级）⭐ [可拆解层级]
│ └── 三级业务需求（功能级）⭐ [可拆解层级]
└── 二级业务需求（模块级）
示例：生产计划系统
生产计划系统（一级：系统级）
├── 月计划填报（二级：模块级）
│ ├── 生产指标预测（三级：功能级）⭐
│ ├── 计划数据审核（三级：功能级）⭐
│ └── 历史数据查询（三级：功能级）⭐
└── 季度计划统计（二级：模块级）
├── 季度汇总报表（三级：功能级）⭐
└── 趋势分析图表（三级：功能级）⭐
拆解规则
✅ 只从最末一级业务需求进行拆解 ✅ 每个业务需求必须关联 PRD 文档章节 ✅ 业务需求层级应与需求文档结构一致
产出物
- 业务需求文档（层级结构）
- PRD 文档框架
阶段 2：业务需求 → 研发需求（用户故事）
角色
产品经理
核心任务
将最末一级业务需求拆解为多个用户故事（User Story）
用户故事格式
作为【用户角色】，
我想要【完成一个任务】，
以便【实现一个价值】。
研发需求层级结构
研发需求（父）- 对应一个页面/模块
├── 用户故事 1（子）- 对应一个功能点
├── 用户故事 2（子）- 对应一个功能点
├── 用户故事 3（子）- 对应一个功能点
└── 用户故事 N（子）- 对应一个功能点
示例：生产指标预测
父研发需求： 生产指标预测（页面级）
子研发需求（用户故事）：
| ID | 用户故事 | 优先级 | 关联原型 |
|---|---|---|---|
| US-001 | 作为【生产经理】，我想要【查看月度生产指标列表】，以便【了解当前生产计划情况】 | P0 | 原型 P01 |
| US-002 | 作为【生产经理】，我想要【新增月度生产指标】，以便【制定下月生产计划】 | P0 | 原型 P01-01 |
| US-003 | 作为【生产经理】，我想要【编辑已填报的指标】，以便【调整生产计划】 | P0 | 原型 P01-02 |
| US-004 | 作为【生产经理】，我想要【删除错误的指标记录】，以便【保持数据准确性】 | P1 | 原型 P01 |
| US-005 | 作为【系统】，我想要【校验指标数据的合理性】，以便【防止异常数据录入】 | P0 | - |
| US-006 | 作为【生产经理】，我想要【导出 Excel 报表】，以便【向上级汇报】 | P2 | 原型 P01 |
关联文档
- PRD 文档（详细说明每个用户故事）
- 原型设计（Axure/Figma）
- 详细设计文档（技术方案）
拆解规则
✅ 从最末一级业务需求拆解 ✅ 每个用户故事必须独立且可测试 ✅ 一个页面 = 一个父研发需求 ✅ 页面功能点 = 子研发需求（用户故事）
阶段 3：研发需求 → 开发任务
角色
技术负责人 / 开发人员
核心任务
将最末一级研发需求（用户故事）拆解为独立的开发任务
任务拆解原则
| 原则 | 说明 |
|---|---|
| 一个任务 = 一个 Commit | 任务完成后立即提交代码 |
| 任务粒度不超过 3 天 | 超过 3 天必须拆分或拉分支 |
| 任务独立可测试 | 每个任务完成后可独立验证 |
| 前后端分离拆解 | 前端任务和后端任务分别创建 |
示例：US-002 新增月度生产指标
用户故事： US-002 - 新增月度生产指标
拆解的开发任务：
| 任务 ID | 任务描述 | 类型 | 预估工时 | 负责人 | 依赖 |
|---|---|---|---|---|---|
| TASK-101 | 设计数据库表结构 | 后端 | 0.5d | 张三 | - |
| TASK-102 | 实现新增指标 API 接口 | 后端 | 1d | 张三 | TASK-101 |
| TASK-103 | 添加数据校验逻辑 | 后端 | 0.5d | 张三 | TASK-102 |
| TASK-104 | 编写后端单元测试 | 后端 | 0.5d | 张三 | TASK-103 |
| TASK-105 | 创建新增指标表单组件 | 前端 | 1d | 李四 | - |
| TASK-106 | 实现表单校验逻辑 | 前端 | 0.5d | 李四 | TASK-105 |
| TASK-107 | 对接新增指标接口 | 前端 | 0.5d | 李四 | TASK-102, TASK-106 |
| TASK-108 | 更新接口文档 | 文档 | 0.5d | 张三 | TASK-102 |
任务状态流转
graph LR
A[待办 Todo] -->|开始开发| B[进行中 In Progress]
B -->|代码提交| C[待测试 Ready for Test]
C -->|测试通过| D[已完成 Done]
C -->|测试失败| B
B -->|阻塞| E[阻塞 Blocked]
E -->|解决阻塞| B
阶段 4：开发任务 → 代码提交（Commit）
角色
开发人员
核心任务
完成开发任务并提交规范的 Git Commit
Commit Message 规范
格式
<type>(<scope>): <subject>
<body>
<footer>
Type 类型
| Type | 说明 | 示例 |
|---|---|---|
feat | 新功能 | feat: 新增生产指标表单组件 |
fix | 修复 Bug | fix: 修复指标数据校验错误 |
docs | 文档更新 | docs: 更新接口文档 |
style | 代码格式调整 | style: 格式化代码 |
refactor | 重构 | refactor: 重构表单校验逻辑 |
test | 测试相关 | test: 添加单元测试 |
chore | 构建/工具变动 | chore: 更新依赖包 |
Scope（可选）
模块名称，如：form, api, utils
Subject
简短描述（不超过 50 字符）
Body（可选）
详细说明
Footer（必填）
关联任务 ID：
关联任务 #TASK-105
关闭任务（自动更新状态）：
closes #TASK-105
fixes #TASK-105
resolves #TASK-105
完整示例
feat(form): 实现新增生产指标表单组件
- 创建 ProductionForm.vue 组件
- 实现字段校验逻辑（产量、日期、备注）
- 支持日期选择和数字输入限制
- 添加表单重置功能
closes #TASK-105
Commit 与任务关联机制
graph LR
A[开发完成] -->|git commit| B[提交代码]
B -->|解析 Commit Message| C{包含任务 ID?}
C -->|是| D[自动更新任务状态]
C -->|否| E[仅记录 Commit]
D -->|closes/fixes| F[任务状态 已完成]
D -->|关联| G[任务状态 待测试]
Commit 规范检查
Git Hook 配置（commit-msg）：
#!/bin/sh
# .git/hooks/commit-msg
COMMIT_MSG=$(cat $1)
# 检查是否包含任务 ID
if ! echo "$COMMIT_MSG" | grep -qE "#TASK-[0-9]+"; then
echo "错误：Commit Message 必须包含任务 ID（格式：#TASK-123）"
exit 1
fi
# 检查 Type 是否合法
if ! echo "$COMMIT_MSG" | grep -qE "^(feat|fix|docs|style|refactor|test|chore)"; then
echo "错误：Commit Type 必须为：feat, fix, docs, style, refactor, test, chore"
exit 1
fi
exit 0
阶段 5：代码提交 → 自动化流程（CI/CD）
角色
DevOps 工程师
核心任务
自动执行测试、打包、部署流程
CI/CD 流水线
graph TB
A[Git Push] -->|Webhook 触发| B[CI/CD 平台]
B -->|1. 代码检查| C[Lint & Format Check]
C -->|2. 单元测试| D[Unit Test]
D -->|3. 集成测试| E[Integration Test]
E -->|4. 构建打包| F[Build]
F -->|5. 部署| G{部署环境}
G -->|开发分支| H[测试环境]
G -->|主分支| I[生产环境]
H -->|通知| J[更新任务状态]
I -->|通知| K[更新发布记录]
C -.失败.-> L[通知开发者]
D -.失败.-> L
E -.失败.-> L
F -.失败.-> L
自动化触发条件
| 分支 | 触发条件 | 执行流程 | 部署目标 |
|---|---|---|---|
feature/* | Push | Lint + Test | - |
develop | Push / Merge | Lint + Test + Build | 测试环境 |
release/* | Push | Lint + Test + Build | 预发布环境 |
main/master | Merge | Full CI/CD | 生产环境 |
关联关系
- 测试结果 → 关联到任务或研发需求
- 打包记录 → 关联到研发需求或迭代版本
- 发布记录 → 关联到迭代版本
示例：Jenkins Pipeline
pipeline {
agent any
stages {
stage('Checkout') {
steps {
git branch: 'develop', url: 'https://git.example.com/project.git'
}
}
stage('Lint') {
steps {
sh 'npm run lint'
}
}
stage('Test') {
steps {
sh 'npm run test'
}
}
stage('Build') {
steps {
sh 'npm run build'
}
}
stage('Deploy') {
when {
branch 'develop'
}
steps {
sh 'scp -r dist/* server@test.example.com:/var/www/'
}
}
stage('Notify') {
steps {
script {
// 解析 Commit Message 中的任务 ID
def taskId = sh(
script: "git log -1 --pretty=%B | grep -oE '#TASK-[0-9]+'",
returnStdout: true
).trim()
// 调用项目管理系统 API 更新任务状态
sh "curl -X POST https://pm.example.com/api/tasks/${taskId}/status -d 'status=done'"
}
}
}
}
}
关联关系说明
完整关联关系图
graph TB
A[业务需求] -->|拆解| B[研发需求]
B -->|拆解| C[开发任务]
C -->|实现| D[Commit]
D -->|触发| E[CI/CD]
A -.关联.-> F[PRD 文档]
B -.关联.-> G[设计文档]
B -.关联.-> H[原型设计]
C -.关联.-> I[技术设计]
C -.关联.-> J[接口文档]
E -.关联.-> K[测试报告]
E -.关联.-> L[部署记录]
D -.更新.-> C
E -.更新.-> B
关联关系表
| 层级 | 关联对象 | 关联类型 | 说明 |
|---|---|---|---|
| 业务需求 | PRD 文档 | 一对一 | 每个业务需求对应 PRD 章节 |
| 研发需求 | 业务需求 | 多对一 | 多个用户故事来自一个业务需求 |
| 研发需求 | 设计文档 | 一对一 | 每个研发需求有对应设计文档 |
| 研发需求 | 原型设计 | 一对多 | 一个研发需求可能有多个原型页面 |
| 开发任务 | 研发需求 | 多对一 | 多个任务来自一个用户故事 |
| 开发任务 | 技术设计 | 多对一 | 多个任务共享一个技术设计 |
| Commit | 开发任务 | 一对一 | 一个 Commit 对应一个任务 |
| CI/CD | Commit | 一对多 | 一次 CI/CD 可能包含多个 Commit |
| 测试报告 | 研发需求 | 多对一 | 多个测试用例对应一个用户故事 |
| 部署记录 | 迭代版本 | 多对一 | 多次部署属于一个迭代 |
工具与自动化
推荐工具栈
| 类型 | 工具选项 | 用途 |
|---|---|---|
| 项目管理 | JIRA / Tapd / 禅道 / 飞书项目 | 需求和任务管理 |
| 原型设计 | Axure / Figma / 墨刀 | 产品原型设计 |
| 文档管理 | Confluence / 飞书文档 / Notion | PRD 和技术文档 |
| 代码管理 | GitLab / GitHub / Gitee | 代码版本控制 |
| CI/CD | Jenkins / GitLab CI / GitHub Actions | 自动化构建部署 |
| 测试管理 | TestRail / 禅道 | 测试用例管理 |
自动化集成方案
方案 1：基于项目管理工具的集成
JIRA + GitLab 集成示例：
-
在 JIRA 中创建任务
- 任务 ID：
PROJ-123
- 任务 ID：
-
在 Commit Message 中关联
feat: 实现用户登录功能 closes PROJ-123 -
自动触发状态更新
- JIRA 自动将
PROJ-123状态更新为 "Done"
- JIRA 自动将
方案 2：基于 Webhook 的集成
GitLab Webhook 配置：
{
"object_kind": "push",
"event_name": "push",
"commits": [
{
"id": "b6568db1bc1d",
"message": "feat: 实现用户登录\n\ncloses #TASK-123",
"timestamp": "2025-10-11T10:00:00+00:00",
"author": {
"name": "张三",
"email": "zhangsan@example.com"
}
}
]
}
后端处理脚本：
// webhook-handler.js
app.post('/webhook/gitlab', (req, res) => {
const commits = req.body.commits;
commits.forEach(commit => {
// 解析 Commit Message 中的任务 ID
const taskIds = commit.message.match(/#TASK-\d+/g);
if (taskIds) {
taskIds.forEach(taskId => {
// 检查是否包含关闭关键字
const shouldClose = /closes|fixes|resolves/.test(commit.message);
// 调用项目管理系统 API
updateTaskStatus(taskId, shouldClose ? 'done' : 'in_test');
});
}
});
res.status(200).send('OK');
});
模板与规范
1. 用户故事模板
### 用户故事：[功能名称]
**ID:** US-XXX
**用户角色：** [角色名称]
**故事描述：**
作为【角色】，我想要【完成任务】，以便【实现价值】。
**验收标准：**
- [ ] 标准 1
- [ ] 标准 2
- [ ] 标准 3
**优先级：** P0 / P1 / P2
**关联：**
- 业务需求：[需求 ID]
- 原型设计：[原型链接]
- PRD 章节：[PRD 章节号]
**备注：**
[补充说明]
2. 开发任务模板
### 开发任务：[任务名称]
**ID:** TASK-XXX
**类型：** 前端 / 后端 / 测试 / 文档
**描述：**
[详细描述任务内容]
**验收标准：**
- [ ] 功能实现完整
- [ ] 代码通过 Lint 检查
- [ ] 单元测试覆盖率 > 80%
- [ ] 通过 Code Review
**预估工时：** X 天
**依赖任务：**
- TASK-XXX
- TASK-XXX
**关联：**
- 用户故事：US-XXX
- 技术设计：[文档链接]
**备注：**
[补充说明]
3. Commit Message 模板
# <type>(<scope>): <subject>
#
# <body>
#
# <footer>
#
# Type 类型：
# feat: 新功能
# fix: 修复 Bug
# docs: 文档更新
# style: 代码格式调整
# refactor: 重构
# test: 测试相关
# chore: 构建/工具变动
#
# Scope（可选）：模块名称
#
# Subject：简短描述（不超过 50 字符）
#
# Body（可选）：详细说明
#
# Footer（必填）：
# 关联任务：关联任务 #TASK-123
# 关闭任务：closes #TASK-123 / fixes #TASK-123 / resolves #TASK-123
#
# 示例：
# feat(auth): 实现用户登录功能
#
# - 添加登录表单组件
# - 实现 JWT 认证逻辑
# - 添加登录状态管理
#
# closes #TASK-101
配置为 Git 默认模板：
git config --global commit.template ~/.gitmessage
常见问题 FAQ
Q1: 任务粒度如何控制？
A: 遵循以下原则：
- ✅ 一个任务 = 一个 Commit
- ✅ 任务工作量不超过 3 天
- ✅ 超过 3 天的任务必须拆分或拉 Feature 分支
- ✅ 任务应独立可测试
Q2: 如何处理紧急 Bug 修复？
A: 流程如下：
- 在项目管理工具中创建 Bug 任务（类型：Bug）
- 关联到相关的研发需求或业务需求
- 按正常流程提交代码，Commit Message 使用
fix类型 - 紧急情况可跳过部分流程，但事后必须补充文档
Q3: 一个 Commit 关联多个任务怎么办？
A: 尽量避免，但如果必须：
feat: 实现用户管理功能
- 添加用户列表页面
- 实现用户新增功能
关联任务 #TASK-101, #TASK-102
Q4: 如何处理跨迭代的任务？
A:
- 方案 1：拉 Feature 分支，迭代结束后合并
- 方案 2：拆分为多个小任务，分别在不同迭代完成
- 方案 3：将任务移至下一迭代
Q5: 前后端联调如何管理？
A:
- 后端先完成接口开发和文档更新（TASK-101）
- 前端基于接口文档开始开发（TASK-102，依赖 TASK-101）
- 联调完成后，前端提交最终代码（TASK-103）
- 三个任务都关联到同一个用户故事
Q6: 如何保证 Commit Message 规范？
A:
- 配置 Git Hooks（commit-msg）进行自动检查
- 使用工具：commitizen, commitlint
- Code Review 时检查 Commit 规范
- 定期进行团队培训
Q7: 测试任务如何管理？
A:
- 单元测试：与开发任务合并（如 TASK-101 包含单元测试）
- 集成测试：独立创建测试任务，关联到研发需求
- UI 测试：独立创建测试任务，关联到研发需求
Q8: 小团队如何简化流程？
A: 可简化为：
- 角色合并：一人多角色（如产品 + 项目经理）
- 文档简化：PRD 和技术设计合并为一份文档
- 层级简化：业务需求只分两级
- 工具简化：使用轻量级工具（如飞书多维表格）
Q9: 如何跟踪整体进度？
A: 建议使用：
- 燃尽图：跟踪迭代进度
- 看板视图：可视化任务状态
- 甘特图：跟踪任务依赖和时间线
- 数据报表：统计完成率、Bug 率等指标
Q10: 如何处理需求变更？
A:
- 评估变更影响范围（业务需求/研发需求/任务）
- 更新相关文档和任务
- 重新评估工作量和优先级
- 通知相关人员
- 记录变更历史
附录
A. 参考资料
B. 工具配置示例
commitlint 配置
// commitlint.config.js
module.exports = {
extends: ['@commitlint/config-conventional'],
rules: {
'type-enum': [
2,
'always',
['feat', 'fix', 'docs', 'style', 'refactor', 'test', 'chore']
],
'subject-max-length': [2, 'always', 50],
'body-max-line-length': [2, 'always', 100],
'footer-max-line-length': [0] // 禁用 footer 长度限制
}
};
husky 配置
{
"husky": {
"hooks": {
"commit-msg": "commitlint -E HUSKY_GIT_PARAMS"
}
}
}
C. 完整示例：生产指标预测功能
详见下一节《完整功能示例》。
完整功能示例：生产指标预测
层级关系表
| 层级 | 类型 | ID | 名称 | 负责人 | 状态 | 关联文档 |
|---|---|---|---|---|---|---|
| 1 | 用户原始需求 | - | 需要生产计划管理系统 | 业务方 | 已收集 | - |
| 2 | 业务需求（一级） | REQ-001 | 生产计划系统 | 项目经理 | 进行中 | PRD v1.0 |
| 3 | 业务需求（二级） | REQ-001-01 | 月计划填报 | 项目经理 | 进行中 | PRD 第 2 章 |
| 4 | 业务需求（三级）⭐ | REQ-001-01-01 | 生产指标预测 | 产品经理 | 开发中 | PRD 2.1 节 |
| 5 | 研发需求（父） | FEAT-001 | 生产指标预测页面 | 产品经理 | 开发中 | 设计文档 + 原型 P01 |
| 6 | 研发需求（子） | US-001 | 查看指标列表 | - | 已完成 | 原型 P01 |
| 7 | 研发需求（子） | US-002 | 新增生产指标 | - | 测试中 | 原型 P01-01 |
| 8 | 研发需求（子） | US-003 | 编辑指标 | - | 待开发 | 原型 P01-02 |
| 9 | 开发任务 | TASK-101 | 设计数据库表 | 张三 | 已完成 | 技术设计 |
| 10 | 开发任务 | TASK-102 | 实现新增 API | 张三 | 已完成 | 接口文档 |
| 11 | 开发任务 | TASK-103 | 添加数据校验 | 张三 | 已完成 | 接口文档 |
| 12 | 开发任务 | TASK-104 | 后端单元测试 | 张三 | 已完成 | - |
| 13 | 开发任务 | TASK-105 | 创建表单组件 | 李四 | 已完成 | 技术设计 |
| 14 | 开发任务 | TASK-106 | 表单校验逻辑 | 李四 | 已完成 | 技术设计 |
| 15 | 开发任务 | TASK-107 | 对接新增接口 | 李四 | 测试中 | - |
| 16 | Commit | - | feat: 实现新增表单 | 李四 | 已提交 | 关联 TASK-105 |
| 17 | CI/CD | BUILD-001 | 部署到测试环境 | DevOps | 已部署 | 关联 US-002 |
时间线
Day 1: TASK-101 完成 → Commit: "feat(db): 设计生产指标表"
Day 2: TASK-102 完成 → Commit: "feat(api): 实现新增指标接口"
Day 3: TASK-103 完成 → Commit: "feat(api): 添加数据校验逻辑"
TASK-104 完成 → Commit: "test(api): 添加单元测试"
Day 4: TASK-105 完成 → Commit: "feat(form): 创建新增表单组件"
Day 5: TASK-106 完成 → Commit: "feat(form): 实现表单校验"
Day 6: TASK-107 进行中 → 前后端联调
Day 7: TASK-107 完成 → Commit: "feat(form): 对接新增接口"
→ 触发 CI/CD → 部署到测试环境
→ 自动更新 US-002 状态为"测试中"
总结
本流程规范旨在为团队提供一套标准化的敏捷开发流程，从用户原始需求到最终上线，实现全流程可追溯、可管理。
核心要点：
- ✅ 层级清晰：业务需求 → 研发需求 → 开发任务
- ✅ 关联完整：每个层级都有明确的关联关系和产出物
- ✅ 自动化：通过 Commit 和 CI/CD 自动更新任务状态
- ✅ 可追溯：从需求到代码，全流程可追溯
- ✅ 可扩展：支持小团队简化，也支持大团队精细化管理
下一步行动：
- 选择项目管理工具并配置集成
- 配置 Git Hooks 和 commitlint
- 搭建 CI/CD 流水线
- 组织团队培训
- 选择一个小功能试点推行
文档维护：
- 当前版本：v1.0
- 最后更新：2025-10-11
- 维护负责人：[待定]
- 反馈渠道：[待定]
