evil0knight's Blog

Agile-Plan

25分钟阅读

敏捷规划与需求-代码-测试追踪方案（Agile Plan）

← 开发流程规范 | ← 主页

参考,仅复制

原文标题：ECS100-敏捷规划与需求-代码-测试追踪方案（Agile Plan）

文档编号EC-S100-AGILE-PLAN
版本V1.0
日期2026-01-02
编写课程研发组
审核系统架构组
批准研发负责人

保密级别：内部

文档变更记录

版本修订日期修订内容修订人审核人
V1.02026-01-02初版：建立敏捷规划、Epic/Sprint示例、需求-代码-测试追踪与Git基线策略。课程研发组系统架构组

1. 目的与范围

本文件用于指导 EC-S100 智能手表项目在“受限网络工况（矿井/山区/海上平台/野外）”场景下的敏捷开发落地：如何把 Stakeholder Needs → Business Requirements → System Requirements → (Software/Hardware Requirements) 落到 Epic/Sprint、代码提交、测试证据与版本基线，形成“可追踪、可验收、可复用”的大厂级工程闭环。

适用范围：包含双 MCU（STM32F411 + nRF52840）方案的固件/硬件/测试开发、以及文档协同与发布流程。

2. 项目背景与关键约束

  • 受限网络：现场可能无蜂窝/无Wi-Fi，依赖 BLE 与手机近场交互；位置信息通过手机端 GPS 获取并回传（不包含 NFC 需求）。

  • 安全与可靠：生命体征/告警链路必须“离线可用”；告警优先级高于普通功能；日志可追溯、可导出。

  • 低功耗：长续航（目标以“至少 5-7 天典型使用”为规划基线），必须建立功耗回归与门禁策略。

  • 多外设/多总线：LCD(SPI)、Flash(SPI/QSPI)、PPG/加速度/温湿度/触控(I2C)、按键/蜂鸣器/背光/电量(ADC)等并发访问，需要统一资源仲裁。

  • 可维护与可演进：平台化分层（BSP/Driver/Svc/App）与接口契约；需求变更需可控，避免“堆功能堆出灾难”。

3. 敏捷开发模型（本项目落地版）

本项目采用“Scrum + 工程门禁（Gates）”的混合模式：Sprint 驱动交付节奏，Gate 驱动质量与合规。默认 Sprint 周期为 2 周；如硬件样机/供应链节点导致节奏变化，可在 Release Planning 中调整，但必须同步更新里程碑门禁与资源计划。

3.1 角色与职责（谁做决定，谁做交付）

角色核心职责主要产出
产品负责人/PO定义价值与优先级，维护产品 Backlog，验收业务价值。BRD、Epic、验收标准
项目经理/PM排期/资源/风险，跨团队协调，推动里程碑与发布。Release Plan、里程碑报告
Scrum Master/敏捷教练保障仪式执行、移除阻塞、推动持续改进。Retro行动项、流程看板
系统工程师/SE把业务需求转为系统能力，推动需求可验证。SyRS、RAM（系统层）
系统架构师/SA做系统方案与分配决策，建立关键接口与约束。SAD、ADR、SID（系统接口）
软件架构师软件分层与模块边界，公共服务与框架落地。SSRD（HLR）、SDD
硬件架构师器件选型/电源/接口/可靠性/可测性（DFM/DFT）。HRS、HDD（原理图/PCB约束）
固件工程师（STM32侧）Driver/Svc/App实现，功耗、日志、UI、存储等。代码、单元/集成测试、调试记录
BLE/无线工程师（nRF侧）BLE协议栈、GATT服务、与STM32通信与功耗。代码、互操作测试、功耗数据
测试/QA测试策略、用例、自动化与质量门禁，缺陷闭环。Test Plan、Test Report、缺陷报告
制造/可靠性产测方案、治具、老化与可靠性验证。MP Test Spec、Reliability Report

3.2 Scrum 仪式与输入输出

活动参与者核心目标输出
Backlog Refinement（每周）PO/SE/架构/开发/QA新需求澄清；拆分为 Epic/Feature/Story；补齐验收与风险准备好进入下次 Sprint 的候选项
Sprint Planning（每两周）全体开发团队 + PO确定 Sprint Goal；选取 Story；拆 Task；估算与承诺Sprint Backlog、Capacity、风险清单
Daily Standup（每日）开发团队同步进展/阻塞/今日计划阻塞清单与快速决策
Sprint Review（每两周）PO/干系人/团队演示可运行增量；对照验收标准验收结果、Backlog调整
Retrospective（每两周）团队复盘流程与质量问题改进行动项（带责任人/截止日期）

