一、汽车软件开发如何敏捷？规模敏捷SAFe（Agile X+ Agile X+）

规模敏捷（Scalable Agile Framework，简称SAFe）是一个为大型组织设计的、以敏捷为基础的框架，旨在帮助这些组织更好地实施敏捷开发和管理方法。在当前的汽车软件开发领域，SAFe的应用正日益增多，这主要得益于汽车行业的复杂性以及对于快速响应市场变化的需求。 SAFe通过灵活的框架结构，使得大规模的团队能够协调一致地工作，同时保持敏捷的灵活性和快速反应能力。 这种框架不仅支持团队级别的协作，还扩展到了更高级别的业务需求和产品路线图规划。 在汽车软件开发中，这意味着可以更快地推出新功能和进行改进，同时确保整个系统的质量和可靠性。

汽车软件的开发 涉及 硬件与软件的深度集成、严格的质量标准以及长周期的开发流程。 这些特点使得传统的 瀑布式开发 模式已难以满足当前汽车产业的发展需求。因此，采用灵活、迭代的敏捷开发方式成为行业的共识 。 而SAFe，作为一个专为大型企业设计的实践框架，为汽车软件开发提供了可行的解决方案。

SAFe的核心理念包括精益思想、系统思考、敏捷开发和持续改进。 它通过定义一系列的实践和角色，确保团队之间的协调一致，并通过PI（Program Increment）计划来驱动项目的进展。每个PI通常包含多个敏捷团队的迭代周期，这样既可以保证团队层面的灵活性，又能从宏观上控制项目的整体进度。

具体到汽车软件的开发中，SAFe可以帮助团队更好地处理复杂的系统集成问题。 通过将整个车辆视为一个系统，各个子系统或模块的开发可以同步进行 ， 同时利用PI计划来定期检查集成进度，确保各部分能够协调工作。这种整体性的考量，有助于降低后期集成时可能出现的风险和成本。

SAFe强调团队成员之间的跨功能协作。 在汽车软件开发中，这意味着工程师、设计师、产品经理等不同角色的成员需要密切合作，共同解决问题。通过日常的站立会议、迭代评审和回顾会议，团队成员可以及时分享信息，快速响应变化，并持续优化开发过程。

SAFe的另一个关键要素是构建可交付的产品增量。 每次PI结束时，团队都应该有一个可以展示给利益相关者的成果，无论是硬件原型还是软件版本。这有助于及早发现潜在的问题，同时也让利益相关者更直观地了解项目进展，从而做出更加合理的决策。

实施SAFe并非没有挑战。 汽车软件开发的特殊性要求团队具备高度的技术专业性，而SAFe的实施需要团队成员具备敏捷的思维和跨学科的协作能力。 这就要求组织在培训和文化转变上下一定的功夫，以确保团队成员能够适应这种新的工作方式。

值得注意的是，尽管SAFe提供了一个框架和方法，但它并不是一成不变的。 每个组织都需要根据自己的实际情况对SAFe进行适当的调整和定制。汽车软件开发的组织应该持续评估自身的实践，寻找最适合自身特点的敏捷之路。

规模敏捷SAFe在汽车软件开发中的应用，不仅能够帮助组织更好地适应快速变化的市场环境，还能够提高开发效率，降低风险。 随着汽车行业对软件依赖程度的不断提高，SAFe无疑将在未来的汽车软件研发中扮演越来越重要的角色。

通过合理运用SAFe提供的方法和工具，汽车软件开发组织能够在激烈的市场竞争中保持灵活，实现持续的技术创新和产品优化，为未来的智能驾驶和车联网时代做好准备。

二、敏捷软件开发 | 汽车行业的规模化敏捷框架（SAFe）入门知识

（原创 Sascha Preissler Elektrobit）

汽车行业正在快速变革：标准日趋严格，汽车架构变得越来越复杂。对功能安全、信息安全和网络连接的要求也越来越高。“软件”这一推动世界运转的动力，正是解决未来挑战的关键所在。

数年来，汽车行业一直在讨论软件重要性日益增加的问题。软件开发方式将成为未来汽车的一个核心话题。业界也在问同样的问题：未来应当如何开展汽车开发工作？如何应对日益增长的软件复杂性？是推行更严格的标准？还是不断改动汽车架构？

在这些问题面前，并没有一个放之四海而皆准的解决方案。诚然，各家厂商在如何解决这些问题上都有各自不同的观点。但大家在一件事情上达成了共识，那就是如今需要做的是重新思考这些问题的解决办法，比如重新设计软件开发方法。

