项目管理工具实践：Jira敏捷开发全流程¶

学习目标¶

完成本教程后，你将能够：

掌握Jira的核心概念和基本操作
能够创建和配置敏捷项目（Scrum/Kanban）
熟练使用看板管理任务流转
掌握Sprint规划和执行流程
能够分析和使用燃尽图、速率图等报表
了解Jira与其他工具的集成方法

前置要求¶

在开始本教程之前，你需要：

知识要求： - 了解敏捷开发基本概念（Scrum、Kanban） - 熟悉软件开发生命周期 - 理解项目管理基本原理 - 有实际项目经验（至少参与过1-2个项目）

技能要求： - 能够使用Web浏览器进行基本操作 - 具备基本的项目管理思维 - 了解团队协作流程

环境要求： - 可访问互联网的计算机 - 现代Web浏览器（Chrome、Firefox、Edge等） - Jira账号（可使用免费试用版）

准备工作¶

软件准备¶

Jira Cloud：注册Atlassian账号，获取Jira Cloud试用版
访问：https://www.atlassian.com/software/jira
选择"Free trial"开始试用
试用期：7-30天（根据版本不同）
可选工具：
Confluence：文档协作工具
Bitbucket/GitHub：代码仓库（用于集成演示）
Slack：团队沟通工具（用于集成演示）

环境配置¶

注册Jira账号
访问Atlassian官网
填写邮箱和基本信息
验证邮箱
创建站点（例如：yourcompany.atlassian.net）
选择产品
选择Jira Software（适合软件开发团队）
跳过其他产品（可后续添加）
初始化设置
选择团队规模
选择项目类型（我们将在教程中详细配置）

Jira核心概念¶

在开始实践之前，先了解Jira的核心概念：

基本概念¶

概念	说明	示例
Project（项目）	工作的容器，包含所有相关的Issue	嵌入式固件开发项目
Issue（问题）	工作项，可以是任务、Bug、Story等	"实现GPIO驱动"
Epic（史诗）	大型工作项，包含多个Story	"设备驱动模块开发"
Story（用户故事）	从用户角度描述的功能需求	"作为用户，我希望..."
Task（任务）	具体的工作任务	"编写SPI驱动代码"
Bug（缺陷）	需要修复的问题	"串口数据丢失"
Sprint（冲刺）	固定时间的开发周期（通常1-4周）	Sprint 1: 2周
Backlog（待办列表）	所有待完成的Issue列表	产品Backlog
Board（看板）	可视化工作流的界面	Scrum Board / Kanban Board
Workflow（工作流）	Issue的状态流转规则	To Do → In Progress → Done

Scrum vs Kanban¶

Scrum特点： - 固定时间的Sprint - Sprint规划会议 - 每日站会 - Sprint评审和回顾 - 适合：需求相对稳定的项目

Kanban特点： - 持续流动，无固定周期 - WIP（在制品）限制 - 关注流动效率 - 适合：需求频繁变化的项目

步骤1：创建敏捷项目¶

1.1 创建Scrum项目¶

进入项目创建页面
点击左上角"Projects" → "Create project"
或直接点击"+"按钮
选择项目模板
选择"Scrum"模板
点击"Use template"

配置项目信息

项目名称：Embedded Firmware Development
项目键：EFD（自动生成，可修改）
项目类型：Team-managed（团队管理型）

完成创建
点击"Create"
等待项目初始化完成

预期结果： - 项目创建成功 - 自动跳转到项目看板 - 看板包含默认的三个列：To Do、In Progress、Done

1.2 配置项目设置¶

访问项目设置
点击左下角"Project settings"
配置Issue类型
进入"Issue types"
确认包含：Epic、Story、Task、Bug
可添加自定义类型（如：Subtask、Improvement）
配置工作流
进入"Workflows"
查看默认工作流：To Do → In Progress → Done
可自定义添加状态（如：Code Review、Testing）

步骤2：创建和管理Issue¶

2.1 创建Epic（史诗）¶

Epic用于组织大型功能模块。

创建Epic
点击"Create"按钮（或快捷键 C）
Issue type：选择"Epic"

填写信息：

Summary: 设备驱动模块开发
Epic Name: Device Drivers
Description: 
开发嵌入式系统的核心设备驱动，包括：
- GPIO驱动
- UART驱动
- SPI驱动
- I2C驱动

点击"Create"
设置Epic颜色
点击Epic卡片
选择颜色标签（便于在看板上识别）

