本文关键点

敏捷可以成功地应用于集成了软硬件的产品开发中。
使整个过程敏捷化的真正挑战，是在迭代过程中构建硬件组件的能力，今天已经有了许多的技术和方法论，使它在许多情况下都可能做到了。
必须让开发过程灵活，可以将敏捷与瀑布和敏捷元素整合在一起使用。
产品负责人和scrum管理员一定要理解，敏捷必须适应工业环境(工业敏捷性)。
工业开发团队技能的异质性比软件的要大得多，并且复杂性也要更高。
我们想给大家讲一个我们在意大利公司的经历，这家公司位于威尼斯以西约60公里。

我们生产工业机械，需要更新许多产品，但使用的时间要比过去短得多。

我们将试着解释为什么在开发新产品时，选择了一种灵活的以敏捷为主的方法，而不是其他更传统的方法。

我们将告诉您我们已经从一个经典的按职能划分的组织转变为一个具有跨职能团队的组织。

在所有这一切中，人仍然是最重要的元素，包括产品负责人和scrum 管理者这些新角色，他们通过调整适应了工业环境，还有学着自组织的开发团队，以及支持团队中相关的人。

之前我们从未尝试过回顾会，它的引入也带来了很强的推动力，这些改进给我们带来了令人非常惊讶的结果，我们正继续将敏捷方法推广到整个开发过程。

这种典型制造业的企业文化，仍然在接受着不断的精益和敏捷转变的冲击，因为这些新的范式还没有被完全吸收。

为什么我们决定应用敏捷方法开发工业机械

布雷顿开发的工业机械是机械、电子、软件和工业处理的集合体，因此它呈现出的复杂性已经超出了大家的想象。

布雷顿拥有三条业务线：天然石材加工机械、块状石板生产工业厂房、金属及碳纤维树脂加工五轴数控机床。

我们分析了此类复杂产品开发管理的最有效方法。

为了减少开发新硬件产品所需的时间，即使使用的仍然是经典的准生产、层层把关和瀑布的方法，但经过多年来的实践也已经把开发的不同阶段做了重叠。

换句话说，在整个设计阶段完成之前，施工时间和供货时间最长的部件(交付周期)就已经投入生产，在所有部件完成之前就已经开始组装。

这种方法称为并行工程。

然而，这种方法带来的好处是有限的，因为瀑布的逻辑思想仍然停留在大多数人的脑子里。

我使用这种方法有很长一段时间了，一直都很清楚它在某些情况下的弊端，所以15年前我能够体会到精益产品开发的逻辑思想。

即使使用精益方法，也不是尽善尽美的，因为它们适用于简单或可预测的项目，但是用于复杂的项目，结果就差强人意了。

在那些年(2006年)，我参与了一个用于文档管理的web软件的开发，核心开发人员向我介绍了敏捷方法论。

我很热衷于方法论，也意识到了新产品开发过程的复杂性。

我很自然就想到，即使是硬件产品，也可以用敏捷的方式开发呀。

这样，阶段的重叠机制会更加完整，因为它们被分解成了更小的阶段。

2008年，我开始在硬件产品开发中尝试敏捷方法。

现在，我不知道还有什么方法能够实现阶段的可持续重叠，就像敏捷方法那样。

2012年，为了应对压缩开发时间的挑战，我们在布雷顿开始了第一个将敏捷方法应用于复杂产品开发的实验。

我们是如何将敏捷、精益和传统方法结合起来的

我们采用了灵活的开发过程，把适用于不同开发阶段的最佳方法进行了整合。

我们发现，愿景、精益和产品画布以及随后使用用户故事映射的待办事项列表分解是非常有效的做法。

如今3D CAD设计和数字孪生使有效的虚拟化成为可能，使硬件产品的早期开发阶段非常类似于软件产品。

一旦完成了包括成本分析在内的产品概念阶段，构建或购买物理组件的阶段就开始使用传统方法了，如现代ERP系统的材料资源规划(MRP)，这实际上是一种瀑布式方法。

这把物理构建变成了异步的，而不是像15天一个sprint那样，以迭代和增量的方式持续开发。

以迭代和增量的方式完成组装，并针对“组装”及其“看板组装板”修改了用户故事映射。

以敏捷的方式进行测试和验证，就像在组装期间一样。

如果有条件的话，我们还使用精益方法对材料和装配区域进行可视化管理。

这个过程是个混合体，因为它以协作的方式集成了敏捷、瀑布式和精益。

所幸有一个集成了瀑布式、精益和敏捷的定制化web版计划软件，我们可以让8个产品开发团队(大约100人)自组织、管理待办事项，同时为管理层提供里程碑计划。

产品负责人和scrum管理员的角色

设计部门以前由几个“组件团队”组成，按照能力或他们所管理的机器类型进行划分。团队由一位团队经理领导，他还负责协调新产品的开发阶段，这些产品对他有直接的影响。生产和采购是分离的、独立的。

