电子电气架构 — 模型设计和传统设计开发（下）

我是穿拖鞋的汉子，魔都中坚持长期主义的汽车电子工程师。

老规矩，分享一段喜欢的文字，避免自己成为高知识低文化的工程师：

做到欲望极简，了解自己的真实欲望，不受外在潮流的影响，不盲从，不跟风。把自己的精力全部用在自己。一是去掉多余，凡事找规律，基础是诚信；二是系统思考、大胆设计、小心求证；三是“一张纸制度”，也就是无论多么复杂的工作内容，要在一张纸上描述清楚；四是要坚决反对虎头蛇尾，反对繁文缛节，反对老好人主义。

一直很喜欢发小老李QQ签名那句话—生活如逆水行舟，不进则退。农村做题家出来的汉子，我可能已经不具备享受快乐的权力，只有做个躬行的卒子，一步一个脚印往前走。

中年男人尽量避免陷入历史虚无主义，自己无需问“人活着为了什么？”，做自己该做之事，七八月只管播种，到了十一二月收获季节，自有收获。

三、敏捷开发的优缺点

（1）、痛点

敏捷开发的优势源于其“以人为本、迭代响应”的核心逻辑，能够精准解决传统开发模式在灵活性、协同性、价值交付等方面的痛点，具体体现在以下五个方面：

-> 1、高适应性与高效协同性：敏捷开发打破了传统开发模式中流程对人的束缚，将“个体和互动”置于核心位置，形成了以人为本的团队协作模式。这种模式下，跨职能团队成员紧密配合，通过开放坦诚的沟通消除信息壁垒，促进知识共享与经验传递，有效提升了团队的协同作战能力。更重要的是，敏捷开发不畏惧变化，而是通过迭代机制主动拥抱变化——当市场需求、技术方向或客户诉求发生调整时，团队可在后续迭代中快速调整开发计划与优先级，无需承担传统模式中“牵一发而动全身”的巨大调整成本，展现出极强的市场适应性。

-> 2、 充分激活个体价值，提升团队积极性：敏捷开发强调对团队成员的信任与授权，鼓励每个成员充分发挥自身专业优势与主观能动性。在敏捷团队中，成员不再是被动执行任务的“螺丝钉”，而是能够参与需求分析、方案设计等核心环节的主体，其创意与建议可直接影响项目走向。这种自主管理、淡化职级的团队氛围，能够最大限度地调动成员的工作热情与创造力，让团队始终保持初创公司般的活力，进而提升整体开发效率与项目执行力。

-> 3、 早期缺陷暴露，保障产品质量：敏捷开发采用迭代式开发模式，每个迭代周期结束后都会交付可工作的软件模块，且在每个迭代过程中都会同步开展测试工作。这种“开发与测试并行”的模式，使得代码缺陷能够在开发早期被及时发现，避免了缺陷积累到项目后期导致的修复成本激增。同时，发现的缺陷可直接纳入下一轮迭代的开发计划中，实现快速修复与验证，从源头上保障了最终产品的质量稳定性。

-> 4、 高频客户互动，提升客户满意度：敏捷开发将“客户合作”置于核心价值观，通过持续的反馈机制让客户深度参与项目全过程。在每个迭代周期结束后，团队都会向客户展示已完成的功能模块，主动收集客户反馈意见。这种高频互动不仅能够帮助客户逐步厘清自身真实需求，避免因初期需求模糊导致的产品与诉求脱节，还能让客户感受到被重视，增强其对项目的信任感。此外，客户反馈可直接影响后续迭代的需求优先级，确保开发资源始终聚焦于客户最关注的核心功能，最终交付的产品能够精准匹配客户需求，从而显著提升客户满意度。

-> 5、 精益开发，降低项目风险与成本：敏捷开发倡导“工作的软件高于详尽的文档”，摒弃了传统模式中对冗余文档的极致追求，将资源集中于核心功能的开发与验证，实现了精益化开发。同时，由于项目通过迭代分次交付，团队能够及时发现需求偏差、技术难题等潜在风险，并快速调整策略，避免了传统模式中“一次性交付”可能导致的全盘失败风险。这种风险的早期管控，使得项目与客户期望不一致的概率大幅降低，有效减少了因需求不符导致的返工、重做成本，进而降低了项目的整体投入成本。

（2）、敏捷开发的应用局限性

尽管敏捷开发具备诸多优势，但并非适用于所有场景，其核心逻辑也决定了在文档管理、团队要求、项目规模等方面存在一定的局限性，具体表现为以下三个方面：

