来源 | 侯哥工作经历
志全 | 加入“软件群”请加微信13636581676并备注软件
（来源：Bing）
近几年，关于如何将“敏捷”应用在汽车行业的讨论很多，我看过一些文章软件开发技术文档模板，大部分都是在说“敏捷”在IT行业有多成功，提升了多少效率，让多少企业脱颖而出，因此汽车行业也应该立刻实施。但是，关于是否应该实施、如何实施、如何改造现有的汽车软件开发流程等，我并没有看到什么有价值的东西。
我们先来看一下目前标准的汽车行业开发流程，即所谓标准的“瀑布式开发流程”，以及为什么它被世界各地的主机厂使用了这么多年。
什么是瀑布？
瀑布方法，也称为线性顺序生命周期模型，以其线性、结构化的项目管理方法定义。它由一系列在软件开发生命周期 (SDLC) 期间按顺序完成的步骤组成。这些步骤通常通过甘特图可视化进行跟踪。Winston W. Royce 博士开发了这种方法，并在 1970 年的论文《管理大型软件系统的开发》中进行了记录。
自其出版以来，出现了各种瀑布，但对于该过程的以下步骤，人们普遍达成了共识：
需求收集：此阶段需要开发团队与客户或最终用户之间预先编写文档。在此阶段，项目计划中的产品功能将详细记录，以便团队确定明确的成本和时间表。一旦双方就需求达成一致，开发团队和客户之间就不会再进行沟通，直到项目完成。
设计：设计阶段包括两个步骤：逻辑设计和物理设计。在逻辑设计中，团队集思广益，提出解决客户问题的可能方案。当开发团队就某个解决方案达成一致时，这些想法就会转化为具体的技术任务，然后将这些任务分配给整个团队，以构建物理设计。
实施：在下一阶段，开发人员根据前面步骤中制定的规范开始编码。
验证：此阶段的测试可确保代码按预期运行，并满足范围文档中的要求。开发团队检查代码中的错误，最终验证由客户进行，以确保功能符合预期。
维护：当用户使用最终产品时，如果出现新问题，需要持续的支持。
如果把“瀑布”前后的工作对应起来，就得到了“V模型”。“V模型”只是“瀑布”的一种变种，本质上开发工作还是按照时间顺序和逻辑顺序进行的。
汽车行业从项目立项到整个产品的SOP（量产）都采用V模型，此模型也得到了全球各大主机厂的广泛接受，成为标准，但在细节上各有特色，至少在整个开发周期分为：概念阶段、设计开发阶段、生产阶段，大致如下图所示。
因为汽车设计开发中非软件开发工作量巨大，成本控制和性能实现至关重要，而传统汽车中软件占比并不高，所以上述节点（Gate）设置中首先考虑的并不是软件。即便现在，汽车中的软件开发也只是众多开发线中的一条。即使在“软件定义汽车”概念越来越火爆的今天，软件开发也并非主机厂的主要工作。在车型开发中，大部分的钱都要投入到各种模具、验证、生产线上，这些都和软件关系不大。
必须要提到的一点是，由于一个车型的生产周期比较长，所以车辆上每一个ECU的软件并不需要一次性全部达到SOP状态，而是分多个阶段进行交付，每个阶段都有不同的目标并进行相应的验证，可以说是迭代成长，而不是有些人说的：到最后才进行验收。
而且，在每个Tier 1交付样品之前，供应商的软件开发都会有N个小版本。
所以我们看到的大V模型指的是整车级别的，每个ECU在发展过程中，都会有N个小V模型的迭代。
瀑布方法的主要优点
1.详细的产品需求和文档使新工程师能够快速轻松地进入项目。
2. 该文件为项目提供了明确的范围，并使项目经理能够与所有相关方沟通预算、时间表和关键里程碑。
3. 为分阶段的项目提供检查点。
4.当前阶段完成后，只需要关注后续阶段。
5、它提供了一个模板，使得分析、设计、编码、测试和支持方法在这个模板下有一个共同的指导方针。
瀑布方法的缺点：
1.各个stage的分工完全固定，而stage之间会产生大量的文档，大大增加了工作量。
2、由于开发模式是线性的，用户在整个过程的最后才能看到开发结果，增加了开发风险。
3. 跟踪项目阶段时，设置过多的强制完成日期和里程碑。
4、瀑布模型的突出缺点是不能适应用户需求的变化。
瀑布方法的主要挑战是：
1. 客户可能发现在项目开始时很难概述他们的所有要求，这导致文档中出现差距。
2. 如果产品不符合预期，开发过程中的客户协作最少，可能会导致代价高昂的变更。
3. 测试人员在流程后期发现问题和错误，这可能会导致架构级别的变化。
值得指出的是，上述挑战在汽车行业并不是特别突出，因为汽车行业对协调性和一致性的要求更高，因此在每个项目前期都有充足的时间收集和确定需求，而且大部分基础功能都非常明确，很少出现需要快速推出产品，后期再更新的情况，否则根本没办法按时交付几百个ECU，另外由于汽车电子的发展是循序渐进的，过去几十年V型模式经历了无数次迭代，现在需要解决的是如何应对电子电气系统的复杂性的问题。
对于瞬息万变的IT行业来说，情况则完全不同。当团队在开发一款应用或网站时，他们并不知道用户的需求是否真的是他们想象的那样，所以需要快速推出原型来试水。然后根据用户的反馈做出相应的调整。这就需要用“敏捷”来应对。
什么是敏捷？
与瀑布式开发不同，敏捷开发采用迭代式项目管理方法。敏捷团队不会在一开始就起草冗长的项目要求，而是将产品分解为具体功能，然后在特定时间限制内交付。对每个功能进行开发，这称为冲刺。
敏捷项目管理需要一个跨职能、自组织的团队，通常由 5 到 9 名成员组成。在每个冲刺期间，他们共同开发一个可工作的软件，该软件与来自以前迭代的其他功能代码相结合。在冲刺时间框架结束时，团队将他们的工作展示给利益相关者以获得反馈，从而使他们在软件开发方法上更加灵活。由于团队可以获得频繁的反馈，因此他们可以在开发过程中调整产品路线图，以确保功能真正满足用户的期望。在瀑布方法中，客户参与通常与最终产品的交付同时进行，当需求被错误解释或记录时，这可能会非常昂贵。
随着 IT 行业的快速发展，一些人发现瀑布式项目管理系统在某些情况下是无效的，并在 2001 年，他们关于软件开发过程的想法在一份名为“敏捷宣言”的文件中得到阐述。他们强调了优先级在软件开发工作流程中的具体价值和原则，并导致了许多流行的敏捷框架，例如 Scrum、看板、特性驱动开发 (FDD) 和极限编程。敏捷软件开发越来越受欢迎，尤其是与瀑布模型相比。
简单来说，敏捷开发关注用户需求的演变，采用迭代、循序渐进的方法进行软件开发。
敏捷开发团队由以下主要角色组成：
产品负责人：该团队成员代表客户和企业的需求。团队通过生成用户故事来了解功能请求如何帮助解决特定问题，从而为团队创建待处理的任务积压。此人还根据故事向客户提供反馈。产品负责人根据故事的价值对故事进行优先排序软件开发技术文档模板，理论上这应该转化为业务价值。当产品负责人以这种方式领导团队时，他们不会设定截止日期或指导团队如何交付工作。
Scrum 主管：该团队成员负责促进整个敏捷开发过程。与项目经理类似，该人员负责确保团队专注于任务，并确保团队在项目期间保持专注。他们还可以充当中立方，调解团队成员之间的分歧。例如，团队成员可能对在给定冲刺中应承担多少工作存在分歧。特别是产品所有者可能会向团队施压，要求他们承诺在给定的时间内交付超出其能力范围的工作。在这些情况下，Scrum 主管可以提醒团队成员他们在团队中的角色范围。
敏捷团队的其他成员：每个团队的组成可能有所不同，但通常包括来自不同领域的人员，例如设计、分析、QA 和开发。这些人一起决定承担多少工作以及如何完成。
敏捷方法也由团队协作的方式定义。有特定的会议有助于促进整个团队的工作流程。其中一些包括：
敏捷方法的一个显著特点是，有特定的会议流程可以帮助促进整个团队的工作。这些包括：
Sprint 规划：在此会议期间，团队聚在一起决定哪些故事将成为当前 Sprint 的一部分。产品负责人将优先考虑用户故事，团队的其他成员需要就该时间段的计划达成一致。就在该时间范围内可以完成多少个用户故事以及哪些用户故事达成一致。
每日站立会议：这些简短的会议也称为每日站会。在这些签到期间，每个团队成员都会传达各自的进度，例如已完成的任务、即将进行的任务以及可能导致延迟的任何障碍或外部依赖关系。
演示：此会议展示了团队在冲刺期间完成的工作软件，冲刺可以是一个为期两周到四周的增量。产品负责人将确定用户故事是否符合“完成”的定义。如果没有，产品待办事项将更新。这也是团队向利益相关者提供反馈的机会。
回顾：此阶段用于自省，团队可借此确定如何改进工作流程，以便在未来取得更好的结果。
敏捷开发的优点：
1.高度适应性、以人为本和基于团队的设计促进更多的协作。
2.更加灵活、更加充分地发挥每个开发人员的优势，调动大家的工作积极性。
3.由于在开发阶段的每次迭代中都会对代码进行测试，因此代码缺陷可以快速纳入未来的软件开发计划中。
4.由于频繁的反馈会提高客户需求的优先级，因此往往会提高客户满意度。
5.这种精益软件开发可以降低成本，因为与客户期望不一致的风险较小。
敏捷开发的缺点：
1.对文档不够重视。由于项目周期很长，很难保证开发人员不会被替换，而文档的缺乏会给交接过程带来很大的困难。如果项目人员的流动率过高，也会给维护带来很大的困难。
2.项目需要有经验丰富的人员在场，否则在大型或复杂的项目中容易遇到瓶颈问题。
3. 只适合小团队，难以处理大规模的开发任务。
观点：
从以上分析我们可以看出：
1. 传统汽车软件开发并非没有迭代
2、敏捷就是通过不断设定“小目标”来实现小步快进，通过不断获取客户的反馈来确保最终交付能够满足用户的期望。
3. 由于汽车软件中的基础功能通常具有非常明确的要求，且在很长一段时间内基本保持不变，因此无需使用敏捷试错法
4.纯软件项目更适合敏捷，因为它们很容易改变
5. 敏捷只能部分应用于需求不明确、需要快速迭代而容易犯错的领域
如果人类现在才刚刚开始设计汽车软件，那么采用敏捷或许是一个快速打下基础的好主意，但相关的硬件成本，以及大规模不同团队之间的合作问题，仍然很难通过敏捷解决。
汽车软件很少由单个控制器独立实现，汽车软件的开发需要大规模的协作，如果没有文档来传达需求，就很难开展协同工作。
此外，汽车特殊的安全要求和大批量的特点决定了安全必须成为首要目标，因此TS16949对开发过程交付物有具体明确的归档要求，欧美法规对设计过程也有管控要求，因此没有文档的开发很难在汽车行业生存，至少ASPICE的一些要求是无法避免的。
建议和结论：
上述分析并不意味着汽车行业完全不能实施敏捷。可以在某些领域实施适当的敏捷：
但是，汽车软件敏捷团队的人必须有维护文档的责任，而这应该包含在绩效中，而不是只注重结果。汽车软件开发不是“一锤子买卖”，这是一份需要有责任感的工作，可能是一种责任，一种法律责任，以及对质量和安全最起码的尊重。我们不仅要满足文档和法规的要求，还要做好懂得如何传递和满足长期维护的需求。
敏捷是为了应对需求不明确的情况而设计的，因此，如果有好的架构设计，有明确正确的需求，就不需要“敏捷”。
敏捷的一些实践和思想可以作为开发中的参考：更加以任务为导向的组织设计、减少管理层级、使用协作工具（相比看板，我觉得好的软件工具链更加高效可追溯、方便大家远程协作）、每日会议、持续集成、快速反馈等。