4. 需求工程分层与编号规则（SN/BR/SR 以及向下分解）

缩写解释：SN=Stakeholder Needs（干系人需求），BR=Business Requirements（业务需求），SR=System Requirements（系统需求）。在 SR 之后进行架构分配（Allocation），再拆分为软件/硬件需求（SSRD/SRS/HRS）。每一层的核心要求是：可追溯、可验证、可变更控制。

本项目采用统一编号规则，确保文档、Jira、代码提交、测试用例三者能闭环关联：

  • SN-XXX：干系人需求（来自客户/甲方/运营/法规/安全部门）

  • UN-XXX：用户需求（典型用户在场景中的目标与痛点）

  • BR-XXX：业务需求（可度量的业务目标/范围/边界）

  • SR-XXX：系统需求（系统必须具备的能力/性能/约束）

  • SWR-XXX：软件需求（功能/接口/行为/异常/性能，来源 SR-XXX 分配）

  • HWR-XXX：硬件需求（器件/电源/接口/可靠性/可测性，来源 SR-XXX 分配）

  • TC-XXX：测试用例（验证 SWR/HWR 的证据）

  • REL-x.y.z：发布版本/基线标签（与 Git Tag 对齐）

追踪原则：下游条目必须引用上游 ID（例如：SWR-012 派生自 SR-005，测试用例 TC-077 覆盖 SWR-012），代码提交需在 commit message 或 PR 中显式写入相关 ID。

4.1 文档体系与交付物（Deliverables）

阶段主要文档编号对象目的
Stage1Stakeholder Needs Document / User Needs DocumentSN-xxx, UN-xxx需求来源、痛点、使用场景、优先级假设
Stage2Kano / QFD / BRDBR-xxx需求价值、权重、范围与业务验收口径
Stage3SyRS（System Requirements Specification）SR-xxx系统级能力、性能、约束、可验证性
Stage4SAD / RAM / ADR / SIDAllocation / Interface系统方案、分配矩阵、关键决策、接口契约
Stage5SSRD（HLR）/ SRS（LLR）/ HRSSWR-xxx, HWR-xxx软件/硬件可实现、可测试的详细需求
Stage6SDD / HDDDesign Artifacts设计实现方案、模块边界、状态机、数据流、原理图/PCB约束
Stage7Implementation & VerificationCode/TC/Evidence实现、测试报告、缺陷闭环、回归结果
Stage8Release & MaintenanceREL/Hotfix发布说明、版本基线、维护策略

5. Backlog 规划：Theme → Epic → Feature → Story → Task

Backlog 的核心是把“文档里的需求”变成“可在一个 Sprint 内交付的工作单元”。本项目按主题拆分：安全监测、连接与同步、交互体验、功耗与可靠、OTA与安全、日志与诊断、制造与运维。

5.1 Epic 与 Story 的模板（课程统一口径）

  • Epic：对业务价值的一个完整闭环（通常 1-3 个月），有明确验收指标与依赖清单。

  • Story：可在 1 个 Sprint 内完成并可演示的最小增量（可运行、可验收）。

  • Task：Story 的工程拆分（编码/联调/测试/文档/工具链）。

5.2 Definition of Ready / Definition of Done（门禁）

DoR（进入 Sprint 前必须具备）：

  • Story 已拆分清晰，依赖与风险已标注；验收标准明确且可测。

  • 需求 ID（SR/SWR/HWR）齐全，必要的接口契约已定义（SID/SDD/HDD中有依据）。

  • 团队确认具备样机/环境/工具链（或有可执行的 Mock 方案）。

DoD（完成必须具备）：

  • 代码合并到主干（或受控集成分支）并通过 CI：编译、静态检查、基础单测。

  • 关键功能在真实硬件上完成冒烟/集成测试，有测试记录或报告（链接到 TC）。

  • 需求追踪更新：SWR/HWR 状态、RAM 关联、Release Note 草稿同步。

  • 功耗/性能/稳定性如被影响，必须有对比数据或解释与回归计划。

6. Release 与里程碑（从工程样机到量产）

