车载软件中的“Story”

车载嵌入式技术场景（如项目管理、需求开发、团队协作），Story（用户故事 / 需求故事） 是灵敏开发（Scrum/Kanban）中核心的需求载体，本质是用简洁、用户视角的语言描述 “谁需要什么功能、为什么需要”，避免传统需求文档的冗长与歧义，适配车载项目快速迭代、多团队协作（硬件 / 软件 / 测试）的特点。以下是车载场景下 Story 的核心含义、编写规范、落地实操及示例：

一、核心定义：车载场景中 Story 的本质

Story 不是技术规格说明书，而是 **“以用户 / 场景为中心的需求描述”**，核心目标是：

让开发、测试、产品、客户（如车企功能部门）达成共识；
明确功能的 “价值”（为什么做）而非仅 “实现”（怎么做）；
适配灵敏迭代（每个 Story 可独立开发、测试、交付，周期一般 1-2 周）。

在车载嵌入式项目中，“用户” 不仅指终端车主，还包括：

内部用户：如车身控制工程师（使用 ECU 诊断功能）、测试工程师（使用自动化测试接口）；
外部用户：如车企客户（需求提出方）、终端车主（最终使用者）；
系统用户：如其他 ECU 模块（如 VCU 与 BMS 的通信需求）。

二、车载 Story 的编写规范（INVEST 原则 + 3C 模板）

1. 核心原则：INVEST（确保 Story 可落地）

原则	含义（车载场景解读）
I（Independent）	独立可交付：每个 Story 可单独开发测试，不依赖其他 Story（如 “CAN 总线数据接收” 与 “LIN 总线数据发送” 可独立）
N（Negotiable）	可协商：细节可与团队 / 客户沟通调整（如 “故障报警方式” 可协商为指示灯 / 声音 / 总线报文）
V（Valuable）	有价值：对用户 / 项目有明确价值（如 “支持 OTA 升级” 对应客户 “降低召回成本” 需求）
E（Estimable）	可估算：开发团队能评估工作量（如 “实现 UDS 诊断服务 0x19” 可估算为 8 人天）
S（Small）	规模适中：车载场景提议 1-2 周完成（避免过大如 “开发智能驾驶系统”，需拆分为 “目标检测”“路径规划” 等子 Story）
T（Testable）	可测试：有明确验收标准（如 “CAN 总线数据传输延迟≤10ms” 可通过 CANoe 测试验证）

2. 编写模板：3C（Card/Conversation/Confirmation）

Card（卡片）：简洁描述核心需求（1-2 句话），核心模板：
作为【角色】，我需要【功能】，以便【价值/目的】
Conversation（沟通）：补充细节（如技术约束、安全要求），通过会议 / 文档同步；
Confirmation（确认）：明确验收标准（Acceptance Criteria，AC），即 “如何判断功能达标”。

三、车载场景 Story 分类与示例（覆盖核心开发场景）

1. 功能类 Story（最常见，聚焦产品功能）

示例 1：终端车主视角（智能座舱）

Card：作为终端车主，我需要通过中控屏设置空调温度（16-30℃），以便根据体感调节车内温度。
Conversation：温度调节精度 0.5℃，设置后 1 秒内空调执行，需同步显示当前温度；支持记忆上次设置值。
Acceptance Criteria（AC）：中控屏空调界面可输入 16-30℃，步长 0.5℃；设置后 1 秒内，空调 ECU 接收并执行温度指令（CAN 总线报文验证）；中控屏实时显示当前设定温度（误差≤0.1℃）；车辆重启后，空调温度默认恢复上次设置值。

示例 2：ECU 协作视角（三电系统）

Card：作为 VCU（整车控制器），我需要接收 BMS（电池管理系统）发送的 SOC（剩余电量）数据（1 次 / 秒），以便调整电机输出扭矩。
Conversation：SOC 数据通过 CAN FD 总线传输，报文 ID 为 0x123，数据长度 8 字节，SOC 精度 1%；需支持异常处理（如 3 秒未接收数据则触发故障报警）。
AC：VCU 每秒接收 1 次 BMS 的 SOC 报文（CANoe 抓包验证，丢包率≤0.1%）；SOC 数据解析精度≤1%（如报文值 0x64 对应 100%，0x00 对应 0%）；连续 3 秒未接收报文时，VCU 触发故障码 DTC P1234，并通过 CAN 总线发送报警报文；故障恢复后（重新接收数据），故障码自动清除。