拥有30多年汽车软件开发经验的Elektrobit也持有相同的观点。我们清楚知道，为了能够交付最好的产品，我们也同样需要重新思考自己的软件开发方式。

幸而规模化敏捷框架（SAFe）给我们的工作提供了一个出色的架构。我们将在这篇文章里解释如何运用SAFe向世界各地的OEM、一级供应商以及合作伙伴提供行业领先的汽车软件。

SAFe？从来没有听说过？如果您对这个话题并不熟悉，不必担心。我们将为您做一个简短的介绍。

什么是SAFe？

在汽车领域里，面向精益企业的规模化敏捷框架（SAFe）指的是业务敏捷性框架。它包含了精益和敏捷产品开发以及DevOps（开发运维一体化）的各个要素。同时，SAFe具有高度可配置性。其原则可以帮助我们：

1）成为一家更加敏捷的企业

2）快速响应变化

从根本上说，SAFe为我们提供了开发产品所需的完美框架。

为什么Elektrobit会选择SAFe

汽车领域是我们的核心业务领域，而SAFe正是汽车领域里应用最普遍的框架。我们的许多客户也在使用 SAFe。该框架让我们从一开始就能够使用同一种语言以此来确保团队之间的顺利协作以及产品的稳定交付。同时，这也是与我们的商业模式、组织规模和产品开发架构最为契合的一种框架。

SAFe对Elektrobit的客户以及产品开发有何意义

SAFe区分了两种“运营体系”：

1) 一种专注于经典的企业分层架构

2) 一种专注于价值流，而非各个部门

第二种运营体系更加注重为市场创造价值。实际操作非常灵活。对我们来说，这意味着：我们利用SAFe框架进行回顾，并赋予敏捷专家（ Scrum Master ）、发布火车工程师（Release Train Engineer）等价值赋能角色以权力，使其能够定期检查从客户需求到交付的所有层面的价值流中的障碍。从这个角度来看产品开发，我们可以做到缩短产品上市时间以及改善工作流程。

SAFe的其中一个步骤是实施敏捷发布火车（Agile Release Train, ART）。这指的是在价值流中交付解决方案的多个敏捷团队。我们已经基于自己的价值流创建了第一批敏捷发布火车，并且做好了创建后续发布火车的准备工作。第一批发布火车让我们了解到了什么对Elektrobit有用，什么没用，同时也促进了我们对持续学习文化的建设。持续学习文化是SAFe中业务敏捷性的核心能力之一。

举例来说，我们会学习如何让敏捷发布火车中的每一个人为完成共同的使命而努力，每个人都会学习如何有效地专注于少数工作项目并快速将其完成。我们会学习如何在敏捷发布火车中逐步发展出良好的团队配置，以减少工作交接。我们会学习如何改进持续交付工具，以便尽早地、频繁地获得反馈。

然而，SAFe并不仅仅专注于敏捷发布火车中单个产品的开发。它还通过精益投资组合管理为我们的业务提供了更大的图景。

业务敏捷性的另一项核心能力是精益投资组合管理。它帮助我们将执行与战略联系到了一起。我们可以从历史数据中了解企业的发展能力。我们的团队所收集到的实时数据能够让我们对企业的所有工作以及团队之间的依赖关系有一个大致的了解。基于这些数据，我们可以改进战略决策。我们可以可靠地交付能够满足客户需求的产品。

当然，这也会对我们的产品开发产生影响。在第二种运营体系中，我们可以指派团队负责具有高度战略意义的主题。这种做法比以前更加灵活。我们意识到只有在一种情况下才能实现这一点：我们需要有一套适用于所有产品开发工作的流程和方法。

我们下一步要做什么？

SAFe为我们解决产品开发的所有重要问题提供了思路。我们应当根据自己的需求对其进行配置，并经常从SAFe的角度来审视我们的业务。这有助于我们应对瞬息万变的汽车市场所带来的一切挑战。从根本上说，SAFe框架为我们提供了最重要的能力，即保持业务的敏捷性。同时，我们也应当为即将到来的挑战做好准备。

三、车企规模化敏捷的实践思考

（来源：时代胶囊 ，作者蓝血的阿健）

"Scaling Agile": At base, you need competent Agile teams. Sine qua non. If you have competent Agile teams, scaling becomes nearly trivial. - Ron Jeffries