Release 是“对外可交付”的节奏单位；Sprint 是“对内可迭代”的节奏单位。Release 的时间由业务窗口、样机节奏、质量门禁决定；Sprint 的时间由团队吞吐与反馈节奏决定。

版本目标门禁（必须满足）核心产出
REL-0.1.0（Engineering Sample）点亮+基础框架+关键外设通可启动、可显示、可日志、可BLE通信Bring-up报告、功耗基线、冒烟用例
REL-0.2.0（MVP）生命体征闭环+离线告警+基础同步核心采集/显示/告警可用；手机近场同步；日志可导出系统测试报告、关键需求追踪覆盖率
REL-0.3.0（Pilot）OTA+可靠性+功耗优化可升级、长稳运行、功耗达标OTA验证报告、老化/回归报告
REL-1.0.0（Production）量产与运维能力产测、校准、故障诊断、版本管理MP测试规范、Release Note、维护策略

7. 三个完整 Sprint 示例（以真实手表能力为蓝本）

说明：以下 Sprint 示例用于课程教学与项目落地参考。实际计划需结合团队容量、样机 availability、依赖解锁情况调整。默认每个 Sprint 2 周，团队规模 6-8 人（固件/无线/硬件/QA）。

7.1 Sprint 1：完成硬件Bring-up与软件骨架：可启动、可显示、可记录日志、BLE链路打通（最小可运行增量）

Sprint Goal：

  • 完成硬件Bring-up与软件骨架：可启动、可显示、可记录日志、BLE链路打通（最小可运行增量）

范围（In Scope）：

  • 建立代码仓库结构、CI编译、基础静态检查

  • STM32侧：时钟/RTOS/日志/驱动框架（Driver-Svc-App）骨架

  • LCD显示点亮、按键输入、RTC走时与基础UI页面

  • nRF侧：BLE广播/连接、与STM32 UART/SPI链路联通（可先用透传/简化协议）

Sprint Backlog（Story 列表）：

Story ID标题关联需求主要任务拆分验收标准（摘要）产出物
ST-001工程化骨架+CI（编译/格式化/基础单测）SR-001, SWR-001repo结构、脚手架、CI脚本、PR模板主干可一键构建；CI通过Repo+CI记录
ST-002LCD点亮与基础UI首页SR-010, SWR-010SPI驱动、ST7789初始化、UI刷新任务上电5s内显示首页；无花屏Demo视频/截图
ST-003系统日志与故障码框架SR-020, SWR-020日志库接入、日志等级、持久化接口可导出日志；关键异常可定位日志规范+样例
ST-004BLE最小链路：广播-连接-基础命令SR-030, SWR-030BLE服务雏形、握手协议、超时重传手机可连接并读写特征；3次重传互操作测试记录

DoD 检查清单：

  • 对应 Story 的 PR 已合并，Commit/PR 中包含需求 ID（SR/SWR/HWR）。

  • 至少完成一次真实板卡演示/录屏；关键链路有测试用例 TC 编号与结果。

  • 更新 Release Note 草稿：新增/变更/已知问题。

风险与对策：

  • 样机/外设不稳定：准备 Mock 驱动与接口隔离；保持可编译可运行。

  • 需求变更：PO 在 Sprint 中途只允许“替换等量范围”，不允许无限加塞。

  • 功耗超标：建立 power baseline 测试脚本，新增功能必须补功耗回归数据。

7.2 Sprint 2：生命体征采集闭环：PPG/温度/加速度采集→算法→显示，并建立数据模型与存储

Sprint Goal：

  • 生命体征采集闭环：PPG/温度/加速度采集→算法→显示，并建立数据模型与存储

范围（In Scope）：

  • PPG（心率/血氧）采集驱动与采样定时（DMA/中断/环形缓冲）

  • 体温/环境温湿度/加速度基础驱动

  • 数据模型：时间戳、采样窗口、异常标记、掉包处理

  • Flash 存储：循环日志区/数据区，支持离线保存

Sprint Backlog（Story 列表）：

Story ID标题关联需求主要任务拆分验收标准（摘要）产出物
ST-101PPG采样与缓冲队列SR-040, SWR-041I2C驱动、采样定时、双/环形缓冲采样稳定；无丢包波形记录+统计
ST-102心率基础算法与显示SR-041, SWR-042滤波/峰值检测、异常检测、UI展示误差达标；异常提示算法报告+演示
ST-103温度/加速度驱动与数据模型SR-042, SWR-043读取/校准/异常恢复每秒更新；断线恢复驱动单测+记录
ST-104Flash数据存储（离线可用）SR-050, SWR-050分区、磨损均衡、导出接口断电不丢关键记录存储设计说明

