完整项目实战演练：智能环境监测系统¶
项目概述¶
项目简介¶
本项目将带你完整经历一个嵌入式项目的全生命周期，从项目启动到最终交付。我们将开发一个**智能环境监测系统**，该系统能够实时监测室内环境参数（温度、湿度、空气质量、光照等），并通过云端平台进行数据分析和可视化展示。
这不仅是一个技术项目，更是一次完整的项目管理实践。你将学习如何： - 进行系统化的需求分析和管理 - 设计可扩展的系统架构 - 制定合理的项目计划和里程碑 - 组织团队协作和任务分配 - 实施敏捷开发流程 - 进行质量控制和测试验证 - 完成项目交付和文档编写
项目特点¶
- 真实场景：基于实际的物联网应用场景，具有商业价值
- 完整流程：覆盖项目管理的所有关键环节
- 敏捷实践：采用Scrum框架进行迭代开发
- 团队协作：模拟真实的团队协作场景
- 工具应用：使用主流的项目管理工具和方法
学习目标¶
完成本项目后，你将能够：
- 需求管理：掌握需求收集、分析、文档化和变更管理的方法
- 架构设计：能够设计分层、模块化的嵌入式系统架构
- 项目规划：制定合理的项目计划、里程碑和资源分配
- 敏捷开发：熟练应用Scrum框架进行迭代开发
- 团队协作：掌握团队沟通、任务分配和进度跟踪的技巧
- 质量控制：建立完整的测试体系和质量保证机制
- 风险管理：识别项目风险并制定应对策略
- 文档编写：编写规范的技术文档和项目文档
适用人群¶
- 有2年以上嵌入式开发经验的工程师
- 希望转型为技术管理者的开发人员
- 项目经理和技术负责人
- 创业团队的技术合伙人
技术栈和工具¶
硬件平台¶
| 组件 | 型号/规格 | 数量 | 用途 |
|---|---|---|---|
| 主控MCU | STM32F407VGT6 | 1 | 核心控制器 |
| 温湿度传感器 | DHT22 | 1 | 温湿度采集 |
| 空气质量传感器 | MQ-135 | 1 | 空气质量检测 |
| 光照传感器 | BH1750 | 1 | 光照强度检测 |
| WiFi模块 | ESP8266 | 1 | 网络连接 |
| OLED显示屏 | 0.96寸 128x64 | 1 | 本地显示 |
| 电源模块 | 5V/2A | 1 | 系统供电 |
软件技术栈¶
嵌入式端： - 开发语言：C语言 - RTOS：FreeRTOS - HAL库：STM32 HAL - 通信协议：MQTT、HTTP - 开发工具：STM32CubeIDE、Keil MDK
云端平台： - 后端：Python + Flask - 数据库：MySQL + InfluxDB（时序数据库） - 消息队列：MQTT Broker (Mosquitto) - 前端：Vue.js + ECharts - 部署：Docker + Nginx
项目管理工具¶
- 需求管理：Jira、Confluence
- 版本控制：Git + GitHub/GitLab
- CI/CD：Jenkins、GitHub Actions
- 文档协作：Markdown、Draw.io
- 沟通工具：Slack、钉钉、腾讯会议
阶段一：项目启动与需求分析（Week 1-2）¶
1.1 项目启动会议¶
会议目标¶
- 明确项目背景和商业价值
- 确定项目范围和边界
- 识别关键干系人
- 建立项目团队
项目背景¶
随着人们对室内环境质量的关注度提升，智能环境监测系统的市场需求日益增长。本项目旨在开发一款低成本、易部署的智能环境监测解决方案，面向家庭、办公室和小型商业场所。
商业价值¶
- 市场需求：室内空气质量监测市场年增长率超过20%
- 差异化优势：低成本、易安装、云端分析
- 盈利模式：硬件销售 + 云服务订阅
项目干系人¶
| 角色 | 姓名 | 职责 | 参与度 |
|---|---|---|---|
| 项目发起人 | 张总 | 提供资源和决策支持 | 低 |
| 产品经理 | 李明 | 需求定义和产品规划 | 高 |
| 技术负责人 | 王工 | 技术架构和团队管理 | 高 |
| 硬件工程师 | 赵工 | 硬件设计和调试 | 高 |
| 固件工程师 | 刘工 | 嵌入式软件开发 | 高 |
| 后端工程师 | 陈工 | 云端平台开发 | 高 |
| 测试工程师 | 周工 | 测试和质量保证 | 中 |
项目团队组建¶
团队结构：
团队协作原则： - 扁平化管理，快速决策 - 每日站会，同步进度 - 双周迭代，持续交付 - 开放沟通，及时反馈
1.2 需求收集¶
需求收集方法¶
- 用户访谈：与潜在用户深度交流，了解痛点
- 市场调研：分析竞品功能和用户评价
- 头脑风暴：团队内部讨论创新功能
- 原型演示：制作原型收集反馈
原始需求列表¶
功能需求： 1. 实时监测温度、湿度、空气质量、光照强度 2. 本地OLED显示屏显示当前数据 3. 数据通过WiFi上传到云端 4. 云端数据存储和历史查询 5. Web端数据可视化展示 6. 移动端App查看（可选） 7. 异常数据告警通知 8. 数据导出功能 9. 多设备管理 10. 用户权限管理
非功能需求： 1. 数据采集频率：每分钟一次 2. 数据上传延迟：< 5秒 3. 系统可用性：99% 4. 设备功耗：< 2W 5. 成本控制：硬件成本 < 100元 6. 易用性：5分钟内完成配置
1.3 需求分析与优先级划分¶
MoSCoW优先级分析¶
Must Have（必须有）- MVP核心功能： - M1: 温湿度实时监测 - M2: 本地显示屏显示 - M3: WiFi数据上传 - M4: 云端数据存储 - M5: Web端数据查看
Should Have（应该有）- 重要功能： - S1: 空气质量监测 - S2: 光照强度监测 - S3: 历史数据查询 - S4: 数据可视化图表 - S5: 异常告警
Could Have（可以有）- 增值功能： - C1: 移动端App - C2: 数据导出 - C3: 多设备管理 - C4: 数据分析报告
Won't Have（暂不实现）： - W1: 语音控制 - W2: AI预测分析 - W3: 第三方平台集成
用户故事编写¶
Epic 1: 环境数据采集
作为 设备用户
我想要 实时监测室内环境参数
以便于 了解当前环境状况
验收标准：
- 能够采集温度、湿度、空气质量、光照数据
- 采集频率为每分钟一次
- 数据精度符合传感器规格
- 采集失败时有错误提示
Epic 2: 数据显示
作为 设备用户
我想要 在本地屏幕上看到当前数据
以便于 无需联网即可查看环境状况
验收标准：
- OLED屏幕显示温度、湿度、空气质量
- 数据每分钟更新一次
- 显示清晰易读
- 包含WiFi连接状态指示
Epic 3: 云端数据上传
Epic 4: Web端数据展示
1.4 需求文档编写¶
需求规格说明书（SRS）结构¶
# 智能环境监测系统需求规格说明书 v1.0
## 1. 引言
### 1.1 目的
### 1.2 范围
### 1.3 定义、缩写和术语
### 1.4 参考资料
## 2. 总体描述
### 2.1 产品前景
### 2.2 产品功能
### 2.3 用户特征
### 2.4 约束条件
### 2.5 假设和依赖
## 3. 具体需求
### 3.1 功能需求
#### 3.1.1 数据采集模块
#### 3.1.2 本地显示模块
#### 3.1.3 网络通信模块
#### 3.1.4 云端服务模块
#### 3.1.5 Web展示模块
### 3.2 非功能需求
#### 3.2.1 性能需求
#### 3.2.2 可靠性需求
#### 3.2.3 可用性需求
#### 3.2.4 安全性需求
#### 3.2.5 可维护性需求
### 3.3 接口需求
#### 3.3.1 硬件接口
#### 3.3.2 软件接口
#### 3.3.3 通信接口
## 4. 附录
### 4.1 用户故事列表
### 4.2 原型设计
### 4.3 数据字典
关键需求详细说明¶
FR-001: 温湿度数据采集
优先级：Must Have
描述：系统应能够通过DHT22传感器采集环境温湿度数据
前置条件：传感器正确连接并初始化成功
输入：无（自动采集）
处理：
1. 每60秒触发一次采集
2. 读取DHT22传感器数据
3. 验证数据有效性
4. 存储到本地缓冲区
输出：温度值（-40~80°C，精度±0.5°C）
湿度值（0~100%RH，精度±2%RH）
异常处理：
- 传感器无响应：重试3次，失败后记录错误
- 数据校验失败：丢弃本次数据，等待下次采集
验收标准：
- 采集成功率 > 99%
- 数据精度符合传感器规格
- 采集周期误差 < 1秒
NFR-001: 系统响应时间
类别：性能需求
描述：系统各模块的响应时间要求
指标：
- 传感器数据采集：< 2秒
- 本地显示更新：< 1秒
- 数据上传延迟：< 5秒
- Web页面加载：< 3秒
- API响应时间：< 500ms
测试方法：
- 使用性能测试工具测量
- 在正常负载下测试
- 记录95百分位响应时间
阶段二：系统架构设计（Week 3-4）¶
2.1 系统架构设计¶
整体架构¶
graph TB
subgraph "设备端"
A[传感器层] --> B[数据采集层]
B --> C[业务逻辑层]
C --> D[通信层]
C --> E[显示层]
end
subgraph "云端"
F[MQTT Broker] --> G[数据接收服务]
G --> H[数据存储层]
H --> I[API服务层]
I --> J[Web前端]
end
D -->|MQTT| F
subgraph "数据库"
H --> K[(MySQL)]
H --> L[(InfluxDB)]
end设备端架构设计¶
分层架构：
+----------------------------------+
| 应用层 (Application) |
| - 业务逻辑 |
| - 数据处理 |
| - 状态管理 |
+----------------------------------+
| 中间件层 (Middleware) |
| - MQTT客户端 |
| - JSON解析 |
| - 任务调度 |
+----------------------------------+
| 驱动层 (Drivers) |
| - 传感器驱动 |
| - WiFi驱动 |
| - OLED驱动 |
+----------------------------------+
| HAL层 (Hardware) |
| - GPIO |
| - I2C |
| - UART |
| - Timer |
+----------------------------------+
模块划分：
- 传感器管理模块
- DHT22温湿度传感器驱动
- MQ-135空气质量传感器驱动
- BH1750光照传感器驱动
-
传感器数据校准和滤波
-
数据采集模块
- 定时采集任务
- 数据缓冲管理
-
数据有效性验证
-
网络通信模块
- WiFi连接管理
- MQTT客户端
- 数据上传队列
-
断线重连机制
-
本地显示模块
- OLED驱动
- UI界面渲染
-
状态指示
-
系统管理模块
- 配置管理
- 日志记录
- 错误处理
- 看门狗
云端架构设计¶
微服务架构：
+------------------+ +------------------+ +------------------+
| MQTT Broker | | 数据接收服务 | | API服务 |
| (Mosquitto) |---->| (Python) |---->| (Flask) |
+------------------+ +------------------+ +------------------+
| |
v v
+------------------+ +------------------+
| InfluxDB | | MySQL |
| (时序数据) | | (元数据) |
+------------------+ +------------------+
|
v
+------------------+
| Web前端 |
| (Vue.js) |
+------------------+
服务模块：
- MQTT Broker
- 消息订阅/发布
- QoS保证
-
持久化会话
-
数据接收服务
- MQTT消息订阅
- 数据解析和验证
-
数据存储
-
API服务
- RESTful API
- 用户认证
- 数据查询
-
告警管理
-
Web前端
- 实时数据展示
- 历史数据图表
- 设备管理
- 用户设置
2.2 数据模型设计¶
设备端数据结构¶
// 传感器数据结构
typedef struct {
float temperature; // 温度 (°C)
float humidity; // 湿度 (%RH)
uint16_t air_quality; // 空气质量 (PPM)
uint16_t light; // 光照强度 (Lux)
uint32_t timestamp; // 时间戳
uint8_t valid; // 数据有效标志
} SensorData_t;
// 设备配置结构
typedef struct {
char device_id[32]; // 设备ID
char wifi_ssid[32]; // WiFi SSID
char wifi_password[64]; // WiFi密码
char mqtt_server[64]; // MQTT服务器地址
uint16_t mqtt_port; // MQTT端口
char mqtt_topic[64]; // MQTT主题
uint16_t sample_interval; // 采样间隔(秒)
} DeviceConfig_t;
// 系统状态结构
typedef struct {
uint8_t wifi_connected; // WiFi连接状态
uint8_t mqtt_connected; // MQTT连接状态
uint8_t sensor_status; // 传感器状态
uint32_t uptime; // 运行时间
uint32_t error_count; // 错误计数
} SystemStatus_t;
云端数据模型¶
MySQL数据库表设计：
-- 设备表
CREATE TABLE devices (
id INT PRIMARY KEY AUTO_INCREMENT,
device_id VARCHAR(32) UNIQUE NOT NULL,
device_name VARCHAR(64),
location VARCHAR(128),
user_id INT,
created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
updated_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
status ENUM('online', 'offline', 'error') DEFAULT 'offline',
INDEX idx_user_id (user_id),
INDEX idx_device_id (device_id)
);
-- 用户表
CREATE TABLE users (
id INT PRIMARY KEY AUTO_INCREMENT,
username VARCHAR(32) UNIQUE NOT NULL,
email VARCHAR(128) UNIQUE NOT NULL,
password_hash VARCHAR(128) NOT NULL,
created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
last_login TIMESTAMP,
INDEX idx_username (username),
INDEX idx_email (email)
);
-- 告警规则表
CREATE TABLE alert_rules (
id INT PRIMARY KEY AUTO_INCREMENT,
device_id VARCHAR(32) NOT NULL,
parameter VARCHAR(32) NOT NULL, -- temperature, humidity, etc.
condition VARCHAR(16) NOT NULL, -- >, <, =, !=
threshold FLOAT NOT NULL,
enabled BOOLEAN DEFAULT TRUE,
created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
INDEX idx_device_id (device_id)
);
InfluxDB数据模型：
measurement: sensor_data
tags:
- device_id
- location
fields:
- temperature (float)
- humidity (float)
- air_quality (integer)
- light (integer)
timestamp: nanosecond precision
2.3 接口设计¶
MQTT消息格式¶
设备上报数据：
{
"device_id": "ENV_MONITOR_001",
"timestamp": 1678886400,
"data": {
"temperature": 25.5,
"humidity": 60.2,
"air_quality": 150,
"light": 450
},
"status": {
"wifi_rssi": -65,
"battery": 100,
"uptime": 86400
}
}
Topic设计：
- 数据上报：devices/{device_id}/data
- 状态上报：devices/{device_id}/status
- 命令下发：devices/{device_id}/command
- 配置更新：devices/{device_id}/config
RESTful API设计¶
设备管理API：
GET /api/v1/devices # 获取设备列表
GET /api/v1/devices/{id} # 获取设备详情
POST /api/v1/devices # 注册新设备
PUT /api/v1/devices/{id} # 更新设备信息
DELETE /api/v1/devices/{id} # 删除设备
数据查询API：
GET /api/v1/devices/{id}/data/latest # 获取最新数据
GET /api/v1/devices/{id}/data/history # 获取历史数据
参数：
- start_time: 开始时间
- end_time: 结束时间
- interval: 数据间隔 (1m, 5m, 1h, 1d)
响应格式：
{
"code": 200,
"message": "success",
"data": {
"device_id": "ENV_MONITOR_001",
"timestamp": 1678886400,
"temperature": 25.5,
"humidity": 60.2,
"air_quality": 150,
"light": 450
}
}
2.4 技术选型与评估¶
技术选型决策矩阵¶
| 技术选项 | 成本 | 性能 | 易用性 | 社区支持 | 总分 | 决策 |
|---|---|---|---|---|---|---|
| RTOS选择 | ||||||
| FreeRTOS | 5 | 4 | 4 | 5 | 18 | ✓ 选择 |
| RT-Thread | 5 | 4 | 5 | 4 | 18 | - |
| Zephyr | 5 | 5 | 3 | 4 | 17 | - |
| 通信协议 | ||||||
| MQTT | 5 | 4 | 5 | 5 | 19 | ✓ 选择 |
| HTTP | 5 | 3 | 5 | 5 | 18 | - |
| CoAP | 4 | 5 | 3 | 3 | 15 | - |
| 数据库 | ||||||
| InfluxDB | 4 | 5 | 4 | 4 | 17 | ✓ 选择 |
| TimescaleDB | 4 | 5 | 3 | 3 | 15 | - |
| MongoDB | 5 | 4 | 4 | 5 | 18 | - |
评分标准：1-5分，5分最高
技术风险评估¶
风险1：WiFi连接稳定性 - 风险等级：高 - 影响：数据上传失败，用户体验差 - 应对措施： - 实现断线重连机制 - 本地数据缓存 - 连接状态监控 - 多次重试策略
风险2：传感器数据准确性 - 风险等级：中 - 影响：数据不准确，影响用户决策 - 应对措施： - 传感器校准 - 数据滤波算法 - 异常值检测 - 定期维护提醒
风险3：云端服务可用性 - 风险等级：中 - 影响：无法查看数据 - 应对措施： - 服务监控和告警 - 自动故障恢复 - 数据备份 - 负载均衡
阶段三：项目规划与任务分解（Week 3-4）¶
3.1 项目计划制定¶
项目里程碑¶
gantt
title 智能环境监测系统开发计划
dateFormat YYYY-MM-DD
section 需求与设计
需求分析 :done, req, 2024-01-01, 2w
架构设计 :done, arch, after req, 2w
section Sprint 1
硬件原型 :active, hw1, after arch, 2w
传感器驱动 :active, drv1, after arch, 2w
section Sprint 2
数据采集 :crit, app1, after hw1, 2w
本地显示 :app2, after hw1, 2w
section Sprint 3
网络通信 :crit, net1, after app1, 2w
云端服务 :crit, cloud1, after app1, 2w
section Sprint 4
Web前端 :web1, after cloud1, 2w
集成测试 :test1, after web1, 1w
section 发布
Beta测试 :beta, after test1, 1w
正式发布 :milestone, release, after beta, 1dSprint规划¶
Sprint 1: 基础功能开发（Week 5-6）
目标：完成硬件原型和基础传感器驱动
任务列表： - [ ] 硬件电路设计和PCB打样 - [ ] DHT22温湿度传感器驱动开发 - [ ] MQ-135空气质量传感器驱动开发 - [ ] BH1750光照传感器驱动开发 - [ ] OLED显示驱动开发 - [ ] 基础测试程序
交付物： - 硬件原型板 - 传感器驱动代码 - 单元测试报告
Sprint 2: 数据采集与显示（Week 7-8）
目标：实现数据采集和本地显示功能
任务列表： - [ ] FreeRTOS任务创建 - [ ] 数据采集任务实现 - [ ] 数据缓冲管理 - [ ] OLED UI设计和实现 - [ ] 数据显示任务 - [ ] 集成测试
交付物： - 数据采集模块 - 本地显示功能 - 功能演示视频
Sprint 3: 网络通信（Week 9-10）
目标：实现WiFi连接和MQTT数据上传
任务列表： - [ ] ESP8266 WiFi驱动 - [ ] WiFi连接管理 - [ ] MQTT客户端集成 - [ ] 数据上传任务 - [ ] 断线重连机制 - [ ] 云端MQTT Broker部署 - [ ] 数据接收服务开发
交付物： - 网络通信模块 - 云端数据接收服务 - 通信测试报告
Sprint 4: Web平台开发（Week 11-12）
目标：完成Web端数据展示平台
任务列表： - [ ] 数据库设计和部署 - [ ] RESTful API开发 - [ ] 用户认证模块 - [ ] Vue.js前端框架搭建 - [ ] 实时数据展示页面 - [ ] 历史数据图表 - [ ] 设备管理页面
交付物： - Web管理平台 - API文档 - 用户手册
3.2 任务分解（WBS）¶
工作分解结构¶
1. 智能环境监测系统
1.1 项目管理
1.1.1 项目启动
1.1.2 需求管理
1.1.3 进度跟踪
1.1.4 风险管理
1.2 硬件开发
1.2.1 电路设计
1.2.2 PCB设计
1.2.3 硬件调试
1.2.4 硬件测试
1.3 固件开发
1.3.1 驱动层开发
1.3.1.1 传感器驱动
1.3.1.2 WiFi驱动
1.3.1.3 显示驱动
1.3.2 应用层开发
1.3.2.1 数据采集
1.3.2.2 数据处理
1.3.2.3 网络通信
1.3.2.4 本地显示
1.3.3 系统集成
1.3.4 固件测试
1.4 云端开发
1.4.1 基础设施
1.4.1.1 服务器部署
1.4.1.2 数据库部署
1.4.1.3 MQTT Broker部署
1.4.2 后端服务
1.4.2.1 数据接收服务
1.4.2.2 API服务
1.4.2.3 用户认证
1.4.3 前端开发
1.4.3.1 页面设计
1.4.3.2 功能实现
1.4.3.3 前端测试
1.5 测试与质量保证
1.5.1 单元测试
1.5.2 集成测试
1.5.3 系统测试
1.5.4 性能测试
1.5.5 用户验收测试
1.6 文档编写
1.6.1 需求文档
1.6.2 设计文档
1.6.3 API文档
1.6.4 用户手册
1.6.5 维护手册
任务估算¶
使用三点估算法（PERT）：
| 任务 | 乐观 | 最可能 | 悲观 | 期望 | 负责人 |
|---|---|---|---|---|---|
| DHT22驱动开发 | 4h | 8h | 16h | 9h | 刘工 |
| MQ-135驱动开发 | 4h | 8h | 12h | 8h | 刘工 |
| BH1750驱动开发 | 3h | 6h | 12h | 7h | 刘工 |
| OLED驱动开发 | 6h | 12h | 20h | 13h | 刘工 |
| 数据采集模块 | 8h | 16h | 32h | 18h | 刘工 |
| WiFi通信模块 | 12h | 24h | 40h | 26h | 刘工 |
| MQTT客户端 | 8h | 16h | 24h | 16h | 刘工 |
| 云端API服务 | 16h | 32h | 48h | 32h | 陈工 |
| Web前端开发 | 24h | 40h | 64h | 42h | 陈工 |
3.3 资源分配¶
人力资源分配¶
Week 5-6 (Sprint 1):
硬件工程师（赵工）: 硬件设计和调试 - 80小时
固件工程师（刘工）: 传感器驱动开发 - 80小时
Week 7-8 (Sprint 2):
固件工程师（刘工）: 数据采集和显示 - 80小时
测试工程师（周工）: 测试用例编写 - 40小时
Week 9-10 (Sprint 3):
固件工程师（刘工）: 网络通信 - 80小时
后端工程师（陈工）: 云端服务 - 80小时
Week 11-12 (Sprint 4):
后端工程师（陈工）: Web开发 - 80小时
测试工程师（周工）: 集成测试 - 80小时
预算分配¶
| 类别 | 项目 | 数量 | 单价 | 小计 |
|---|---|---|---|---|
| 硬件 | 开发板 | 5 | 200 | 1,000 |
| 硬件 | 传感器套件 | 5 | 150 | 750 |
| 硬件 | PCB打样 | 10 | 50 | 500 |
| 软件 | 云服务器 | 3个月 | 500 | 1,500 |
| 软件 | 域名和SSL | 1年 | 200 | 200 |
| 人力 | 开发团队 | 12周 | 10,000 | 120,000 |
| 其他 | 测试和杂费 | - | - | 3,050 |
| 总计 | 127,000 |
阶段四：敏捷开发实施（Week 5-12）¶
4.1 Scrum框架实践¶
每日站会（Daily Standup）¶
时间：每天上午9:30，15分钟
参与人员：全体开发团队
会议格式： 每个人回答三个问题： 1. 昨天完成了什么？ 2. 今天计划做什么？ 3. 遇到了什么阻碍？
示例记录：
日期：2024-01-15
参与人：王工、赵工、刘工、陈工、周工
刘工：
- 昨天：完成了DHT22驱动开发和单元测试
- 今天：开始MQ-135驱动开发
- 阻碍：MQ-135数据手册中文版缺失，需要英文版
陈工：
- 昨天：完成了MQTT Broker部署和配置
- 今天：开发数据接收服务
- 阻碍：无
周工：
- 昨天：编写了传感器驱动测试用例
- 今天：执行DHT22驱动测试
- 阻碍：缺少测试硬件，需要赵工提供
行动项：
- 王工协助刘工获取MQ-135英文数据手册
- 赵工为周工准备测试硬件
Sprint计划会议（Sprint Planning）¶
时间：每个Sprint开始时，2-4小时
目标： - 确定Sprint目标 - 选择用户故事 - 分解任务 - 估算工作量
Sprint 1计划会议记录：
# Sprint 1 计划会议
日期：2024-01-08
参与人：全体团队
Sprint周期：2024-01-08 至 2024-01-21 (2周)
## Sprint目标
完成硬件原型和基础传感器驱动开发
## 选定的用户故事
### US-001: 温湿度数据采集
故事点：8
优先级：Must Have
验收标准：
- 能够通过DHT22采集温湿度数据
- 采集精度符合传感器规格
- 采集周期可配置
任务分解：
- [8h] DHT22驱动开发 - 刘工
- [4h] 数据校验算法 - 刘工
- [4h] 单元测试 - 周工
### US-002: 空气质量监测
故事点：5
优先级：Should Have
验收标准：
- 能够通过MQ-135采集空气质量数据
- 数据转换为PPM值
- 提供校准接口
任务分解：
- [8h] MQ-135驱动开发 - 刘工
- [4h] ADC采样和转换 - 刘工
- [3h] 单元测试 - 周工
### US-003: 光照强度检测
故事点：3
优先级：Should Have
验收标准：
- 能够通过BH1750采集光照数据
- 数据单位为Lux
- I2C通信稳定
任务分解：
- [6h] BH1750驱动开发 - 刘工
- [2h] I2C通信调试 - 刘工
- [2h] 单元测试 - 周工
## 容量规划
团队总容量：160小时 (2人 × 80小时)
已分配：54小时
缓冲：106小时（用于硬件调试和问题解决）
## 风险识别
1. 传感器数据手册理解困难 - 中等风险
2. I2C总线冲突 - 低风险
3. 硬件PCB延期 - 高风险
## 完成定义（Definition of Done）
- 代码通过Code Review
- 单元测试覆盖率 > 80%
- 功能测试通过
- 代码提交到主分支
- 文档更新完成
Sprint评审会议（Sprint Review）¶
时间：每个Sprint结束时，1-2小时
目标： - 演示完成的功能 - 收集反馈 - 更新产品待办列表
Sprint 1评审会议记录：
# Sprint 1 评审会议
日期：2024-01-21
参与人：全体团队 + 产品经理
## 完成情况
### 已完成的用户故事
✅ US-001: 温湿度数据采集 (8点)
✅ US-002: 空气质量监测 (5点)
✅ US-003: 光照强度检测 (3点)
总完成：16故事点
### 功能演示
1. DHT22温湿度采集演示
- 实时显示温度和湿度
- 数据精度符合预期
- 采集周期稳定
2. MQ-135空气质量演示
- 显示PPM值
- 对烟雾有明显响应
- 需要进一步校准
3. BH1750光照检测演示
- 光照强度实时变化
- 数据准确
- I2C通信稳定
## 反馈收集
产品经理反馈：
- 温湿度数据很准确，符合预期
- 空气质量传感器需要校准方案
- 建议增加传感器故障检测
技术反馈：
- DHT22偶尔读取失败，需要重试机制
- MQ-135预热时间较长，需要提示用户
- 考虑增加数据滤波算法
## 下一步计划
- Sprint 2重点：数据采集任务和本地显示
- 增加传感器故障检测功能
- 实现数据滤波算法
Sprint回顾会议（Sprint Retrospective）¶
时间：每个Sprint结束后，1小时
目标： - 回顾Sprint过程 - 识别改进点 - 制定行动计划
Sprint 1回顾会议记录：
# Sprint 1 回顾会议
日期：2024-01-21
参与人：开发团队
## 做得好的地方 (Keep)
- 每日站会准时高效
- 代码审查质量高
- 团队协作顺畅
- 文档及时更新
## 需要改进的地方 (Improve)
- 任务估算偏乐观，实际耗时更长
- 硬件调试时间占用过多
- 测试环境搭建延迟
- 技术文档不够详细
## 遇到的问题 (Problems)
- PCB打样延期2天
- MQ-135数据手册理解困难
- I2C地址冲突导致调试延迟
- 测试硬件不足
## 行动计划 (Actions)
1. 任务估算增加20%缓冲时间 - 王工负责
2. 提前准备备用PCB - 赵工负责
3. 建立技术知识库 - 刘工负责
4. 采购额外测试硬件 - 周工负责
## 团队士气
😊😊😊😊😐 (4/5)
整体评价：团队合作良好，虽然遇到一些技术挑战，但都及时解决了。
4.2 开发流程实践¶
Git工作流¶
分支策略：
main (生产分支)
|
|-- develop (开发分支)
|
|-- feature/sensor-driver (功能分支)
|-- feature/data-collection
|-- feature/wifi-communication
|-- feature/web-frontend
|
|-- bugfix/dht22-retry (修复分支)
|-- bugfix/mqtt-reconnect
提交规范：
# 功能开发
git commit -m "feat(sensor): add DHT22 temperature sensor driver"
# Bug修复
git commit -m "fix(wifi): resolve connection timeout issue"
# 文档更新
git commit -m "docs(api): update MQTT message format"
# 代码重构
git commit -m "refactor(display): optimize OLED rendering performance"
# 测试相关
git commit -m "test(sensor): add unit tests for MQ-135 driver"
Pull Request流程：
- 创建功能分支
- 完成开发和自测
- 提交Pull Request
- Code Review（至少1人审核）
- 通过CI/CD测试
- 合并到develop分支
代码审查清单¶
## 代码审查清单
### 功能性
- [ ] 代码实现符合需求
- [ ] 边界条件处理正确
- [ ] 错误处理完善
- [ ] 日志记录充分
### 代码质量
- [ ] 命名清晰易懂
- [ ] 函数职责单一
- [ ] 代码复杂度合理
- [ ] 无重复代码
### 性能
- [ ] 无明显性能问题
- [ ] 内存使用合理
- [ ] 无内存泄漏
### 安全性
- [ ] 输入验证充分
- [ ] 无安全漏洞
- [ ] 敏感信息保护
### 测试
- [ ] 单元测试覆盖充分
- [ ] 测试用例合理
- [ ] 测试通过
### 文档
- [ ] 代码注释清晰
- [ ] API文档更新
- [ ] README更新
持续集成配置¶
GitHub Actions配置：
name: CI/CD Pipeline
on:
push:
branches: [ develop, main ]
pull_request:
branches: [ develop, main ]
jobs:
firmware-build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
- name: Setup ARM GCC
run: |
sudo apt-get update
sudo apt-get install gcc-arm-none-eabi
- name: Build Firmware
run: |
cd firmware
make clean
make all
- name: Run Unit Tests
run: |
cd firmware/tests
make test
- name: Upload Artifacts
uses: actions/upload-artifact@v2
with:
name: firmware
path: firmware/build/*.bin
backend-test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
- name: Setup Python
uses: actions/setup-python@v2
with:
python-version: '3.9'
- name: Install Dependencies
run: |
cd backend
pip install -r requirements.txt
- name: Run Tests
run: |
cd backend
pytest --cov=app tests/
- name: Code Coverage
run: |
cd backend
coverage report
coverage html
frontend-test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
- name: Setup Node.js
uses: actions/setup-node@v2
with:
node-version: '16'
- name: Install Dependencies
run: |
cd frontend
npm install
- name: Run Tests
run: |
cd frontend
npm run test:unit
- name: Build
run: |
cd frontend
npm run build
阶段五：测试与质量保证（Week 11-13）¶
5.1 测试策略¶
测试金字塔¶
单元测试示例¶
传感器驱动单元测试：
// test_dht22.c
#include "unity.h"
#include "dht22.h"
#include "mock_gpio.h"
void setUp(void) {
// 测试前准备
DHT22_Init();
}
void tearDown(void) {
// 测试后清理
}
// 测试正常读取
void test_DHT22_Read_Success(void) {
float temperature, humidity;
// 模拟传感器响应
mock_gpio_set_response(DHT22_VALID_DATA);
// 执行读取
DHT22_Status status = DHT22_Read(&temperature, &humidity);
// 验证结果
TEST_ASSERT_EQUAL(DHT22_OK, status);
TEST_ASSERT_FLOAT_WITHIN(0.1, 25.5, temperature);
TEST_ASSERT_FLOAT_WITHIN(0.1, 60.2, humidity);
}
// 测试超时处理
void test_DHT22_Read_Timeout(void) {
float temperature, humidity;
// 模拟超时
mock_gpio_set_timeout();
// 执行读取
DHT22_Status status = DHT22_Read(&temperature, &humidity);
// 验证错误处理
TEST_ASSERT_EQUAL(DHT22_TIMEOUT, status);
}
// 测试校验和错误
void test_DHT22_Read_ChecksumError(void) {
float temperature, humidity;
// 模拟校验和错误
mock_gpio_set_response(DHT22_INVALID_CHECKSUM);
// 执行读取
DHT22_Status status = DHT22_Read(&temperature, &humidity);
// 验证错误处理
TEST_ASSERT_EQUAL(DHT22_CHECKSUM_ERROR, status);
}
集成测试¶
MQTT通信集成测试：
# test_mqtt_integration.py
import pytest
import paho.mqtt.client as mqtt
import json
import time
class TestMQTTIntegration:
@pytest.fixture
def mqtt_client(self):
client = mqtt.Client()
client.connect("localhost", 1883, 60)
client.loop_start()
yield client
client.loop_stop()
client.disconnect()
def test_device_data_upload(self, mqtt_client):
"""测试设备数据上传"""
received_data = []
def on_message(client, userdata, msg):
data = json.loads(msg.payload)
received_data.append(data)
# 订阅主题
mqtt_client.subscribe("devices/+/data")
mqtt_client.on_message = on_message
# 模拟设备发送数据
test_data = {
"device_id": "TEST_001",
"timestamp": int(time.time()),
"data": {
"temperature": 25.5,
"humidity": 60.2
}
}
mqtt_client.publish(
"devices/TEST_001/data",
json.dumps(test_data)
)
# 等待消息接收
time.sleep(1)
# 验证
assert len(received_data) == 1
assert received_data[0]["device_id"] == "TEST_001"
assert received_data[0]["data"]["temperature"] == 25.5
系统测试用例¶
| 用例ID | 测试场景 | 前置条件 | 测试步骤 | 预期结果 |
|---|---|---|---|---|
| TC-001 | 设备启动 | 设备上电 | 1. 连接电源 2. 观察启动过程 |
1. OLED显示启动画面 2. 传感器初始化成功 3. WiFi连接成功 |
| TC-002 | 数据采集 | 设备正常运行 | 1. 等待1分钟 2. 观察数据更新 |
1. 温湿度数据更新 2. 数据显示在OLED上 3. 数据上传到云端 |
| TC-003 | 网络断开 | 设备正常运行 | 1. 断开WiFi 2. 等待5分钟 3. 恢复WiFi |
1. 显示网络断开状态 2. 本地继续采集 3. 重连后补传数据 |
| TC-004 | 异常告警 | 设备正常运行 | 1. 制造高温环境 2. 观察告警 |
1. 温度超过阈值 2. 发送告警通知 3. Web端显示告警 |
5.2 性能测试¶
性能指标¶
响应时间:
传感器读取: < 2秒
数据上传: < 5秒
API响应: < 500ms
页面加载: < 3秒
吞吐量:
并发设备数: 100+
每秒消息数: 1000+
API QPS: 500+
资源使用:
MCU内存: < 80%
MCU CPU: < 60%
服务器CPU: < 70%
服务器内存: < 80%
压力测试脚本¶
# load_test.py
from locust import HttpUser, task, between
import random
class WebUser(HttpUser):
wait_time = between(1, 3)
@task(3)
def get_latest_data(self):
device_id = f"ENV_MONITOR_{random.randint(1, 100):03d}"
self.client.get(f"/api/v1/devices/{device_id}/data/latest")
@task(2)
def get_history_data(self):
device_id = f"ENV_MONITOR_{random.randint(1, 100):03d}"
self.client.get(
f"/api/v1/devices/{device_id}/data/history",
params={
"start_time": "2024-01-01T00:00:00",
"end_time": "2024-01-02T00:00:00"
}
)
@task(1)
def get_device_list(self):
self.client.get("/api/v1/devices")
运行压力测试：
5.3 质量保证流程¶
缺陷管理¶
缺陷等级定义：
- P0 - 致命：系统崩溃、数据丢失、安全漏洞
- P1 - 严重：核心功能不可用、性能严重下降
- P2 - 一般：功能异常但有变通方案
- P3 - 轻微：UI问题、文档错误
缺陷处理流程：
graph LR
A[发现缺陷] --> B[创建Issue]
B --> C[分配处理]
C --> D[修复开发]
D --> E[代码审查]
E --> F[测试验证]
F --> G{通过?}
G -->|是| H[关闭Issue]
G -->|否| D缺陷报告模板：
## 缺陷描述
简要描述问题
## 复现步骤
1. 步骤1
2. 步骤2
3. 步骤3
## 预期结果
应该发生什么
## 实际结果
实际发生了什么
## 环境信息
- 固件版本：v1.0.0
- 硬件版本：v1.0
- 测试环境：实验室
## 附件
- 截图
- 日志文件
- 视频录屏
## 优先级
P1 - 严重
## 影响范围
影响所有设备的数据上传功能
测试报告¶
测试总结报告：
# 智能环境监测系统测试报告
## 测试概述
- 测试周期：2024-01-22 至 2024-02-05
- 测试人员：周工、刘工
- 测试环境：实验室 + 云端测试环境
## 测试范围
- 单元测试：传感器驱动、数据处理、网络通信
- 集成测试：设备端到云端完整流程
- 系统测试：功能测试、性能测试、兼容性测试
- 用户验收测试：真实场景测试
## 测试结果统计
### 测试用例执行情况
| 测试类型 | 计划 | 执行 | 通过 | 失败 | 阻塞 | 通过率 |
|---------|------|------|------|------|------|--------|
| 单元测试 | 120 | 120 | 118 | 2 | 0 | 98.3% |
| 集成测试 | 45 | 45 | 43 | 2 | 0 | 95.6% |
| 系统测试 | 80 | 80 | 76 | 3 | 1 | 95.0% |
| 性能测试 | 20 | 20 | 19 | 1 | 0 | 95.0% |
| **总计** | **265** | **265** | **256** | **8** | **1** | **96.6%** |
### 缺陷统计
| 严重程度 | 新增 | 已修复 | 遗留 | 修复率 |
|---------|------|--------|------|--------|
| P0 致命 | 0 | 0 | 0 | - |
| P1 严重 | 3 | 3 | 0 | 100% |
| P2 一般 | 8 | 7 | 1 | 87.5% |
| P3 轻微 | 12 | 10 | 2 | 83.3% |
| **总计** | **23** | **20** | **3** | **87.0%** |
## 主要问题
### 已修复的严重问题
1. **WiFi断线后无法重连** (P1)
- 原因：重连逻辑错误
- 修复：增加重连状态机
- 验证：通过
2. **MQTT消息丢失** (P1)
- 原因：QoS设置错误
- 修复：使用QoS 1
- 验证：通过
3. **Web页面加载超时** (P1)
- 原因：数据库查询未优化
- 修复：添加索引和缓存
- 验证：通过
### 遗留问题
1. **OLED显示偶尔闪烁** (P2)
- 影响：用户体验
- 计划：下个版本修复
2. **历史数据导出速度慢** (P3)
- 影响：大数据量导出
- 计划：优化查询算法
3. **移动端适配问题** (P3)
- 影响：小屏幕显示
- 计划：响应式优化
## 性能测试结果
### 响应时间
| 指标 | 目标 | 实际 | 状态 |
|------|------|------|------|
| 传感器读取 | < 2s | 1.2s | ✅ |
| 数据上传 | < 5s | 3.5s | ✅ |
| API响应 | < 500ms | 320ms | ✅ |
| 页面加载 | < 3s | 2.1s | ✅ |
### 并发性能
- 支持100个并发设备
- API QPS达到650
- 系统稳定运行24小时无异常
## 测试结论
系统整体质量良好，核心功能稳定可靠，性能指标达标。
建议修复遗留的P2问题后发布Beta版本。
## 建议
1. 增加自动化测试覆盖率
2. 建立性能监控机制
3. 完善错误日志收集
4. 增加用户反馈渠道
阶段六：项目交付与总结（Week 14）¶
6.1 交付物清单¶
硬件交付物¶
- 硬件原理图和PCB设计文件
- 物料清单（BOM）
- 硬件测试报告
- 硬件使用手册
软件交付物¶
- 固件源代码（GitHub仓库）
- 云端服务源代码（GitHub仓库）
- Web前端源代码（GitHub仓库）
- 编译和部署脚本
- 数据库初始化脚本
文档交付物¶
- 需求规格说明书 v1.0
- 系统设计文档 v1.0
- API接口文档 v1.0
- 用户使用手册 v1.0
- 运维部署手册 v1.0
- 测试报告 v1.0
- 项目总结报告 v1.0
6.2 部署指南¶
设备端部署¶
固件烧录步骤：
# 1. 安装依赖工具
sudo apt-get install gcc-arm-none-eabi openocd
# 2. 克隆代码仓库
git clone https://github.com/your-org/env-monitor-firmware.git
cd env-monitor-firmware
# 3. 配置设备参数
cp config.h.example config.h
# 编辑config.h，填写WiFi和MQTT配置
# 4. 编译固件
make clean
make all
# 5. 烧录固件
make flash
# 6. 查看串口输出
make monitor
设备配置：
// config.h
#define WIFI_SSID "Your_WiFi_SSID"
#define WIFI_PASSWORD "Your_WiFi_Password"
#define MQTT_SERVER "mqtt.example.com"
#define MQTT_PORT 1883
#define MQTT_CLIENT_ID "ENV_MONITOR_001"
#define SAMPLE_INTERVAL 60 // 采样间隔(秒)
云端部署¶
使用Docker Compose部署：
# docker-compose.yml
version: '3.8'
services:
mosquitto:
image: eclipse-mosquitto:2.0
ports:
- "1883:1883"
- "9001:9001"
volumes:
- ./mosquitto/config:/mosquitto/config
- ./mosquitto/data:/mosquitto/data
- ./mosquitto/log:/mosquitto/log
mysql:
image: mysql:8.0
environment:
MYSQL_ROOT_PASSWORD: your_password
MYSQL_DATABASE: env_monitor
ports:
- "3306:3306"
volumes:
- mysql_data:/var/lib/mysql
- ./init.sql:/docker-entrypoint-initdb.d/init.sql
influxdb:
image: influxdb:2.0
ports:
- "8086:8086"
environment:
INFLUXDB_DB: sensor_data
INFLUXDB_ADMIN_USER: admin
INFLUXDB_ADMIN_PASSWORD: your_password
volumes:
- influxdb_data:/var/lib/influxdb
backend:
build: ./backend
ports:
- "5000:5000"
environment:
MYSQL_HOST: mysql
MYSQL_USER: root
MYSQL_PASSWORD: your_password
INFLUXDB_HOST: influxdb
MQTT_HOST: mosquitto
depends_on:
- mysql
- influxdb
- mosquitto
frontend:
build: ./frontend
ports:
- "80:80"
depends_on:
- backend
volumes:
mysql_data:
influxdb_data:
部署命令：
# 1. 克隆代码
git clone https://github.com/your-org/env-monitor-cloud.git
cd env-monitor-cloud
# 2. 配置环境变量
cp .env.example .env
# 编辑.env文件
# 3. 启动服务
docker-compose up -d
# 4. 查看日志
docker-compose logs -f
# 5. 访问Web界面
# http://localhost
6.3 用户培训¶
培训计划¶
培训对象： - 设备使用人员 - 系统管理员 - 技术支持人员
培训内容：
- 设备使用培训（1小时）
- 设备安装和配置
- 数据查看和解读
- 常见问题处理
-
维护保养
-
系统管理培训（2小时）
- 云端平台使用
- 设备管理
- 用户管理
- 告警配置
-
数据导出
-
技术支持培训（4小时）
- 系统架构介绍
- 故障诊断方法
- 日志分析
- 性能优化
- 版本升级
用户手册目录¶
# 智能环境监测系统用户手册
## 第一章：快速入门
1.1 系统简介
1.2 设备开箱
1.3 快速配置
1.4 首次使用
## 第二章：设备使用
2.1 设备安装
2.2 WiFi配置
2.3 数据查看
2.4 参数设置
2.5 固件升级
## 第三章：Web平台
3.1 用户注册和登录
3.2 设备管理
3.3 实时数据查看
3.4 历史数据分析
3.5 告警设置
3.6 数据导出
## 第四章：常见问题
4.1 设备无法连接WiFi
4.2 数据不更新
4.3 告警不生效
4.4 Web页面无法访问
## 第五章：维护保养
5.1 传感器清洁
5.2 定期校准
5.3 固件更新
5.4 故障排查
## 附录
A. 技术参数
B. 错误代码表
C. 联系方式
6.4 项目总结¶
项目回顾会议¶
会议议程：
- 项目成果展示（30分钟）
- 功能演示
- 数据统计
-
用户反馈
-
目标达成情况（20分钟）
- 功能完成度
- 质量指标
-
进度和预算
-
经验教训（30分钟）
- 成功经验
- 遇到的挑战
-
改进建议
-
后续计划（20分钟）
- 产品迭代
- 市场推广
- 技术演进
项目指标总结¶
功能完成度：
| 功能模块 | 计划功能 | 完成功能 | 完成率 |
|---|---|---|---|
| 数据采集 | 4 | 4 | 100% |
| 本地显示 | 3 | 3 | 100% |
| 网络通信 | 5 | 5 | 100% |
| 云端服务 | 8 | 7 | 87.5% |
| Web前端 | 6 | 6 | 100% |
| 总计 | 26 | 25 | 96.2% |
质量指标：
| 指标 | 目标 | 实际 | 达成 |
|---|---|---|---|
| 代码覆盖率 | ≥80% | 85% | ✅ |
| 缺陷密度 | ≤5/KLOC | 3.2/KLOC | ✅ |
| 性能达标率 | 100% | 95% | ⚠️ |
| 用户满意度 | ≥80% | 85% | ✅ |
进度和成本：
| 项目 | 计划 | 实际 | 偏差 |
|---|---|---|---|
| 开发周期 | 12周 | 14周 | +2周 |
| 人力投入 | 960人时 | 1120人时 | +16.7% |
| 项目预算 | ¥127,000 | ¥135,000 | +6.3% |
经验教训¶
成功经验：
- 敏捷开发实践
- 双周迭代节奏合理
- 每日站会提高沟通效率
-
Sprint回顾促进持续改进
-
技术选型
- FreeRTOS稳定可靠
- MQTT协议适合物联网场景
-
Docker简化部署流程
-
团队协作
- 代码审查提高代码质量
- 文档及时更新减少沟通成本
-
技术分享促进知识传播
-
质量保证
- 自动化测试提高效率
- 持续集成及早发现问题
- 性能测试保证用户体验
遇到的挑战：
- 技术挑战
- WiFi稳定性问题花费较多时间
- 传感器数据准确性需要反复调试
-
云端性能优化超出预期
-
管理挑战
- 任务估算偏乐观，导致进度延期
- 需求变更影响开发节奏
-
跨团队协调需要改进
-
资源挑战
- 测试硬件不足影响测试进度
- 部分技术文档缺失增加学习成本
- 云服务器成本超出预算
改进建议：
- 项目管理
- 任务估算增加更多缓冲时间
- 建立更严格的需求变更流程
-
加强风险识别和应对
-
技术实践
- 提前进行技术预研
- 建立技术知识库
-
增加代码复用
-
团队建设
- 定期技术培训
- 建立导师制度
-
改善工作环境
-
工具和流程
- 引入更多自动化工具
- 优化CI/CD流程
- 完善文档模板
后续计划¶
产品迭代（v2.0）：
计划功能： - [ ] 移动端App开发 - [ ] 数据分析和预测 - [ ] 多设备联动 - [ ] 语音控制 - [ ] 第三方平台集成
市场推广：
- 参加物联网展会
- 发布技术博客和视频
- 寻找合作伙伴
- 开展试用活动
技术演进：
- 升级到更高性能的MCU
- 引入边缘计算能力
- 优化功耗设计
- 增强安全性
项目管理工具实践¶
Jira使用指南¶
项目配置¶
创建项目： 1. 选择Scrum模板 2. 设置项目名称：智能环境监测系统 3. 配置工作流：To Do → In Progress → Code Review → Testing → Done 4. 创建Sprint：Sprint 1-4
Issue类型配置： - Epic：大功能模块 - Story：用户故事 - Task：开发任务 - Bug：缺陷 - Sub-task：子任务
看板管理¶
Sprint看板示例：
To Do In Progress Code Review Testing Done
------- ----------- ----------- ------- ----
[Story] [Task] [Task] [Task] [Story]
US-001 DHT22驱动 WiFi模块 数据采集 US-005
8 SP 刘工 刘工 周工 完成
[Task] [Bug] [Task] [Task]
OLED驱动 #BUG-001 API测试 传感器驱动
刘工 刘工 周工 完成
[Story]
US-002
5 SP
燃尽图分析：
Story Points
|
40 |●
| ●
30 | ●
| ●
20 | ●
| ●
10 | ●
| ●
0 |________________●
Day1 Day3 Day5 Day7 Day9
理想线：直线下降
实际线：●连线
Confluence文档协作¶
文档结构¶
智能环境监测系统
├── 项目概述
│ ├── 项目背景
│ ├── 项目目标
│ └── 团队成员
├── 需求文档
│ ├── 功能需求
│ ├── 非功能需求
│ └── 用户故事
├── 设计文档
│ ├── 系统架构
│ ├── 数据模型
│ └── 接口设计
├── 开发文档
│ ├── 编码规范
│ ├── Git工作流
│ └── 环境搭建
├── 测试文档
│ ├── 测试计划
│ ├── 测试用例
│ └── 测试报告
└── 运维文档
├── 部署指南
├── 监控告警
└── 故障处理
Git协作最佳实践¶
分支命名规范¶
# 功能分支
feature/sensor-driver
feature/data-collection
feature/web-frontend
# 修复分支
bugfix/wifi-reconnect
bugfix/mqtt-timeout
# 发布分支
release/v1.0.0
release/v1.1.0
# 热修复分支
hotfix/critical-bug
Commit Message规范¶
# 格式
<type>(<scope>): <subject>
<body>
<footer>
# 示例
feat(sensor): add DHT22 temperature sensor driver
- Implement DHT22 communication protocol
- Add data validation and error handling
- Include unit tests
Closes #123
Type类型： - feat：新功能 - fix：修复bug - docs：文档更新 - style：代码格式 - refactor：重构 - test：测试相关 - chore：构建/工具
总结与扩展¶
项目管理核心要点¶
1. 需求管理¶
- 清晰定义：使用用户故事和验收标准
- 优先级划分：MoSCoW方法
- 变更控制：建立正式的变更流程
- 持续沟通：与干系人保持密切联系
2. 计划与估算¶
- WBS分解：将大任务分解为可管理的小任务
- 三点估算：考虑乐观、最可能、悲观情况
- 缓冲时间：预留20-30%的缓冲
- 里程碑设置：设置清晰的检查点
3. 敏捷实践¶
- 迭代开发：2周Sprint节奏
- 每日站会：15分钟同步进度
- Sprint评审：展示成果，收集反馈
- 持续改进：回顾会议识别改进点
4. 团队协作¶
- 角色明确：清晰的职责分工
- 开放沟通：鼓励提问和讨论
- 代码审查：提高代码质量
- 知识分享：定期技术分享
5. 质量保证¶
- 测试驱动：先写测试再写代码
- 自动化测试：提高测试效率
- 持续集成：及早发现问题
- 性能监控：关注系统性能
6. 风险管理¶
- 提前识别：定期风险评估
- 制定预案：准备应对措施
- 持续监控：跟踪风险状态
- 及时应对：快速响应变化
实践练习¶
练习1：需求分析¶
选择一个你感兴趣的嵌入式项目，完成以下任务： 1. 编写5个用户故事 2. 使用MoSCoW方法划分优先级 3. 为每个用户故事编写验收标准 4. 识别3个主要风险
练习2：架构设计¶
基于练习1的需求，完成： 1. 绘制系统架构图 2. 设计数据模型 3. 定义主要接口 4. 评估技术选型
练习3：项目计划¶
制定项目实施计划： 1. 创建WBS 2. 估算任务工作量 3. 制定Sprint计划 4. 绘制甘特图
练习4：团队协作¶
模拟团队协作场景： 1. 组织一次Sprint计划会议 2. 进行每日站会 3. 执行代码审查 4. 召开Sprint回顾会议
扩展阅读¶
推荐书籍¶
- 《敏捷软件开发：原则、模式与实践》- Robert C. Martin
- 《Scrum精髓》- Kenneth S. Rubin
- 《人月神话》- Frederick P. Brooks
- 《项目管理知识体系指南（PMBOK）》- PMI
- 《持续交付》- Jez Humble & David Farley
在线资源¶
- Scrum Guide: https://scrumguides.org/
- Agile Manifesto: https://agilemanifesto.org/
- Atlassian Agile Coach: https://www.atlassian.com/agile
- Project Management Institute: https://www.pmi.org/
工具推荐¶
- 项目管理：Jira、Trello、Asana
- 文档协作：Confluence、Notion、GitBook
- 版本控制：Git、GitHub、GitLab
- CI/CD：Jenkins、GitHub Actions、GitLab CI
- 沟通协作：Slack、Microsoft Teams、钉钉
下一步学习¶
完成本项目后，建议继续学习：
- 高级项目管理
- 大型项目管理
- 多团队协作
-
项目组合管理
-
DevOps实践
- 持续集成/持续部署
- 基础设施即代码
-
容器化和编排
-
产品管理
- 产品规划
- 用户研究
-
数据驱动决策
-
技术领导力
- 团队建设
- 技术决策
- 架构治理
参考资料¶
- Scrum Guide 2020
- PMI PMBOK Guide 7th Edition
- Agile Estimating and Planning - Mike Cohn
- The Lean Startup - Eric Ries
- Continuous Delivery - Jez Humble & David Farley
项目完成标志： - ✅ 完成所有功能开发 - ✅ 通过所有测试 - ✅ 完成文档编写 - ✅ 成功部署上线 - ✅ 用户验收通过
恭喜你完成了这个完整的项目实战！
通过这个项目，你已经掌握了： - 系统化的需求分析方法 - 完整的架构设计能力 - 敏捷开发的实践经验 - 团队协作和沟通技巧 - 质量保证和测试方法 - 项目交付和总结能力
继续保持学习和实践，你将成为一名优秀的技术管理者！