2.2 创建Story（用户故事）¶

Story描述具体的功能需求。

创建Story
点击"Create"
Issue type：选择"Story"

填写信息：

Summary: 实现GPIO驱动基本功能
Epic Link: 设备驱动模块开发
Description:
作为嵌入式开发者，我希望实现GPIO驱动的基本功能，
以便能够控制LED和读取按键状态。

验收标准：
- [ ] 支持GPIO输出模式
- [ ] 支持GPIO输入模式
- [ ] 提供初始化接口
- [ ] 提供读写接口
- [ ] 通过单元测试

Story Points：估算工作量（如：5点）
Priority：设置优先级（High/Medium/Low）
Assignee：分配给团队成员
Sprint：选择Sprint（或留在Backlog） ```
点击"Create"

Story Points估算参考： - 1点：1-2小时的工作 - 3点：半天的工作 - 5点：1天的工作 - 8点：2天的工作 - 13点：1周的工作

2.3 创建Task（任务）¶

Task是Story的具体实现步骤。

从Story创建Task
打开Story详情
点击"Create subtask"或"Link issue" → "Create"
Issue type：选择"Task"

填写信息：

Summary: 编写GPIO初始化函数
Parent: 实现GPIO驱动基本功能
Description:
实现GPIO_Init()函数，支持以下功能：
- 时钟使能
- 引脚模式配置
- 上下拉配置
- 速度配置

技术要点：
- 使用HAL库
- 参数验证
- 错误处理

Original Estimate：2h（预估时间）
Assignee：分配给开发者 ```
创建更多Task
编写GPIO读写函数（2h）
编写单元测试（3h）
编写API文档（1h）

2.4 创建Bug¶

Bug用于跟踪需要修复的问题。

创建Bug
点击"Create"
Issue type：选择"Bug"

填写信息：

Summary: GPIO输出模式下电平翻转失败
Priority: High
Affects Version: v1.0
Description:
**问题描述**：
在GPIO输出模式下，调用HAL_GPIO_TogglePin()后，
引脚电平没有翻转。

**复现步骤**：
1. 配置PA5为输出模式
2. 调用HAL_GPIO_TogglePin(GPIOA, GPIO_PIN_5)
3. 用示波器观察引脚电平

**预期结果**：
引脚电平应该翻转

**实际结果**：
引脚电平保持不变

**环境信息**：
- 硬件：STM32F407VG
- 固件版本：v1.0
- HAL库版本：1.7.0

