Scrum敏捷开发流程规范

Scrum 敏捷开发流程规范

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


📋 目录

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

流程概览

完整流程图

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:用户原始需求 → 业务需求

角色

项目经理 / 业务分析师

核心任务

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

业务需求层级结构

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

任务状态流转

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 规范

格式
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(可选)

详细说明

Footer(必填)

关联任务 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 集成示例:

  1. 在 JIRA 中创建任务

    • 任务 ID:PROJ-123
  2. 在 Commit Message 中关联

    bash 复制代码
    feat: 实现用户登录功能
    
    closes PROJ-123
  3. 自动触发状态更新

    • 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: 流程如下:

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

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

A: 尽量避免,但如果必须:

bash 复制代码
feat: 实现用户管理功能

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

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

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

A:

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

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

A:

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

Q6: 如何保证 Commit Message 规范?

A:

  1. 配置 Git Hooks(commit-msg)进行自动检查
  2. 使用工具:commitizen, commitlint
  3. Code Review 时检查 Commit 规范
  4. 定期进行团队培训

Q7: 测试任务如何管理?

A:

  • 单元测试:与开发任务合并(如 TASK-101 包含单元测试)
  • 集成测试:独立创建测试任务,关联到研发需求
  • UI 测试:独立创建测试任务,关联到研发需求

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

A: 可简化为:

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

Q9: 如何跟踪整体进度?

A: 建议使用:

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

Q10: 如何处理需求变更?

A:

  1. 评估变更影响范围(业务需求/研发需求/任务)
  2. 更新相关文档和任务
  3. 重新评估工作量和优先级
  4. 通知相关人员
  5. 记录变更历史

附录

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 状态为"测试中"

总结

本流程规范旨在为团队提供一套标准化的敏捷开发流程,从用户原始需求到最终上线,实现全流程可追溯、可管理。

核心要点:

  1. 层级清晰:业务需求 → 研发需求 → 开发任务
  2. 关联完整:每个层级都有明确的关联关系和产出物
  3. 自动化:通过 Commit 和 CI/CD 自动更新任务状态
  4. 可追溯:从需求到代码,全流程可追溯
  5. 可扩展:支持小团队简化,也支持大团队精细化管理

下一步行动:

  • 选择项目管理工具并配置集成
  • 配置 Git Hooks 和 commitlint
  • 搭建 CI/CD 流水线
  • 组织团队培训
  • 选择一个小功能试点推行

文档维护:

  • 当前版本:v1.0
  • 最后更新:2025-10-11
  • 维护负责人:[待定]
  • 反馈渠道:[待定]
相关推荐
Value_Think_Power4 小时前
变量->约束->目标
前端
开源框架4 小时前
招商银行模拟器app,网银模拟生成器,jar+c++组合模板
前端
日月之行_4 小时前
React 19.2正式发布啦!
前端
奔赴_向往4 小时前
抛弃虚拟DOM:Vue Vapor如何实现性能飞跃?
前端
小高0074 小时前
🤔Proxy 到底比 defineProperty 强在哪?为什么今天还在聊 Proxy?
前端·javascript·vue.js
哔哩哔哩技术4 小时前
VibeCut - 智能剪辑探索与实现
前端
用户904706683574 小时前
在uniapp Vue3版本中,如何解决,web/H5网页浏览器跨域的问题
前端
Value_Think_Power4 小时前
问题->语言(符号)
后端
90后的晨仔4 小时前
一键获取设备IP地址:内网与外网IP的完整指南
后端