-> 1、文档重视不足，影响项目交接与维护：“工作的软件高于详尽的文档”是敏捷开发的核心价值观之一，但这一理念在实际应用中容易走向极端——部分敏捷团队过度简化文档，甚至忽略必要的核心文档编制。在项目周期较长的场景中，团队成员流动是不可避免的客观现象，而不完善的文档会导致知识传承出现断层：新成员难以快速了解项目的需求背景、设计思路、技术架构等关键信息，极大地增加了工作交接的难度与周期。更重要的是，缺乏规范文档会给项目后期的维护工作带来巨大挑战，后续维护人员无法精准定位问题根源、理解功能逻辑，导致维护成本激增，甚至影响产品的长期迭代能力。

-> 2、对核心人员依赖度高，复杂项目易遇瓶颈：敏捷开发强调团队的自主管理与协同协作，但这一模式的顺利推进高度依赖经验丰富的核心人员，尤其是Scrum Master、产品负责人等关键角色。这类核心人员需要具备扎实的技术能力、丰富的项目管理经验，以及较强的沟通协调能力，能够在团队遇到技术难题时提供指导，在需求优先级混乱时做出精准判断，在团队协作出现矛盾时进行调和。若项目团队中缺乏此类核心人员，在面对大型复杂项目时，容易出现需求拆解不清晰、迭代计划不合理、技术选型失误等问题，导致项目推进受阻，甚至陷入瓶颈。

-> 3、 适配小团队作战，难以应对大规模开发任务：敏捷开发的高效协同依赖于团队成员之间的直接沟通与快速响应，这种模式在小团队（通常5-9人）中能够发挥最佳效果——成员之间熟悉度高、沟通成本低，能够快速达成共识并推进工作。但当面对大规模开发任务（如大型企业级系统、复杂的智能汽车座舱系统等）时，需要组建多个跨职能团队协同作战，此时敏捷开发的管理难度会大幅提升。多个团队之间的需求衔接、进度同步、资源调配等问题难以通过传统的敏捷机制有效解决，容易出现团队之间信息壁垒、需求冲突、进度脱节等情况，导致整体开发效率下降，无法充分发挥敏捷开发的优势。

（3）、 敏捷开发方式案例——Scrum

在众多敏捷开发框架中，Scrum是目前应用最广泛、最成熟的一种开发方式。Scrum以“小步快跑、快速迭代”为核心逻辑，通过明确的角色定义、标准化的会议机制与流程规范，将敏捷开发的核心价值观落到实处，成为众多企业实现敏捷转型的首选框架。以下将从基本术语、核心会议与工作流程两个维度，对Scrum进行详细解读。

Scrum的基本术语

Scrum框架包含一系列精准的术语定义，这些术语构成了Scrum团队的沟通共识，是保障流程顺畅推进的基础，核心术语如下：

-> Sprint（冲刺周期）：Sprint是Scrum开发的核心单元，指团队在固定时间内完成特定“小目标”的周期，也是Scrum迭代开发的基本时间单位。通常情况下，Sprint周期设定为2-6周，其中2周是最常用的周期长度——这一长度既能够保证团队完成具有一定价值的功能模块，又能确保足够的灵活性，以便及时响应需求变化。在一个Sprint周期内，团队的目标与任务是固定的，不允许随意变更，确保团队能够聚焦精力推进工作。

-> User Story（用户故事）：User Story是对用户外在业务需求的简洁描述，通常以“作为[用户角色]，我希望[完成某项操作]，以便[实现某个价值]”的格式呈现。例如，“作为汽车驾驶员，我希望通过语音控制打开空调，以便在驾驶过程中无需手动操作，提升驾驶安全性”。User Story聚焦于用户的实际需求与价值，而非具体的技术实现细节，能够帮助团队快速理解用户诉求，同时为需求拆解提供基础。

-> Task（任务）：Task是由User Story拆解而来的具体开发任务，是团队成员实际执行的最小工作单元。每个User Story需要拆解为多个可落地的Task，每个Task都有明确的目标、负责人与完成时限，且能够独立完成并验证。例如，将“语音控制打开空调”这一User Story，可拆解为“语音指令识别模块开发”“空调控制接口对接”“语音控制功能测试”等多个Task。通过Task拆解，能够让团队成员清晰了解自身工作内容，同时便于进度跟踪与风险管控。

-> acklog（需求列表）：Backlog是Scrum框架中的需求清单，分为产品Backlog与Sprint Backlog两类。产品Backlog是整个项目的需求总清单，包含所有待实现的User Story，由产品负责人负责维护，根据市场需求与客户反馈动态调整需求优先级；Sprint Backlog则是从产品Backlog中筛选出的、当前Sprint周期内需要完成的需求清单，由团队共同确认，是团队在本Sprint周期内的核心工作目标。

