first commit
This commit is contained in:
@@ -0,0 +1,202 @@
|
||||
# Etunel 项目生命周期
|
||||
|
||||
Hub 选择阶段、正式成果、任务波次、门禁或结项时读取。成员只在当前任务需要理解上下游时读取相关阶段。
|
||||
|
||||
## 通用推进原则
|
||||
|
||||
- 正常顺序是：业务需求 → 产品定义 → 方案设计 → 项目规划 → 软硬件实现 → 测试验证 → 业务验收 → 发布结项。
|
||||
- 每项任务只有一个主责角色、一个主责成员、一个 SUBTASK_ID 和可独立判定结果。
|
||||
- 主责草案、专业角色评估／设计和主责收口的依赖不可颠倒；同一基线上的独立任务可形成波次。
|
||||
- 正式结果必须有指定成果、版本、证据、专业自审和 human owner 确认。
|
||||
- 正式成果名以本文件清单为准；过程记录、支持材料和 ADDITIONAL 文件不得冒充正式成果。
|
||||
- 不适用统一写 NA；成果豁免写 WAIVED；延期写 DEFERRED。BYPASSED_WITH_RISK 仅用于明确的模拟／流程验证，不得满足正式门禁。
|
||||
- 正式项目遵循门禁。仅明确的模拟／流程验证 WORK_ID 可按异常规则灵活跳转并标记 SIMULATION_ONLY。
|
||||
|
||||
## 阶段 1：业务需求
|
||||
|
||||
### 正常任务链
|
||||
|
||||
1. 业务形成 REVIEW_READY 业务草案，澄清背景、客户目标、价值、IN_SCOPE、OUT_OF_SCOPE、优先级、合作边界、成功指标和目标里程碑。
|
||||
2. 产品判断是否需要早期专业风险预审，并精确选择一个或多个角色、问题和必要输入。
|
||||
3. 如需要，Hub 只向产品指定角色派发预审任务，不擅自增删名单；预审只识别约束与风险，不替代后续设计和测试。
|
||||
4. 产品整理预审影响，业务负责人确认阶段 1 基线。
|
||||
|
||||
### 正式成果
|
||||
|
||||
- Project Background Brief
|
||||
- Project Milestone Plan
|
||||
|
||||
早期风险预审记录、客户材料索引和开放项是支持材料，不新增正式门禁成果。客户期望日期只有获得相应授权才成为正式承诺。
|
||||
|
||||
### 门禁
|
||||
|
||||
有权业务负责人确认项目目标、范围、业务边界和成果版本；开放项、假设和风险如实保留；产品取得足够输入继续定义。
|
||||
|
||||
## 阶段 2：产品定义
|
||||
|
||||
### 正常任务链
|
||||
|
||||
1. 产品基于阶段 1 基线形成产品定义草案、详细客户输入和可测试验收标准。
|
||||
2. Hub 以同一草案版本向技术负责人、嵌入式应用层、嵌入式底层、硬件和测试中的适用角色派发专业评估；依赖独立时可并行。
|
||||
3. 各角色只返回本领域可行性、约束、缺口、风险和建议，不代产品改需求。
|
||||
4. 产品处置反馈、解决需求冲突并收口产品基线。
|
||||
5. 业务批准客户范围、验收边界和需要组织授权的结论。
|
||||
|
||||
### 正式成果
|
||||
|
||||
- Project Initiation Package
|
||||
- Test & Acceptance Criteria
|
||||
- Milestone Requirements
|
||||
|
||||
Customer Input Matrix、平台 SDK、串号、对接资料、功能清单、器件和板框资料可作为包内内容或支持输入，不另立旧版开发资料包。
|
||||
|
||||
### 门禁
|
||||
|
||||
产品行为、范围、异常边界、接口期望和客观验收标准明确；关键专业约束已处置；产品负责人确认，业务完成范围批准。
|
||||
|
||||
## 阶段 3：方案设计
|
||||
|
||||
### 正常任务链
|
||||
|
||||
1. 技术负责人基于产品基线形成总体方案、接口契约和设计任务草案；方案不得依赖尚未形成的 Project Plan。
|
||||
2. Hub 以同一方案／接口版本向适用角色形成设计波次：
|
||||
- 嵌入式应用层：应用架构、模块、状态、应用接口和集成需求；
|
||||
- 嵌入式底层：BSP、Bootloader、驱动、RTOS、HAL 和底层接口；
|
||||
- 硬件：电路、PCB、器件、BOM、电源、信号、热和板卡接口；
|
||||
- 测试：Test Plan、环境、策略、覆盖、可测试性和通过标准；
|
||||
- 产品：确认方案没有需求漂移。
|
||||
3. 技术负责人处理冲突并收口统一架构、接口和关键决定。
|
||||
4. 受影响角色分别确认本领域约束与统一版本一致。
|
||||
|
||||
### 正式成果
|
||||
|
||||
- Solution Architecture
|
||||
- Software/Hardware Interface Contract
|
||||
- Hardware Design Package
|
||||
- Architecture Decision Record
|
||||
- Test Plan
|
||||
|
||||
技术负责人主责总体方案、接口契约和 ADR；硬件主责 Hardware Design Package；测试主责 Test Plan。
|
||||
|
||||
### 门禁
|
||||
|
||||
方案、接口、职责、验证方式、版本和风险形成一致基线；技术负责人确认可用于规划，受影响专业角色和产品完成各自范围确认。
|
||||
|
||||
## 阶段 4：项目规划
|
||||
|
||||
### 正常任务链
|
||||
|
||||
1. Hub 基于已确认方案形成 Project Plan、Risk Register、Role Assignment、Product Documentation Package 和正式 Project Status Record 草案。
|
||||
2. 技术负责人先确认整体任务结构、技术顺序、依赖、角色覆盖、集成关系和关键风险。
|
||||
3. 只有具体任务存在缺失、冲突或确需专业估算时，Hub 才定向询问对应执行角色；不要求所有角色重复确认整份计划。
|
||||
4. Hub 收口计划和状态记录；业务授权真实成员、资源、采购、成本和正式日期。
|
||||
5. Hub 向相关主责成员下发依赖就绪任务切片。
|
||||
|
||||
### 正式成果
|
||||
|
||||
- Project Plan
|
||||
- Risk Register
|
||||
- Role Assignment
|
||||
- Product Documentation Package
|
||||
- Project Status Record
|
||||
|
||||
项目创建时的成员映射和阶段 1–3 状态在本阶段正式化；完整计划由 Hub 维护，不要求全员查看或 READY。
|
||||
|
||||
### 门禁
|
||||
|
||||
每项计划任务有主责角色、主责成员、输入、输出、证据、期限、完成条件和依赖；真实资源与日期状态明确，首批任务可执行。
|
||||
|
||||
## 阶段 5：软硬件实现
|
||||
|
||||
### 正常任务链
|
||||
|
||||
1. Hub 按依赖向嵌入式应用层、嵌入式底层和硬件形成一个或多个实现波次。
|
||||
2. 各实现角色形成本领域实现成果、版本、自测、证据和负责人确认。
|
||||
3. 底层向 Hub 提交可消费底层版本和集成说明；Hub 交应用层合版。
|
||||
4. 应用层解决集成问题并作为唯一出口形成 Application Firmware Package。
|
||||
5. 硬件形成匹配板卡、BOM、ECO、样机和实现资料。
|
||||
6. Hub 维护固件、底层、硬件、BOM／ECO、配置和接口匹配关系；技术负责人确认可提测组合。
|
||||
|
||||
### 正式成果
|
||||
|
||||
- Hardware Implementation Package
|
||||
- Low-Level Implementation Package
|
||||
- Application Firmware Package
|
||||
|
||||
版本矩阵、构建记录和角色自测是必要支持证据，但不新增正式成果类别。底层不得直接向测试提交最终固件。
|
||||
|
||||
### 门禁
|
||||
|
||||
适用实现成果形成；统一固件与底层、硬件、BOM／ECO、配置和接口版本匹配；技术负责人确认当前组合可交测试。
|
||||
|
||||
## 阶段 6：测试验证
|
||||
|
||||
### 正常任务链
|
||||
|
||||
1. Hub 将应用层统一固件、技术负责人确认的版本组合和对应环境基线交测试。
|
||||
2. 测试依据 Test Plan 和 Test & Acceptance Criteria 执行功能、可靠性、专项和回归验证。
|
||||
3. 测试创建并维护 Defect Analysis Report；缺陷由 Hub 向实际责任角色形成修复波次。
|
||||
4. 实现角色提交 Root Cause Analysis、Fix Plan、修复成果、版本、自测和影响；不能替测试关闭缺陷报告。
|
||||
5. 底层修复先由应用层重新合版；硬件 ECO 同步完成底层兼容、应用有效性和版本组合确认。
|
||||
6. 测试在目标版本组合上独立复验并更新缺陷状态；全部适用验证完成后由测试负责人确认结论。
|
||||
|
||||
### 正式成果
|
||||
|
||||
- Functional Test Report
|
||||
- Reliability Test Report
|
||||
- Specialized Test Report
|
||||
- Test Evidence Package
|
||||
- Defect Analysis Report
|
||||
|
||||
质量结论、回归和缺陷证据写入上述适用正式成果，不另立其他测试门禁成果。
|
||||
|
||||
### 门禁
|
||||
|
||||
测试对象、环境、范围、结果、证据、缺陷、复验和剩余风险可追踪；测试给出 PASS、FAIL 或 BLOCKED。测试通过不替代业务验收。
|
||||
|
||||
## 阶段 7：业务验收
|
||||
|
||||
### 正常任务链
|
||||
|
||||
1. 产品基于产品基线、平台结果和测试结论组织验收材料、用例、演示／试用和差异处置。
|
||||
2. 外部客户不是默认 Etunel 角色；客户输入由业务或产品真人负责人按联络边界取得，并返回对应角色会话。只有已契约化、由 Hub 负责人手动加入 Etunel 的客户角色才可接收任务。
|
||||
3. 问题由产品判断为需求理解、实现缺陷、环境问题或正式变更；Hub 只路由实际受影响角色，并从正确阶段返工。
|
||||
4. 产品形成验收报告和附条件事项；业务批准验收结论、上线／交付条件和业务风险接受。
|
||||
|
||||
### 正式成果
|
||||
|
||||
- Platform Test Approval Report
|
||||
- Customer Acceptance Approval Report
|
||||
- Conditional Acceptance Items
|
||||
|
||||
不适用的平台或客户验收成果按 NA／Artifact Waiver 规则处理，不能用内部测试自动替代。
|
||||
|
||||
### 门禁
|
||||
|
||||
平台与客户验收证据、差异、附条件事项、责任、期限和业务决定明确；未解决项有处置条件和承接人。
|
||||
|
||||
## 阶段 8：发布结项
|
||||
|
||||
### 正常任务链
|
||||
|
||||
1. Hub 只向实际参与、拥有正式成果、遗留风险或发布责任的角色派发发布／结项任务：
|
||||
- 应用层输出唯一最终发布固件和发布说明；
|
||||
- 底层归档实际被集成的版本和接口信息；
|
||||
- 硬件归档板卡、BOM、生产资料和适用 ECO；
|
||||
- 技术负责人确认最终版本组合与发布技术前提；
|
||||
- 测试对最终组合执行适用发布验证；
|
||||
- 产品确认发布范围与批准产品和验收一致；
|
||||
- 业务确认交付、合同、License、客户沟通和遗留责任。
|
||||
2. 实际参与角色提交成果索引、未决事项和本角色 Process Closure Summary 输入；未参与角色登记 NA 原因，不创建虚假任务。
|
||||
3. Hub 汇总归档、变更、结项报告和流程闭环总结，并完成必要确认。
|
||||
|
||||
### 正式成果
|
||||
|
||||
- Closure Documentation Archive
|
||||
- Change Log
|
||||
- Closure Report
|
||||
- Process Closure Summary
|
||||
|
||||
### 门禁
|
||||
|
||||
正式项目只有在适用交付、验证、批准、归档和遗留承接完成后才可关闭。模拟项目只记录 SIMULATION_COMPLETED，不得宣称真实发布、客户验收或生产就绪。
|
||||
Reference in New Issue
Block a user