DoD 检查清单：

  • 对应 Story 的 PR 已合并，Commit/PR 中包含需求 ID（SR/SWR/HWR）。

  • 至少完成一次真实板卡演示/录屏；关键链路有测试用例 TC 编号与结果。

  • 更新 Release Note 草稿：新增/变更/已知问题。

风险与对策：

  • 样机/外设不稳定：准备 Mock 驱动与接口隔离；保持可编译可运行。

  • 需求变更：PO 在 Sprint 中途只允许“替换等量范围”，不允许无限加塞。

  • 功耗超标：建立 power baseline 测试脚本，新增功能必须补功耗回归数据。

7.3 Sprint 3：受限网络场景的告警与同步：离线告警优先，近场同步，手机GPS回传，事件队列可靠上传

Sprint Goal：

  • 受限网络场景的告警与同步：离线告警优先，近场同步，手机GPS回传，事件队列可靠上传

范围（In Scope）：

  • 告警策略：阈值+持续时间+多源融合（心率/体温/跌倒）

  • BLE GATT：事件/日志/位置上报；手机端作为网关（可用Mock APP）

  • 离线队列：事件先入Flash，联机后补传；防重复/幂等

  • 功耗：连接窗口、广播间隔、唤醒策略优化

Sprint Backlog（Story 列表）：

Story ID标题关联需求主要任务拆分验收标准（摘要）产出物
ST-201告警状态机与本地提示SR-060, SWR-061状态机、蜂鸣/震动/屏显、恢复告警<1s触发；可确认状态机图+演示
ST-202手机GPS获取与回传协议SR-061, SWR-062GATT特征定义、超时/重试位置更新；时间同步OKSID更新+互测记录
ST-203离线事件队列与补传机制SR-062, SWR-063Flash队列、幂等ID、补传窗口断网不丢；恢复补传测试报告
ST-204功耗回归与优化1.0SR-070, SWR-071测量脚本、场景对比、参数调整功耗下降并稳定功耗曲线与结论

DoD 检查清单：

  • 对应 Story 的 PR 已合并，Commit/PR 中包含需求 ID（SR/SWR/HWR）。

  • 至少完成一次真实板卡演示/录屏；关键链路有测试用例 TC 编号与结果。

  • 更新 Release Note 草稿：新增/变更/已知问题。

风险与对策：

  • 样机/外设不稳定：准备 Mock 驱动与接口隔离；保持可编译可运行。

  • 需求变更：PO 在 Sprint 中途只允许“替换等量范围”，不允许无限加塞。

  • 功耗超标：建立 power baseline 测试脚本，新增功能必须补功耗回归数据。

8. Git 分支策略与版本基线（把“代码提交”变成“可审计的交付”）

本项目推荐 Trunk-Based Development（主干开发）+ 短生命周期 Feature Branch：减少长期分支带来的集成地狱，适配嵌入式“硬件在环”的频繁联调。

8.1 分支命名与合并规则

  • 主干：main（始终可发布/可回退）

  • 集成分支（可选）：develop（当硬件联调频繁、需要暂存时使用）

  • 功能分支：feature/SWR-041-ppg-sampling（必须包含至少一个需求ID）

  • 修复分支：fix/TC-077-i2c-timeout 或 hotfix/REL-0.2.0-ble-crash

  • 发布分支：release/REL-0.2.0（仅用于发布前收敛，禁止新特性）

合并门禁（PR 必须满足）：

  • PR 描述中列出：关联需求ID（SR/SWR/HWR）+ 覆盖的测试用例ID（TC）+ 证据链接（日志/截图/录屏）。

  • CI 通过：编译、基础静态检查、单测（如有）。

  • 关键模块（功耗、存储、通信）必须有 Review：至少 1 名架构/模块Owner批准。

  • 合并后必须更新追踪表（RAM/追踪矩阵/Release Note 之一）。

8.2 Commit Message 规范（推荐）

  • 格式：[SWR-041][SR-040] feat(ppg): add DMA ring buffer for sampling

  • 一个 commit 尽量只对应一个“逻辑变更点”；大改动拆成多个小 commit（便于回滚与审计）。

  • 涉及接口变更必须同步更新：SID/SDD/HDD（至少在同一 PR 中提交）。