组件团队一刻不停地工作着，在订单开发和新产品开发之间频频切换任务。

由于产品开发延迟成本巨大，所以开始招聘新的开发人员，以便即不影响订单，也不影响新产品开发。

针对客户要求的标准和定制版机器的开发，我们继续保持了组件团队，同时我们也创建了多个“跨职能团队”，里面包括有机械人员、电气人员和软件设计人员、估算人员、采购人员、生产和装配人员(我们的职能团队)。

在开发结束时，由PO和SM协调的“职能团队”解散，其成员返回组件团队。

每个团队都是针对每个新项目选择最合适的人员创建的。产品负责人是从销售工程师中挑选出来的，他们为销售人员提供支持，由销售人员向客户提出我们的解决方案。

他们对市场有深刻的认识，他们能够描绘出客户和股东的利益，同时他们对产品也有深入的认识，从而能够指导产品的开发。

“组件团队”的团队领导已经成了干系人，如产品开发总监、总裁、总经理等，这个角色可以创造很多帮助开发团队的机会，而不是简单地讨论技术解决方案的产品负责人。法比亚诺·加佐拉(ABD2018的联合主办人)是布雷顿的一个业务部门的负责人。

最难引入组织的角色是scrum 管理者，因为在公司里从来就没有过教练的角色。

我们于2015年在丹妮拉·里纳尔迪的支持下开始了我们的项目，她也是2018年ABD2018大会的联合主办者。作为一名外部顾问，她帮助我们弄清楚了scrum管理者的角色，以及从公司外部聘请现有scrum管理者的所有优点和缺点，并作为一名女性支持着几乎完全由男性组成的开发团队。

她帮助团队进行项目的分解，以及以迭代和增量的方式开发产品，这真是一场真正的革命。

一年之后，浮现出几个需要内部scrum管理者的需求，所以我们招募了一些年轻的工程师，他们都有项目管理的学术背景，性格比较适合担任这个角色。事实证明，这个决定是正确的，因为它使我们的敏捷开发具有了可持续性。

一开始，scrum 管理员在有时间限制的会议中扮演了重要的推动者和组织者的角色。在观看团队工作时，发现了一些意外收获。有些人在敞开心扉帮助别人，可一开始他们看起来那么不情愿这么做。在日常站立会中，看到产品人员在为团队提供服务，在推进会议，这真是一个巨大的惊喜。

借鉴回顾会

我们地区的典型制造业公司都是由强壮的男性组成的，对于这样一家制造业公司来说，回顾会可算是个最大的新元素了。

跨职能团队中包括有年龄差异非常大的人，可能比父子之间的年龄差异还要大，对他们来说，把遇到的困难提出来可不是件容易的事。

并不是每个人都有勇气在开会的时候敞开心扉，于是，丹妮拉开发了一种面对面的事后回顾会，通过它与最难相处的人交流。

换句话说，她以一种非常慈祥的方式，让一些人有机会私下里表达他们的困难。

团队很多，但是scrum管理员仍然太少，所以我们的回顾会仍然开得很少。

最近新引入的年轻scrum管理者是sprint会议仪式的主持人，但还没有足够的经验来主持回顾会。

通常，我们不会回顾每个sprint，即使这一直都是我们的目标，但是在项目的重要时刻我们会特别关注，也是就项目结束的时候。

回顾会主要反馈回来的意见如下。

一名产品负责人同时忙于多个开发项目，结果没有为团队提供足够的支持。感谢这条反馈意见，我们现在正在努力，争取为每个项目单独配一个产品负责人。

开发团队需要一个项目室，或者在整个开发期间至少有一个他们可以使用的角落。当产品开始进入实物阶段，团队要求得有个专用的安装区域，就像项目室这样的角落。

在整个项目期间，并不是一直都需要所有的技能。因此，开发团队部分由始终在场的人员(核心团队)和部分临时人员组成，临时人员仅在开发到了某些细节或特殊需要时才到场（攻坚团队）。这样大家开会就不会那么拥挤了，因为团队成员一般不会超过10人。

有的人以前喜欢一心多用，现在也明白了只专注于项目的必要性；当这不可能的时候，他们也不想一天处理多个任务，而宁可把一个任务分配到很多天。

通过回顾会，我们还从组件团队的领导那里收集了一些反馈，他们很难从以前开发人员、部分项目经理和订单经理这样的多重角色转变为一个干系人，仅仅去支持开发团队。

一些组件团队领导已经体验过产品负责人的角色。但很快就意识到，他作为干系人和团队本身的外部支持，对团队更有帮助，而不是还没有做好充分准备就关注于为客户提供价值。

敏捷和精益为布雷顿带来的好处

我们相信，与使用所有传统开发方法论的竞争对手相比，现在布雷顿的竞争优势是新智能产品的灵活敏捷开发。

由于这种灵活、敏捷的开发，使我们在某些情况下已经将开发时间减少了25%。

