50%汽车人都在拒绝敏捷开发，我们在拒绝什么?

（一）需求分解的差异

敏捷开发中，需求按照 Epic、Feature、Story、Requirement 等方式进行分解。这种分解方式灵活且不确定，根据不同项目的特点灵活变化，且不同的团队，上述4种需求的命名方式、上下层级关系，可能完全不同。然而，汽车行业对“确定性”有着极高的要求。在使用 ASPICE 流程的团队中，V 模型的左侧是统一的，名词和含义都是一致的。这种一致性是为了满足主机厂对供应商软件研发流程透明化、可视化、可管控的要求。例如，一家主机厂可能需要管理成百上千个供应商，如果每个供应商的需求分解方式都不一致，主机厂的管理成本将大幅增加。而敏捷开发的需求分解方式难以与汽车行业 V 模型左侧的任务类型形成映射，这使得汽车工程师在一开始就对敏捷开发产生抵触。

案例：某德国车企尝试引入敏捷需求管理，发现供应商A将“Feature”定义为功能模块，而供应商B却将其拆解为子功能，导致主机厂的集成工作陷入混乱。

（二）需求优先级排序的矛盾

汽车行业在项目初始时期就会定义项目的边界，边界内的任务都需要完成，很少有在项目进行过程中不断增加新需求或砍掉老需求的情况。而敏捷开发则强调需求的优先级排序，根据需求的优先级和价值，先做高优先级的，再做低优先级的，甚至可以根据市场和客户要求的变化，放弃一些低优先级的需求，增加更有价值的需求。

这种需求排序的逻辑与汽车行业的传统做法明显不符。例如，在传统汽车项目中，一旦项目启动，需求变更的代价极高，可能涉及到大量的重新设计、测试和验证工作，在上一篇文章中，我们也深入分析了，为什么“经典”的ASPICE理论和工具链，事实上无法很好支撑变更。而敏捷开发则认为需求的变化是正常的，需要随时调整开发任务以适应变化。这种对需求变更的不同态度，使得汽车工程师难以接受敏捷开发的这种做法。

案例：某新能源车企在开发中期试图砍掉低优先级功能（如后排座椅加热），却因硬件已采购、测试用例已冻结，最终导致成本超支30%。

（三）敏捷冲刺与汽车行业习惯的不符

敏捷冲刺要求 2 - 4 周为一个冲刺，一个冲刺需要发布多个版本。然而，大多数传统造车团队的发版周期是 2 - 3 个月，无法执行敏捷冲刺。

此外，敏捷开发要求持续迭代，能够快速验证代码的正确性。但在汽车行业，开发工程师提交代码后，可能需要数周甚至数月才能拿到结果，反馈速度太慢，无法支撑持续迭代。这与当前传统汽车行业缺乏支撑CICD的工具链，有极大的关系。

每次冲刺前，都需要重新定义本次冲刺需要做的任务和目标，这意味着每 2 - 4 周就要进行一次需求优先级的重新排序和任务的重新规划。这与汽车行业的习惯不符，汽车行业一般是项目开始前就制定计划和重要的里程碑节点。

案例：某自动驾驶公司尝试将敏捷冲刺应用于感知算法开发，但是传感器标定的周期却无法在一个冲刺内搞定，从而导致算法迭代效率下降50%。

（四）版本管理的复杂性

敏捷开发中没有明确的版本管理概念，大多数情况下只有最新的当前版本。开发永远是基于当前版本，如果当前版本改错了，可以从历史记录中找回原来的样子再改回去。这种逻辑的前提是赋能每一个人，相信团队成员的能力，并且能够及时纠正错误。然而，汽车行业对版本管理的要求非常严格，每次发布一个版本都需要配套准备对应的基线、版本、变更等文档，文档工作非常繁重。敏捷开发的快速迭代和频繁发布版本的方式，使得汽车行业的配置管理工作难以跟上节奏。

案例：某供应商尝试引入敏捷，半年内积累200+版本，最终因无法追溯历史版本，无法出具配置管理清单，每次发版都说不清楚发了什么功能，导致无法满足ASPICE评审要求。

将上述分析过程汇总如下：

上述便是敏捷开发想要进入汽车行业的 4 个比较大的难点。这些困难是否值得我们去解决呢？我觉得至少有这下面几个充分的理由，值得汽车人一试。

• 特斯拉迭代式开发的方式，早已获得了成功，其自动驾驶的能力，在目前所有自动驾驶方案中首屈一指，就是对敏捷开发最有力的背书。

  
  

• 敏捷开发中CICD工具链以及开发理念，可以极大地提高软件开发的迭代速度，这是肉眼可见无法否认的。

  
  

• 随着自动化编译和自动化测试的大幅普及，测试工程师需要996才能完成测试的情况大幅减少，反而减少了疲惫状态下进行测试，更容易漏出大量bug的风险，也提高了团队成员对工作的满意度，对公司的忠诚度，降低了离职风险。

  
  

• 敏捷开发对于团队成员的充分赋能，更容易激发每一个人的创造力，而汽车软件开发，是一项创造性的脑力劳动。