敏捷转型对于企业的本质思考

敏捷的第一性原理是什么

敏捷在中国发展到今天已经不是一个新鲜的事物了，从五大行到城商行，从通信企业到现在的汽车，新零售行业，有趣的是每一家在最初尝试敏捷从0到1的阶段甚至是从1到N的阶段中大家背后的动因都在无限的趋同，我们想借这个平台与机会来谈一谈的内容便是，敏捷背后的第一性原理。

如果一定要回归到敏捷的第一最基本命题，我个人的理解是敏捷是一种可以影响到组织，甚至个人的核心思维方式的改变 -- 组织的迭代式演进，组织能够通过不断的迭代式的试错学习从而调整到一个最适应组织当下的状态。再要追根溯源的话，敏捷背后的动因以我们的调研和学习发现是希望打造一种复杂自适应系统。只有在形成复杂自适应的条件下，对抗外力的变化可能性才能无限的提升。

因此，总结一下来说：

于组织角度，敏捷的第一性原理是成就一个具有进化能力的，会思考的组织。

于个人角度，就是不断地通过迭代来优化自己，让自己随着组织共同学习并且进步。

插图：敏捷的业务价值

一个大型组织为何需要敏捷

对齐 ，一定是对 齐，确保信息足够的透明，保持一致性

很多组织都在谈我们需要战略对齐，让整个组织共同对着同一个战略目标而努力。 结果发现最难解决的问题正是组织的对齐。 对齐需要从多种不同视角来呈现，主要可以分为年度的战略目标对齐，季度的里程碑目标对齐，月度/双周的发布版本对齐。

插图：组织的心跳

假设一个大型的正在做数字化创新的组织，从以上的三个视角都没有对齐，那么每一个迭代的方向都可能是各不相同的，对于组织产生的伤害以及投入的成本都是巨大的。组织规模越大，成本消耗与浪费也将越大。

根据我们多年的实施咨询项目的经验以及多年来在办公室里摸爬滚打的经验来看，组织方向的对齐本质就是组织高层中层的对齐。很多企业和大型组织中存在着巨大的部门壁垒，阻碍着多端的对齐可能，无论是自上而下的对齐还是横向的对齐，都是为了确保组织是朝着一个共同的方向前行的。在我们实施过的规模化敏捷企业中，大多都会引入一种PI Planning的大型workshop方式来使得组织自顶向下，自底向上的动态对齐目标，这样一定程度上解决了各做各的，互相同步信息不及时的问题，也为组织提升了一下活力，每个季度完成一次组织上下的大规模的互动，也一定程度上提升了组织成员的凝聚力，管理者也可以借用这一平台宣传组织的发展方向。可谓达到一举两得的效果。

当然这里一定也有人持不同的想法，因为有一些组织就是可能完全松散耦合存在，各自孵化着各自的小产品独立运营。那么此时我们需要的更多是一种企业文化与战略规划上的宣传。对齐目标仅仅是一个目标愿景的对齐了。这个部分我就不在此问赘述了，也请各位读者来关注我的公众号，我们会更深入详细的探讨从系统思考角度来论证什么时候需要PI Planning这样形式的工作坊/会议，什么情况下并不需要。

规模化敏捷的几大误区

根据服务过多家跨国银行，保险公司，汽车行业的客户公司的经验。我们总结了如下的一些误区

认为人数一旦规模化，敏捷也就规模化了，其实架构也应该考虑规模化

规模化一直以来对于组织是一个很大的考验，不管规模化什么，可能是某一个工具链，某一种技术实践，某一种文化理念等等都可以被所谓的规模化，那么敏捷自然的大家就想到是否可以规模化。

那么敏捷的第一性原理与本质我们也有过一些探讨，各位可以思考一下如果一个团队甚至个人可以实现敏捷化转型，自然的一个超大型组织自然也是可以被敏捷化的。于是乎就有很多组织试图尝试将每一个业务部门都与IT或者供应商形成强大的跨职能敏捷团队进行规范化的敏捷化处理，为此也定义了详尽的“敏捷”流程，然而短期内并未发现比过去更好，有些情况下可能相反更糟了。

我们也在许多企业中实践过此方法论下的全民敏捷广播体操活动，结论不完全不好。因为规范化总是有效的，但是很多时候也是无效的，原因是不能按照规范要求“敏捷起来”的团队背后原因都有一个有趣的共性，那就是虽然业务线被严格的设计好了，story也认真的拆分成功了，但是底层的服务却没能很成功的形成一定的独立性，因此就成了如下图所示的样子