-> Daily meeting（每日站会）：每日站会是Scrum团队的日常同步会议，通常在工作日每天固定时间召开，时长控制在15分钟以内，要求团队成员全员参与。会议核心目的是同步项目进度、暴露潜在问题、协调资源配合，团队成员需依次回答三个核心问题：“昨天完成了哪些工作？”“今天计划完成哪些工作？”“遇到了哪些阻碍？”。通过每日站会，能够让团队快速掌握整体进度，及时发现并解决影响进度的问题，同时增强团队的协作意识。

-> Sprint Review meeting（冲刺评审会议）：冲刺评审会议在一个Sprint周期结束后召开，参会人员包括团队成员、产品负责人、客户及相关 stakeholders。会议核心内容是团队向参会人员演示本Sprint周期内完成的功能模块，展示可工作的软件版本。参会人员可对演示的功能提出反馈意见，这些意见将作为后续需求调整的重要依据，确保产品始终贴合客户需求。

-> Sprint burn down（冲刺燃尽图）：冲刺燃尽图是用于跟踪Sprint进度的可视化工具，以图表形式展示当前Sprint周期内剩余任务的数量与时间的关系。图表横轴为Sprint周期的时间节点，纵轴为剩余任务数量（通常以故事点或工时计量）。理想状态下，燃尽图呈下降趋势，直至Sprint结束时剩余任务数量为0。通过燃尽图，团队能够直观掌握进度是否符合计划，若出现进度滞后，可及时分析原因并调整工作策略。

-> Release（发布）：当一个或多个Sprint周期完成后，若积累的功能模块已满足预设的发布条件，团队将进行产品版本的发布，向用户交付具备完整核心功能的可用产品。发布并非必须在单个Sprint结束后进行，而是根据产品规划与市场需求灵活确定，既可以是小版本的功能迭代发布，也可以是包含核心功能的重大版本发布。

Scrum的四个会议与工作流程

Scrum工作流程以Sprint为核心，通过四个标准化会议（Sprint计划会、每日站会、Sprint评审会、Sprint回顾会）贯穿整个开发周期，形成“计划-执行-评审-改进”的闭环管理。Scrum工作流程如图所示。

在项目正式启动之前，Scrum团队首先召开Sprint计划会。此次会议是整个Sprint周期的基础，参会人员包括产品负责人、开发团队与Scrum Master。会议核心目标是明确本Sprint的工作目标与具体任务：产品负责人向团队讲解产品Backlog中的需求内容与优先级，团队成员结合自身能力与技术可行性，对需求进行评估与讨论，最终从产品Backlog中筛选出可在本Sprint周期内完成的需求，形成Sprint Backlog。同时，团队会将Sprint Backlog中的User Story拆解为具体的Task，明确每个Task的负责人与完成时限，并制定详细的开发计划，为Sprint的顺利推进奠定基础。

Sprint计划会结束后，团队正式进入Sprint执行阶段。在整个Sprint周期内，团队成员按照既定计划推进Task的开发工作，确保各项任务有序落地。为保障进度同步与问题及时解决，团队每天召开每日站会：成员简要汇报昨日工作完成情况、今日工作计划及遇到的阻碍，Scrum Master负责记录阻碍问题，并协调资源帮助团队解决。同时，团队会根据每日站会的进度情况，及时更新冲刺燃尽图，让所有人直观了解项目进度与剩余任务，确保团队始终朝着Sprint目标推进。

当Sprint周期结束后，团队召开Sprint评审会议。会议上，团队向产品负责人、客户等参会人员演示本Sprint周期内完成的功能模块，展示可工作的软件版本。参会人员结合自身诉求与使用体验，对演示功能提出反馈意见，产品负责人负责记录这些意见，并评估是否需要纳入后续的产品Backlog中。若演示的功能符合预期，团队将启动本版本的发布工作，向用户交付可用的产品功能；若存在未完成的任务或功能不符合需求，团队将分析原因，并在后续Sprint中进行优化调整。

Sprint评审会议结束后，团队紧接着召开Sprint回顾会议（又称总结会议）。此次会议的核心目的是总结本Sprint周期内的经验与不足，持续优化团队的工作方式。会议采用轮流发言的形式，每个团队成员都需要参与讨论：分享本Sprint中做得好的地方、遇到的问题、可以改进的环节等。例如，团队可能会讨论“每日站会时长过长，影响开发效率”“需求拆解不够细致，导致部分Task延期”等问题，并共同制定改进措施，如“将每日站会时长严格控制在10分钟以内”“下次Sprint计划会增加需求拆解的讨论时间”等。这些改进措施将被纳入下一轮Sprint的计划中，帮助团队不断提升协作效率与开发能力。

