Scrum敏捷开发流程规范

Scrum 敏捷开发流程规范

版本： v1.0 更新日期： 2025-10-11 适用范围： 全项目通用

📋 目录

流程概览
角色定义
阶段详解
关联关系说明
工具与自动化
模板与规范
[常见问题 FAQ](#常见问题 FAQ "#%E5%B8%B8%E8%A7%81%E9%97%AE%E9%A2%98-faq")

流程概览

完整流程图

五大阶段

阶段	输入	输出	负责角色	产出物
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：用户原始需求 → 业务需求

角色

项目经理 / 业务分析师

核心任务

将用户的模糊需求整理为结构化的业务需求文档

业务需求层级结构

css 复制代码

一级业务需求（系统级）
├── 二级业务需求（模块级）
│   ├── 三级业务需求（功能级）⭐ [可拆解层级]
│   └── 三级业务需求（功能级）⭐ [可拆解层级]
└── 二级业务需求（模块级）

示例：生产计划系统

markdown 复制代码

生产计划系统（一级：系统级）
├── 月计划填报（二级：模块级）
│   ├── 生产指标预测（三级：功能级）⭐
│   ├── 计划数据审核（三级：功能级）⭐
│   └── 历史数据查询（三级：功能级）⭐
└── 季度计划统计（二级：模块级）
    ├── 季度汇总报表（三级：功能级）⭐
    └── 趋势分析图表（三级：功能级）⭐

拆解规则

✅ 只从最末一级业务需求进行拆解 ✅ 每个业务需求必须关联 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

任务状态流转

阶段 4：开发任务 → 代码提交（Commit）

角色

开发人员

核心任务

完成开发任务并提交规范的 Git Commit

Commit Message 规范

格式

xml 复制代码

<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（可选）

详细说明

关联任务 ID：

bash 复制代码

关联任务 #TASK-105

关闭任务（自动更新状态）：

bash 复制代码

closes #TASK-105
fixes #TASK-105
resolves #TASK-105

完整示例

bash 复制代码

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）：

bash 复制代码

#!/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

groovy 复制代码

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

在 Commit Message 中关联

bash 复制代码

feat: 实现用户登录功能

closes PROJ-123

自动触发状态更新
- JIRA 自动将 PROJ-123 状态更新为 "Done"

方案 2：基于 Webhook 的集成

GitLab Webhook 配置：

json 复制代码

{
  "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"
      }
    }
  ]
}

后端处理脚本：

javascript 复制代码

// 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. 用户故事模板

markdown 复制代码

### 用户故事：[功能名称]

**ID:** US-XXX

**用户角色：** [角色名称]

**故事描述：**
作为【角色】，我想要【完成任务】，以便【实现价值】。

**验收标准：**
- [ ] 标准 1
- [ ] 标准 2
- [ ] 标准 3

**优先级：** P0 / P1 / P2

**关联：**
- 业务需求：[需求 ID]
- 原型设计：[原型链接]
- PRD 章节：[PRD 章节号]

**备注：**
[补充说明]

2. 开发任务模板

markdown 复制代码

### 开发任务：[任务名称]

**ID:** TASK-XXX

**类型：** 前端 / 后端 / 测试 / 文档

**描述：**
[详细描述任务内容]

**验收标准：**
- [ ] 功能实现完整
- [ ] 代码通过 Lint 检查
- [ ] 单元测试覆盖率 > 80%
- [ ] 通过 Code Review

**预估工时：** X 天

**依赖任务：**
- TASK-XXX
- TASK-XXX

**关联：**
- 用户故事：US-XXX
- 技术设计：[文档链接]

**备注：**
[补充说明]

3. Commit Message 模板

bash 复制代码

# <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 默认模板：

bash 复制代码

git config --global commit.template ~/.gitmessage

常见问题 FAQ

Q1: 任务粒度如何控制？

A: 遵循以下原则：

✅ 一个任务 = 一个 Commit
✅ 任务工作量不超过 3 天
✅ 超过 3 天的任务必须拆分或拉 Feature 分支
✅ 任务应独立可测试

Q2: 如何处理紧急 Bug 修复？

A: 流程如下：

在项目管理工具中创建 Bug 任务（类型：Bug）
关联到相关的研发需求或业务需求
按正常流程提交代码，Commit Message 使用 fix 类型
紧急情况可跳过部分流程，但事后必须补充文档

Q3: 一个 Commit 关联多个任务怎么办？

A: 尽量避免，但如果必须：

bash 复制代码

feat: 实现用户管理功能

- 添加用户列表页面
- 实现用户新增功能

关联任务 #TASK-101, #TASK-102

Q4: 如何处理跨迭代的任务？

方案 1：拉 Feature 分支，迭代结束后合并
方案 2：拆分为多个小任务，分别在不同迭代完成
方案 3：将任务移至下一迭代

Q5: 前后端联调如何管理？

后端先完成接口开发和文档更新（TASK-101）
前端基于接口文档开始开发（TASK-102，依赖 TASK-101）
联调完成后，前端提交最终代码（TASK-103）
三个任务都关联到同一个用户故事

Q6: 如何保证 Commit Message 规范？

配置 Git Hooks（commit-msg）进行自动检查
使用工具：commitizen, commitlint
Code Review 时检查 Commit 规范
定期进行团队培训

Q7: 测试任务如何管理？

单元测试：与开发任务合并（如 TASK-101 包含单元测试）
集成测试：独立创建测试任务，关联到研发需求
UI 测试：独立创建测试任务，关联到研发需求

Q8: 小团队如何简化流程？

A: 可简化为：

角色合并：一人多角色（如产品 + 项目经理）
文档简化：PRD 和技术设计合并为一份文档
层级简化：业务需求只分两级
工具简化：使用轻量级工具（如飞书多维表格）

Q9: 如何跟踪整体进度？

A: 建议使用：

燃尽图：跟踪迭代进度
看板视图：可视化任务状态
甘特图：跟踪任务依赖和时间线
数据报表：统计完成率、Bug 率等指标

Q10: 如何处理需求变更？

评估变更影响范围（业务需求/研发需求/任务）
更新相关文档和任务
重新评估工作量和优先级
通知相关人员
记录变更历史

附录

A. 参考资料

B. 工具配置示例

commitlint 配置

javascript 复制代码

// 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 配置

json 复制代码

{
  "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

时间线

sql 复制代码

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
维护负责人：[待定]
反馈渠道：[待定]

Scrum敏捷开发流程规范