2. 安全类 Story（适配 ISO 26262/21434）

示例：功能安全视角（ADAS 系统）

Card：作为 ADAS 域控制器，我需要在激光雷达信号异常时（如数据中断），100ms 内切换至摄像头 + 毫米波雷达融合感知，以便保障行车安全（ASIL-B 等级）。
Conversation：激光雷达异常定义为 “连续 5 帧无有效数据”；切换过程需无感知（不触发急刹 / 跑偏）；需记录故障日志。
AC：激光雷达连续 5 帧无有效数据时，判定为异常（日志记录触发时间）；异常后 100ms 内，感知模块切换至摄像头 + 毫米波雷达融合模式（通过 HIL 测试验证响应时间）；切换过程中，车辆行驶状态无突变（加速度变化≤0.5m/s²）；故障日志包含异常类型、切换时间、恢复时间，可通过 UDS 诊断服务 0x19 读取。

3. 技术类 Story（聚焦底层开发 / 工具适配）

示例：嵌入式开发视角（S32G 芯片）

Card：作为软件开发者，我需要实现 S32G399 的 SPI 外设驱动，以便与车载传感器（如胎压传感器）通信。
Conversation：支持 SPI 模式 0/1/2/3，最大传输速率 10MHz；支持中断 / DMA 两种传输方式；需适配 AUTOSAR MCAL 架构。
AC：SPI 驱动可配置为模式 0-3，传输速率最高 10MHz（示波器测量 SCLK 引脚验证）；支持中断和 DMA 传输，DMA 传输 1KB 数据耗时≤1ms（通过芯片定时器测量）；驱动通过 AUTOSAR MCAL 测试用例（如 EB tresos 的 MCAL Validation Suite）；驱动代码覆盖率≥90%（单元测试工具如 VectorCAST 验证）。

4. 测试类 Story（聚焦测试流程 / 工具）

示例：测试工程师视角（HIL 测试）

Card：作为测试工程师，我需要开发 HIL 测试用例，验证 VCU 的驾驶模式切换功能（经济 / 标准 / 运动），以便自动化验证功能正确性。
Conversation：覆盖正常切换、异常切换（如高速行驶中切换）、故障切换（如模式切换超时）；用例可通过 Vector TestManager 执行。
AC：测试用例覆盖 3 种驾驶模式的正常切换（每种模式切换≥10 次，成功率 100%）；覆盖高速（120km/h）行驶中模式切换，无功能异常（如扭矩输出符合模式定义）；覆盖模式切换超时（响应时间＞500ms）时的故障处理（触发 DTC P1235）；所有用例可通过 HIL 系统自动化执行，执行结果自动生成报告。

四、车载 Story 的落地流程（灵敏迭代中）

需求收集：从 SOR（系统需求文档）、客户反馈、安全合规要求中提取 Story；
Story 拆分：将大需求拆分为符合 INVEST 原则的小 Story（如 “智能驾驶” 拆分为 “感知”“决策”“控制” 等子 Story）；
估算与排序：团队用 “故事点”（如 1/2/3/5）估算工作量，按业务价值、安全优先级排序（如 ASIL-D 级 Story 优先开发）；
迭代开发：每个 Sprint（一般 2-4 周）选取部分 Story 开发，每日站会同步进度（如 “SPI 驱动开发已完成 80%，剩余 DMA 传输调试”）；
验收测试：按 AC（验收标准）执行测试，通过则视为 “完成”，未通过则反馈团队修复；
交付与复盘：迭代结束后交付可运行的功能，复盘 Story 编写 / 开发中的问题（如 “AC 不明确导致返工”）。

五、车载 Story 与传统需求文档的区别

对比维度	传统需求文档（如 SOR）	车载 Story
视角	系统 / 技术视角（如 “VCU 需支持 3 种驾驶模式”）	用户 / 场景视角（如 “车主需切换驾驶模式以适配不同路况”）
粒度	粗（多为系统级需求，周期长）	细（可独立交付，周期 1-2 周）
内容	详细技术规格（如 “报文 ID 为 0x123”）	核心需求 + 验收标准（技术细节由团队协商）
协作方式	单向传递（产品→开发）	双向沟通（产品 / 开发 / 测试 / 客户共同确认）
适配场景	瀑布开发、需求稳定的项目	灵敏开发、需求迭代快的车载项目（如智能座舱 / 智驾）