一、前言

作为负责人，熟悉项目流程便于提前规划和风险控制，有利于更好的把控项目。作为工程师，了解项目流程也可以明确项目进度和紧急程度，利于更好的开展自身工作，以及明确自身工作的优先级，为后续软件负责人做储备。本文以软件负责人的角度，介绍嵌入式项目开发周期和流程。

二、项目周期

常规的项目流程如下：

汇总各阶段中的内容和注意事项：

2.1 项目立项

• 明确需求

项目立项有产品提出，研发需要与产品battle，对于产品做成什么样，形成清晰的认识，对需求进行评估，分强需求和弱需求，哪些功能出货必须带，哪些后续可以OTA。 以及结合项目周期和功能难度和工作量，对需求做减法。

• 工作量摸底

其次对于需求对应功能，初步拆分任务和分类，对于工作量做初步摸底，新的东西工作量就会大，心中有数：

功能分类	特点
已有功能适配	完全已知，可控，工作量小，适配方案明确
已有功能移植	半已知，已有功能移植，移植适配点有风险和工作量。
新功能开发	完全未知，工作量大，风险高。需要经历调研、需求分析、方案设计和开发、测试设计。

• 风险和难点评估

”未知的东西工作量大，风险高。“

在立项过程中对于风险和难点需要进行评估，未知的是风险，新的东西是风险所在。可能本身并不难，但是认知需要时间。所以即使功能简单工作量评估也不能太保守。将未知的可能的风险列出来，做提前的预案和设计。

2.2 前期评估

立项前其实就需要对项目进行评估，功能需求可行性，CPU选型等进行评估。

评估点：

1）是否能满足需求

2）工作量评估

3）风险和难点评估

4）各功能适配点评估

评估对象：

• 硬件

1）CPU选型：

功能：datasheet CPU宣称功能是否能够满足需求

性能：内存评估（DDR带宽和容量是否满足软件需求）和CPU算力评估（DMIPS可选芯片间对比）。

CPU选型：研发提供功能和性能可用的，有产品和采购综合考虑价格等因素，可能最终选择的不是最强的，而是性价比最高的芯片方案。

2）原理图评审

软件需要参与原理图评审，如GPIO使用、I2C总线使用等是否符合软件需求等等。

• SDK：

SDK主要对应供应商的驱动代码，这部分需要查找相似性，还是在探究**“新”**的东西，新的东西工作量大和风险高。

对比代码差异的话，可以使用git做提交对比，给出数据支撑，避免个人标准和认知差异，导致差异大和小的理解不同，做到工作留痕。

• 对比大法

不同芯片之间对比，与已有机型方案之间对比芯片和驱动之间对比，形成认识。否则芯片性能是否达到需求这件事不容易评估。

2.3 项目计划

项目计划需要做任务拆分和工作量评估，以及里程碑设置。

• 任务拆分

1）工作量预估：要有参考（参考过往项目时间），讨论，以及考虑人力竞争，确认净投入时间和持续时间。

2）新功能开发周期：新功能一般需要调研、需求分析、方案设计和开发、测试设计等步骤，开发周期会长一些。

3）把握重难点问题：分析和预研重难点，发起讨论。

4）SMART原则：任务安排注意遵循SMART原则，人员安排需要具有相关性，以及工作难度和人员能力相匹配。

5）发现任务阻塞点：合理规划任务开展时间，找到任务之间的阻塞点，保证并行开展。

• 里程碑

设置每轮的开发目标，形成阶段性成果。通知项目组成员明确时间目标，严格按照时间开展。

任务	内容	时间计划	工程师
任务1
任务2
QA提测1	集成xxx功能
QA提测2	集成xxx功能
软件发布
试产

2.4 bringup

新的芯片方案bringup工作，详情可参考此文章嵌入式系统bringup通用流程

项目一前一后时间紧迫感比较强：bringup和上线。bringup 未知东西多，容易不可控，所以需要严格按照时间推进，有阻塞问题及时汇报。

2.5 开发和QA提测

开发和QA提测阶段有如下注意事项：

1、每日汇报

2、进度控制

3、卡点解决

4、聚焦疑难问题

5、方案评审，工作留痕，勿留话柄。

6、质量控制

7、测试方案讨论和跟进

8、bug解决

9、及时调整

10、风险控制成果固化

• 每日汇报

工程师汇报模版如下，每天汇报进展和卡点，便于负责人及时知晓，对于卡点问题协调支援。对于进度不符合预期及时跟进等，汇报很重要。

每日进展
明日计划
问题卡点
方案讨论
思考总结
相关链接

• 聚焦疑难问题

负责人精力要投在难点上，其他简单事要分出去。对于疑难问题寻求外部支援，发起讨论。对于新方案需要评审，进行“分锅”，避免一人独自决策背锅。工作留痕，邮件、会议等做好记录。

• 测试跟进

研发自测bug和测试部测试bug都需要管理起来，测试bug要更严格，研发自测bug管理更宽松松一些。注意QA提测后跟进测试计划和测试进度。避免测试进度不达预期影响项目进度。

• 及时调整

项目管理的精髓在于调整协调，以下两种情况下需要及时调整。

1）需求无法实现时，及时讨论调整需求或实现方案。

2）计划无法满足时，及时汇报调整计划。

其他tips：

1）成果固化：QA提测后注意成果固化下来，提测时注意保留，提测后方案不宜大改。
2）给予资源：注意给工程师资源如资料、指导，一起解决疑难问题，并肩作战。

2.6 软件发布

功能开发完成，测试bug基本修复完成之后，就需要准备软件发布工作。软件发布过程有可能还会修一些严重的紧急问题，此时注意的是风险控制，由于试产时间交期很紧，拉出hotfix分支，用于修复紧急问题。切勿带上其他问题，导致bug不断，软件一直无法发布的情况。

2.7 试用

软件ok后可以组织试用，为了鼓励试用，可以做一些激励措施，比如一些礼品之类的。否则试用反馈bug可能不积极，没有预想中的那么好。

2）周期性收集试用报告和bug反馈

3）bug反馈做记录跟踪

2.8 小批试产

小批试产的目的是验证硬件性能和质量，以及发现并修复软件严重bug，软件可以考后续OTA升级解决，但是硬件一旦出货不容有大问题。所以需要试产验证。

试产一般内容：

1）产测：核心硬件器件功能、外设按键、无线校准、样机MAC和ID写入等。

2）老化测试和稳定性测试：高低温开关机、老化测试稳定性

3）性能测试：如路由器转发丢包问题等、吞吐量测试。

4）运输实验：整箱、单个跌落等测试。

2.9 量产

试产问题解决后才允许量产，量产流程则主要过产测，不再做实验。

2.10 维护迭代

• 分支管理

软件维护注意分支管理，分支管理参考文章：嵌入式git分支管理策略-CSDN博客

1）紧急问题修复，基于hotfix分支快速修复。

2）普通bug集中修复，以及功能优化等，基于开发分支，定期刷新维护，一般一个季度发布一轮固件的频次。

• 市场反馈问题

市场反馈问题解决需要高优先级处理，通用的处理流程参考文章：解决技术问题思路-CSDN博客

调试手段准备：

需要为市场反馈问题做预案，提前准备调试工具、调试命令、典型问题分析案例。

2.11 项目汇报模板

整体进度
下一步计划
整体计划
任务进展
关键问题
瓶颈和解决方案
项目风险和预案
供应商沟通问题
方案评审
人力安排
质量优化