Sprint计划会、每日站会、Sprint评审会与Sprint回顾会这四个会议，构成了Scrum开发的完整闭环，确保团队在每个Sprint周期内都能实现“计划-执行-评审-改进”的良性循环。

从敏捷开发的核心思想来看，Scrum框架进行了完美的落地实践。首先，2周左右的短小精悍的Sprint周期，使得开发计划或用户需求发生变化时，团队能够在后续Sprint中及时调整，充分体现了“响应变化高于遵循计划”的价值观；其次，在Sprint计划会与评审会中，团队充分吸纳客户反馈，动态调整User Story与需求优先级，践行了“客户合作高于合同谈判”的理念；再次，每个Sprint交付的功能都是可立即工作的软件模块，精准落实了“工作的软件高于详尽的文档”的要求；最后，自主管理、淡化职级的团队模式，以及每日站会带来的高频互动，充分激发了个体潜力，强化了团队协作，体现了“个体和互动高于流程和工具”的核心思想。

通过这种闭环管理模式，Scrum将总体上难以预测的软件开发过程，拆解为一个个局部相对可预测、易控制的Sprint周期，既降低了项目的整体风险与管理成本，又提升了工作效率与产品质量。正是这些显著优势，使得Scrum成为目前全球范围内应用最广泛、最广为人知的敏捷开发方法，被互联网、汽车、金融等多个行业的企业广泛采用。

四、敏捷开发应用于汽车行业的挑战

从敏捷开发的核心逻辑来看，其核心优势在于通过拆解“大目标”为一系列可快速落地的“小目标”，实现“小步快跑、快速迭代”的开发节奏，同时依托持续的客户反馈机制，确保最终交付成果精准匹配用户实际需求。然而，当这一开发模式应用于汽车行业这一特殊领域时，由于行业自身的技术特性、安全要求和协作模式等诸多限制，其应用场景和实施效果受到显著制约。具体而言，汽车软件体系中，基础功能模块尤其是面向嵌入式系统的开发内容，普遍具有需求明确、长期稳定的特点，这类开发工作无需通过敏捷迭代进行试错验证；而纯软件项目因具备更改成本低、调整周期短的特性，更适配敏捷开发模式。因此，敏捷开发在汽车行业并非普适性解决方案，仅能针对性应用于需求模糊、需通过快速试错探索方向的特定领域，其全面落地还面临诸多亟待破解的挑战。

结合汽车行业的开发实践，敏捷开发的应用挑战可具体归纳为以下六大核心维度，各维度相互关联、相互影响，共同构成了敏捷模式在汽车领域推广的主要障碍。

其一，硬件成本与跨团队协作的双重制约。若汽车软件采用从零搭建的开发路径，敏捷开发的快速迭代思路虽有助于快速构建基础框架、验证核心逻辑，但汽车行业的开发并非纯软件层面的独立推进，而是与硬件深度绑定的系统工程。一方面，每一轮软件迭代都可能需要配套的硬件适配，而汽车硬件研发、生产及测试的成本极高，频繁的迭代调整将带来巨额的硬件投入，这与敏捷开发“低成本试错”的核心前提相背离；另一方面，汽车软件开发涉及电子电气、动力控制、智能座舱、自动驾驶等多个细分领域，需要超大规模跨专业团队协同推进，不同团队的技术规范、工作节奏和沟通逻辑存在差异，敏捷开发强调的“轻量化协作”难以破解大规模团队的协同壁垒，导致迭代效率大幅降低，难以实现预期的敏捷效果。

其二，大规模协作对文档支撑的刚性需求。汽车整车软件系统极为复杂，几乎不存在单一控制器即可实现的完整功能，任何核心功能的落地都需要多个控制器、多个系统的协同配合，这就决定了整车软件开发必然是大规模跨部门、跨层级协作的过程。在这种协作模式下，需求的精准传递是确保开发方向一致的核心前提。敏捷开发强调“弱化文档、强化口头沟通”，但这一理念在汽车行业大规模协作场景中完全不适用。若缺乏标准化、规范化的文档作为需求传递和追溯的载体，不同团队之间极易出现需求理解偏差、开发边界模糊等问题，不仅会导致重复开发、返工整改等低效行为，更可能引发系统兼容故障，严重影响开发进程。因此，文档作为协作的“桥梁”，是汽车行业大规模软件开发不可或缺的基础支撑。

