“敏捷”适用于汽车软件开发吗.docVIP

“敏捷”适用于汽车软件开发吗？ 最近几年一直都有很多关于“敏捷”如何在汽车行业应用的讨论，看了一些文章，大都是说“敏捷”在IT行业如何的成功、提升了多少效率、帮助多少企业脱颖而出，因此汽车行业也应该立即效法实施等等。可是是否应该实施、究竟该如何实施、现有的汽车软件开发流程如何改造等等却没有看到任何有一点价值的东西。 我们先看看现在标准的汽车行业开发流程，即所谓的标准“瀑布式开发流程” 究竟是什么样子的，为啥被全世界的OEM们用了这么多年。 瀑布是什么? 瀑布方法，也被称为线性顺序生命周期模型，是由其对项目管理的线性、结构化方法定义的。它由一系列在软件开发生命周期(SDLC)中按顺序完成的步骤组成。这些步骤通常通过甘特图可视化来跟踪。温斯顿·w·罗伊斯博士开发了这种方法，他在1970年的论文《管理大型软件系统的开发》中记录了这种方法。 自从它发表以来，各种各样的瀑布出现了，但在这个过程中，人们对以下步骤达成了普遍共识: 需求的收集:这个阶段需要在开发团队和客户或最终用户之间预先编写文档。在这个阶段，项目计划中的产品特性被详细地记录下来，使团队能够确定一个明确的成本和时间表。在双方对需求保持一致之后，在项目完成之前，开发团队和客户之间不会有任何通信。 设计:设计阶段包括两个步骤:逻辑设计和物理设计。在逻辑设计中，团队头脑风暴解决客户问题的可能方法。当开发团队就解决方案达成一致意见时，这些想法将转化为具体的技术任务，然后在整个团队中分发这些任务以构建物理设计。 实现:在下一阶段，开发人员开始基于前面步骤中开发的规范进行编码。 验证:此阶段测试确保代码按预期运行，并确保范围文档中的需求得到满足。开发团队检查代码中的错误，最终验证由客户端进行，以确保功能满足预期。 维护:当用户使用终端产品时，出现新问题时需要持续的支持。 如果将“瀑布”的前后工作对应起来，就得到了“V模型”。?“V模型”只是“瀑布”的变种，本质上还是按照时间和逻辑顺序的进行开发工作。 汽车行业的流程从整个产品的立项到SOP（量产），采用的就是V模型。这种模式也被全世界的OEM普遍接受，成为了标准。只是大家在细节上各有特点。至少都会在整个开发周期内分为：概念阶段、设计开发阶段和生产阶段。大体如下图所示。 ? 因为汽车的设计开发中非软件类的开发工作数量巨大、对成本的控制和性能的实现至关重要，而且传统的汽车中软件比重也不高，所以上述的节点（Gate）设置中首要考虑的不是软件。汽车中的软件开发工作即使在现在也只是众多开发线中的一条。即使在“软件定义汽车”的概念越来越火的今天，软件开发也不是OEM的最主要工作。在所有的车型开发中，最多的钱一定还是投资在各种模具、验证和产线上的，这些与软件的关系都不大。 不得不提的一点是，由于一个车型的周期比较长，汽车上各个ECU的软件不是一下子就需要达到SOP的状态，而是分为多个阶段交样，每个阶段都有不同的目标并进行相应的验证，可以说是迭代增长的。而不是某些人说的那种：直到最后才进行验收。 而且，在每个Tier1的每次交样前，供应商的软件开发又会有N个小版本。 因此，我们所看到的大V模型是指整车级别的，在每个ECU的开发过程中，会有N个小V模型的迭代。 瀑布法的主要好处： 详细的产品需求和文档使新工程师能够快速、轻松地进入项目。 文档为项目提供了清晰的范围，使项目经理能够与相关各方沟通预算、时间线和关键里程碑。 为项目提供了按阶段划分的检查点。 当前一阶段完成后，您只需要去关注后续阶段. 它提供了一个模板，这个模板使得分析、设计、编码、测试和支持的方法可以在该模板下有一个共同的指导。 瀑布法的缺点： 1. 各个阶段的划分完全固定，阶段之间产生大量的文档，极大地增加了工作量。 2. 由于开发模型是线性的，用户只有等到整个过程的末期才能见到开发成果，从而增加了开发风险。 3. 通过过多的强制完成日期和里程碑来跟踪各个项目阶段。 4. 瀑布模型的突出缺点是不适应用户需求的变化。 瀑布法的主要挑战： 客户可能会发现在项目开始时很难概述他们的所有需求，这导致了文档中的空白。 如果产品没有达到预期，开发过程中最小的客户协作可能导致昂贵的更改。 测试人员在过程的后期才能发现问题和bug，这可能导致架构级别的更改。 值得特别指出的是，上述的挑战在汽车行业并不是很突出，因为汽车行业更需要的是协调一致，所以在每个项目的前期会有充分的需求收集和确定的时间，而且车上的大部分基本功能都很清楚，很少存在要快速推出产品再后续更新的情况，否则上百个ECU就没有办法都能按时交样了。另外，由于汽车电子的发展是渐进式的，过去的几十年里面已经经过了无数个V模型的迭代。现在要解决的是电子电气系统的复杂性如何应对的问题。 而对于快速变化的IT行业则完全不同，一个队伍在开发一个APP或一个网