8.3 基线（Baseline）与 Tag 规则

基线的意义：把某一次代码快照“冻结”为可复现、可审计、可回滚的交付物。每个基线必须能回答：它实现了哪些需求？通过了哪些测试？已知问题是什么？

Tag触发条件需求范围（示例）测试证据（示例）备注
baseline/REL-0.1.0Bring-up完成SR-001/010/020/030 等最小集冒烟用例 TC-001~TC-010 全通过上电显示、日志、BLE握手
baseline/REL-0.2.0MVP冻结SR-040~063 核心闭环系统测试报告 TR-0.2.0生命体征+离线告警+近场同步
baseline/REL-0.3.0Pilot冻结SR-070/080 安全与功耗功耗回归 PR-POWER-0.3.0OTA/长稳/功耗达标

8.4 需求-代码-测试追踪矩阵（示例）

系统需求SR软件需求SWRStory基线Tag示例Commit测试用例TC证据摘要
SR-040SWR-041ST-101baseline/REL-0.2.0a1b2c3dTC-021PPG采样稳定性测试通过
SR-060SWR-061ST-201baseline/REL-0.2.0b2c3d4eTC-055告警触发<1s，手动确认OK
SR-061SWR-062ST-202baseline/REL-0.2.0c3d4e5fTC-061GPS回传协议互测通过

8.5 提交与合并基线的“模拟示例”（教学用）

  1. feature/SWR-041-ppg-sampling 分支创建（关联 SR-040）。

  2. 提交1：[SWR-041][SR-040] feat(ppg): add i2c burst read + DMA ring buffer

  3. 提交2：[TC-021][SWR-041] test(ppg): add sampling jitter measurement

  4. PR 合并：Review通过 + CI通过 + 板上测试录像上传 → merge 到 main。

  5. 打 Tag：baseline/REL-0.2.0-rc1（进入发布收敛）。

  6. 修复：[SWR-041] fix(ppg): handle i2c timeout and retry → 合并 → baseline/REL-0.2.0 冻结。

9. 质量策略与验证计划（与敏捷同步推进）

质量不是“最后一周补测试”，而是每个 Sprint 的 DoD 内置。QA 在 Backlog Refinement 时参与，确保每个 Story 都能落到可测的验收标准。

  • 测试分层：单元测试（可选）→ 模块集成测试 → 系统测试 → 现场场景测试（受限网络）。

  • 关键回归：功耗回归、存储回归、通信稳定性回归、告警时延回归。

  • 缺陷闭环：缺陷必须关联需求ID/Story/基线；修复后必须补充回归证据。

10. 风险与应对（面向真实工程）

风险典型原因影响应对策略
网络与手机依赖手机端兼容性/蓝牙连接不稳同步失败影响告警闭环离线优先；协议重试；APP端提供Mock与兼容矩阵
功耗超标功能堆叠导致续航骤降产品不可用/返工建立功耗基线；每Sprint功耗回归；参数门禁
I2C资源冲突多传感器+触控共总线死锁/卡总线I2C仲裁服务层；超时恢复；总线健康监控
存储磨损频繁写日志/事件Flash寿命下降分区+磨损均衡；写入节流；寿命评估
双MCU接口变化UART/SPI协议变更联调周期拉长SID冻结接口；版本化协议；兼容策略

附录A：模板（可复制到 Jira/Confluence）

A.1 Epic 模板

  • Epic 名称 / 目标（量化）

  • 覆盖需求：BR-xxx / SR-xxx（列表）

  • 范围（In/Out of Scope）

  • 依赖（硬件/供应链/外部系统）

  • 验收指标（KPI/门禁）

  • 里程碑（日期/责任人）

A.2 Sprint Planning 模板

  • Sprint Goal

  • 团队容量（人日）与假期/并行项目影响

  • Story 列表（含需求ID与验收标准）

  • 风险清单与缓冲策略

  • Demo 计划（演示什么、谁演示）

A.3 PR Checklist 模板

  • 关联需求ID：SR/SWR/HWR

  • 覆盖测试用例：TC

  • 证据：日志/截图/录屏/功耗数据

  • 接口变更：是否更新 SID/SDD/HDD

  • 回滚方案：如出现问题如何快速回退

关系图谱

反向链接