209 lines
12 KiB
Markdown
209 lines
12 KiB
Markdown
# Etunel 项目生命周期
|
|
|
|
Hub 选择阶段、正式成果、任务波次、门禁或结项时读取。成员只在当前任务需要理解上下游时读取相关阶段。
|
|
|
|
## 通用推进原则
|
|
|
|
- 正常顺序是：业务需求 → 产品定义 → 方案设计 → 项目规划 → 软硬件实现 → 测试验证 → 业务验收 → 发布结项。
|
|
- 每个阶段开始时，Hub 在该阶段的《阶段记录》中写下简短的“本阶段完成约定”，分为本阶段必须完成、后续阶段处理和当前不需要。Hub 根据当前流程基线、有效上游成果和项目已确认规则整理，并放入承担当前必需项的主责角色在该阶段收到的首个任务；各角色只在与本角色负责人对齐时确认或纠正自己的部分，不为此另开全员确认任务。
|
|
- 角色提出新缺口时，必须说明它直接影响哪项本阶段成果、完成条件或决定，以及为什么现在必须解决。后续使用但不影响当前判断的资料只登记为后续依赖，不能阻塞当前阶段。
|
|
- 本阶段门禁满足、成果和确认留档后，Hub 及时结束本阶段并启动下一阶段。不要等待后续阶段的全部资料提前齐备；新阶段根据自己的任务按需取得输入。
|
|
- 每项任务只有一个主责角色和一个可以独立判断的结果。
|
|
- 主责草案、专业角色评估或设计、主责收口的依赖不可颠倒；同一基线上的独立任务可以形成波次。
|
|
- 正式结果必须有指定成果、版本、证据、专业自审和负责人确认。
|
|
- 正式成果使用中文名称；过程记录、支持材料和额外文件不得冒充正式成果。
|
|
- 不适用、延期、豁免、阻塞、模拟和正式完成是不同状态，不能相互替代。
|
|
- 正式项目遵循门禁。明确的模拟或流程验证可以按异常规则灵活跳转，但必须标明模拟和风险。
|
|
- 每个阶段的文件、进度和交接按 [项目文件与进度留档](project-files-and-progress.md) 保存。
|
|
|
|
## 阶段 1：业务需求
|
|
|
|
### 正常任务链
|
|
|
|
1. 业务形成待评审的业务草案，澄清背景、客户目标、价值、范围、优先级、合作边界、成功指标和目标里程碑。
|
|
2. 产品判断是否需要早期专业风险预审，并精确选择角色、问题和必要输入。
|
|
3. 如需要，Hub 只向产品指定角色派发预审任务，不擅自增删名单；预审只识别约束与风险，不替代后续设计和测试。
|
|
4. 产品整理预审影响，业务负责人确认阶段 1 基线。
|
|
|
|
### 正式成果
|
|
|
|
- 项目背景说明
|
|
- 项目目标与里程碑计划
|
|
|
|
早期风险预审记录、客户材料索引和开放项是支持材料，不新增正式门禁成果。客户期望日期只有获得相应授权才成为正式承诺。
|
|
|
|
### 门禁
|
|
|
|
有权业务负责人确认项目目标、范围、业务边界和成果版本；开放项、假设和风险如实保留；产品取得足够输入继续定义。
|
|
|
|
## 阶段 2：产品定义
|
|
|
|
### 正常任务链
|
|
|
|
1. 产品优先使用阶段 1 基线、项目已确认规则和已有资料，明确产品做什么、不做什么、外部可见行为以及如何判断结果符合要求，形成三类正式成果草案；只补当前阶段确实需要的客户输入，不提前收齐后续设计、实现、测试或生产资料。
|
|
2. 产品在评审请求中明确目标角色、具体问题、关联内容和期望输出。测试检查产品结果是否可判断；技术负责人、应用层、底层和硬件只在产品内容确实涉及本领域约束时参与。影响范围不清时，可先由技术负责人界定相关专业领域，不能因此默认让所有角色全面评估。
|
|
3. Hub 以同一草案版本按产品指定范围定向派发；依赖独立时可以形成波次，但不得自行增加评审对象或专业问题。
|
|
4. 各角色只返回本领域对当前产品定义的可行性、约束、缺口、风险和建议，并说明是否直接影响本阶段完成约定；不代产品改需求，也不把后续阶段的完整资料要求变成当前阻塞。
|
|
5. 测试在本阶段判断预期结果是否清楚、可区分通过与不通过；样机数量、执行轮次、工具和详细环境通常留到《测试计划》或后续测试准备，除非它们本身是已批准的产品承诺。
|
|
6. 产品处置反馈、解决需求冲突并收口产品基线。
|
|
7. 业务批准客户范围、验收边界和需要组织授权的结论。
|
|
|
|
### 正式成果
|
|
|
|
- 立项资料
|
|
- 测试验收标准
|
|
- 里程碑要求
|
|
|
|
客户输入矩阵、平台 SDK、串号、对接资料、功能清单、器件和板框资料在当前产品定义确实需要时，可以作为包内内容或支持输入；不另立旧版开发资料包，也不因后续阶段可能使用而要求阶段 2 全部收齐。
|
|
|
|
### 门禁
|
|
|
|
产品行为、范围、异常边界、确有需要的接口期望和可判断的验收结果明确；直接影响当前定义的关键专业约束已处置；产品负责人确认，业务完成范围批准。已经登记的后续依赖不妨碍阶段交接，下一阶段启动后按需取得资料。
|
|
|
|
## 阶段 3：方案设计
|
|
|
|
### 正常任务链
|
|
|
|
1. 技术负责人基于产品基线形成总体方案、接口契约和设计任务草案；方案不得依赖尚未形成的《项目计划》。
|
|
2. Hub 以同一方案和接口版本向适用角色形成设计波次：
|
|
- 嵌入式应用层：应用架构、模块、状态、应用接口和集成需求；
|
|
- 嵌入式底层：BSP、Bootloader、驱动、RTOS、HAL 和底层接口；
|
|
- 硬件：电路、PCB、器件、BOM、电源、信号、热和板卡接口；
|
|
- 测试：测试计划、环境、策略、覆盖、可测试性和通过标准；
|
|
- 产品：确认方案没有需求漂移。
|
|
3. 技术负责人处理冲突并收口统一架构、接口和关键决定。
|
|
4. 受影响角色分别确认本领域约束与统一版本一致。
|
|
|
|
### 正式成果
|
|
|
|
- 总体技术方案
|
|
- 软硬件接口契约
|
|
- 硬件设计包
|
|
- 架构决策记录
|
|
- 测试计划
|
|
|
|
技术负责人主责《总体技术方案》《软硬件接口契约》和《架构决策记录》；硬件主责《硬件设计包》；测试主责《测试计划》。
|
|
|
|
### 门禁
|
|
|
|
方案、接口、职责、验证方式、版本和风险形成一致基线；技术负责人确认可用于规划，受影响专业角色和产品完成各自范围确认。
|
|
|
|
## 阶段 4：项目规划
|
|
|
|
### 正常任务链
|
|
|
|
1. Hub 基于已确认方案形成《项目计划》《项目风险》《角色分工》《产品资料整合》和《项目状态内部记录》草案。
|
|
2. 技术负责人先确认整体任务结构、技术顺序、依赖、角色覆盖、集成关系和关键风险。
|
|
3. 只有具体任务存在缺失、冲突或确需专业估算时，Hub 才定向询问对应执行角色；不要求所有角色重复确认整份计划。
|
|
4. Hub 收口计划和状态记录；业务授权真实人员、资源、采购、成本和正式日期。
|
|
5. Hub 向相关主责角色下发依赖就绪的任务切片。
|
|
|
|
### 正式成果
|
|
|
|
- 项目计划
|
|
- 项目风险
|
|
- 角色分工
|
|
- 产品资料整合
|
|
- 项目状态内部记录
|
|
|
|
项目创建时由 Etunel 提供的角色事实和阶段 1–3 状态在本阶段正式化；完整计划由 Hub 维护，不要求全员查看或重复确认。
|
|
|
|
### 门禁
|
|
|
|
每项计划任务有主责角色、输入、输出文件、证据、期限、完成条件和依赖；真实资源与日期状态明确，首批任务可以执行。
|
|
|
|
## 阶段 5：软硬件实现
|
|
|
|
### 正常任务链
|
|
|
|
1. Hub 按依赖向嵌入式应用层、嵌入式底层和硬件形成一个或多个实现波次。
|
|
2. 各实现角色形成本领域实现成果、版本、自测、证据和负责人确认。
|
|
3. 底层向 Hub 提交可消费的底层版本和集成说明；Hub 交应用层合版。
|
|
4. 应用层解决集成问题并作为唯一出口形成《嵌入式应用层固件包》。
|
|
5. 硬件形成匹配板卡、BOM、ECO、样机和实现资料。
|
|
6. Hub 维护固件、底层、硬件、BOM／ECO、配置和接口匹配关系；技术负责人确认可提测组合。
|
|
|
|
### 正式成果
|
|
|
|
- 硬件实现资料
|
|
- 嵌入式底层实现资料
|
|
- 嵌入式应用层固件包
|
|
|
|
版本矩阵、构建记录和角色自测是必要支持证据，但不新增正式成果类别。底层不得直接向测试提交最终固件。
|
|
|
|
### 门禁
|
|
|
|
适用实现成果形成；统一固件与底层、硬件、BOM／ECO、配置和接口版本匹配；技术负责人确认当前组合可交测试。
|
|
|
|
## 阶段 6：测试验证
|
|
|
|
### 正常任务链
|
|
|
|
1. Hub 将应用层统一固件、技术负责人确认的版本组合和对应环境基线交测试。
|
|
2. 测试依据《测试计划》和《测试验收标准》执行功能、可靠性、专项和回归验证。
|
|
3. 测试创建并维护《缺陷分析报告》；缺陷由 Hub 向实际责任角色形成修复波次。
|
|
4. 实现角色提交根因分析、修复计划、修复成果、版本、自测和影响，不能替测试关闭缺陷报告。
|
|
5. 底层修复先由应用层重新合版；硬件 ECO 同步完成底层兼容、应用有效性和版本组合确认。
|
|
6. 测试在目标版本组合上独立复验并更新缺陷状态；全部适用验证完成后由测试负责人确认结论。
|
|
|
|
### 正式成果
|
|
|
|
- 功能测试报告
|
|
- 可靠性测试报告
|
|
- 专项测试报告
|
|
- 测试证据包
|
|
- 缺陷分析报告
|
|
|
|
质量结论、回归和缺陷证据写入上述适用正式成果，不另立其他测试门禁成果。
|
|
|
|
### 门禁
|
|
|
|
测试对象、环境、范围、结果、证据、缺陷、复验和剩余风险可追踪；测试明确给出通过、失败或阻塞。测试通过不替代业务验收。
|
|
|
|
## 阶段 7：业务验收
|
|
|
|
### 正常任务链
|
|
|
|
1. 产品基于产品基线、平台结果和测试结论组织验收材料、用例、演示或试用和差异处置。
|
|
2. 外部客户不是默认 Etunel 角色；客户输入由业务或产品负责人按联络边界取得，并返回对应角色会话。只有已经定义职责并由 Hub 负责人手动加入 Etunel 的客户角色才可接收任务。
|
|
3. 问题由产品判断为需求理解、实现缺陷、环境问题或正式变更；Hub 只路由实际受影响角色，并从正确阶段返工。
|
|
4. 产品形成验收报告和附条件事项；业务批准验收结论、上线或交付条件和业务风险接受。
|
|
|
|
### 正式成果
|
|
|
|
- 平台提测通过报告
|
|
- 客户验收通过报告
|
|
- 附条件验收事项
|
|
|
|
不适用的平台或客户验收成果按不适用或《成果豁免申请》规则处理，不能用内部测试自动替代。
|
|
|
|
### 门禁
|
|
|
|
平台与客户验收证据、差异、附条件事项、责任、期限和业务决定明确；未解决项有处置条件和承接人。
|
|
|
|
## 阶段 8：发布结项
|
|
|
|
### 正常任务链
|
|
|
|
1. Hub 只向实际参与、拥有正式成果、遗留风险或发布责任的角色派发发布或结项任务：
|
|
- 应用层输出唯一最终发布固件和发布说明；
|
|
- 底层归档实际被集成的版本和接口信息；
|
|
- 硬件归档板卡、BOM、生产资料和适用 ECO；
|
|
- 技术负责人确认最终版本组合与发布技术前提；
|
|
- 测试对最终组合执行适用发布验证；
|
|
- 产品确认发布范围与已批准产品和验收一致；
|
|
- 业务确认交付、合同、授权、客户沟通和遗留责任。
|
|
2. 实际参与角色提交成果索引、未决事项和本角色流程闭环输入；未参与角色说明不适用原因，不创建虚假任务。
|
|
3. Hub 汇总归档、变更、结项报告和流程闭环总结，并完成必要确认。
|
|
|
|
### 正式成果
|
|
|
|
- 结项资料归档
|
|
- 变更记录
|
|
- 结项报告
|
|
- 流程闭环总结
|
|
|
|
### 门禁
|
|
|
|
正式项目只有在适用交付、验证、批准、阶段文件留档和遗留承接完成后才可关闭。模拟项目只记录“模拟完成”，不得宣称真实发布、客户验收或生产就绪。
|