Assignee：分配给负责人
Labels：添加标签（如：driver, gpio, critical） ```

步骤3：Sprint规划¶

3.1 创建Sprint¶

进入Backlog视图
点击左侧菜单"Backlog"
创建Sprint
点击"Create sprint"
Sprint自动命名（Sprint 1, Sprint 2...）
可自定义Sprint名称
设置Sprint目标
点击Sprint名称旁的"..."
选择"Edit sprint"

填写信息：

Sprint name: Sprint 1 - 驱动基础功能
Duration: 2 weeks
Start date: 2026-03-10
End date: 2026-03-24
Sprint goal: 完成GPIO和UART驱动的基本功能实现

3.2 规划Sprint内容¶

从Backlog拖拽Issue到Sprint
在Backlog中找到要添加的Issue
拖拽到Sprint区域
或点击Issue，选择"Move to sprint"
Sprint容量规划
查看团队速率（Velocity）
根据历史数据估算Sprint容量

示例：

团队规模：5人
每人每天可用时间：6小时
Sprint时长：10个工作日
总容量：5人 × 6小时 × 10天 = 300小时
或：约60个Story Points（假设1点=5小时）

平衡工作负载
查看每个成员的分配情况
确保工作量均衡
考虑技能匹配

3.3 启动Sprint¶

检查Sprint准备度
Sprint目标明确
Issue定义清晰
工作量估算合理
任务已分配
团队成员理解任务
启动Sprint
点击"Start sprint"
确认Sprint信息
点击"Start"

预期结果： - Sprint状态变为"Active" - Issue移动到Active Sprint - 看板显示Sprint内容

步骤4：使用看板管理工作流¶

4.1 理解看板布局¶

Scrum Board默认包含三列：

┌─────────────┬─────────────┬─────────────┐
│   To Do     │ In Progress │    Done     │
├─────────────┼─────────────┼─────────────┤
│  待开始的   │  进行中的   │  已完成的   │
│   任务      │    任务     │    任务     │
└─────────────┴─────────────┴─────────────┘

4.2 自定义看板列¶

添加新列
点击看板右上角"..."
选择"Board settings"
进入"Columns"
点击"Add column"

添加列：

- Code Review（代码审查）
- Testing（测试中）
- Ready for Deploy（待部署）

配置列映射
将工作流状态映射到列

示例映射：

To Do → To Do
In Progress → In Progress
Code Review → Code Review
Testing → Testing
Done → Done

设置WIP限制（可选）
为每列设置最大Issue数量
防止工作堆积

示例：

In Progress: Max 5
Code Review: Max 3
Testing: Max 4

4.3 移动Issue¶

拖拽移动
直接拖拽Issue卡片到目标列
系统自动更新Issue状态
快速操作
点击Issue卡片
在详情页面更改Status
或使用快捷键
批量操作
选中多个Issue（Ctrl+点击）
右键选择"Bulk change"
批量更新状态、分配人等

4.4 使用泳道（Swimlanes）¶

泳道可以按不同维度组织Issue。

配置泳道
Board settings → Swimlanes
选择泳道类型：
- By Assignee（按分配人）
- By Epic（按Epic）
- By Priority（按优先级）
- Custom（自定义JQL查询）

示例：按Epic分组

┌─ Epic: 设备驱动模块开发 ─────────────┐
│ To Do  │ In Progress │ Done         │
│ Story1 │ Story2      │ Story3       │
└──────────────────────────────────────┘
┌─ Epic: 通信协议实现 ─────────────────┐
│ To Do  │ In Progress │ Done         │
│ Story4 │             │ Story5       │
└──────────────────────────────────────┘

4.5 过滤和搜索¶

快速过滤
使用看板顶部的过滤器
按分配人、Epic、标签等过滤
JQL搜索
点击"Search"
使用JQL（Jira Query Language）

示例查询：

project = EFD AND assignee = currentUser() AND status != Done

（查找当前用户未完成的任务）

步骤5：Sprint执行与跟踪¶

5.1 每日站会（Daily Standup）¶

使用Jira支持每日站会：

查看团队进度
打开Active Sprint看板
查看每个成员的任务状态
站会三问
昨天完成了什么？（查看Done列）
今天计划做什么？（查看In Progress列）
遇到什么阻碍？（查看Blocked标签）
更新任务状态
团队成员实时更新Issue状态
添加评论记录进展
标记阻碍（添加"Blocked"标签）

5.2 记录工作时间¶

记录时间
打开Issue详情
点击"Log work"

填写信息：

Time spent: 2h
Date started: 2026-03-11 09:00
Work description: 完成GPIO初始化函数的实现和单元测试

查看时间统计
Issue详情页显示：
- Original Estimate（原始估算）
- Time Spent（已花费时间）
- Remaining Estimate（剩余估算）
时间跟踪最佳实践
每天记录工作时间
及时更新剩余估算
如果超出估算，及时沟通

5.3 处理阻碍¶

标记阻碍
添加"Blocked"标签
在评论中说明阻碍原因
@提及相关人员

阻碍类型示例

技术阻碍：
- 缺少硬件设备
- 第三方库问题
- 技术难题需要研究

流程阻碍：
- 等待代码审查
- 等待测试环境
- 等待需求澄清

人员阻碍：
- 关键人员请假
- 技能不匹配
- 工作负载过重

解决阻碍
在每日站会中讨论
分配责任人跟进
记录解决方案
移除"Blocked"标签

5.4 Sprint中期调整¶

添加紧急任务
创建新Issue
标记为"Urgent"
添加到当前Sprint
评估对Sprint目标的影响
移除任务
如果任务无法完成
移回Backlog
记录原因
在Sprint回顾中讨论
调整优先级
根据实际情况调整
与Product Owner沟通
更新看板顺序

步骤6：报表分析¶

6.1 燃尽图（Burndown Chart）¶

燃尽图显示Sprint中剩余工作量的趋势。

查看燃尽图
进入"Reports" → "Burndown Chart"
查看图表

理解燃尽图

Story Points
↑
60│╲
50│ ╲
40│  ╲___
30│      ╲___
20│          ╲___
10│              ╲___
0 └──────────────────→ Days
  1  3  5  7  9  11 13

灰色线：理想燃尽线
蓝色线：实际燃尽线

分析燃尽图
理想情况：实际线接近理想线
进度超前：实际线在理想线下方
进度落后：实际线在理想线上方
平台期：实际线水平，可能有阻碍

常见问题

问题1：燃尽图上升
原因：Sprint中添加了新任务
应对：评估是否影响Sprint目标

问题2：燃尽图平台
原因：任务被阻塞或无人处理
应对：每日站会中识别和解决

问题3：最后冲刺
原因：任务集中在Sprint末期完成
应对：改进任务分解和时间估算

6.2 速率图（Velocity Chart）¶

速率图显示团队在多个Sprint中的完成能力。

查看速率图
Reports → Velocity Chart

理解速率图

Story Points
↑
60│    ┌──┐
50│    │  │ ┌──┐
40│ ┌──┤  │ │  │ ┌──┐
30│ │  │  │ │  │ │  │
20│ │  │  │ │  │ │  │
10│ │  │  │ │  │ │  │
0 └─┴──┴──┴─┴──┴─┴──┴─→ Sprint
  S1  S2  S3  S4  S5

绿色：已完成
蓝色：已提交但未完成

计算平均速率

Sprint 1: 45 points
Sprint 2: 52 points
Sprint 3: 48 points
平均速率 = (45 + 52 + 48) / 3 = 48.3 points

使用速率规划
根据历史速率规划下个Sprint
考虑团队变化（人员增减、假期等）
预留缓冲（建议10-20%）

6.3 累积流图（Cumulative Flow Diagram）¶

累积流图显示不同状态的Issue数量随时间的变化。

查看累积流图
Reports → Cumulative Flow Diagram

理解累积流图

Issue Count
↑
50│         ╱Done
40│       ╱╱
30│     ╱╱ Testing
20│   ╱╱  In Progress
10│ ╱╱   To Do
0 └────────────────→ Time

不同颜色代表不同状态
带宽表示该状态的Issue数量

分析CFD
健康状态：各带宽稳定，平行上升
瓶颈：某个状态带宽增大（堆积）
流动性好：Done区域持续增长

6.4 控制图（Control Chart）¶

控制图显示Issue完成的周期时间。

查看控制图
Reports → Control Chart

关键指标

Cycle Time（周期时间）：
从"In Progress"到"Done"的时间

示例：
平均周期时间：3.5天
中位数：3天
85th百分位：5天

改进周期时间
减少WIP（在制品）
消除阻碍
优化工作流
提高自动化程度

步骤7：Sprint结束¶

7.1 Sprint评审（Sprint Review）¶

准备演示
筛选已完成的Issue
准备演示环境
邀请利益相关者
演示内容
展示完成的功能
运行实际代码
收集反馈
在Jira中记录
在Sprint页面添加评审记录
记录反馈意见
创建后续Issue（如有需要）

7.2 Sprint回顾（Sprint Retrospective）¶

回顾会议结构

1. 设定基调（5分钟）
2. 收集数据（10分钟）
3. 产生洞察（15分钟）
4. 决定行动（15分钟）
5. 结束（5分钟）

使用Jira记录
创建"Retrospective"页面（使用Confluence）
或在Sprint描述中添加回顾内容

回顾模板

## Sprint X 回顾

### 做得好的（Keep）
- 代码审查流程顺畅
- 每日站会高效
- 团队协作良好

### 需要改进的（Improve）
- 任务估算不够准确
- 测试环境不稳定
- 文档更新不及时

### 行动项（Action Items）
- [ ] 改进估算方法（负责人：张三，截止日期：下周五）
- [ ] 升级测试环境（负责人：李四，截止日期：本周三）
- [ ] 建立文档更新检查清单（负责人：王五，截止日期：明天）

创建改进Issue
将行动项转化为Issue
添加到下个Sprint
跟踪执行情况

7.3 完成Sprint¶

检查未完成Issue
查看未完成的Issue
决定处理方式：
- 移回Backlog
- 移到下个Sprint
- 关闭（如果不再需要）
完成Sprint
点击"Complete sprint"
选择未完成Issue的处理方式
确认完成
查看Sprint报告
自动生成Sprint报告
包含：
- 完成的Story Points
- 完成率
- 燃尽图
- 关键指标

预期结果： - Sprint状态变为"Closed" - 报告已生成 - 未完成Issue已处理 - 团队准备好下个Sprint

步骤8：高级功能¶

8.1 自动化规则（Automation）¶

Jira Automation可以自动化重复性任务。

创建自动化规则
Project settings → Automation
点击"Create rule"

示例规则1：自动分配Bug

触发器（Trigger）：
- Issue created

条件（Condition）：
- Issue type = Bug
- Priority = High

动作（Action）：
- Assign to: 技术负责人
- Send notification

示例规则2：自动关闭旧Issue

触发器：
- Scheduled (每周一)

条件：
- Status = In Progress
- Updated < 30 days ago

动作：
- Add comment: "此Issue已超过30天未更新，请确认状态"
- Send notification to assignee

示例规则3：Sprint自动提醒

触发器：
- Sprint started

动作：
- Send notification to team
- Message: "Sprint X 已开始，目标：{sprint.goal}"

8.2 集成Git仓库¶

将Jira与Git仓库集成，实现代码与Issue的关联。

集成GitHub
Project settings → Integrations
选择"GitHub"
授权连接
选择要关联的仓库

在提交中引用Issue

git commit -m "EFD-123: 实现GPIO初始化函数

- 添加GPIO_Init()函数
- 支持输入输出模式配置
- 添加参数验证
"

查看开发信息
在Issue详情页查看"Development"面板
显示：
- 关联的提交
- 分支
- Pull Request
- 构建状态

智能提交

# 自动转换Issue状态
git commit -m "EFD-123 #done 完成GPIO驱动实现"

# 添加工作时间
git commit -m "EFD-123 #time 2h 实现GPIO读写函数"

# 添加评论
git commit -m "EFD-123 #comment 已完成单元测试"

8.3 集成CI/CD¶

将Jira与CI/CD工具集成。

集成Jenkins
安装Jira插件
配置Jira连接
在构建中引用Issue

构建状态同步

// Jenkinsfile
pipeline {
    stages {
        stage('Build') {
            steps {
                // 构建代码
                sh 'make build'

                // 更新Jira
                jiraComment issueKey: 'EFD-123',
                            body: '构建成功 #${BUILD_NUMBER}'
            }
        }
    }
}

自动化部署流程

代码提交 → 触发构建 → 运行测试 → 更新Jira
↓
测试通过 → 部署到测试环境 → 更新Issue状态
↓
测试验证 → 部署到生产环境 → 关闭Issue

8.4 自定义字段¶

为特定需求添加自定义字段。

创建自定义字段
Project settings → Issue types
选择Issue type
点击"Add field"

嵌入式项目常用字段

字段名称：硬件平台
类型：Select List (single choice)
选项：
- STM32F4
- STM32F7
- ESP32
- NXP i.MX

字段名称：固件版本
类型：Text Field (single line)

字段名称：测试状态
类型：Select List
选项：
- 未测试
- 测试中
- 测试通过
- 测试失败

在Issue中使用
创建或编辑Issue时填写
可用于过滤和报表

步骤9：团队协作最佳实践¶

9.1 Issue描述规范¶

好的Issue描述应该包含：

## 背景
简要说明为什么需要这个功能/修复这个Bug

## 目标
明确要达成的目标

## 技术方案（可选）
- 方案概述
- 关键技术点
- 依赖关系

## 验收标准
- [ ] 标准1
- [ ] 标准2
- [ ] 标准3

## 测试计划
- 单元测试
- 集成测试
- 性能测试

## 参考资料
- 相关文档链接
- 参考代码

9.2 评论和协作¶

有效的评论

✅ 好的评论：
"已完成GPIO初始化函数的实现，代码已提交到feature/gpio分支。
单元测试覆盖率达到85%。请 @张三 进行代码审查。"

❌ 不好的评论：
"完成了"

使用@提及
@用户名：通知特定人员
@team：通知整个团队
在评论中提及相关人员

链接相关Issue

- Blocks: EFD-124（阻塞关系）
- Is blocked by: EFD-122（被阻塞）
- Relates to: EFD-125（相关）
- Duplicates: EFD-126（重复）

9.3 标签使用规范¶

建立统一的标签体系：

技术标签：
- driver（驱动）
- middleware（中间件）
- application（应用层）
- testing（测试）

优先级标签：
- critical（关键）
- urgent（紧急）
- nice-to-have（可选）

状态标签：
- blocked（阻塞）
- needs-review（需要审查）
- ready-for-test（待测试）

平台标签：
- stm32
- esp32
- linux

9.4 通知管理¶

配置通知偏好
个人设置 → Notifications
选择接收通知的场景：
- Issue分配给我
- 有人@我
- Issue状态变更
- 评论添加
避免通知疲劳
只订阅关键通知
使用过滤器
定期清理通知

团队通知规范

紧急问题：@提及 + Slack通知
一般问题：Jira评论
信息同步：每日站会

步骤10：Jira与其他工具集成¶

10.1 集成Confluence¶

Confluence是Atlassian的文档协作工具，与Jira深度集成。

启用Confluence
在Atlassian账号中添加Confluence
自动与Jira关联
在Jira中链接Confluence页面
打开Issue详情
点击"..."→"Link"→"Confluence page"
选择或创建页面

常见用途

需求文档：
- 详细的功能规格说明
- 架构设计文档
- API文档

会议记录：
- Sprint规划会议记录
- 回顾会议记录
- 技术讨论记录

知识库：
- 开发规范
- 部署指南
- 故障排查手册

Confluence宏（Macro）

Jira Issues宏：
在Confluence页面中嵌入Jira Issue列表

示例：
{jira:project=EFD|status=In Progress|max=10}

10.2 集成Slack¶

Slack是流行的团队沟通工具。

安装Jira for Slack
在Slack中搜索"Jira Cloud"应用
点击"Add to Slack"
授权连接

配置通知

在Slack频道中：
/jira connect
/jira subscribe EFD

配置通知规则：
/jira subscribe EFD filter "priority = High"

Slack中的Jira操作

创建Issue：
/jira create

查看Issue：
/jira EFD-123

搜索Issue：
/jira search assignee = currentUser()

转换状态：
在Issue通知下点击按钮直接转换状态

通知示例

📋 新Issue创建
EFD-145: 实现I2C驱动
优先级：High
分配给：@张三
[查看详情] [开始工作] [分配给我]

10.3 集成测试工具¶

集成TestRail
测试用例管理工具
将测试结果同步到Jira
在Issue中查看测试覆盖率
集成Zephyr
Jira原生测试管理插件
创建测试用例
执行测试
生成测试报告

测试工作流

开发完成 → 创建测试用例 → 执行测试
↓
测试通过 → 更新Issue状态 → 准备发布
↓
测试失败 → 创建Bug → 分配给开发者

实战案例：嵌入式项目完整流程¶

让我们通过一个完整的案例来演示Jira在嵌入式项目中的应用。

案例背景¶

项目：智能温控器固件开发
团队：5人（1个Product Owner，4个开发者）
周期：4个Sprint，每个Sprint 2周
技术栈：STM32F4 + FreeRTOS + MQTT

Sprint 1：基础架构搭建¶

Sprint目标：完成项目基础架构和核心驱动

Epic创建

Epic 1: 硬件驱动层
Epic 2: RTOS任务管理
Epic 3: 通信协议
Epic 4: 用户界面

Story分解

Epic 1下的Story：
- EFD-1: 实现温度传感器驱动（DHT22）
- EFD-2: 实现显示屏驱动（OLED）
- EFD-3: 实现按键驱动
- EFD-4: 实现继电器控制

Task分解（以EFD-1为例）

EFD-1: 实现温度传感器驱动
├─ EFD-1.1: 研究DHT22通信协议（2h）
├─ EFD-1.2: 实现单总线时序（4h）
├─ EFD-1.3: 实现数据解析（3h）
├─ EFD-1.4: 编写驱动API（2h）
├─ EFD-1.5: 编写单元测试（3h）
└─ EFD-1.6: 硬件测试验证（2h）

总计：16h（约3个Story Points）

Sprint规划

Sprint 1容量：40 Story Points

选择的Story：
- EFD-1: 温度传感器驱动（3点）
- EFD-2: 显示屏驱动（5点）
- EFD-3: 按键驱动（2点）
- EFD-5: FreeRTOS移植（8点）
- EFD-6: 任务框架搭建（5点）
- EFD-7: 项目构建系统（3点）

总计：26点（预留缓冲）

执行过程

Day 1-2: 
- 开发者A：开始EFD-1（温度传感器）
- 开发者B：开始EFD-5（FreeRTOS移植）
- 开发者C：开始EFD-7（构建系统）
- 开发者D：开始EFD-3（按键驱动）

Day 3-5:
- EFD-3完成，开发者D开始EFD-2（显示屏）
- EFD-7完成，开发者C协助EFD-5
- EFD-1遇到问题：DHT22时序不稳定
  → 添加"Blocked"标签
  → 在站会中讨论
  → 决定使用DMA+定时器方案

Day 6-8:
- EFD-1问题解决，继续开发
- EFD-5完成，开始EFD-6
- EFD-2进展顺利

Day 9-10:
- 所有Story完成
- 代码审查
- 集成测试

Sprint结束

完成情况：
- 计划：26点
- 完成：26点
- 完成率：100%

燃尽图：接近理想线

回顾要点：
✅ 做得好：
- 团队协作顺畅
- 问题快速解决
- 代码质量高

⚠️ 需改进：
- 硬件时序问题估算不足
- 需要更多硬件测试时间

📋 行动项：
- 下个Sprint预留硬件调试时间
- 建立硬件问题知识库

Sprint 2-4：功能迭代¶

Sprint 2：通信协议实现
Sprint 3：温控逻辑和UI
Sprint 4：测试和优化

每个Sprint遵循相同的流程： 1. Sprint规划 2. 每日站会 3. 持续开发和测试 4. Sprint评审 5. Sprint回顾

常见问题与解决方案¶

Q1：如何处理频繁变化的需求？¶

问题：客户需求经常变化，导致Sprint计划被打乱。

解决方案： 1. 使用Kanban模式 - 更适合需求频繁变化的场景 - 持续流动，无固定Sprint

设置变更控制
Sprint开始后不接受新需求
紧急需求评估影响后再决定
缩短Sprint周期
从2周改为1周
更快响应变化
建立需求缓冲区
在Backlog中维护优先级队列
每个Sprint预留10-20%容量应对变更

Q2：团队成员不愿意更新Jira怎么办？¶

问题：开发者觉得更新Jira浪费时间，不愿意记录。

解决方案： 1. 简化流程 - 减少必填字段 - 使用模板快速创建 - 启用快捷键

展示价值
用数据说话（速率图、燃尽图）
展示如何帮助团队改进
强调对个人绩效评估的帮助
自动化
Git提交自动更新Issue
CI/CD自动更新状态
减少手动操作
建立习惯
每日站会前更新
代码审查时检查
定期提醒

Q3：如何估算Story Points？¶

问题：团队对Story Points估算不准确。

解决方案： 1. 使用Planning Poker - 团队一起估算 - 讨论差异 - 达成共识

建立基准Story

1点：简单配置修改（1-2小时）
3点：小功能实现（半天）
5点：中等功能（1天）
8点：复杂功能（2天）
13点：大型功能（1周）

持续校准
每个Sprint回顾估算准确性
调整估算标准
记录经验教训
分解大Story
超过8点的Story应该分解
分解到可以在1-2天完成

Q4：如何管理技术债务？¶

问题：技术债务积累，影响开发速度。

解决方案： 1. 创建技术债务Epic

Epic: 技术债务清理
├─ Story: 重构GPIO驱动
├─ Story: 优化内存使用
├─ Story: 更新过时依赖
└─ Story: 补充单元测试

每个Sprint分配容量
20%的Sprint容量用于技术债务
不能全部用于新功能
使用标签跟踪
添加"tech-debt"标签
定期审查和优先级排序
量化影响
记录技术债务导致的问题
评估修复的收益
优先处理高影响的债务

Q5：如何处理跨团队依赖？¶

问题：项目依赖其他团队，导致阻塞。

解决方案： 1. 使用Issue链接

EFD-123 is blocked by HW-456
（我们的Issue被硬件团队的Issue阻塞）

建立依赖看板
创建专门的看板跟踪依赖
定期同步状态
提前识别依赖
Sprint规划时识别所有依赖
提前与相关团队沟通
建立缓冲时间
建立协作机制
定期跨团队会议
共享Jira项目
使用@提及通知

性能优化技巧¶

1. 使用过滤器（Filters）¶

创建常用的过滤器，快速访问：

我的待办任务：
assignee = currentUser() AND status != Done

本周到期：
duedate >= startOfWeek() AND duedate <= endOfWeek()

高优先级Bug：
type = Bug AND priority in (High, Highest) AND status != Done

当前Sprint：
sprint in openSprints() AND project = EFD

保存过滤器并添加到收藏夹。

2. 使用看板快捷键¶

C: 创建Issue
/: 快速搜索
G + D: 跳转到看板
G + B: 跳转到Backlog
.: 打开命令面板

3. 批量操作¶

选中多个Issue后： - 批量更新状态 - 批量分配 - 批量添加标签 - 批量移动到Sprint

4. 使用模板¶

创建Issue模板，快速填充常用字段：

Bug报告模板：
---
**问题描述**：

**复现步骤**：
1. 
2. 
3. 

**预期结果**：

**实际结果**：

**环境信息**：
- 硬件：
- 固件版本：
- 测试日期：

总结¶

通过本教程，我们学习了：

Jira基础
核心概念（Project、Issue、Epic、Sprint等）
Scrum vs Kanban的选择
项目创建和配置
Issue管理
创建和管理不同类型的Issue
使用Epic组织大型功能
Story和Task的分解
Sprint管理
Sprint规划和容量估算
Sprint执行和跟踪
每日站会和阻碍处理
看板使用
自定义看板列和泳道
工作流管理
WIP限制
报表分析
燃尽图：跟踪Sprint进度
速率图：评估团队能力
累积流图：识别瓶颈
控制图：优化周期时间
高级功能
自动化规则
Git集成
CI/CD集成
自定义字段
团队协作
Issue描述规范
评论和通知管理
标签使用规范
工具集成
Confluence文档协作
Slack团队沟通
测试工具集成
实战案例
完整的嵌入式项目流程
从规划到交付的全过程
最佳实践
- 常见问题解决方案
- 性能优化技巧
- 团队协作建议

下一步学习¶

完成本教程后，建议继续学习：

深入Jira高级功能
Jira Query Language (JQL)高级查询
自定义工作流设计
权限方案配置
插件开发
敏捷方法论
Scrum Master认证
敏捷教练技能
大规模敏捷（SAFe、LeSS）
项目管理工具对比
Azure DevOps
GitLab Issues
Linear
Monday.com
DevOps实践
CI/CD流水线设计
自动化测试
持续部署
监控和告警
团队管理
团队建设
冲突解决
绩效管理
远程团队协作

项目管理工具实践：Jira敏捷开发全流程¶

学习目标¶

前置要求¶

准备工作¶

软件准备¶

环境配置¶

Jira核心概念¶

基本概念¶

Scrum vs Kanban¶

步骤1：创建敏捷项目¶

1.1 创建Scrum项目¶

1.2 配置项目设置¶

步骤2：创建和管理Issue¶

2.1 创建Epic（史诗）¶

2.2 创建Story（用户故事）¶

2.3 创建Task（任务）¶

2.4 创建Bug¶

步骤3：Sprint规划¶

3.1 创建Sprint¶

3.2 规划Sprint内容¶

3.3 启动Sprint¶

步骤4：使用看板管理工作流¶

4.1 理解看板布局¶

4.2 自定义看板列¶

4.3 移动Issue¶

4.4 使用泳道（Swimlanes）¶

4.5 过滤和搜索¶

步骤5：Sprint执行与跟踪¶

5.1 每日站会（Daily Standup）¶

5.2 记录工作时间¶

5.3 处理阻碍¶

5.4 Sprint中期调整¶

步骤6：报表分析¶

6.1 燃尽图（Burndown Chart）¶

6.2 速率图（Velocity Chart）¶

6.3 累积流图（Cumulative Flow Diagram）¶

6.4 控制图（Control Chart）¶

步骤7：Sprint结束¶

7.1 Sprint评审（Sprint Review）¶

7.2 Sprint回顾（Sprint Retrospective）¶

7.3 完成Sprint¶

步骤8：高级功能¶

8.1 自动化规则（Automation）¶

8.2 集成Git仓库¶

8.3 集成CI/CD¶

8.4 自定义字段¶

步骤9：团队协作最佳实践¶

9.1 Issue描述规范¶

9.2 评论和协作¶

9.3 标签使用规范¶

9.4 通知管理¶

步骤10：Jira与其他工具集成¶

10.1 集成Confluence¶

10.2 集成Slack¶

10.3 集成测试工具¶

实战案例：嵌入式项目完整流程¶

案例背景¶

Sprint 1：基础架构搭建¶

Sprint 2-4：功能迭代¶

常见问题与解决方案¶

Q1：如何处理频繁变化的需求？¶

Q2：团队成员不愿意更新Jira怎么办？¶

Q3：如何估算Story Points？¶

Q4：如何管理技术债务？¶

Q5：如何处理跨团队依赖？¶

性能优化技巧¶

1. 使用过滤器（Filters）¶

2. 使用看板快捷键¶

3. 批量操作¶

4. 使用模板¶

总结¶

下一步学习¶

延伸阅读¶

官方文档¶

书籍推荐¶

在线资源¶

相关课程¶