1.虽然是我的业务，但是服务却在你这里，于是本来不需要沟通的部分却成了沟通讨论的增项环节

2.对应端上开发的敏捷团队（APP，小程序等）与中台团队对接异常的困难，端上的逻辑层似乎就成了一种单纯的调用关系而不是逻辑封装

在迭代中演进并且取得某种意义上的平衡态才是我们需要认真考虑与总结的，换言之，我们的架构如果不够支持可扩展性，那么自然的，扑上再多的人跑的再标准的“敏捷规模化实践流程”也仍然减少不了各种复杂的沟通过程。

插图：架构的一纵一横两大难题

必须定义足够的细节规范才能确保大家正确执行敏捷

在初期导入以及实践过程中，我们是否碰到过类似的问题

• 究竟定义到怎样的边界才是 epic ，feature，story，如果没有feature是不是跑不起来了，如果各业务部门的需求类型有不同，那么应该怎样做适配还是说完全套用我们定义的所谓“组织级”分类和工作流？

• 企业接入了许多开发供应商，各自都有着自己过去引以为傲的“敏捷最佳实践”

• 由于人员层级，角色，供应商或者IT部门等等复杂因素的结合，因此不同角色之间如何分清楚角色边界，新引入的例如Scrum Master，DevOps SRE到底该干什么也成了首当其冲的问题

以上三类问题也只是作为一种抛砖引玉，事实场景可比这个更复杂，我们总是希望大家可以足够的简单起跑，可总是有人希望事情该规划的足够细致入微才可以不出错。管理究竟是简单有效还是复杂有效呢？

基于我们过去的经验，我们也尝试着定义过许多复杂的框架体系，希望团队能够在复杂框架体系下“健康”的成长，然而总是事与愿违，因为这样的结果往往带来的是消化不良。

根据我们的多年实施的经验总结，组织就应该根据现状定义可接受的框架式的实践流程，而不是一股脑的使用各类市场上常见而且看似最终形态非常有效强大的实践作为导入阶段的实践组合。那么此时对团队的不是适用，而是伤害了。

插图：演进式的最适配实践

究竟是全面敏捷还是局部敏捷

在我们服务过的企业中，有过全面敏捷的企业，也有过局部试点的企业。其背后的动因与目的各不相同。全面与局部各有优劣，但是从我们调研过的敏捷企业中发现，似乎全面敏捷化（这里特指更宽泛意义的敏捷思维方式）对于企业的战略对齐以及灵活性具有更深远的影响。

组织规模化的过程是齐头并进还是略有先后，这都无法明确成为一种定论。但是从我们已知实践过的企业中所得到的结论是，如果敏捷动因正确（外部环境压力，内部激活组织，形成创新文化，打破部门壁垒，形成学习型能力的组织等等）那么即使开始是局部的，最终也一定是全面的。

这里要提一下的是，假设有一天全面敏捷化的话，好处是什么呢？

这可能是一个深层次的自我认知并且自问自答的过程，因为可能起步的过程中，大家并不知道为什么要敏捷，自然就不知道为什么要全面敏捷。根据我们之前的讨论，本质上假设有一天组织敏捷了，那么团队会思考了，大团队组合也会思考了，组织也学会思考了。那么这艘大船就很清晰自己什么时候该调头，什么时候该加速疾行，什么时候该韬光养晦了。那么由此假设可以判断，至少全面敏捷益处肯定是不少的。

就像我们之前讨论过的最适配实践同样的道理，即便我们认为终点是正确的，最佳实践是美好的，但是组织在演进的整个过程是需要时间积累的。

如何成就一个规模化的敏捷组织

组织领导者的转型驱动力

组织的领导者是对于组织转型非常重要的驱动者，很多时候嘴上说的动因来自于外力，根本推动企业的或许就是这些我们实质上的领导者。这么说或许有片面性，也有人会认为可以带上我们的具有影响力的领导力的同事们，这样也是在推动着组织转型，很多成功的组织转型也的确是这么在践行着的。

试想下，如果关键领导者不动手不发话，那么基层影响力也是很难自下而上的带动组织转型的。许多类似的转型都止步于某一个小部门或者某一个大项目。因为组织领导者从中并不能识别出敏捷转型对组织整体能够带来的良性变化，仅仅将敏捷当作一种项目管理工具或者方法论，应用于一些特殊的“试点”项目中。毕竟转型是需要成本也可能会失败的。

