最近几年一直都有很多关于“敏捷”如何在汽车行业应用的讨论，看了一些文章，大都是说“敏捷”在IT行业如何的成功、提升了多少效率、帮助多少企业脱颖而出，因此汽车行业也应该立即效法实施等等。可是是否应该实施、究竟该如何实施、现有的汽车软件开发流程如何改造等等却没有看到任何有一点价值的东西。
我们先看看现在标准的汽车行业开发流程，即所谓的标准“瀑布式开发流程” 究竟是什么样子的，为啥被全世界的OEM们用了这么多年。
瀑布是什么?
瀑布方法，也被称为线性顺序生命周期模型，是由其对项目管理的线性、结构化方法定义的。它由一系列在软件开发生命周期(SDLC)中按顺序完成的步骤组成。这些步骤通常通过甘特图可视化来跟踪。温斯顿·w·罗伊斯博士开发了这种方法，他在1970年的论文《管理大型软件系统的开发》中记录了这种方法。
自从它发表以来，各种各样的瀑布出现了，但在这个过程中，人们对以下步骤达成了普遍共识:
需求的收集:这个阶段需要在开发团队和客户或最终用户之间预先编写文档。在这个阶段，项目计划中的产品特性被详细地记录下来，使团队能够确定一个明确的成本和时间表。在双方对需求保持一致之后，在项目完成之前，开发团队和客户之间不会有任何通信。
设计:设计阶段包括两个步骤:逻辑设计和物理设计。在逻辑设计中，团队头脑风暴解决客户问题的可能方法。当开发团队就解决方案达成一致意见时，这些想法将转化为具体的技术任务，然后在整个团队中分发这些任务以构建物理设计。
实现:在下一阶段，开发人员开始基于前面步骤中开发的规范进行编码。
验证:此阶段测试确保代码按预期运行，并确保范围文档中的需求得到满足。开发团队检查代码中的错误，最终验证由客户端进行，以确保功能满足预期。
维护:当用户使用终端产品时，出现新问题时需要持续的支持。
如果将“瀑布”的前后工作对应起来，就得到了“V模型”。 “V模型”只是“瀑布”的变种，本质上还是按照时间和逻辑顺序的进行开发工作。
汽车行业的流程从整个产品的立项到SOP（量产），采用的就是V模型。这种模式也被全世界的OEM普遍接受，成为了标准。只是大家在细节上各有特点。至少都会在整个开发周期内分为：概念阶段、设计开发阶段和生产阶段。大体如下图所示。
因为汽车的设计开发中非软件类的开发工作数量巨大、对成本的控制和性能的实现至关重要，而且传统的汽车中软件比重也不高，所以上述的节点（Gate）设置中首要考虑的不是软件。汽车中的软件开发工作即使在现在也只是众多开发线中的一条。即使在“软件定义汽车”的概念越来越火的今天，软件开发也不是OEM的最主要工作。在所有的车型开发中，最多的钱一定还是投资在各种模具、验证和产线上的，这些与软件的关系都不大。
不得不提的一点是，由于一个车型的周期比较长，汽车上各个ECU的软件不是一下子就需要达到SOP的状态，而是分为多个阶段交样，每个阶段都有不同的目标并进行相应的验证，可以说是迭代增长的。而不是某些人说的那种：直到最后才进行验收。
而且，在每个Tier1的每次交样前，供应商的软件开发又会有N个小版本。
因此，我们所看到的大V模型是指整车级别的，在每个ECU的开发过程中，会有N个小V模型的迭代。
瀑布法的主要好处
1. 详细的产品需求和文档使新工程师能够快速、轻松地进入项目。
2. 文档为项目提供了清晰的范围，使项目经理能够与相关各方沟通预算、时间线和关键里程碑。
3. 为项目提供了按阶段划分的检查点。
4. 当前一阶段完成后，您只需要去关注后续阶段.
5. 它提供了一个模板，这个模板使得分析、设计、编码、测试和支持的方法可以在该模板下有一个共同的指导。
瀑布法的缺点：
1. 各个阶段的划分完全固定，阶段之间产生大量的文档，极大地增加了工作量。
2. 由于开发模型是线性的，用户只有等到整个过程的末期才能见到开发成果，从而增加了开发风险。
3. 通过过多的强制完成日期和里程碑来跟踪各个项目阶段。
4. 瀑布模型的突出缺点是不适应用户需求的变化。
瀑布法的主要挑战：
1. 客户可能会发现在项目开始时很难概述他们的所有需求，这导致了文档中的空白。
2. 如果产品没有达到预期，开发过程中最小的客户协作可能导致昂贵的更改。
3. 测试人员在过程的后期才能发现问题和bug，这可能导致架构级别的更改。
值得特别指出的是，上述的挑战在汽车行业并不是很突出，因为汽车行业更需要的是协调一致，所以在每个项目的前期会有充分的需求收集和确定的时间，而且车上的大部分基本功能都很清楚，很少存在要快速推出产品再后续更新的情况，否则上百个ECU就没有办法都能按时交样了。另外，由于汽车电子的发展是渐进式的，过去的几十年里面已经经过了无数个V模型的迭代。现在要解决的是电子电气系统的复杂性如何应对的问题。
而对于快速变化的IT行业则完全不同，一个队伍在开发一个APP或一个网站的时候根本不知道用户的需求是不是真的像他们想象的那样，所以就需要快速的推出原型产品来试水，再根据用户的反馈来进行相应的调整。这就需要使用“敏捷”进行应对。
什么是敏捷?
与瀑布式开发相反，敏捷（agile method）是由项目管理的迭代方法定义的。敏捷团队不是一开始就起草冗长的项目需求，而是将产品分解成具体的功能，然后在特定的时间限制下处理每一个功能，这就是所谓的sprint。
敏捷项目管理需要一个跨职能、自组织的团队，通常由5到9个成员组成。在每个sprint期间，他们一起开发了一个可工作的软件部分，该部分与之前迭代的其他功能代码相结合。在“冲刺”时间框的最后，团队向利益相关者（Stakeholder）演示他们的工作以获得反馈，允许他们在软件开发方法上更加灵活。由于团队可以获得频繁的反馈，他们可以在开发生命周期中调整产品路线图，以确保功能真正满足用户的期望。在瀑布式方法中，客户的参与通常与最终产品的交付同时进行，当需求被错误地解释或记录时，这可能是非常昂贵的代价。
当IT行业迅速发展的时候，有人发现瀑布式项目管理系统在某些情况下是无效的，并且在2001年，他们关于软件开发过程的想法在一份称为“敏捷宣言”的文章中被明确提出。他们强调了软件开发工作流中优先级的具体价值和原则，并产生了许多流行的敏捷框架，如Scrum、看板、功能驱动开发(FDD, Feature Driven Development)和极限编程。从那时起，敏捷软件开发越来越受欢迎，特别是与瀑布模型相比。
简单的说，敏捷开发以用户的需求进化为核心，采用迭代、循序渐进的方法进行软件开发。
敏捷开发的团队由以下主要角色构成：
产品负责人:这个团队成员代表了客户和企业的需求。通过制作用户故事，团队可以了解特性请求如何帮助解决特定问题，这些故事为团队制定了要处理的任务积压。这个人还根据故事对客户的价值对故事进行优先排序，从理论上讲，这些价值应该转化为企业的价值。当产品负责人以这种方式领导团队时，他们不会设定最后期限或指导团队如何交付工作。
Scrum master:这个团队成员促进了整个敏捷开发过程。与项目经理类似，这个人让团队专注于任务，确保团队在项目期间保持专注。他们也可以作为中立的一方来调解团队成员之间的分歧。例如，团队成员可能不同意在给定的sprint中承担多少任务。特别是产品负责人，可能会迫使团队承诺在给定的时间框架内交付超出他们能力的内容。在这些情况下，scrum管理员可以提醒团队成员他们在团队中的角色范围。
敏捷团队的其他成员：每个团队的成员构成可以不同，但通常包括来自不同领域的人员，如设计、分析、QA和开发。这些人一起协作决定要承担多少工作以及如何完成它。
Agile methodologies are also defined by the ways in which the team comes together. There are specific meetings which help facilitate the workflow across the team. Some of them include the following:
敏捷方法的一个显著特征是有一些特定的会议流程，从而可以帮助促进整个团队的工作。其中包括:
Sprint计划:在这个会议期间，团队聚集在一起决定哪些故事（Story）将成为当前Sprint的一部分。产品所有者将对用户故事进行优先级划分，团队的其他成员需要就他们在设定的时间段内可以完成多少和哪些用户故事达成一致。
每日站立（Daily standup）:这些简短的会议也被称为每日scrum。在这些签入（Check-ins）过程中，每个团队成员都要交流他们的个人进展，如已完成的任务、即将到来的任务，以及可能导致延迟的任何障碍或对外部的依赖性。
演示:这个会议展示了团队在sprint过程中完成的工作软件，可以是两周到四周的增量。产品所有者将确定用户故事是否满足“完成”的定义。如果没有，将更新产品的待办事项列表并补充所遗漏的内容。这也是团队向利益相关者提供反馈的机会。
回顾:这段时间是留给团队自省的，团队在此确定如何改进他们的工作流程，以在未来获得更好的结果。
敏捷开发的优点：
1. 高适应性，以人为本，团队设计促进了更多的合作。
2. 更加灵活并且更加充分的利用了每个开发者的优势，调动了每个人的工作热情。
3. 由于代码在开发阶段的每个迭代中都要进行测试，所以代码缺陷可以迅速的列入未来的软件的开发计划中。
4. 往往会产生更高的客户满意度，因为频繁的反馈会增加客户需求的优先级。
5. 这种精益的软件开发可以降低成本，因为与客户期望的不一致的风险更小。
敏捷开发的缺点：
1. 对于文档的重视不足。由于其项目周期很长，所以很难保证开发的人员不更换，而没有文档就会造成在交接的过程中出现很大的困难。若项目人员流动性太大，又给维护带来不少难度。
2. 需要项目中存在经验较强的人，否则在大或复杂的项目中容易遇到瓶颈问题。
3. 只适合小团队作战。难以应对大规模的开发任务。
观点：
从上述的分析中，我们可以看到：
1. 传统的汽车软件开发并不是没有迭代的
2. 敏捷是通过不断地设立“小目标”的方式，实现小步快跑，通过不断的从客户处获得反馈来保证最终的交付能够满足用户的期望目标
3. 由于汽车软件中的基础功能通常都是需求非常明确的，而且长期基本不变，不需要通过敏捷来试错
4. 纯软件项目由于更改方便，更适合敏捷
5. 敏捷只能部分应用于需求不明确、需要通过快速迭代来试错的领域
如果人类是从现在才开始设计汽车软件，那么采用敏捷也许是一个好主意，可以快速的打下基础，但是相关硬件成本的投入和超大规模的不同团队合作的问题还是难以通过敏捷来解决。
汽车软件中极少有由一个单一控制器独立实现的，整车软件开发需要大规模协作，如果没有文档作为需求的传递，将难以开展协同工作。
另外，汽车特殊的安全性要求和大批量的特点，决定了一切要以安全为首要目标，因此，TS16949中对开发过程交付物有着具体而明确的存档要求，欧美法规也有对设计过程的管控要求和责任追究制度。因此，没有文档支撑的开发是难以在汽车行业活下去的。至少ASPICE的部分要求还是逃不掉的。
建议和结论：
上述的分析并不是说汽车行业就完全不能实施敏捷，可以在某些领域进行适当的敏捷：
- 在快速迭代的领域适当进行：多媒体中的APP，智驾中的部分功能的原型开发都是与硬件关联度不高的，可以结合MIL（Model In Loop，模型在环仿真）的实施来尝试“敏捷”。
- SOA中的部分服务在接口需求明确的情况下可以在开发阶段进行敏捷的尝试。
然而，汽车软件敏捷团队中的人一定有维护文档的职责，而且要列入绩效，不能只关注结果。汽车软件开发不是“一锤子买卖”，是一个需要有责任感的工作，而且是可能要负法律责任，对质量和安全要有最起码的敬畏心。不但要满足文档与法规的要求，还要做好Knowhow传承，以及满足长期维护的需求。
敏捷是为了应对需求的不明确，那么，如果有良好的架构设计，又有清晰正确的需求，就不需要“敏捷”。
开发中可以参考部分敏捷的做法和思想：更任务导向的组织机构设计、减少管理的层级、协同工具的使用（相比于看板，我觉得好的软件工具链效率更高，而且可以追溯和便于大家远程协作）、每日例会、持续集成、快速反馈等。
