工业级项目管理

1 简介

市面上项目管理书籍、博文等多是互联网的，管理经验和严谨程度和工业级、车规级还是有差距的。目前做工业级产品，故想总结一下管理流程，尽力严谨！

2 车规级规范

汽车工业中关键安全部件(Safety Critical Parts)的控制软件开发规范

所谓“关键安全部件”，通俗点说就是出了问题要死人的部件，比如发动机、变速箱、转向系统、安全气囊、刹车系统等等。与之相对的非关键部件，则包括电动车窗、空调系统、音响系统什么的。

2.1 行业标准（V Model）

关键安全部件的软件设计流程的行业标准有2个，aSPICE （Automotive Software Process Improvement and Capability Determination） 和 功能安全标准ISO26262 中的软件部分（(Road vehicles – Functional safety - Part 6）。几乎所有整车厂和绝大部分汽车零配件供应商都参考这两个标准来制定自己的软件设计流程。而越来越多的整车厂——比如德国大众——采购零部件的基本门槛之一就是供应商的软件设计流程通过了aSPICE认证。

aSPICE流程

软件开发过程可以被拆分为需求分析——架构设计——单元设计——单元测试——软件集成和集成测试，以及最后的软件综合测试，每个步骤依次进行。

ISO26262流程

aSPICE 和 ISO26262 在业内一般统称为“V”型开发流程 （The V Model）。

2.2 V Model 特点

分层开发验证

需求文档和需求验证相对应，是第一层级；
架构设计和集成测试相对应，是第二层级；
单元设计与单元测试相对应，是第三层级。
V型流程要求，同一层级的开发与测试，由同一个（或一组）责任人负责。
如，架构师除了参与架构设计，还要制定集成测试用例 （Test Case），并且在集成测试完成后审阅测试报告；
如，参与单元设计的工程师除了写代码，还要写单元测试用例，并且审阅单元测试报告。
该流程的设计是为了最大限度的保证软件被可靠而完整的验证，降低由沟通不畅而引发设计缺陷的可能。

极强的可追溯性

理论上在最终发布的代码中任意选择一个语句，都能够快速地确定它是实现哪项软件设计，对应哪一条软件需求，进而对应哪一条客户需求；另一方面，这条语句被哪个单元测试用例测试过，进而又对应哪条集成测试用例，也必须是清晰明了的。而所有这些信息还必须包括对应的责任人、审阅人、日期及必要的备注。
这样设计流程的目的，一方面是为了在团队高流动性的情况下，新人能够快速、准确的上手；更重要的是为了在出现问题以后，能够快速而全面的做出故障分析，得出故障的根本原因。

2.3 按部就班甚少

知乎博主 木城 所分享经历来看，按部就班完全遵循了aSPICE和ISO26262 part6流程者甚少，我工作接触的一级供应商企业（雷诺子公司）也是没有按部就班，我当时公司也在搞ISO26262 part6，还挖了汽车行业的项目经理，最终太难执行。
ISO26262 part6 和aSPICE。前者现在是发布汽车相关软件必须遵守的标准，而后者基本上只有大众、戴姆勒等几家德国车企才强制要求（内部能否完全执行这些流程带考究）。

2.4 V Model 弊端

• 灵活性差
  需求确定，架构设计才开始，架构确定，单元设计才开始，层级依赖在实际项目里容易造成窝工。
• 开头难
  项目启动，先冻结需求，对需求工程师的要求太高，造成项目开头难。
• 易加班赶进度
  实际开发，需求变动，人员变动是常见的，加班赶进度便是家常便饭，除非公司能强势抗住产品延期发布带来的后果。

3 工业级规范

3.1 前提

• 需求不可能冻结
• 市场推动产品，产品推动市场
• 技术服从进度

3.2 保V型核心再微调

V型核心：分层验证，可回溯性
微调（敏捷开发）：可回溯性上，可以先代码后文档

3.3 例会跟踪进度

项目周一例会，确定总进度
小组周一周三例会，确定模块进度
最终会议纪要，邮件更新

3.4 文档

需求文档、设计文档、测试文档、进度文档
责任人、审阅人、日期及必要的备注

进度文档：含甘特图
设计文档：UML

4 思考

技术服从进度
工业级产品与商业级产品区别
知识广度是深度的副产品
市场推动产品，产品推动市场

参考

1、华为硬件开发
2、《人月神话》精简
3、国内IT项目开发流程
3、写工业级别代码是怎样一种体验？
4、大型公司开发软件的流程是怎样的？
5、酷壳–这多年来我一直在钻研的技术
6、一套文档–语雀