根据我们的一些分析以及长期的观察，我们发现对于组织转型成功与否，决定组织方向的领导者都会有一些独有的特质，我们可以将其归纳为：

1.具有一种长期坚持的学习与自驱力，具有这种特质的领导者能够及时的通过组织的某些转变（成功亦或是失败）都可以从中学到经验教训，也可以及时的思考并转身

2.坚持以身作则，将转型作为一种可以外包给别人的领导者，那么转型最终也只是成了一个外包项目

3.持有成长型思维，这种思维模式是非常可贵的，有些情况下我们总是看到一旦我们犯了某种错误，似乎就被判定为不可饶恕，而如果我们将任何失败或者错误看作是一种试错，而将每次试错看作经验财富，那么组织是具有正能量的，是会持续进步的。当然某些极端情况下，我们允许了大家试错，但是总是一错再错屡教不改，那么这种情况是不能被鼓励的。而是应该被深究原因的。

业务线+微服务+关键岗位

良好的业务线划分而不是草率的划分了业务线但是又不与实际的业务能力相匹配并及时调整，那么这样的组织架构设计大概率也只是感动到了自己吧。微服务也是我们开头说过的，架构是一个数字化组织的基底，如果基底乱了，业务再好也是无济于事的。最后关键岗位，我们要做敏捷转型，我们究竟是依赖于敏捷教练，还是scrum master，还是产品经理，还是BA，还是测试，还是开发，还是业务人员等等的。其实每一个岗位尤其是关键岗位应该精挑细选，经过统一认知的培训。

在过去我们的优秀实践中，有过一种方法，那就是集中优势力量，整合一套标准化教材，统一培训train the trainer，然后用 TTT 的力量再扩散到其他业务部门与团队中，能够快速有效的培养起一大波统一认知与工作方式相同的人员，当然我们也提过优秀的最佳实践的危险的。我们还需要从中识别中重要的关键岗位人才，确保大家的价值观与做事方式基本一致。

个人对于规模化敏捷的思考

组织是能够思考的，只是需要一些时间以及给予足够的信任

我们深信组织是能够学会思考的，只是组织速度快一些，有些则异常缓慢，但终究是可以学会的。

此处我们该不断的给予一些信任，以我本人过去多年的经验，我总是会不断的去找关键岗位的人聊天谈心，启发其思考总结，很多时候转变真的只是一瞬间。

不断把你的、我的，变成我们的

最后想总结一点，这点也是我近1年来不断在做的事情，就是在组织中不断的强调，没有那么多的你的，我的，当有一天我们认识到这件事情是我们的时候，那么组织将会有巨大的改变。是我们共同创造了一个会思考的组织，是我们营造了一种共同创新的文化，也是我们共同维持了一个可持续的秩序，让组织不断的根据外部环境的变化而变化，真正成为动态自适应的平衡态的组织。

by/资深顾问&敏捷PMO教练 徐陈飞

四、哈佛商业评论 | 汽车硬件研发规模化敏捷的三项原则

（ SAI SAFe规模化敏捷官网 ）

作者简介：

Christoph Weber 担任AutoForm中国区总经理 – 全球所有主要汽车制造商都选择AutoForm软件。他是经过认证的Scaled Agile Framework® 5项目顾问，帮助汽车制造商通过车身工程和制造的数字化转型加速生产的启动。

01 汽车制造商规模化敏捷概览

汽车制造商正在转型成为科技公司。软件开发人员利用敏捷方法每隔几周就能交付一次新产品的迭代，但硬件工程师仍然依赖瀑布式项目管理方法，开发周期需要 2 至 4 年。在我们过去的项目中，我们已经确定了实现硬件产品开发敏捷化的三项原则。

本文将描述它们如何应用，分享汽车车身制造的实际案例，并解释 数字孪生技术 是如何发挥作用的。我们旨在激励来自任何传统行业的管理者，敢于向更高的灵活性和以客户为中心为目标迈出下一步。

汽车制造商面临着快速推出新款电动车型、满足精通技术消费者的期望以及赢得新工作时代人才争夺战的压力。尽管如此，车身工程等传统领域可能认为数字化和 敏捷颠覆不 适用于他们自己的领域，因为交付周期和对模具、冲压线和焊接机器人的大量投入似乎决定了前期规划的 事无巨细 。