公司第一次出现这样的情况：在某些情况下产品成本目标更好了，也就是目标成本更低了；在许多情况下，已经完全实现了成本目标；只有在某些情况下，仅实现了部分成本目标。

我们在智能机器上做第一个实验时，设立了两个产品负责人，分别负责机器软件部分的开发和硬件部分的开发。不出所料，两个小组之间出现了协调和知识传递的问题。因此，我们决定在之后项目中只设立一个产品负责人，我们将与开发团队一起支持这些项目，编写软件和流程故事。
我们大家都清楚，开发过程中的瓶颈是由于使用了标准的施工过程和经典的材料管理(MRP)方法。

于是，我们启动了一个“工厂内工厂”的内部项目，将开发时间减半，这得益于专用的空间、永久性的跨职能团队、新的渠道和新的施工方法。

因为现在有了增材制造等新方法，或者专门的机器和部门，在某些情况下我们能够在一个sprint中就构建出相对简单的组件，而“工厂内部工厂”项目的其中一个目标就是尽可能在一个迭代中构建出硬件组件。

这只适用于最初的原型，因为对于系列产品来说，通常这些新方法比传统方法要更加昂贵。

“工厂内的工厂”项目是在敏捷模式下管理的，它的另一个目标是改进目前已经在做敏捷开发的产品的所有阶段。
这个工厂的主要目标是尽快发布新的经过验证的产品，为系列产品做好准备。

我们的文化是如何改变的

我们的文化仍处于变革中，因为我们是从2014-2015年才开始全面改革的。

敏捷见到了成效，因为它让大家学到了知识，提高了创造力和生产力，这证明创建跨职能团队是明智的选择。

产品和设计师之间的关系好多了，因为他们都开始清楚和理解了对方的工作。

有的时候，组装阶段需要创建一个新的组件，团队在下午进行了构思和设计，晚上开始做，第二天早上就完成了，然后在中午就安装到了机器上。

管理层并未从中干预施加压力，而是团队自主自发的，作为经理，我们的支持方式只是让大家能够使用其他制造资源。

以前按作息规定下午5点30分就收工回家的人，如果有需要，会一直自发地工作到晚上8点。

在某些情况下，团队成员之间的互帮互助使得scrum管理员这个角色变得似乎有些可有可无了。

从传统的任务管理转变为借助用户故事的可交付管理极大地激励着团队成员。

Sprint评审看起来越来越像“有时间限制的设计评审”。

高层管理人员总是希望参与画布板的编写，并很有兴趣接受邀请参与到sprint评审中。

销售相关干系人与开发团队之间的合作得到了极大的改善。

在开发新产品的过程中，从头到尾所涉及的每个人都取得了显著的成长，个人方面、专业方面，不一而足。

最后的想法

出于推迟向市场推出新产品的成本考虑，促使我们考虑比传统方法更快的开发方法，即使第一个原型产品可能要付出更高的成本。

在开发新产品时，敏捷转换最重要的方面还是人。

由于更积极主动的人的参与，实现了更好的结果和更好的产品。

敏捷是一种有效的方法，它可以促进社交学习，大家一起共享知识，因为在一起工作的是拥有各种技能的人。“个体和交互高于过程和工具”是敏捷宣言中的原则之一，只有培养创造力和生产力，它才能真正行得通。

团队气氛有了显著改善。所有的开发团队都非常喜欢在一起工作，而不必与其他项目一起同时处理多个任务。

再加上从回顾会上获得的意见，我们可以启动组织项目“工厂中的工厂”，在条件成熟的时候，将敏捷模式推广到所有产品阶段。

最重要的挑战之一将是，把敏捷性推广到机器组件的构建(目前是使用经典方法构建的)，以及将敏捷思想推广到产品开发之外的其他业务流程。

非常重要的一点是，所有的管理人员共同分享敏捷方法论。

今天，高层要求以敏捷模式开发越来越多的产品，这是一个强大的动力，但是在我们把这些新方法固化下来之前，还需要再谨慎些。

尽管如此，我们要想把整个产品开发过程敏捷化，还有很长的路要走，现在我们是把敏捷、精益和瀑布方法与数字技术的结合在一起使用的。

关于作者

克劳迪奥·绍林热衷于组织性的创新。他是布雷顿s.p.a.的产品开发总监。这家公司有大约900名员工，在特雷维索附近生产工业机械。他以一种更加灵活的方式实现新产品开发，将敏捷、精益和瀑布式方法结合在一起使用，并对开发过程进行了大量的数字化。克劳迪奥协调过一个公司项目，是由MISE(意大利经济发展部)出资的一个关于数字转型的项目，该项目涉及到集成18个IT平台，数字化办公室和工厂的工作。他还协调过另一个同样由MISE出资的公司项目，开发支持工业4.0的“智能机床”。
查看英文原文：Applying Agile for Developing Industrial Machinery

创作场景

将敏捷应用于工业机械开发