制造业产品开发中应用敏捷Scrum的思考 （下篇） 上篇作者作为一名机械制造业的从业者，简单介绍了敏捷Scrum，并分享了一些对Scrum理念的理解下篇以制造业产品开发中应用敏捷Scrum的思考进行了一系列的分享
点击链接阅读：
敏捷Scrum理念的背后写给机械制造行业同仁（上篇）
作者 : Sven Fang 房世庆
Scrum硬件及制造业专家
德国杜伊斯堡艾森大学机电工程专业博士
如同IT行业，制造业也面临着越来越严峻的挑战，市场要求企业能够做到更快的产品更新，更低的成本和更高的质量在IT行业日益得到推广的敏捷Scrum框架给制造业的产品开发带来许多启发不少企业已经开始尝试改变传统的瀑布式产品开发模式，应用敏捷Scrum 框架以快速适应市场变化，控制风险和提高客户满意度本文在考虑国内制造业特点和目前状况基础上，就如何应用Scrum框架和理念表达作者的一点拙见这里假设读者已经拥有敏捷理念和Scrum框架的基本知识
1 制造业产品开发的运作方式
图1 普遍采用的产品开发项目流程
这里所说的制造业是广义的制造业，区别于软件业，以物理对象为产品，如机械，仪器，仪表，工具，汽车业，家电等等在软件业，习惯把所有非程序类产品称作硬件为避免和PCB板之类的硬件电子产品混淆，我们这里没有用硬件一词
制造业悠久的发展历史，积淀了百年的经验，很多约定俗成的理念和方法源远流长
现代产品开发的运作方式受泰勒（Frederick Taylor）和法约尔（Henri Fayol）的思想的影响，采用瀑布(或称 串行)式的方式，高度重视计划分工职权和控制其实产品开发的理念及流程和变革前的软件行业没有本质区别 以汽车零部件行业为例，产品开发是一个计划性过程控制，一般产品开发都以项目形式管理，项目经理对项目的成本进度以及交付负责在产品开发前，客户和企业就产品需求以合同的形式固定下来，从明确的需求开始，制定开发计划，分工开发组件，集成后测试，冻结设计，模具释放，工艺方案设计及实施，样件，最后批量生产（如图1所示）对于产品换代缓慢，大规模生产的时代，这是最合适的方式
今天的世界已经不是昨天的世界了，为追求更高利润，单纯地扩大规模以降低成本已经不够，市场竞争压力越来越向产品开发部门转移传统的基于计划的开发理念和运行方式对于那些必须开发复杂产品（复杂产品未必结构复杂）以提高市场溢价权的企业来说，很可能导致企业的衰退面对更多不确定性的当下世界，大家都意识到下列问题必须解决：
- 局部优化是不够的，必须以系统思维开发产品
- 仅有销售部门面向客户是不够的，必须面向客户开发产品
- 再完善的开发计划都赶不上变化，必须拥抱变化
- 再专业的项目经理都是不够的，必须要团队协作
- 等等
敏捷理念下的Scrum框架，采用跨职能团队迭代增量持续可交付产品等方法为我们提供了这种变革的一种可能
2 敏捷Scrum在制造业的实践
这里要提到的是，其实机械制造行业很早就接触并应用了敏捷理念作者认为，大家熟悉的精益生产理念其实就是敏捷理念的源头，甚至敏捷理念下Scrum的构思也起源于制造业 [Kenneth S. Rubin, 2012 ]从精益生产理念扩展而来的产品生命周期管理（PLM）并行工程(Concurrent Engineering) 已经被一些企业自觉或不自觉地运用到产品开发中[熊光楞主编，2011]所谓并行工程旨在整个开发工作都着眼于整个过程和产品目标，避免传统的串行开发模式带来的弊端，其中不少地方如跨职能团队，产品导向都能看到和敏捷Scrum类似的宗旨和方法
敏捷理念下的Scrum框架简单，有其独到性，这也是为什么在软件界得到迅速的认可和普及尽管传统制造行业的产品开发和软件行业有所不同，但Scrum在软件行业应用的成功使得硬件及制造业的管理者们开始尝试在本行业的应用 走在前面的是那些包含嵌入式软件的供应商以及一些仪器设备供应商们 然后慢慢延伸到纯机械制造行业正如Rubin提到的：虽然 Scrum 最常用于开发软件产品, 但 Scrum 的核心价值和原则可以而且正在被用于开发不同类型的产品或组织不同类型的工作流程例如, 我曾与成功使用 Scrum 的组织合作, 以组织和管理与硬件开发营销计划和销售计划相关的工作[Kneneth S. Rubin, 2012 ]
这里我们列举两个业界的例子，可以说是基于敏捷Scrum框架进行的产品开发
2.1 波音777 的研发
波音公司从1990年概念设计开始到1995年5月在联合航空投入商业运营，在6年里成功完成了一个50亿美金的新产品波音777开发项目，参与员工达1万多人项目负责人 Alan Mulally 创新地运用的一起工作模式其实体现了敏捷理念
Mulally组织起了约250个多功能团队DBT（DesignBuild Team），每个DBT团队负责一个功能模块每个DBT都由综合多样的人员组成，可以完成从概念到制造和维护团队中有设计，制造，模具人员，财务，材料，维护，分包合同代表，客户代表所有DBT每周进度例会保证团队之间的沟通协调，为进一步做到透明开放的沟通，他将波音777的所有10000个员工每个季度都汇集到西雅图，开为期两天的all-team meeting！这样的会议在30个月里开 了9次（见图2）匪夷所思！
图2. 波音777 及西雅图大会
Source: https://theleanviking.wordpress.com/
对于那些小的日常的变化，DBT多功能团队会来处理新涌现的信息，并在制造和设计工程师之间形成快速的反馈循环需求变更以往需要消耗几周，但是在DBT团队一天就可以搞定了当你可以快速合作，应对变化就会变得更容易
777是几乎完全使用三维CAD软件代替二维图纸设计的第一架飞机在建造第一个原型之前，3D CAD模型就可以组合在一起进行实时验证这就加快了反馈闭环的形成，增量的质量也有一定的提升，从而能够更早更好地得到反馈
波音通过许多举措让客户参与到开发中来，并强调和客户的合作高于一切由于客户的参与，客户快速反馈，团队可以及时响应变化而非无条件遵循计划在这里Scrum框架的跨职能团队迭代增量等均有体现
较详细资料请参见Agile at Boeing in 1990s the 777 Program
链接：
https://theleanviking.wordpress.com/2014/10/07/agile-at-boeing-in-1990s-the777-program/?from=singlemessage 以及唐怡佳的硬件敏捷先驱波音777案例分析；链接： http://www.shinescrum.com/news_and_events/777
2.2 Wikispeed
图3. Scrum in Wikispeed, Source: http://wikispeed.org
提到敏捷Scrum 在制造业的应用，大家都愿意拿Wikispeed举例Wikispeed 是一个汽车制造组织，它使用面向世界开源（Open Source）的方式制造有上路许可证的节能汽车它的员工由分布在全世界20多个国家的近200个自愿者组成，用户可以在网上订购从世界不同地方生产的9个模块组件组装成定制的汽车，目前，可选汽油机或电动机为动力Wikispeed曾经运用Scrum框架在3个月内开发并制作出一辆原型车Wikispeed 的开发特点可以总结以下三点[Shantam Shukla,2013]：
- 开源设计
如我们以前熟知的Linux系统的开发，Wikispeed的团队开放资源，吸引全世界的造车爱好者参加到开放中，自愿者们大多利用业余时间参与团队并完成部分工作
- 模块化及测试驱动开发
Wikispeed团队将整个汽车分成8个模块，每个模块由来自世界各地的一个或多个团队自愿者负责开发，成员一般是该领域的技术专家或爱好者为了实现开发和组装的灵活性，为每个模块定义了通用接口，以实现即插即用的理想虽然模块化设计导致模块内的冗余，可能会导致局部成本的增加，但考虑到客户的多样性和灵活性的要求，以及Wikispeed 开发组织的特点，从系统角度考虑，这是个明智的选择
对于每个模块的开发, 团队最开始先构建了重要的测试要求例如， 一个从事底盘设计的团队可以以任何方式开发它, 直到它满足最初的测试要求
- Scrum框架组织开发
发起人Joe Justice 是软件工程师出身，用业余时间开发并制作一辆汽车对于他和他的团队来说是充满不确定性和挑战的项目由于是开源的形式，为了管理和协调来自不同地区不断壮大的志愿者团队，他和Wikispeed的其他成员使用Scrum的原则协调分布式虚拟环境中的开发
开发团队承担Sprint的任务, 并尝试在7天内实现预期结果Sprint的任务由团队中的产品负责人（Product Owner）定义，并负责定义正在开发的模块测试的要求和参数不同的Sprint可能有不同的产品负责人自愿担任，他往往是该Sprint任务领域最专业的人士
由于是自愿开源的形式，团队中没有主管, 也没有说由PO来确定团队任务的优先级
图4. Sprint in Wikispeed
source：[Shantam Shukla,2013]
3 制造业应用敏捷Scrum 进行产品开发的 一些问题
如何在机械制造行业成功地应用Scrum？，这个话题太大，涉及到的方面太多，一本书的篇幅也很难阐述清楚, 我们或许可以把问题分成两类：一方面其实是制造业的人文问题，另一方面是技术问题所谓人文问题，是制造业根深蒂固的传统理念，和许多固化的思考及行为方式所谓技术问题是指：制造行业的产品对象为物理实体，在开发过程中会遇到很多和软件业不同的问题但必须承认， 有时候很难区分是人文还是技术问题，有时候表面上看似是技术问题，其实是人文问题
在制造行业应用敏捷Scrum，首先需要深入理解企业，从产品当前的组织管理架构组织文化人员状况等多维度，考虑是否合适采用Scrum框架以及实施的节奏 不是每个组织都适合采用敏捷Scrum，也不是每个企业的Scrum都是一模一样的
3.1 应用敏捷Scrum的人文问题和思考
组织文化
Scrum的成功需要文化机制来保证试图改变一个组织的文化是愚蠢的，它总是以失败告终人的行为（文化）是制度的产物； 当制度改变时人们的行为才会随之而变 [Craig larman and Bas Vodde，2016]
而改变机制需要改变一个根本的观念：对人的观念敏捷理念是建立在如何利用人的潜力这个基础上的：如果给与机会，人类广泛具有想象力，创造力；人们会为自己所认可并承诺的目标做出努力，承担责任而传统的管理模式是基于假设：人们逃避责任，没有主见，本性懒惰麦格雷戈在他的企业的人性面中把建立在这两种假设上的管理理论和实践称为Y-X理论对人的根深蒂固观念受文化和教育的影响很难改变，直到今天，我们国内学校还在按传统的假设（X假设）培养我们的下一代可想而知，敏捷理念的实施和落地在国内将遇到多少困难 传统的对人的观念，已经渗入我们传统行业每个管理者和被管理者的骨髓在采用Scrum实践中，管理者往往有强烈的变革意识，希望推动Scrum，但他们习惯的不经意的控制行为往往阻碍Scrum的成功，个人绩效是个控制的例子
从组织管理角度，重构机制，降低管理者的控制欲，使管理者成为引导，教练型角色，给与个体贡献潜能的空间，作者认为是Scrum成功的条件敏捷Scrum 的采用提供了变革的工具，但如果没有机制作为保障，只能带来混乱 （本人也是X假设下培养出来的）想象一下，取消个人绩效取而代之的是团队的绩效，由团队自己决定收益分配，仅仅就是这一点机制的改变，在国内制造业的人文环境下就很难实现
由于有各种人文阻力要比软件业更大，Scrum的采用步骤和规模值得注意
虽然我们有波音777的大规模研发中使用敏捷理念成功的案例，但个人还是建议循序渐进地在机械制造行业采用Scrum通过小规模地采用Scrum，适应新的思维和行为规范， 最重要的是试验新的文化机制Scrum只提供了一个框架，在许多方面它没有提供明确答案，而其他没有说明的，如文化机制却决定了其实效性实施Scrum的具体建议见在章节3.2
成员状况
对比软件业，我们不能不承认，制造业研发从业人员的平均年龄都偏高，由于各种原因，对待新事物的态度偏保守在硬件及制造行业，专业化很强开发人员往往只具有某项专业技能，需要多年的工作经验成为某专业的专家，一专多能较难实现在开发中，对这样的专家依赖严重 这样的状况有时是产品本身特点造成的，有时是传统组织架构长期累积的结果
在实践Scrum前，一个重要准备是需要企业内部各个层面及个体对敏捷理念，Scrum框架以及其背后宗旨的深刻理解在此基础上才可能灵活运用敏捷Scrum以达到目的
另一方面，在组织中自上而下的推动，自下而上的实施成功率要高些，因为Scrum挑战很多传统的思想和行为，会涉及到个人或组织阶层的固有利益（非公司利益）
3.2 应用Scrum的技术问题和具体建议
讨论了应用Scrum的人文方面的问题后，下面讨论普遍存在的所谓技术问题
产品开发的复杂度
Rubin 在他的Essential Scrum 一书里把要解决的问题分成了5种，并非所有问题都适合Scrum框架Scrum 框架一般较适合于解决较复杂的不确定性强的开发，尤其是有很强的探索性开发一个以委外加工为主，设计图纸又由客户提供的公司，Scrum很难带来大的改变不少领域的工作使用Kanban 可视化管理就能收到很好的效果
产品的测试环节需要较大的资金投入，并且准备时间及制作周期长
由于产品对象是物理实体，相比软件业，制造行业产品开发有如其特殊性很多产品的样件往往需要模具，尽管可以使用 软模具，但依然成本很高漫长的制作时间往往成了项目开发周期的瓶颈除此之外，模具及样件往往由外部供应商提供，有时还需要考虑采购部门的选择定点时间样件制作是项目经理最头疼的一件事
以汽车零部件企业为例，为了小规模采用Scrum来提高企业应对市场灵活能力，推荐在企业的预研发（pre-development）环节先实践Scrum框架 一般来说， 预研发产品开发是制造企业对前沿技术或工艺做研究性或探索性的尝试，经过一系列功能等实验验证，并根据客户（也可能是公司内部客户）或市场需求制作出样品，在展览会或目标客户处展示，测试市场反应预研产品代表了公司或行业的最前沿技术水平，在得到订单后进一步开发成批量产品由于预研产品开发交付的产品是样件，涉及的外围职能团队相对较少，比较容易组织起跨职能团队，一般由设计，仿真，测试等组成即可，产品负责人（PO）可由该产品领域业务单元客户组成员担任这样的规模对企业整体组织的变更度最少，阻力也相对较小，同时提高了企业新产品的更新换代速度在Scrum实施获得成效后，扩大产品定义或产品交付的定义，组织变革的范围也随之扩大，整个企业的灵活性，创造力随之放大最终做到整个系统的敏捷：从研发到批量供货
在制造业产品开发中，利用虚拟仿真工具减少对实物测试验证的依赖是必由之路我们前面举的两个例子来说，如果波音公司没有在研发中使用 3D CAD 制图，很难尽早发现设计的一些问题并进行迭代现代的技术手段为敏捷开发提供了更多的物理可能性3D打印技术，3D扫描技术，各种仿真技术等都提供了强有力的支持（虚拟现实技术的实际运用还要等一等） 目前还存在着仿真的建模时间较长，仿真结果的可信度等问题影响开发迭代周期，但这都不是制造业拒绝Scrum的借口例如，十几年前就有国外汽车零部件企业不借助商业软件实现了3D CAD模型到多体仿真模型的自动建模，将建模时间从数周减少到数小时
产品的功能涉及很多组件，并与其它功能相互交织，功能之间的接口不易定义清楚
机械产品中每个功能都可能会影响到所有其他功能功能间耦合度高而在软件开发中，可以从几个功能和一个简单的产品开始, 然后再陆续发布新的功能和更新产品这对于机械开发是不易实现的表面上可能会给产品待办列表（Product Backlog）的拆分以及各Scrum团队的协作带来困难实际上，这是个研发思路问题，是设计理念问题 只有对某个研究对象能进行充分的解耦，我们才能说了解了这个对象 如果我们设计的产品系统难以被解耦，说明最终产品的某种健壮性（robust）会有问题这点和软件设计开发没有本质区别
解决这个问题需要工程实践，在初次采用Scrum框架时，会花费团队意想不到的的时间去定义Sprint的任务和测试方法，这很正常，因为我们现在使用不同的思路和角度去理解产品， 现在我们不再是以产品本身功能实现的角度，而是以面向客户产品价值的角度审视我们的产品
产品开发需要的外部协作较多，共享资源多，接口多
实体对象的开发需要采购，核算，样件，测试，物流，质量，生产等部门以及外部供应商们的协作各职能部门由于人员，设备的限制，资源由各开发项目共享你的项目任务是公共职能部门手里众多项目中的一个，灵活性受到限制如图5所示，是汽车零部件企业典型的组织架构
图5. 当前普遍的组织架构
其实，大型软件开发也会遇到同样的问题不同的是制造业设备资源等投资大，需要考虑共享但软件行业不少用于开发的商用软件价格也不菲共享部门的支持，外部协作不可避免如何解决是具体方法问题而非Scrum框架问题制造业完全可以借鉴软件行业的经验，做些适应性调整如果很难做到真正的跨职能团队，必须使用公共资源的时候，可以考虑软件业使用的打桩（mock-up）的方法，在迭代中尽量降低依赖度制造业也经常使用所谓的Dummy来暂时替代还没有完成的部分，以保证研发的持续，随着其他部门工作的推进，缩小被设置 Dummy的部分的规模，直到彻底取消
团队异地合作
Scrum强调团队要在同地点工作以方便随时沟通，但如今跨国合作进行产品开发很普遍，这在软件行业也非常常见，但在机械制造行业异地团队合作的难度更大实践经验告诉我们，如果一个Scrum团队有异地成员，一般Sprint的长度不易定义偏短，尽管有视频会议，联合开发平台的支持，用于沟通的时间要大幅增加有时实物异地运输时间也要考虑在内
4 总结
为了提高企业的市场竞争力，制造业的产品开发完全可以运用敏捷Scrum框架以改变由来已久的传统模式实践Scrum需要结合自身的具体情况，在深刻理解敏捷理念的基础上灵活地做探索性的调整 在实践中，最大的阻力是组织内的传统理念，从业人员的理念，而非其他技术性问题， 至上而下的推动是必要的作者认为，组织的机制是决定敏捷Scrum成败的关键作者提倡首先在产品先期研发项目上实践敏捷Scrum，然后逐步推广到整个产品开发由于制造业开发的对象是实体，生产最终产品的代价高，因此更需要在资金大投入前利用Scrum框架下的迭代增量的方法充分验证产品的市场价值，加大虚拟，快速成型等手段在研发阶段的应用力度在虚拟仿真和快速成型技术日益成熟的今天，机械产品开发和软件开发的差别越来越小
参考文献
1. 熊光楞主编. 并行工程的理论与实践. 2012. 清华大学出版社
2. Shantam Shukla, Wikispeed. 2013.Indian Institute of Management, Ahmedabad, India, prepared this case study as part of his doctoral dissertation. (shantams@iimahd.ernet.in)
3. Craig Larman and Bas Vodde. 2016. Large-Scale Scrum: More with LeSS
大规模Scrum 大规模敏捷组织的设计. 肖冰 译.2018.
4. Kenneth S. Rubin. 2012. Essential Scrum -A practical guide to the most popular agile process. Addison-Wesley.
文章审核：Jim Wang王军
版权所有，反对抄袭，欢迎转发
敏捷开发适用于什么行业类型的产品
制造业产品开发中应用敏捷Scrum的思考 （下篇） 上篇作者作为一名机械制造业的从业者，简单介绍了敏捷Scrum，并分享了一些对Scrum理念的理解下篇以制造业产品开发中应用敏捷Scrum的思考进行了一系列的分享
点击链接阅读：
敏捷Scrum理念的背后写给机械制造行业同仁（上篇）
作者 : Sven Fang 房世庆
Scrum硬件及制造业专家
德国杜伊斯堡艾森大学机电工程专业博士
如同IT行业，制造业也面临着越来越严峻的挑战，市场要求企业能够做到更快的产品更新，更低的成本和更高的质量在IT行业日益得到推广的敏捷Scrum框架给制造业的产品开发带来许多启发不少企业已经开始尝试改变传统的瀑布式产品开发模式，应用敏捷Scrum 框架以快速适应市场变化，控制风险和提高客户满意度本文在考虑国内制造业特点和目前状况基础上，就如何应用Scrum框架和理念表达作者的一点拙见这里假设读者已经拥有敏捷理念和Scrum框架的基本知识
1 制造业产品开发的运作方式
图1 普遍采用的产品开发项目流程
这里所说的制造业是广义的制造业，区别于软件业，以物理对象为产品，如机械，仪器，仪表，工具，汽车业，家电等等在软件业，习惯把所有非程序类产品称作硬件为避免和PCB板之类的硬件电子产品混淆，我们这里没有用硬件一词
制造业悠久的发展历史，积淀了百年的经验，很多约定俗成的理念和方法源远流长
现代产品开发的运作方式受泰勒（Frederick Taylor）和法约尔（Henri Fayol）的思想的影响，采用瀑布(或称 串行)式的方式，高度重视计划分工职权和控制其实产品开发的理念及流程和变革前的软件行业没有本质区别 以汽车零部件行业为例，产品开发是一个计划性过程控制，一般产品开发都以项目形式管理，项目经理对项目的成本进度以及交付负责在产品开发前，客户和企业就产品需求以合同的形式固定下来，从明确的需求开始，制定开发计划，分工开发组件，集成后测试，冻结设计，模具释放，工艺方案设计及实施，样件，最后批量生产（如图1所示）对于产品换代缓慢，大规模生产的时代，这是最合适的方式
今天的世界已经不是昨天的世界了，为追求更高利润，单纯地扩大规模以降低成本已经不够，市场竞争压力越来越向产品开发部门转移传统的基于计划的开发理念和运行方式对于那些必须开发复杂产品（复杂产品未必结构复杂）以提高市场溢价权的企业来说，很可能导致企业的衰退面对更多不确定性的当下世界，大家都意识到下列问题必须解决：
- 局部优化是不够的，必须以系统思维开发产品
- 仅有销售部门面向客户是不够的，必须面向客户开发产品
- 再完善的开发计划都赶不上变化，必须拥抱变化
- 再专业的项目经理都是不够的，必须要团队协作
- 等等
敏捷理念下的Scrum框架，采用跨职能团队迭代增量持续可交付产品等方法为我们提供了这种变革的一种可能
2 敏捷Scrum在制造业的实践
这里要提到的是，其实机械制造行业很早就接触并应用了敏捷理念作者认为，大家熟悉的精益生产理念其实就是敏捷理念的源头，甚至敏捷理念下Scrum的构思也起源于制造业 [Kenneth S. Rubin, 2012 ]从精益生产理念扩展而来的产品生命周期管理（PLM）并行工程(Concurrent Engineering) 已经被一些企业自觉或不自觉地运用到产品开发中[熊光楞主编，2011]所谓并行工程旨在整个开发工作都着眼于整个过程和产品目标，避免传统的串行开发模式带来的弊端，其中不少地方如跨职能团队，产品导向都能看到和敏捷Scrum类似的宗旨和方法
敏捷理念下的Scrum框架简单，有其独到性，这也是为什么在软件界得到迅速的认可和普及尽管传统制造行业的产品开发和软件行业有所不同，但Scrum在软件行业应用的成功使得硬件及制造业的管理者们开始尝试在本行业的应用 走在前面的是那些包含嵌入式软件的供应商以及一些仪器设备供应商们 然后慢慢延伸到纯机械制造行业正如Rubin提到的：虽然 Scrum 最常用于开发软件产品, 但 Scrum 的核心价值和原则可以而且正在被用于开发不同类型的产品或组织不同类型的工作流程例如, 我曾与成功使用 Scrum 的组织合作, 以组织和管理与硬件开发营销计划和销售计划相关的工作[Kneneth S. Rubin, 2012 ]
这里我们列举两个业界的例子，可以说是基于敏捷Scrum框架进行的产品开发
2.1 波音777 的研发
波音公司从1990年概念设计开始到1995年5月在联合航空投入商业运营，在6年里成功完成了一个50亿美金的新产品波音777开发项目，参与员工达1万多人项目负责人 Alan Mulally 创新地运用的一起工作模式其实体现了敏捷理念
Mulally组织起了约250个多功能团队DBT（DesignBuild Team），每个DBT团队负责一个功能模块每个DBT都由综合多样的人员组成，可以完成从概念到制造和维护团队中有设计，制造，模具人员，财务，材料，维护，分包合同代表，客户代表所有DBT每周进度例会保证团队之间的沟通协调，为进一步做到透明开放的沟通，他将波音777的所有10000个员工每个季度都汇集到西雅图，开为期两天的all-team meeting！这样的会议在30个月里开 了9次（见图2）匪夷所思！
图2. 波音777 及西雅图大会
Source: https://theleanviking.wordpress.com/
对于那些小的日常的变化，DBT多功能团队会来处理新涌现的信息，并在制造和设计工程师之间形成快速的反馈循环需求变更以往需要消耗几周，但是在DBT团队一天就可以搞定了当你可以快速合作，应对变化就会变得更容易
777是几乎完全使用三维CAD软件代替二维图纸设计的第一架飞机在建造第一个原型之前，3D CAD模型就可以组合在一起进行实时验证这就加快了反馈闭环的形成，增量的质量也有一定的提升，从而能够更早更好地得到反馈
波音通过许多举措让客户参与到开发中来，并强调和客户的合作高于一切由于客户的参与，客户快速反馈，团队可以及时响应变化而非无条件遵循计划在这里Scrum框架的跨职能团队迭代增量等均有体现
较详细资料请参见Agile at Boeing in 1990s the 777 Program
链接：
https://theleanviking.wordpress.com/2014/10/07/agile-at-boeing-in-1990s-the777-program/?from=singlemessage 以及唐怡佳的硬件敏捷先驱波音777案例分析；链接： http://www.shinescrum.com/news_and_events/777
2.2 Wikispeed
图3. Scrum in Wikispeed, Source: http://wikispeed.org
提到敏捷Scrum 在制造业的应用，大家都愿意拿Wikispeed举例Wikispeed 是一个汽车制造组织，它使用面向世界开源（Open Source）的方式制造有上路许可证的节能汽车它的员工由分布在全世界20多个国家的近200个自愿者组成，用户可以在网上订购从世界不同地方生产的9个模块组件组装成定制的汽车，目前，可选汽油机或电动机为动力Wikispeed曾经运用Scrum框架在3个月内开发并制作出一辆原型车Wikispeed 的开发特点可以总结以下三点[Shantam Shukla,2013]：
- 开源设计
如我们以前熟知的Linux系统的开发，Wikispeed的团队开放资源，吸引全世界的造车爱好者参加到开放中，自愿者们大多利用业余时间参与团队并完成部分工作
- 模块化及测试驱动开发
Wikispeed团队将整个汽车分成8个模块，每个模块由来自世界各地的一个或多个团队自愿者负责开发，成员一般是该领域的技术专家或爱好者为了实现开发和组装的灵活性，为每个模块定义了通用接口，以实现即插即用的理想虽然模块化设计导致模块内的冗余，可能会导致局部成本的增加，但考虑到客户的多样性和灵活性的要求，以及Wikispeed 开发组织的特点，从系统角度考虑，这是个明智的选择
对于每个模块的开发, 团队最开始先构建了重要的测试要求例如， 一个从事底盘设计的团队可以以任何方式开发它, 直到它满足最初的测试要求
- Scrum框架组织开发
发起人Joe Justice 是软件工程师出身，用业余时间开发并制作一辆汽车对于他和他的团队来说是充满不确定性和挑战的项目由于是开源的形式，为了管理和协调来自不同地区不断壮大的志愿者团队，他和Wikispeed的其他成员使用Scrum的原则协调分布式虚拟环境中的开发
开发团队承担Sprint的任务, 并尝试在7天内实现预期结果Sprint的任务由团队中的产品负责人（Product Owner）定义，并负责定义正在开发的模块测试的要求和参数不同的Sprint可能有不同的产品负责人自愿担任，他往往是该Sprint任务领域最专业的人士
由于是自愿开源的形式，团队中没有主管, 也没有说由PO来确定团队任务的优先级
图4. Sprint in Wikispeed
source：[Shantam Shukla,2013]
3 制造业应用敏捷Scrum 进行产品开发的 一些问题
如何在机械制造行业成功地应用Scrum？，这个话题太大，涉及到的方面太多，一本书的篇幅也很难阐述清楚, 我们或许可以把问题分成两类：一方面其实是制造业的人文问题，另一方面是技术问题所谓人文问题，是制造业根深蒂固的传统理念，和许多固化的思考及行为方式所谓技术问题是指：制造行业的产品对象为物理实体，在开发过程中会遇到很多和软件业不同的问题但必须承认， 有时候很难区分是人文还是技术问题，有时候表面上看似是技术问题，其实是人文问题
在制造行业应用敏捷Scrum，首先需要深入理解企业，从产品当前的组织管理架构组织文化人员状况等多维度，考虑是否合适采用Scrum框架以及实施的节奏 不是每个组织都适合采用敏捷Scrum，也不是每个企业的Scrum都是一模一样的
3.1 应用敏捷Scrum的人文问题和思考
组织文化
Scrum的成功需要文化机制来保证试图改变一个组织的文化是愚蠢的，它总是以失败告终人的行为（文化）是制度的产物； 当制度改变时人们的行为才会随之而变 [Craig larman and Bas Vodde，2016]
而改变机制需要改变一个根本的观念：对人的观念敏捷理念是建立在如何利用人的潜力这个基础上的：如果给与机会，人类广泛具有想象力，创造力；人们会为自己所认可并承诺的目标做出努力，承担责任而传统的管理模式是基于假设：人们逃避责任，没有主见，本性懒惰麦格雷戈在他的企业的人性面中把建立在这两种假设上的管理理论和实践称为Y-X理论对人的根深蒂固观念受文化和教育的影响很难改变，直到今天，我们国内学校还在按传统的假设（X假设）培养我们的下一代可想而知，敏捷理念的实施和落地在国内将遇到多少困难 传统的对人的观念，已经渗入我们传统行业每个管理者和被管理者的骨髓在采用Scrum实践中，管理者往往有强烈的变革意识，希望推动Scrum，但他们习惯的不经意的控制行为往往阻碍Scrum的成功，个人绩效是个控制的例子
从组织管理角度，重构机制，降低管理者的控制欲，使管理者成为引导，教练型角色，给与个体贡献潜能的空间，作者认为是Scrum成功的条件敏捷Scrum 的采用提供了变革的工具，但如果没有机制作为保障，只能带来混乱 （本人也是X假设下培养出来的）想象一下，取消个人绩效取而代之的是团队的绩效，由团队自己决定收益分配，仅仅就是这一点机制的改变，在国内制造业的人文环境下就很难实现
由于有各种人文阻力要比软件业更大，Scrum的采用步骤和规模值得注意
虽然我们有波音777的大规模研发中使用敏捷理念成功的案例，但个人还是建议循序渐进地在机械制造行业采用Scrum通过小规模地采用Scrum，适应新的思维和行为规范， 最重要的是试验新的文化机制Scrum只提供了一个框架，在许多方面它没有提供明确答案，而其他没有说明的，如文化机制却决定了其实效性实施Scrum的具体建议见在章节3.2
成员状况
对比软件业，我们不能不承认，制造业研发从业人员的平均年龄都偏高，由于各种原因，对待新事物的态度偏保守在硬件及制造行业，专业化很强开发人员往往只具有某项专业技能，需要多年的工作经验成为某专业的专家，一专多能较难实现在开发中，对这样的专家依赖严重 这样的状况有时是产品本身特点造成的，有时是传统组织架构长期累积的结果
在实践Scrum前，一个重要准备是需要企业内部各个层面及个体对敏捷理念，Scrum框架以及其背后宗旨的深刻理解在此基础上才可能灵活运用敏捷Scrum以达到目的
另一方面，在组织中自上而下的推动，自下而上的实施成功率要高些，因为Scrum挑战很多传统的思想和行为，会涉及到个人或组织阶层的固有利益（非公司利益）
3.2 应用Scrum的技术问题和具体建议
讨论了应用Scrum的人文方面的问题后，下面讨论普遍存在的所谓技术问题
产品开发的复杂度
Rubin 在他的Essential Scrum 一书里把要解决的问题分成了5种，并非所有问题都适合Scrum框架Scrum 框架一般较适合于解决较复杂的不确定性强的开发，尤其是有很强的探索性开发一个以委外加工为主，设计图纸又由客户提供的公司，Scrum很难带来大的改变不少领域的工作使用Kanban 可视化管理就能收到很好的效果
产品的测试环节需要较大的资金投入，并且准备时间及制作周期长
由于产品对象是物理实体，相比软件业，制造行业产品开发有如其特殊性很多产品的样件往往需要模具，尽管可以使用 软模具，但依然成本很高漫长的制作时间往往成了项目开发周期的瓶颈除此之外，模具及样件往往由外部供应商提供，有时还需要考虑采购部门的选择定点时间样件制作是项目经理最头疼的一件事
以汽车零部件企业为例，为了小规模采用Scrum来提高企业应对市场灵活能力，推荐在企业的预研发（pre-development）环节先实践Scrum框架 一般来说， 预研发产品开发是制造企业对前沿技术或工艺做研究性或探索性的尝试，经过一系列功能等实验验证，并根据客户（也可能是公司内部客户）或市场需求制作出样品，在展览会或目标客户处展示，测试市场反应预研产品代表了公司或行业的最前沿技术水平，在得到订单后进一步开发成批量产品由于预研产品开发交付的产品是样件，涉及的外围职能团队相对较少，比较容易组织起跨职能团队，一般由设计，仿真，测试等组成即可，产品负责人（PO）可由该产品领域业务单元客户组成员担任这样的规模对企业整体组织的变更度最少，阻力也相对较小，同时提高了企业新产品的更新换代速度在Scrum实施获得成效后，扩大产品定义或产品交付的定义，组织变革的范围也随之扩大，整个企业的灵活性，创造力随之放大最终做到整个系统的敏捷：从研发到批量供货
在制造业产品开发中，利用虚拟仿真工具减少对实物测试验证的依赖是必由之路我们前面举的两个例子来说，如果波音公司没有在研发中使用 3D CAD 制图，很难尽早发现设计的一些问题并进行迭代现代的技术手段为敏捷开发提供了更多的物理可能性3D打印技术，3D扫描技术，各种仿真技术等都提供了强有力的支持（虚拟现实技术的实际运用还要等一等） 目前还存在着仿真的建模时间较长，仿真结果的可信度等问题影响开发迭代周期，但这都不是制造业拒绝Scrum的借口例如，十几年前就有国外汽车零部件企业不借助商业软件实现了3D CAD模型到多体仿真模型的自动建模，将建模时间从数周减少到数小时
产品的功能涉及很多组件，并与其它功能相互交织，功能之间的接口不易定义清楚
机械产品中每个功能都可能会影响到所有其他功能功能间耦合度高而在软件开发中，可以从几个功能和一个简单的产品开始, 然后再陆续发布新的功能和更新产品这对于机械开发是不易实现的表面上可能会给产品待办列表（Product Backlog）的拆分以及各Scrum团队的协作带来困难实际上，这是个研发思路问题，是设计理念问题 只有对某个研究对象能进行充分的解耦，我们才能说了解了这个对象 如果我们设计的产品系统难以被解耦，说明最终产品的某种健壮性（robust）会有问题这点和软件设计开发没有本质区别
解决这个问题需要工程实践，在初次采用Scrum框架时，会花费团队意想不到的的时间去定义Sprint的任务和测试方法，这很正常，因为我们现在使用不同的思路和角度去理解产品， 现在我们不再是以产品本身功能实现的角度，而是以面向客户产品价值的角度审视我们的产品
产品开发需要的外部协作较多，共享资源多，接口多
实体对象的开发需要采购，核算，样件，测试，物流，质量，生产等部门以及外部供应商们的协作各职能部门由于人员，设备的限制，资源由各开发项目共享你的项目任务是公共职能部门手里众多项目中的一个，灵活性受到限制如图5所示，是汽车零部件企业典型的组织架构
图5. 当前普遍的组织架构
其实，大型软件开发也会遇到同样的问题不同的是制造业设备资源等投资大，需要考虑共享但软件行业不少用于开发的商用软件价格也不菲共享部门的支持，外部协作不可避免如何解决是具体方法问题而非Scrum框架问题制造业完全可以借鉴软件行业的经验，做些适应性调整如果很难做到真正的跨职能团队，必须使用公共资源的时候，可以考虑软件业使用的打桩（mock-up）的方法，在迭代中尽量降低依赖度制造业也经常使用所谓的Dummy来暂时替代还没有完成的部分，以保证研发的持续，随着其他部门工作的推进，缩小被设置 Dummy的部分的规模，直到彻底取消
团队异地合作
Scrum强调团队要在同地点工作以方便随时沟通，但如今跨国合作进行产品开发很普遍，这在软件行业也非常常见，但在机械制造行业异地团队合作的难度更大实践经验告诉我们，如果一个Scrum团队有异地成员，一般Sprint的长度不易定义偏短，尽管有视频会议，联合开发平台的支持，用于沟通的时间要大幅增加有时实物异地运输时间也要考虑在内
4 总结
为了提高企业的市场竞争力，制造业的产品开发完全可以运用敏捷Scrum框架以改变由来已久的传统模式实践Scrum需要结合自身的具体情况，在深刻理解敏捷理念的基础上灵活地做探索性的调整 在实践中，最大的阻力是组织内的传统理念，从业人员的理念，而非其他技术性问题， 至上而下的推动是必要的作者认为，组织的机制是决定敏捷Scrum成败的关键作者提倡首先在产品先期研发项目上实践敏捷Scrum，然后逐步推广到整个产品开发由于制造业开发的对象是实体，生产最终产品的代价高，因此更需要在资金大投入前利用Scrum框架下的迭代增量的方法充分验证产品的市场价值，加大虚拟，快速成型等手段在研发阶段的应用力度在虚拟仿真和快速成型技术日益成熟的今天，机械产品开发和软件开发的差别越来越小
参考文献
1. 熊光楞主编. 并行工程的理论与实践. 2012. 清华大学出版社
2. Shantam Shukla, Wikispeed. 2013.Indian Institute of Management, Ahmedabad, India, prepared this case study as part of his doctoral dissertation. (shantams@iimahd.ernet.in)
3. Craig Larman and Bas Vodde. 2016. Large-Scale Scrum: More with LeSS
大规模Scrum 大规模敏捷组织的设计. 肖冰 译.2018.
4. Kenneth S. Rubin. 2012. Essential Scrum -A practical guide to the most popular agile process. Addison-Wesley.
文章审核：Jim Wang王军
版权所有，反对抄袭，欢迎转发
点击链接阅读：
敏捷Scrum理念的背后写给机械制造行业同仁（上篇）
作者 : Sven Fang 房世庆
Scrum硬件及制造业专家
德国杜伊斯堡艾森大学机电工程专业博士
如同IT行业，制造业也面临着越来越严峻的挑战，市场要求企业能够做到更快的产品更新，更低的成本和更高的质量在IT行业日益得到推广的敏捷Scrum框架给制造业的产品开发带来许多启发不少企业已经开始尝试改变传统的瀑布式产品开发模式，应用敏捷Scrum 框架以快速适应市场变化，控制风险和提高客户满意度本文在考虑国内制造业特点和目前状况基础上，就如何应用Scrum框架和理念表达作者的一点拙见这里假设读者已经拥有敏捷理念和Scrum框架的基本知识
1 制造业产品开发的运作方式
图1 普遍采用的产品开发项目流程
这里所说的制造业是广义的制造业，区别于软件业，以物理对象为产品，如机械，仪器，仪表，工具，汽车业，家电等等在软件业，习惯把所有非程序类产品称作硬件为避免和PCB板之类的硬件电子产品混淆，我们这里没有用硬件一词
制造业悠久的发展历史，积淀了百年的经验，很多约定俗成的理念和方法源远流长
现代产品开发的运作方式受泰勒（Frederick Taylor）和法约尔（Henri Fayol）的思想的影响，采用瀑布(或称 串行)式的方式，高度重视计划分工职权和控制其实产品开发的理念及流程和变革前的软件行业没有本质区别 以汽车零部件行业为例，产品开发是一个计划性过程控制，一般产品开发都以项目形式管理，项目经理对项目的成本进度以及交付负责在产品开发前，客户和企业就产品需求以合同的形式固定下来，从明确的需求开始，制定开发计划，分工开发组件，集成后测试，冻结设计，模具释放，工艺方案设计及实施，样件，最后批量生产（如图1所示）对于产品换代缓慢，大规模生产的时代，这是最合适的方式
今天的世界已经不是昨天的世界了，为追求更高利润，单纯地扩大规模以降低成本已经不够，市场竞争压力越来越向产品开发部门转移传统的基于计划的开发理念和运行方式对于那些必须开发复杂产品（复杂产品未必结构复杂）以提高市场溢价权的企业来说，很可能导致企业的衰退面对更多不确定性的当下世界，大家都意识到下列问题必须解决：
- 局部优化是不够的，必须以系统思维开发产品
- 仅有销售部门面向客户是不够的，必须面向客户开发产品
- 再完善的开发计划都赶不上变化，必须拥抱变化
- 再专业的项目经理都是不够的，必须要团队协作
- 等等
敏捷理念下的Scrum框架，采用跨职能团队迭代增量持续可交付产品等方法为我们提供了这种变革的一种可能
2 敏捷Scrum在制造业的实践
这里要提到的是，其实机械制造行业很早就接触并应用了敏捷理念作者认为，大家熟悉的精益生产理念其实就是敏捷理念的源头，甚至敏捷理念下Scrum的构思也起源于制造业 [Kenneth S. Rubin, 2012 ]从精益生产理念扩展而来的产品生命周期管理（PLM）并行工程(Concurrent Engineering) 已经被一些企业自觉或不自觉地运用到产品开发中[熊光楞主编，2011]所谓并行工程旨在整个开发工作都着眼于整个过程和产品目标，避免传统的串行开发模式带来的弊端，其中不少地方如跨职能团队，产品导向都能看到和敏捷Scrum类似的宗旨和方法
敏捷理念下的Scrum框架简单，有其独到性，这也是为什么在软件界得到迅速的认可和普及尽管传统制造行业的产品开发和软件行业有所不同，但Scrum在软件行业应用的成功使得硬件及制造业的管理者们开始尝试在本行业的应用 走在前面的是那些包含嵌入式软件的供应商以及一些仪器设备供应商们 然后慢慢延伸到纯机械制造行业正如Rubin提到的：虽然 Scrum 最常用于开发软件产品, 但 Scrum 的核心价值和原则可以而且正在被用于开发不同类型的产品或组织不同类型的工作流程例如, 我曾与成功使用 Scrum 的组织合作, 以组织和管理与硬件开发营销计划和销售计划相关的工作[Kneneth S. Rubin, 2012 ]
这里我们列举两个业界的例子，可以说是基于敏捷Scrum框架进行的产品开发
2.1 波音777 的研发
波音公司从1990年概念设计开始到1995年5月在联合航空投入商业运营，在6年里成功完成了一个50亿美金的新产品波音777开发项目，参与员工达1万多人项目负责人 Alan Mulally 创新地运用的一起工作模式其实体现了敏捷理念
Mulally组织起了约250个多功能团队DBT（DesignBuild Team），每个DBT团队负责一个功能模块每个DBT都由综合多样的人员组成，可以完成从概念到制造和维护团队中有设计，制造，模具人员，财务，材料，维护，分包合同代表，客户代表所有DBT每周进度例会保证团队之间的沟通协调，为进一步做到透明开放的沟通，他将波音777的所有10000个员工每个季度都汇集到西雅图，开为期两天的all-team meeting！这样的会议在30个月里开 了9次（见图2）匪夷所思！
图2. 波音777 及西雅图大会
Source: https://theleanviking.wordpress.com/
对于那些小的日常的变化，DBT多功能团队会来处理新涌现的信息，并在制造和设计工程师之间形成快速的反馈循环需求变更以往需要消耗几周，但是在DBT团队一天就可以搞定了当你可以快速合作，应对变化就会变得更容易
777是几乎完全使用三维CAD软件代替二维图纸设计的第一架飞机在建造第一个原型之前，3D CAD模型就可以组合在一起进行实时验证这就加快了反馈闭环的形成，增量的质量也有一定的提升，从而能够更早更好地得到反馈
波音通过许多举措让客户参与到开发中来，并强调和客户的合作高于一切由于客户的参与，客户快速反馈，团队可以及时响应变化而非无条件遵循计划在这里Scrum框架的跨职能团队迭代增量等均有体现
较详细资料请参见Agile at Boeing in 1990s the 777 Program
链接：
https://theleanviking.wordpress.com/2014/10/07/agile-at-boeing-in-1990s-the777-program/?from=singlemessage 以及唐怡佳的硬件敏捷先驱波音777案例分析；链接： http://www.shinescrum.com/news_and_events/777
2.2 Wikispeed
图3. Scrum in Wikispeed, Source: http://wikispeed.org
提到敏捷Scrum 在制造业的应用，大家都愿意拿Wikispeed举例Wikispeed 是一个汽车制造组织，它使用面向世界开源（Open Source）的方式制造有上路许可证的节能汽车它的员工由分布在全世界20多个国家的近200个自愿者组成，用户可以在网上订购从世界不同地方生产的9个模块组件组装成定制的汽车，目前，可选汽油机或电动机为动力Wikispeed曾经运用Scrum框架在3个月内开发并制作出一辆原型车Wikispeed 的开发特点可以总结以下三点[Shantam Shukla,2013]：
- 开源设计
如我们以前熟知的Linux系统的开发，Wikispeed的团队开放资源，吸引全世界的造车爱好者参加到开放中，自愿者们大多利用业余时间参与团队并完成部分工作
- 模块化及测试驱动开发
Wikispeed团队将整个汽车分成8个模块，每个模块由来自世界各地的一个或多个团队自愿者负责开发，成员一般是该领域的技术专家或爱好者为了实现开发和组装的灵活性，为每个模块定义了通用接口，以实现即插即用的理想虽然模块化设计导致模块内的冗余，可能会导致局部成本的增加，但考虑到客户的多样性和灵活性的要求，以及Wikispeed 开发组织的特点，从系统角度考虑，这是个明智的选择
对于每个模块的开发, 团队最开始先构建了重要的测试要求例如， 一个从事底盘设计的团队可以以任何方式开发它, 直到它满足最初的测试要求
- Scrum框架组织开发
发起人Joe Justice 是软件工程师出身，用业余时间开发并制作一辆汽车对于他和他的团队来说是充满不确定性和挑战的项目由于是开源的形式，为了管理和协调来自不同地区不断壮大的志愿者团队，他和Wikispeed的其他成员使用Scrum的原则协调分布式虚拟环境中的开发
开发团队承担Sprint的任务, 并尝试在7天内实现预期结果Sprint的任务由团队中的产品负责人（Product Owner）定义，并负责定义正在开发的模块测试的要求和参数不同的Sprint可能有不同的产品负责人自愿担任，他往往是该Sprint任务领域最专业的人士
由于是自愿开源的形式，团队中没有主管, 也没有说由PO来确定团队任务的优先级
图4. Sprint in Wikispeed
source：[Shantam Shukla,2013]
3 制造业应用敏捷Scrum 进行产品开发的 一些问题
如何在机械制造行业成功地应用Scrum？，这个话题太大，涉及到的方面太多，一本书的篇幅也很难阐述清楚, 我们或许可以把问题分成两类：一方面其实是制造业的人文问题，另一方面是技术问题所谓人文问题，是制造业根深蒂固的传统理念，和许多固化的思考及行为方式所谓技术问题是指：制造行业的产品对象为物理实体，在开发过程中会遇到很多和软件业不同的问题但必须承认， 有时候很难区分是人文还是技术问题，有时候表面上看似是技术问题，其实是人文问题
在制造行业应用敏捷Scrum，首先需要深入理解企业，从产品当前的组织管理架构组织文化人员状况等多维度，考虑是否合适采用Scrum框架以及实施的节奏 不是每个组织都适合采用敏捷Scrum，也不是每个企业的Scrum都是一模一样的
3.1 应用敏捷Scrum的人文问题和思考
组织文化
Scrum的成功需要文化机制来保证试图改变一个组织的文化是愚蠢的，它总是以失败告终人的行为（文化）是制度的产物； 当制度改变时人们的行为才会随之而变 [Craig larman and Bas Vodde，2016]
而改变机制需要改变一个根本的观念：对人的观念敏捷理念是建立在如何利用人的潜力这个基础上的：如果给与机会，人类广泛具有想象力，创造力；人们会为自己所认可并承诺的目标做出努力，承担责任而传统的管理模式是基于假设：人们逃避责任，没有主见，本性懒惰麦格雷戈在他的企业的人性面中把建立在这两种假设上的管理理论和实践称为Y-X理论对人的根深蒂固观念受文化和教育的影响很难改变，直到今天，我们国内学校还在按传统的假设（X假设）培养我们的下一代可想而知，敏捷理念的实施和落地在国内将遇到多少困难 传统的对人的观念，已经渗入我们传统行业每个管理者和被管理者的骨髓在采用Scrum实践中，管理者往往有强烈的变革意识，希望推动Scrum，但他们习惯的不经意的控制行为往往阻碍Scrum的成功，个人绩效是个控制的例子
从组织管理角度，重构机制，降低管理者的控制欲，使管理者成为引导，教练型角色，给与个体贡献潜能的空间，作者认为是Scrum成功的条件敏捷Scrum 的采用提供了变革的工具，但如果没有机制作为保障，只能带来混乱 （本人也是X假设下培养出来的）想象一下，取消个人绩效取而代之的是团队的绩效，由团队自己决定收益分配，仅仅就是这一点机制的改变，在国内制造业的人文环境下就很难实现
由于有各种人文阻力要比软件业更大，Scrum的采用步骤和规模值得注意
虽然我们有波音777的大规模研发中使用敏捷理念成功的案例，但个人还是建议循序渐进地在机械制造行业采用Scrum通过小规模地采用Scrum，适应新的思维和行为规范， 最重要的是试验新的文化机制Scrum只提供了一个框架，在许多方面它没有提供明确答案，而其他没有说明的，如文化机制却决定了其实效性实施Scrum的具体建议见在章节3.2
成员状况
对比软件业，我们不能不承认，制造业研发从业人员的平均年龄都偏高，由于各种原因，对待新事物的态度偏保守在硬件及制造行业，专业化很强开发人员往往只具有某项专业技能，需要多年的工作经验成为某专业的专家，一专多能较难实现在开发中，对这样的专家依赖严重 这样的状况有时是产品本身特点造成的，有时是传统组织架构长期累积的结果
在实践Scrum前，一个重要准备是需要企业内部各个层面及个体对敏捷理念，Scrum框架以及其背后宗旨的深刻理解在此基础上才可能灵活运用敏捷Scrum以达到目的
另一方面，在组织中自上而下的推动，自下而上的实施成功率要高些，因为Scrum挑战很多传统的思想和行为，会涉及到个人或组织阶层的固有利益（非公司利益）
3.2 应用Scrum的技术问题和具体建议
讨论了应用Scrum的人文方面的问题后，下面讨论普遍存在的所谓技术问题
产品开发的复杂度
Rubin 在他的Essential Scrum 一书里把要解决的问题分成了5种，并非所有问题都适合Scrum框架Scrum 框架一般较适合于解决较复杂的不确定性强的开发，尤其是有很强的探索性开发一个以委外加工为主，设计图纸又由客户提供的公司，Scrum很难带来大的改变不少领域的工作使用Kanban 可视化管理就能收到很好的效果
产品的测试环节需要较大的资金投入，并且准备时间及制作周期长
由于产品对象是物理实体，相比软件业，制造行业产品开发有如其特殊性很多产品的样件往往需要模具，尽管可以使用 软模具，但依然成本很高漫长的制作时间往往成了项目开发周期的瓶颈除此之外，模具及样件往往由外部供应商提供，有时还需要考虑采购部门的选择定点时间样件制作是项目经理最头疼的一件事
以汽车零部件企业为例，为了小规模采用Scrum来提高企业应对市场灵活能力，推荐在企业的预研发（pre-development）环节先实践Scrum框架 一般来说， 预研发产品开发是制造企业对前沿技术或工艺做研究性或探索性的尝试，经过一系列功能等实验验证，并根据客户（也可能是公司内部客户）或市场需求制作出样品，在展览会或目标客户处展示，测试市场反应预研产品代表了公司或行业的最前沿技术水平，在得到订单后进一步开发成批量产品由于预研产品开发交付的产品是样件，涉及的外围职能团队相对较少，比较容易组织起跨职能团队，一般由设计，仿真，测试等组成即可，产品负责人（PO）可由该产品领域业务单元客户组成员担任这样的规模对企业整体组织的变更度最少，阻力也相对较小，同时提高了企业新产品的更新换代速度在Scrum实施获得成效后，扩大产品定义或产品交付的定义，组织变革的范围也随之扩大，整个企业的灵活性，创造力随之放大最终做到整个系统的敏捷：从研发到批量供货
在制造业产品开发中，利用虚拟仿真工具减少对实物测试验证的依赖是必由之路我们前面举的两个例子来说，如果波音公司没有在研发中使用 3D CAD 制图，很难尽早发现设计的一些问题并进行迭代现代的技术手段为敏捷开发提供了更多的物理可能性3D打印技术，3D扫描技术，各种仿真技术等都提供了强有力的支持（虚拟现实技术的实际运用还要等一等） 目前还存在着仿真的建模时间较长，仿真结果的可信度等问题影响开发迭代周期，但这都不是制造业拒绝Scrum的借口例如，十几年前就有国外汽车零部件企业不借助商业软件实现了3D CAD模型到多体仿真模型的自动建模，将建模时间从数周减少到数小时
产品的功能涉及很多组件，并与其它功能相互交织，功能之间的接口不易定义清楚
机械产品中每个功能都可能会影响到所有其他功能功能间耦合度高而在软件开发中，可以从几个功能和一个简单的产品开始, 然后再陆续发布新的功能和更新产品这对于机械开发是不易实现的表面上可能会给产品待办列表（Product Backlog）的拆分以及各Scrum团队的协作带来困难实际上，这是个研发思路问题，是设计理念问题 只有对某个研究对象能进行充分的解耦，我们才能说了解了这个对象 如果我们设计的产品系统难以被解耦，说明最终产品的某种健壮性（robust）会有问题这点和软件设计开发没有本质区别
解决这个问题需要工程实践，在初次采用Scrum框架时，会花费团队意想不到的的时间去定义Sprint的任务和测试方法，这很正常，因为我们现在使用不同的思路和角度去理解产品， 现在我们不再是以产品本身功能实现的角度，而是以面向客户产品价值的角度审视我们的产品
产品开发需要的外部协作较多，共享资源多，接口多
实体对象的开发需要采购，核算，样件，测试，物流，质量，生产等部门以及外部供应商们的协作各职能部门由于人员，设备的限制，资源由各开发项目共享你的项目任务是公共职能部门手里众多项目中的一个，灵活性受到限制如图5所示，是汽车零部件企业典型的组织架构
图5. 当前普遍的组织架构
其实，大型软件开发也会遇到同样的问题不同的是制造业设备资源等投资大，需要考虑共享但软件行业不少用于开发的商用软件价格也不菲共享部门的支持，外部协作不可避免如何解决是具体方法问题而非Scrum框架问题制造业完全可以借鉴软件行业的经验，做些适应性调整如果很难做到真正的跨职能团队，必须使用公共资源的时候，可以考虑软件业使用的打桩（mock-up）的方法，在迭代中尽量降低依赖度制造业也经常使用所谓的Dummy来暂时替代还没有完成的部分，以保证研发的持续，随着其他部门工作的推进，缩小被设置 Dummy的部分的规模，直到彻底取消
团队异地合作
Scrum强调团队要在同地点工作以方便随时沟通，但如今跨国合作进行产品开发很普遍，这在软件行业也非常常见，但在机械制造行业异地团队合作的难度更大实践经验告诉我们，如果一个Scrum团队有异地成员，一般Sprint的长度不易定义偏短，尽管有视频会议，联合开发平台的支持，用于沟通的时间要大幅增加有时实物异地运输时间也要考虑在内
4 总结
为了提高企业的市场竞争力，制造业的产品开发完全可以运用敏捷Scrum框架以改变由来已久的传统模式实践Scrum需要结合自身的具体情况，在深刻理解敏捷理念的基础上灵活地做探索性的调整 在实践中，最大的阻力是组织内的传统理念，从业人员的理念，而非其他技术性问题， 至上而下的推动是必要的作者认为，组织的机制是决定敏捷Scrum成败的关键作者提倡首先在产品先期研发项目上实践敏捷Scrum，然后逐步推广到整个产品开发由于制造业开发的对象是实体，生产最终产品的代价高，因此更需要在资金大投入前利用Scrum框架下的迭代增量的方法充分验证产品的市场价值，加大虚拟，快速成型等手段在研发阶段的应用力度在虚拟仿真和快速成型技术日益成熟的今天，机械产品开发和软件开发的差别越来越小
参考文献
1. 熊光楞主编. 并行工程的理论与实践. 2012. 清华大学出版社
2. Shantam Shukla, Wikispeed. 2013.Indian Institute of Management, Ahmedabad, India, prepared this case study as part of his doctoral dissertation. (shantams@iimahd.ernet.in)
3. Craig Larman and Bas Vodde. 2016. Large-Scale Scrum: More with LeSS
大规模Scrum 大规模敏捷组织的设计. 肖冰 译.2018.
4. Kenneth S. Rubin. 2012. Essential Scrum -A practical guide to the most popular agile process. Addison-Wesley.
文章审核：Jim Wang王军
版权所有，反对抄袭，欢迎转发