事实是，当今数字孪生技术已经准备好，即使是应对复杂的硬件产品，也可以实现全面的数字化和敏捷转型。

图 1 ：汽车车身工程和制造必须变得更快、更便宜和以客户为中心

在过去三年与汽车制造商和供应商的合作项目中，我们已经确定了三个精益-敏捷原则，帮助传统硬件生产商能够一定程度变得敏捷：点对点负责，基于工作系统优化各项环节和跨职能团队。 一个普通汽车制造商可以通过车身工程和制造的数字化和敏捷转型，将生产开始时间加快6个月，每年节省超过1000万美元，并激发更高的客户和员工参与度。

02 原则一：点对点负责

图 2 ：实现硬件产品开发敏捷性的三个原则

在开发一个复杂的产品，如新款车型时，需要多个部门和供应商一同协作。然而，在瀑布式组织架构中，每个部门都有自己的时间节点和KPI。每个部门可能使用不同的工具来制定产品设计和生产概念。不同的工具--例如软件、电子表格、历史数据或个人经验--是基于对同个现实的不同模式和理解。 由于这种组织和技术上的脱节，工程师专注于他们的目标，可能没有充分考虑其他部门的限制和目标。缺乏相互接受的数据减缓了跨部门决策的速度。自发的信息反馈是不可能的。这些职能部门之间的交接导致了浪费和延误--比如过度的工程设计，整合问题的延迟发现，错过了成本节约和轻量化的潜力，因此导致了预算和时间进度的超支。

图 3 ：职能之间的隔阂导致浪费和延误

敏捷的企业打破了职能上的隔阂，建立了跨职能的团队，对每个价值流承担点到点的责任。每个价值流提供一个模块，如车身或动力系统，之于整个解决方案，即汽车。每个价值流和支流都需要明确定义的接口，并应尽可能地相互独立。

团队承担从设计到生产的点到点责任，以优化流程，实现系统思维，而不是局部优化。一款集成软件工具的数字化点到点平台应该支持每个团队。规模化敏捷框架为这种方法提供了进一步的指导。

图 4 ：价值流组织优化了流程和系统思维

一家 德国汽车制造商 已经成功地将车身冲压和装配之间职能上的隔阂衔接起来。传统上，大多数汽车制造商对单件冲压和车身装配进行分别优化，这导致了额外的校正轮次。

通过新方法，冲压和装配工程师共同承担点对点的责任，以优化整个车身系统。他们整合冲压和装配的数字工艺模型，以优化车身装配的单件形状。通过这种系统优化的方法，这家领先的汽车制造商将一个引擎盖装配的生产准备时间从12个月缩短至6个月。

图 5 ：系统优化减少过度工程和浪费

03 原则二：基于工作系统优化各项环节

传统的产品开发方法是在2至4年内通过数个瀑布式的项目规划阶段进行的，然后以"大爆炸"的方式向市场推出一款新车型。因此，客户的反馈只能针对每款车型每隔几年被纳入考虑。

此外，制造和集成问题只能在生产升级阶段发现。相比之下，敏捷产品开发每隔几周在常规的冲刺中测试和提交小的产品迭代。尽早并尽可能频繁地采纳客户的反馈，发现制造问题减少了产品和可行性失败的风险。

软件产品的迭代可以在几秒钟内通过点击鼠标按钮进行测试。然而，像汽车车身这样的硬件产品需要几个月的准备时间，并在模具、冲压线和焊接机器人方面进行大量投入。这就是数字孪生--现实生活中的物体或过程的虚拟模型--可以取代物理试制和测试。

物理驱动的数字孪生技术帮助工程师能够在几个小时内测试产品性能和可制造性，即使是复杂的硬件产品在每一次产品迭代中也是如此。这确保了每一个产品迭代从一开始就有质量保证。

对于设计或制造概念的任何变化，数字孪生技术提供关于对质量、成本和时间影响的即时反馈。内部和外部客户可以在此基础上提供有意义的反馈。

图 6 ：物理驱动的数字孪生实现预测和自我修正

一家 日本汽车制造商 通过系统地探索数以百计的替代产品设计和生产过程，并通过数字孪生的快速迭代测试，实现了客户价值最大化。例如，他们通过数字工艺孪生分析了具有替代材料厚度和形状的铝制发动机罩部件的冲压过程。

他们排除了不可行的设计，然后选择了一个重量最轻、成本最低的设计--每个零件的重量减少了7%，材料成本减少了1欧元。

04 原则三：跨职能团队

