汽车产品为什么也需要敏捷（Scrum）开发？

Posted 2021-05-25 汽车NVH充电宝

一、传统的汽车产品开发

汽车是一个由成百上千个零件组装而成的机器，是工业革命时代的产物，改变了人类的生活方式，其开发的复杂程度高，是一项系统工程，因此开发周期长。

一个全新架构下的新车型开发一般是55个月（4-5年左右）时间，即使一个成熟架构下的汽车开发一般需要36个月。但实际上三年后，客户的实际需求已经发生了变化，当初的产品配置已跟不上科技的发展。随着市场的变化和客户需求千人千面的现状，就要求产品开发需要快速响应和迭代。因此为了提高企业竞争力，有一些传统车企和造车新势力将开发周期缩短为24个月。

大部分主机厂采用的开发流程是按照“阶段-闸门式” （Phase-Gateway）开发产品，概括的说就是一个任务被标准化，切割成若干环节，分解为若干任务，被各个职责部门和岗位认领并加以贯彻执行。

大致分为以下几个过程，项目概念阶段（Concept），设计阶段（Design）、工程阶段（Engineering）、验证阶段（Verification）、投产阶段（Launch），只有经过一个里程碑（Milestone）或者说上一个项目节点通过，闸门才打开，进入到下一个工作阶段。这样经过一个又一个的闸门，直到项目投产结束，交付到客户手中。

这是一种“瀑布式”（Waterfall Model）开发逻辑，这也是软件早期开发的模式。强调系统开发应有完整之周期，且必须完整的经历周期之每一开发阶段，并系统化的考量分析与设计的技术、时间与资源之投入等。由于该模式强调系统开发过程需有完整的规划、分析、设计、测试及文件等管理与控制，因此能有效的确保系统质量，是软体业界大多数软件开发的最初标准。

汽车产品的开发是在工业时代发展下的组织形态产物，能显著提高生产效率，保证产品的可靠性，降低产品的开发风险。

但是今天，人们对汽车的理解和需求已经发生了翻天覆地的变化，科技的发展驱动汽车向智能化、电动车发展，软件越来越重要，远远超出最初制造业的开发逻辑。标准化的条线层级被割裂的组织逐渐显示出各种病症，组织对外部环境的感知降低，内部各个子系统的决策缓慢，各个部门的壁垒墙阻碍等等逐渐显性出来。

二  何为敏捷开发？

前段时间，公司老板召开了员工大会，强调我们要做一家科技公司，轻资产，扁平化，快速响应，迭代升级，打造敏捷组织，因此受到启发，翻看一本书，名叫《敏捷革命》，作者是杰夫· 萨瑟兰，他曾参与敏捷软件开发宣言的起草，是Scrum的共同发明者。

Scrum 是从橄榄球比赛演变而来的，scrum 的原始含义是指英式橄榄球次要犯规时在犯规地点的对阵点球，在英语是橄榄球运动中争球的意思。1986年，两位日本学者Takeuchi and Nonaka 在《哈佛商业评论》中发表了题为The New Product Development Game文章，首次提到了将Scrum 应用于产品开发，文章指出，传统的接力式的开发模式已经不能满足快速灵动的市场需求，而整体或橄榄球式的方法，即团队作为一个整体在内部传球并保持前进，可以更好的应对当前的市场竞争。

一个Scrum 团队只有三种角色，Scrum Master、Product Manager、Srume Member。在Scrum 团队里面，每个人正在做什么，正面临什么挑战，取得了哪些进展，是公开透明的，团队工作是多职能，跨部门的。

1. Scrum Master是Scrum教练和团队带头人，确保团队合理的运作Scrum，并帮助团队扫除推进中的障碍。

2. Product Manager，产品负责人，确定产品的方向和愿景，定义产品发布的内容、优先级及交付时间，拟定待办事项内容，确定事项的优先顺序。

3. Srume Member，开发团队成员，一个跨职能的小团队，人数5-9人，拥有交付需要的各种技能。

   
   

   
   

