汽车领域：双态敏捷开发模型
01
汽车软件开发面临的问题与挑战
汽车产业经历了从机械时代到电子时代、到如今迈入软件时代的发展历程。这一过程中汽车软件的形态由和硬件深度耦合的方式演变为与硬件解耦，并逐渐向面向服务的架构（SOA）演进，同时复杂度也呈指数级不断攀升。
“软件定义汽车”的时代，软件在整车制造中的重要性日渐凸显。但不同于其他行业的软件开发，汽车行业有自己独特的软件开发要求。首先是需求严谨、需求层次复杂、需要通过专业的工具进行管理；其次开发团队技术栈需覆盖多个领域，一整套嵌入式软硬件开发的解决方案，涉及硬件设计开发、基础软件开发、上层应用软件开发等，各团队之间技术栈差异极大；最后还要求不同领域/团队之间协同紧密，即使是一个简单的功能开发，可能需要涉及多个领域协作完成。
在此背景下，传统的瀑布模型与缩短上市周期、基于消费者需求需快速迭代等要求相矛盾。无论是主机厂还是汽车零部件供应商，都需要更加高效、同时可支撑更高质量和更高安全要求的软件产品开发所对应的开发模型。
02
双态模型解决方案
1．敏捷、瀑布和双态开发模型对比
瀑布开发模型
优点：
1. 阶段清晰。从计划到开发到最后的上线，各个阶段非常清晰。
2. 时间顺序明确。每个阶段顺序必须是从上到下，严格按照时间先后进行。
3. 环环相扣。每一个阶段都必须有产出物然后才能进入下一个阶段。
4. 黑盒开发。每个阶段都有各自的分工，各自关心自己的任务。
缺点：
1. 需求隔离。由于各阶段只能接触到自己工作范围的内容，所以对客户的需求理解不成体系，容易出现偏差。
2. 变更代价大。项目中出现的变更，容易导致项目从需求分析开始再次实施，一方面时间成本高，另外容易让开发人员滋生抵触情绪。
3. 项目初始阶段，需求不明确。实际项目的初始阶段，客户很难一次性给出详尽的需求，该模型实施会存在很多困难。
4. 测试暴露问题晚。测试集中在瀑布模型后半段执行，缺乏全程测试思想，导致问题暴露晚。
敏捷开发模型
优点：
1. 更快的交付价值。用户很快可以看到一个基线架构版的产品，客户前期满意度高。
2. 更低的风险。可及早规避风险，前提是存在良好的信息传递渠道。
3. 可积极应对变化。项目组内部和外部之间有良好的沟通渠道，中途的修改是容易的。
4. 持续改进。敏捷流程自身可在进行过程中不断改进和精炼。
5. 更高的客户满意度。客户参与度高，能及时根据客户的反馈进行调整。
6. 更高的团队满意度。有助于项目组的学习和提高，团队成员有机会在整个生命周期中边做边学，各显其能。
7. 更好的质量。积极应对客户的需求，调整开发出更符合客户期望的产品。
缺点：
1. 资源规划困难。由于项目初期无法明确划定项目范围，因此很难进行准确的资源规划。
2. 文档不足。敏捷宣言“工作的软件高于详尽的文档”和汽车行业的开发规范《ISO26262》功能安全要求以及ASPICE标准存在天然的冲突。
3. 团队人数限制。敏捷开发一般适用于10人以下，不适合需要很多人参与的大型或复杂项目。
4. 人员素质要求高。要求团队成员有全面的工作技能、优秀的沟通能力以及一定的主观能动性。
5. 客户参与度高。需要依赖客户积极参与整个开发周期。
双态敏捷开发模型
优点：
1. 初期可清晰定义项目框架、预算和交付时间。开发过程中可通过敏捷方式激发工程师的热情，加速设计和开发。
2. 成本相对较低。一方面可以在遵守行业标准的同时能缩短上市时间，达到兼顾质量和效率等多方面要求的目的。另外一方面，通过不停交付工作产品，保持与客户的频繁沟通，降低了项目潜在风险成本。
3. 项目目标可灵活调整。可积极应对需求变更并能及时调整项目目标，使其与战略目标始终保持一致。
4. 可加强团队协作。混合模型需要两种类型的团队之间的紧密协作，也会促进和客户的合作方式的改变，真正地实现共同开发。
缺点：
1. 人员素质要求高。要求团队所有成员具备优秀的知识储备、技能储备并熟悉敏捷和瀑布的开发流程。
2. 沟通渠道要通畅高效。双态开发模型需要不同类型的团队之间紧密协作，对团队间沟通能力要求较高。
3. 项目管理工具要求高。需要成熟可靠的在线管理工具让双态开发实际落地。
2．双态敏捷开发模型解决方案
双态敏捷开发模型可用于以下几种典型场景：
场景一：用户需求初始模糊，随着开发的演进，需求变更频繁。
场景二：该产品由具有相同重要性的硬件和软件组件组成（两者都不占主导地位）。
场景三：该产品是一款涉及复杂后端和前端技术的软件（在这种情况下，后端将使用瀑布模型开发）。
场景四：可能不是基于项目本身的特征。在通常情况下，客户不会干扰项目的执行方式，因此可以使用敏捷与瀑布融合的开发模型。例如，瀑布方法可用于应用产品规划、需求定义和设计，而敏捷可用于开发和测试。
如上所述，由于没有一刀切的解决方案，实施双态敏捷开发模型方法需要因地制宜，根据项目本身特性进行灵活部署，同时在其他人的失败案例中吸取教训，作为最佳实践指导。根据我们在实际项目中的推进经验，以下建议可供参考：
制定计划，需求分析与设计阶段可以通过瀑布模型完成，开发与测试阶段采用敏捷开发以迭代或增量开发的方式通过短期的冲刺来完成；
产品负责人和客户定期进行沟通，确保所有干系人都深度参与本产品的整个开发生命周期；
从设计阶段开始融合标准、法律法规等要求。可以通过功能强大的工作流管理工具保证整个生命周期执行已定义的合规流程以达到加快产品开发的目的；
使用协作软件作为支持数据共享、通信和可追溯性的解决方案，同时也需要根据新的协作工具同步更新交流方式。
3．汽车行业应用解决方案
如上所述，通常认为使用瀑布进行整体项目开发是一种可靠的模型，但敏捷模型却可以赋予软件开发可受益的灵活性。软件生命周期管理工具、自动集成CI/CD和自动化测试系统的打通，能大大减少时间成本，提升软件产品品质。利用工具自动化生成符合功能安全或ASPICE要求的各种检查记录及文档，使得在敏捷的产品管理中也不会忽视瀑布模型的要求。
在汽车基础软件领域，有很多软件具备可复用的特点。汽车软件服务商要建立企业软件产品库，针对不同客户的不同需求可很快拿出相似产品的原型版本进行功能展示。这样，不仅能提升开发的效率，而且也符合敏捷思想。在后面的项目开发实际开始时，可基于该原型版本，采用敏捷迭代开发模式，运用用户故事、故事点和燃尽图等敏捷开发工具可助力项目的正常进行。当开发开始后，同时开展测试相关流程，可及时发现问题，最终确保将优质产品交付给客户。
借助软件生命周期管理工具，可根据项目范围、质量要求、功能要求对开发流程做适当的适配。此外，该工具还可以提升问题管理、变更管理和文档记录管理等流程的效率。同时使用软件生命周期管理工具也能促进工程开发活动的效率提升，如自动集成、自动测试、伪代码和代码框架的生成等。
4．意义与展望
无论是瀑布模型还是敏捷模型，都无法在当今的软件定义汽车趋势中完美的满足需求。汽车行业的要求不同于一般互联网行业的开发要求，需既要考虑进度，也要同时兼顾质量和安全。
瀑布模型和敏捷模型有各自的适用场景。在传统汽车软件范围，瀑布模型之所以能得到很好的应用，是因为传统的汽车ECU功能分配趋于完善，各种功能需求已经很明确，并且硬件平台趋于大同，传统的软件功能不会有太多变化，因此瀑布模型很适合于传统的ECU开发。
但是在“软件定义汽车”的时代背景下，会遇到很多需求不明确的场景，项目范围的频繁变更更是让传统的瀑布模型无法应对。因此引入敏捷模型的思想，借鉴它可以很好的适应需求变化，快速打造产品原型，以及可灵活的在需求的变化中进行不断迭代的特点，将其融入到传统的瀑布模型中，形成了现在的双态开发模型。可以让汽车软件开发在适应需求变化的同时重拾对质量追溯文档记录的重视。
“瀑布式计划，敏捷执行，并加快整个过程。”双态敏捷开发模型以敏捷思想的框架，在每一个迭代中融入瀑布模型，既解决了单一的瀑布模型不能适应需求不明确的情况，也解决了单纯敏捷模型带来的文档化不足的问题，让项目风险可更早的被监控到，可用的工作产品能更早地展示给客户。
文章来源：
AUTOSEMO《中国汽车基础软件发展白皮书3.0》