我们的客户调查显示，50%的冲压工艺工程师没有系统地参与到冲压模具调试。工程师和车间团队之间这种令人震惊的脱节，基本上切断了工程设计的“数字孪生”和实际制造的“物理孪生”之间的联系。

工程团队可能不了解生产的实际情况，缺乏建立一个准确的数字孪生模型所需的反馈。车间团队可能会收到设计不良的模具，并以试错的方式重新设计流程，而不是在现有的流程知识基础上进行改造。

解决方案是在一个点对点的平台上连接设计师、工程师和车间工人，在一个数字工艺孪生平台上协同工作。工程师必须对车间的质量目标负责，并基于数字工艺孪生测试所有的KPI。

例如，工程师应通过进行工艺能力分析来确保稳定的生产。车间工人应将实际的制造数据输入系统，以使数字和物理孪生保持一致，达到准确的预测。在此基础上，物理驱动的工艺孪生计算并提供指导，以最系统的方式达到一个稳健的生产过程。

图 7 ：数字工艺孪生在点对点平台上连接团队

一家 中国模具供应商 利用跨职能的团队合作，为一个具有挑战性的A级铝制引擎盖项目减少质量检测轮次。如今，中国大多数汽车和模具制造商需要超过10个质量检测轮次来交付具有高表面和尺寸质量的铝板--这导致了大约一年时间上的延迟和巨大的模具再加工费用。

在这个咨询项目中，我们与每个部门和供应商密切跟进，建立了一个精确的数字工艺孪生模型，包括材料测试数据和工艺能力分析。因此，我们可以准确地预测和补偿尺寸回弹，并在第一次调试时提供良好的零件。

05 结论与实施建议

汽车和其他行业的硬件产品开发必须走向敏捷，这样才可以变得更快、更便宜、更以客户为中心。当今数字孪生技术实现了全面的数字化和敏捷性转型。

以下三个原则助力硬件产品的开发，实现规模化敏捷。

1）点对点负责：围绕价值流建立团队，为完整的系统优化单一部件。

2）基于工作系统优化各项环节：通过由物理驱动的数字孪生测试快速优化轮次实现客户价值最大化。

3）跨职能团队：在点到点平台上连接工程和车间团队，在一个数字工艺孪生平台上协同工作。 数字化和敏捷转型是一项领导任务。在制定战略目标和审查业务结构和流程、软件和技术、人员和文化方面，需要C级的支持。

下图概述了最近与中国一家汽车制造商合作的转型项目的目标和关键措施。

图 8: 数字化和敏捷转换是一项领导任务

五、SAFe（规模化敏捷框架）与IPD的区别

（原创 宋荆汉 质量与创新）

近期群里有位粉丝同学问宋老师一个问题：SAFe与IPD有什么区别？

还真是第一次有人问到这个问题的，因为，目前了解SAFe的人本身也不多，同时涉及SAFe与IPD的人群更少了，宋老师恰好又这2个框架体系的经验，觉得这个问题还是有价值的，所以宋老师决定还是认真的一篇推文谈谈我的理解。

— 1 — SAFe是什么？

IPD这个大家已经很熟悉了，我就不再累述了。重点先介绍一下SAFe（Scale Agile Framework），中文全称是规模化敏捷框架。很多人可能会认为这个是不是就是大规模敏捷软件开发的框架呢？在官方课件中介绍是

SAFe 是实现业务敏捷的运营系统

因此，SAFe已经不仅仅是敏捷项目开发了，而是上升到业务运营层面的框架，那么如何理解业务敏捷呢？还是看官方课件

业务敏捷， 是指通过创新的数字化业务解决方案，快速响应市场变化和新兴机会， 从而在数字化时代开展竞争和实现蓬勃发展的一种能力。

这个听起来有点抽象，我们看一下官方发布的全景图，可以看到整个框架的构建分4个层次展开的，从上向下分为：

投资组合层，这个属于战略规划层级的；

解决方案层，大家可以理解为是产品组合或产品线层级；

产品交付层，就是我们理解的产品开发；

团队层，可以理解为产品有很多子系统或特性构成，这层级就是某个敏捷开发项目；

我们可以理解为什么说SAFe是业务敏捷了吧？SAFe是从组织业务级敏捷到开发项目敏捷的结构化框架，不是大家了解的Scrum这类软件敏捷开发项目级的敏捷了。