其三，行业法规与安全标准的严格约束。汽车作为关乎驾乘人员生命安全的交通工具，“安全第一”是行业不可逾越的核心准则，这一准则直接体现在严格的法规要求和标准体系中。国际层面，ISO/TS 16949质量管理体系对汽车行业开发过程的交付物提出了具体且明确的存档要求，涵盖需求文档、设计方案、测试报告等全流程资料，确保开发过程可追溯、可验证；欧美等主流汽车市场的相关法规，更建立了完善的设计过程管控机制和责任追究制度，一旦出现安全问题，需通过完整的开发文档界定责任主体。而敏捷开发的“轻文档”特性，与上述法规和标准的要求存在本质冲突。此外，汽车行业普遍推行的ASPICE（汽车软件过程改进及能力评定）标准，对软件开发的流程规范性、文档完整性有严格规定，是企业进入主流市场的必备资质，敏捷开发若无法满足ASPICE的相关要求，将难以在汽车行业立足。

其四，固定需求场景下敏捷优势的失效。汽车行业存在大量长期稳定的产品功能和开发需求，这类需求并非由市场随机反馈决定，而是由国家标准、行业规范以及企业内部的技术标准提前明确界定，具有极强的刚性和稳定性。例如，汽车的动力输出控制、制动系统逻辑、安全防护机制等核心功能，其技术参数和性能要求均需符合国家强制性标准，开发过程中不允许随意调整迭代。对于这类固定需求项目，开发的核心目标是严格按照既定标准完成落地，确保合规性和稳定性，而敏捷开发最核心的“快速响应需求变化”优势无从发挥。此时，敏捷开发的迭代机制反而可能增加开发流程的复杂性，降低开发效率，不如传统开发模式更适配。

其五，形式化应用导致的额外工作负担。敏捷开发的核心要义在于其背后的价值观和原则，即强调团队自主、持续反馈、快速适应变化等，工具和方法仅是实现这些理念的手段。然而在实际应用中，部分汽车企业存在“重形式、轻本质”的误区，在团队未真正理解和践行敏捷价值观的前提下，盲目要求项目成员套用特定的“敏捷工具”，并严格按照固定的流程开展交付和迭代。这种形式化的应用方式，不仅违背了敏捷开发的核心初衷，更会给项目成员增加额外的工作负担：一方面，团队需要花费大量精力学习和维护敏捷工具，撰写符合流程要求的迭代报告；另一方面，原有开发节奏被打乱，新旧工作模式的冲突导致效率下降。相比之下，瀑布式开发通过提前明确各阶段的交付物、时间节点和工作要求，能够确保项目按部就班稳定推进，更适配这类缺乏敏捷理念支撑的团队场景。

其六，团队规模与人员稳定性的客观限制。敏捷开发高度依赖团队成员之间的高频次、近距离沟通，强调通过即时交流解决问题、同步信息，这一要求在小团队、人员稳定的场景下较易实现。但汽车行业的项目开发往往涉及数百人甚至上千人的超大团队，且项目周期通常长达数年，人员变动难以避免。当团队规模过于庞大时，敏捷开发强调的“扁平化沟通”难以落地，信息传递的效率和准确性会大幅降低；而人员的频繁变动则会导致知识传承断层，新成员需要花费大量时间熟悉项目背景和迭代逻辑，直接影响迭代节奏的连续性。与之形成鲜明对比的是，瀑布式开发以标准化的文档存档和规范化的工作流程为核心，信息传递主要依托文档载体，无需依赖人员之间的即时沟通，即使面对大团队和人员流动场景，也能保障项目按既定流程稳定推进，更契合汽车行业的团队管理实际。

敏捷开发并非汽车行业开发模式的“万能钥匙”，其应用效果与汽车产品特性、团队基础条件密切相关。在汽车行业向智能化、网联化转型的背景下，完全摒弃敏捷开发或盲目推行敏捷模式均不可取。行业实践中，应立足具体项目的产品特性，精准区分固定需求与可变需求的边界，同时结合团队的规模、协作能力和敏捷理念认知水平，在充分尊重敏捷核心价值观和原则的基础上，探索“敏捷+传统”的混合开发模式，例如在需求探索阶段采用敏捷迭代验证方向，在核心功能开发阶段采用规范化流程保障稳定，以此找到适配汽车项目的敏捷开发路径，实现开发效率与安全合规的平衡

搁笔分享完毕！

愿你我相信时间的力量

做一个长期主义者