通过产品负责人拟定待办事项列表（Product Backlog）冲刺事项列表和燃尽图（Burn-down Chart）让整个团队的活动在看板上一目了然，同时通过冲刺计划会议（Sprint Planning Meeting）、每日站会（Daily Scrum Meeting）,冲刺评审和回顾会议，以及产品Backlog 梳理会议（Product Backlog Refinement）让所有人既能聚焦自主工作，又能统揽全局，能够清晰的看到自己的个人目标对整体的可视贡献和价值。

Scrum Master 流程执行人，召开每日站会上，顾名思义，就是每个团队成员站着开会，时间控制15分钟以内。只问以下三个问题：

1. 你昨天做了什么来帮助团队取得进展

2. 今天你打算做什么来帮助团队取得进展

3. 在推进的过程中，有哪些障碍

三、如何打造敏捷开发

在《敏捷革命》中，作者提到了最优秀的团队比如丰田，谷歌，亚马逊，他们都具备多样性，也就是说团队成员必须掌握一整套的技能，既要无私，也要有自主性，每个成员多才多艺。

要形成一个敏捷组织，首先要符合团队的人数要求。根据作者介绍，团队成员不是越多越好，人数越多，其沟通的成本就越大，效率就越低，沟通的成本可以用数量来衡量，沟通的数量可以用公式n(n-1)/2来评估，如果团队有5个人，那么沟通的数量就是10条，如果是6个人，沟通的数量就是15条，一次类推，如果是10条，沟通的数量就是45条，这么多的沟通数量，大脑是没法承受的，导致的结果就是你根本不知道别人在做什么，因此敏捷组织是少而精的，最佳的人数范围是5-9人。

书中介绍打造一个敏捷组织的方法和原则：

1. 挑选一位产品负责人

2. 组件团队

3. 选择Scrum 主管

4. 拟定待办事项，并确定优先事项

5. 评估待办事项

6. 交付计划

7. 工作透明化

8. 每日站会

9. 交付展示

10. 回顾

11. 开始下一轮交付与计划

    
    

    
    

    
    

对于我们做汽车产品的NVH属性开发，我也深受启发。汽车产品的NVH开发，分为测试、仿真和属性。仿真、测试和属性就可以建立Scrum 团队，实践敏捷开发组织。

按照传统的组织划分，是根据整车各个板块划分职责，负责底盘路噪的，车身结构、风噪，电机，操作声品质的等等，每个人负责各自的领域，本质上是按照岗位和职责划分的，这就是前面所示的单线程框架，这种组织划分不利于团队间的融合，每个岗位可能就是1-2个人，会因为某一个岗位负责人的离开而陷于手忙脚乱的境地。

随着互联网的发展，获取知识的成本越来越低，每个人可以更容易的掌握其他领域的知识，毕竟都是NVH出身，各个专业之间不会有很大的鸿沟，NVH控制的基本理论都是相通的，因此就符合敏捷团队里面的多样性原则，每个人对项目上的进展和待办事项很清楚，能够相互补位，不会因为某一个人的离开，团队的某一项工作就无法交付。

之前的那家单位，常听到专家们讲：专业人做专业事。这句话没错，但是随着专业间的融合越来越多，推进一个工作需要跨部门、跨职能，专业间的界限越来越模糊，不是非黑即白，而是存在灰色地带。就不能各自门前扫雪，只负责自己的领域的事情。

前段时间，参加部门老板的《汽车架构开发》培训，强调架构开发其首要原则就是兼容性高于完整度，任何系统都要满足上述原则，包括属性和功能，有各个模块和属性间的兼容，就存在灰色地带，传统的解决方案就是请老板定夺，划分职责。这是每个组织有可能存在的问题。

那么有了敏捷开发组织的应用，处理灰色地带的问题是否就越少，汽车产品的开发效率是否会提高，开发周期是否会缩短，实现24个月甚至更短的产品交付，我们拭目以待。