在早期敏捷项目中，通常项目团队成员就7人左右团队，但是现在很多大型产品的复杂度与研发团队的规模远远超出7个人的水准，但同样需要实现敏捷化应对外部快速变化的环境，因此SAFe规模化敏捷框架也就应运而生了。

SAFe将价值流、团队和时间盒等敏捷元素进行规模化扩展，使得从百人到数千人的企业都能成功应用敏捷方法。

— 2 — SAFe与IPD的区别

IPD集成产品开发管理框架，是一套包含企业产品开发的实现、模式、工具的系统工程。通过“做正确的事”确保产品聚焦市场需求，通过把“事情做正确“提高效率、减少浪费、降低成本，确保产品符合市场要求，最终实现产品的商业成功。

1、从框架内容的主要区别

无论是IPD还是SAFe框架，都包含从业务战略到产品开发的项目开发的整体管理解决方案。但核心管理模式上 IPD管理模式还是基于门径而SAFe在各层级都应用了精益敏捷的方式。 例如：

IPD，需要大量的前期调研还有预算规划，基于ROI来确定确定投资方向，通过门径及计划管理来管理投资及任务完成进度。

SAFe，采用敏捷模式，动态调整预算，通过MVP、业务成果假设等精益方法来推动业务，通过看板来管理。

IPD的产品开发，基本还是采用瀑布模式，而SAFe产品开发采用的敏捷模式；

IPD强调通过基于CBB的产品开发及结构化的流程，但SAFe面向更多是软件开发相对角色比较简单，对流程结构化层的要求不高，而是敏捷化也很难构建CBB，因此在SAFe里面基本没有太涉及。

2、适用不同企业

IPD体系通常适用于如下企业

• 经营模式验证后，管理模式优化或重构的问题，IPD就适用了；
• 市场需求拉动而不是技术驱动创新；
• IPD非常适合那种行业商业模式是基本确定，市场竞争相对激烈，有标杆、竞争对手和客户需求去牵引。
• IPD体系非常合适做长生命周期产品的企业，长周期产品才要求不断迭代，通过不断迭代产品和技术创新，提升企业的产品和技术竞争力。开发所谓“爆品”的作用不大。
• IPD体系非常适合需要很多不同的专业部门来共同协作的产品开发过程，比如软硬件一体化产品

SAFe可以适用

• 模式还未经过成熟验证，需要快速迭代跑通的情况；
• 行业竞争变化较快，创新性强，模式不确定、需求不确定的情况
• 软件产品

— 3 —SAFe与IPD的整合

现在其实新能源汽车行业，有很多头部车厂都在同时导入SAFe框架及IPD体系，新能源汽车本质就是一个大型的软硬件一体的电子产品开发项目，整体上非常适合IPD体系来进行统一化管理，同时软件在新能源车的比重和带来的附加值也越来越高，而且软件本身透明度低、变化快、需求难以明确等特性，使得采用敏捷开发方法更加适用。 所以，很多车企也在对2种体系进行整合。

汽车本身是一个软硬件一体化的产品，而且需要非常多不同专业领域的工程师协作才能完成产品的开发， 而且因为汽车行业对安全质量的要求非常高，所以在整个产品开发过程中需要遵循很多的合规性要求，而合规是刚性的，这就决定了全面采用敏捷开发模式是不适合的。

另外，汽车行业一个产品的投资决策到产品上市的过程周期相对较长，而且资金投入巨大因此，需要对投入产出进行更精细化的管控，计划、预算必不可少。采用敏捷化的投资决策，难以匹配组织的风险与财务管控要求。

汽车作为大宗消费品，可以对其选择还是比较看重安排、品质和生命周期成本，客户体验并不是最核心的购买要素，需求变化和不确定性并不会像互联网产品那么大。

因此，总体来说整车研发 更 适合采用IPD的模式来进行管理。

但是，因为硬件层面的同质化，软件价值日益凸显，很多车企期望通过软件来实现产品的差异化，因此软件开发的比例也逐步加大了。特别像自动驾驶这里基于AI与大数据、云的应用系统，如果采用传统IPD开发模式，就会显的比较繁重，对市场需求的反馈速度也会被拉慢，产品竞争力就会受影响了，采用敏捷产品开发模式就更加适合了。

因此，可以基于IPD产品开发管理框架为基座，通过流程结构化，把软件开发过程异步分离出来，然后针对软件部分应用SAFe的方法，同时做好与主业务流程的接口衔接。采用混合模式管理，不失为一种比较好的管理方法。