转载

Ivar Jacobson：工业互联网需要更多的软件方法

什么是工业互联网？

软件的世界在持续地革新中，将会在很多领域带来新的机会和挑战。十年前，我们热衷于SOA和产品线工程（现在还非常流行），但是现在一些系统体系已经商品化了，并且扩展到了大数据的云计算和移动应用。现在软件开发方法也随着这种趋势发展，大部分是敏捷——其中Scrum和SAFe是中间的佼佼者。

这种趋势在很多方面影响着我们——例如开发出更加有影响力且更强大的技术化产品。但是，这其中的任何一个产品, 都没有产生真正变革和颠覆性的影响。19世纪的工业革命本质上就是将人类从一个手工作坊带到了制造业。20 世纪的互联网革命是另外一个类似的转换。现在物联网被称作是将会给世界带来第三次转变的技术【请参考文章Evans and Marco Annunziata, “General Electric: Industrial Internet, Pushing the Boundaries of Minds and Machines,” November 2012】。

物联网将会对所有的商业模型带来什么样的改变？现在已经展示了无数的例子和想法【请参考文章 Dirk Slama, Frank Puhlmann, Jim Morrish, Rishi Bhatnagar: Enterprise Internet of Things】。

在这里我们将给出一个具体的例子来说明。

在之前的传统行业，一个企业卖出一个产品，一旦产品离开工厂的大门，企业就不知道产品发生了什么事。通过产品上的传感器连接到物联网，企业完全可以改变整个价值流。企业可以从提供一个产品转变成为提供一种服务加上产品，并且可以和客户之间建立一种长期的关系。例如，飞机引擎的供应商可以将他们的产品作为服务来提供（费用根据飞行的时间长短）。效果就是供应商现在会积极想办法让引擎工作的时间尽可能长，否则他们就是损失收入。航空公司可以通过减少飞机的宕机时间提高收入。

工业互联网和物联网基本上是同一个理念，但是工业互联网是被一个集团领导的，致力于移除工业互联网的路障，推动工业互联网广泛使用。工业互联网的目标市场包括政府、工业、研究和学术界。工业互联网的技术范围包括互联，技术，标准，大数据，安全和系统集成。

工业互联网的集团成立于2014 年，一开始有五个成员，包括：ATT、Cisco、GE、IBM和Intel。愿景是：建立生态系统，使用共同的架构，提供互操作性和开放标准，将人、流程和数据连接起来，加速工业互联网的成长，最终引导商业转型。这个集团逐步成长，已经有了数百家大大小小的公司。

工业互联网就是一切

工业互联网将会触及到所有的领域，只要人们提供产品或者服务，不管是在今天还是未来。

而且，工业互联网还需要我们今天拥有的所有的系统：通信、移动设备、分布式、大数据、云计算等等。还会发展出我们今天难以想象的一些技术。

这不仅对企业和开发团队来说是一个挑战，需要开发出能使这一切变成现实的软件，也对他们使用的开发方法是个巨大挑战。

大量不同类型的应用，这些应用之间要求的高度互联互通，以及开发团队之间密切协作，对企业来说是一个巨大的压力。这些压力和挑战将要求他们打破以前的开发方法。想要取得成功，企业需要快速响应需求，并且保持一定水平的工程规范——尤其是在基于分布式的云服务。

这中间包括了很多的复杂度：从一个简单装置上传感器运行的简单软件到高性能、高度可靠的、高度自治的、安全的、有弹性的、有扩展性的系统，这个系统需要处理、分析并且响应大量的数据，其中一些是自己产生的数据还有一些是互联互通的数据。不仅是这样，变革的速度和创新的需求也是以前从未所见的高度。

如果我们考虑像图1所示的一个简单开发方法的前景，仅考虑两个维度：复杂度和变化率先，忽略掉其他的维度，如技术、错误的严重程度、团队的分布、规模大小等等，我们会发现一种开发方法不能适应各种程度的复杂度和变化率。

Ivar Jacobson：工业互联网需要更多的软件方法

图1 The applicability of most pre-defined methods

企业中每天碰到不同类型软件的开发方法，这现象出现了一种令人担忧的趋势。这种趋势有两种开发方法——一种是敏捷，对面向客户的小的应用程序使用实验性的开发方法，另外一种典型是瀑布模型，特别是在云中开发的应用。看起来这些办法既不灵活，也有些教条。导致看起来象图1一样，大多数开发团队只能在这两种开发方法选择一种对他们说危险性最小的。

这对物联网提供产品和服务的企业是个问题，且这个问题不仅局限在这里，它对所有软件开发的企业而言是通用的问题。当产品增加了开发的多样性，产品开发需要高度的协作和交互，以及更多的人来参与。

对企业来说，最糟糕的事情是企业做了一个极端的选择，就是开发团队要么针对云开发选择了一种重装的、规范开发的过程，要么是针对面向客户的应用选择了一种轻量的、实验性的过程。

对那些工作在成熟并且指定领域的企业来说，也许能保留一两种预先定义的方法，但是老实说，也不能持续维持太久的时间。采用这种方法的企业很快会发现，他们采用的开发方法总是落后于行业的最佳实践，并且企业的创新能力和规模都需要向开发的过程妥协。

事实是，没有两种软件开发活动是完全相同的，任何两种软件开发活动之间也没有屏障。不是只有在大型产品中才会有复杂度的问题，创新也不只是在前端的产品中才需要，所有的事情都需要按照互联网发展的速度随之发生变化。

我们现在需要一种方法能对之前的开发方法进行组合；一种方法能让企业取得平衡，在创新和控制之间，在速度和质量之间，在自由表达和工程规范之间取得平衡。企业需要新创立的一种方法，这种方法不需要向自主和创新妥协，也不能局限他们企业工作方法和真实需要的方法。

工业互联网需要的每一样事情

工业互联网从来不缺少方法论：瀑布模型和敏捷，针对小的APP的方法和针对复杂的系统体系的方法，针对系统工程的方法如软硬件结合的方法。这些方法论对工业互联网都需要。一个大型的企业需要多样化的方法，一个小型的企业需要更具体和聚焦的方法，但是当新产品出现时开发方法可以扩展和集成。目前采用的方法主要有 RUP，Scrum，User Story based 和 SAFe。而且随着新的趋势，新的方法论也随着诞生。伴随着物联网产生方法论并且发布的开发方法很少。我们发现在物联网领域有两种方法论： Ignite Enterprise IoT【请参考文章《Enterprise Internet of Things》】和 IoTMethodology【请参考文章《A Methodology for Building the Internet of Things》】。 Ignite 即将发行一本书，IoTMethology现在只有一些胶片。

从这些新涌现的方法论，以及我们掌握涌现的新技术和新的领域实践来看，物联网有一些最基本的属性。

1. 分布式。物联网上的系统比其他系统更加分布。从通信系统的经验来看，新的失效模式（因为通信失败）、可靠性工程、冗余系统开始起作用。

2. 移动性。通信的运营商也有开发移动系统的经验，现在也是适用的。比如说这些系统可以不受影响的升降级，安全性是非常重要的，系统需要高的鲁棒性。

3. 无人干涉。整个物联网的概念就是传感-分析-激活，都是无人干涉的，比如说无人驾驶的汽车、自动交易系统、大众健康集成系统。这里也许需要针对可靠性、失效管理、异常管理设计一些实践。

工业互联网需要Essence

从前面的章节来看，物联网需要多种的方法和实践，一些是领域相关的实践，另外一些是普遍被接受的工程开发实践。

【Essence 和实践】

软件开发世界已经识别并且描述了数以百种的不同的方法和实践，如图2所示。在理想世界里面，开发团队可以容易地识别当前的情况，选择一系列的实践组合成为一个开发方法。例如，一个为物联网开发的有高度复杂度和高变化率的软件，可以选择下图中绿色的方法，使用 User-Case 和 Architectural Essentials来保证开发的纪律，并且选用 Scrum 和 Agile Modeling 来适应高变化率。

Ivar Jacobson：工业互联网需要更多的软件方法

图2 An abundance of Pratices, some selected for an Internet of Things team

问题是这些实践来自不同地方，并且彼此之间没有共享一个共同的基础，没有了这共同的基础就没办法将他们组合成为一个有效的方法。

这不仅是对工业互联网是一个问题，这从工业化一开始就是个麻烦，现在由于新出现的技术变得更麻我们怎么能赋予团队自己选择和控制自己的开发方法同时：1）提供他们走向成功的指导，2）反应出对组织的控制和承诺。开发团队怎么能从持续增长的实践中获益并且面对他们每天碰到的挑战同时持续的创新。这个影响着公司转向工业互联网的问题，与此同时，企业需要更多的方法。

我们实际需要的是一些具体的通用基础，在这个基础之上，具体的实践可以共享通用的词汇来定义实践，可以提供一个框架来组合和分析各种开发方法。

【Essence介绍】

Object Management Group(OMG)standard Essence【请参考文章《General Electric: Industrial Internet, Pushing theBoundaries of Minds and Machines》】是设计支持组织和社区变成自学习组织和社区，赋予开发团队拥有他们自己的工作方式，共享他们自己的实践。可以通过解放具体实践并且能让这些具体实践随意的组合。

1. 通过关注本质使得方法非常轻量。

2. 帮助团队使用和方法无关的方式来度量进度和健康度。

3. 允许组织建立一个实践库，团队可以从中针对特定的解决方案自由选择实践——有些需要重的开发方法，另外一些团队只需要轻量的开发方法。

4. 帮助组织建立一个自学习型的组织。

Essence 提供了一个软件工程方法的基础。这个基础1）可以让团队以和方法无关的方式理解并且可视化过程和能力的健康度，2）允许团队容易分享、适应即插即用的实践，来创建一个创新的开发方法，帮助团队适应和持续改进。

Essence引导开发人员获得可以度量的结果，并且以系统的方式重用他们的知识。

Essence帮助执行者以平衡的方式来领导项目，不需要更多的控制，协助建立一个自学习的组织。

这将使得企业可以准备一个实践库，包括所有的软件开发实践。这个实践库可以很容易地分享、适配，“即插即用”可以很容易组合成为一种新的开发方法帮助团队适应并持续改进。

这种通用基础已经以 Essence kernel 的形式准备好了，是 Object Management Group (OMG) standard Essence【请参考文章《Essence - Kernel And Language For Software Engineering Methods 》】的一部分，提供了一个基础，可以供团队分享并且从一个大流程中自由获取实践的方法。

【什么是 Essence Kernel?】

Essence Kernel[请参考文章《The Essence of Software Engineering: The SEMAT Kernel》、《A New Software Engineering》、《Major-League》《SEMAT: Why should an executive care》、《Agile and SEMAT – Perfect Partners》、《SEMAT Yesterday, Today and Tomorrow》、《15 Fundamentals for Higher Performance in Software Development》]可以被看成是一个框架，包含了软件开发方法的通用的最小集合。 Essence Kernel是一个小的实践的独立过程，基于你的工作和方法提供了通用的基础。从三个方面描述一个过程或者软件工程：

第一个方面是描述软件工程能力健康进度；

第二个方面是支持能力进度的必要实践；

第三个方面是执行这些实践需要的能力。

最重要的是有一个通用的认识，来理解软件工程能力是如何进展的。Essence 定义了七个纬度来描述度量这种进展，成为阿尔法：机遇、涉众、需求、软件系统、工作、团队、工作方式。

每一个阿尔法都有一系列指定的状态，每个状态随着进度的进展都有一个编号。每一个状态都有一个检查单来帮助执行者来监控当前阿尔法的能力状态，并且来帮助执行者移动到下一个状态。这是想给执行者提供一种直觉的工具来了解当前能力的进展和健康度，使用一种通用的、和开发方法无关的方式。

阿尔法可以变成一种可以触摸的牌，每个牌都有一个状态，状态下面有一个简要的检查单（参考图3）。牌的厚度很容易放到衣服的口袋里面。尽管也需要更详细的指导书，这些牌就给开发团队提供了关键的提醒，就很像一个工程师的工具书。[请参考文章《The Essence of Software Engineering: Applying the SEMAT Kernel》]提供了一个关于内核和使用更加全面的讨论。

Ivar Jacobson：工业互联网需要更多的软件方法

图2 Alphas, their states and checklists - made tangible with cards

【控制和承诺】

由于内核是基于结果的，这使得内核对工业互联网的软件开发扮演了另外一个重要的角色，帮助以这样的方式建立控制和承诺的不同级别：

1. 灵活的：由团队独立的选择实践；

2. 授权的：允许团队改革和提升实践，而不是向质量妥协或者超过了控制范围；

3. 有效的：最少的浪费；

4. 专注在结果：使用真实进展的检查单，而不是过程的步骤或者是完成模板。

这可以通过内核阿尔法提供的检查单，再根据组织的策略、财务的约束、本地化的标准和工业标准增加一些指定的检查点。例如，团队可以轻易地识别出从产品到发布时当前所处的状态，并且向 Essence的通用检查单中增加企业特有的检查项。通过使用基于成就和结果的检查单，而不是流程或者工作产品要求的检查单，我们可以帮助团队理解他们想要达成什么，什么时候和什么地方需要工程的约束，而且这个检查单可以非常安全地适用于大型的和复杂的系统。

任何阿尔法的状态需要,和其他阿尔法状态平衡的点，都可以做成一个检查点。检查点可以是单独的，也可以和一个或者多个开发的生命周期结合。能选择不同生命周期对管理一个非常复杂的领域，例如工业互联网。使用 Essence 内核非常容易地组合了很多生命周期，每一个生命周期都使用相同的生命周期控制中心，但是使用了不同的上下文以及上下文相关的检查单。例如Munich Re定义了一个生命周期家族，每一个都有不同的上下文。

1. 实验性的生命周期：对实验性的，概念验证的，能力创新的定义一个轻量的敏捷生命周期。

2. 增量特性开发的生命周期：对有强架构的、快速特性增量开发的模型定义一个严格的软件工程生命周期。

3. 维护和小的增强的生命周期：对连续的小的特性增强和问题修复，定义一个以时间段（典型是一年）的轻量的生命周期。

4. 技术支持的生命周期：对从开发转换到技术支持的企业定义一个专注在技术支持的生命周期。

这种将检查点和生命周期结合的能力是非常强大的。这样解放了团队，可以让团队使用合适的工程实践，而不是限制到预先定义的类型或者开发模式。也使得整个工业互联网能采用一个最小化的、扩展的、演进的一系列工程方法，而且能使得团队获得他们需要的帮助，但是又不向敏捷力和工程约束妥协。

【将工程实践组合成为方法】

在过去，不同的方法基本上被描述成为一个独立的概念孤岛。每一个方法基本上都是独立的，用自己的语言和词汇来描述，不代表任何广泛接受的公共基础；每一个方法都自成体系。但是其实每个方法都有由许多实践组合而成的。

例如，敏捷中的XP中描述有12项实践，包括结对编程、测试驱动开发、持续集成等等。另外 Scrum 包含的实践包括维护产品backlog，每日的Scrum和 sprint。Scrum并不是一个完整的方法论，Scrum包括一系列可以一起工作的实践。Scrum可以作为一个过程框架和其他实践组合起来一起使用，例如，敏捷团队可以将XP组合到Scrum 中形成开发方法。

关键是，Essence内核提供了一个通用的框架来描述所有的实践，并且允许这些实践组合形成开发方法。而且对内核还有额外的一点，就是 Essence标准也定义了一种语言来描述内核，并且用内核的术语来描述实践和开发方法。

现在，个人的实践可以用Essence来描述。一个实践可以用扩展内核，增加新的状态，检查单甚至新的阿尔法，通过状态转换和产品的工作产品来描述活动，并且描述执行活动的能力。

将一系列实践带到通用的系统，是允许中间的空白和重叠的，这些空白和重叠是非常容易识别的。中间的空白可以被其他的实践填充，重叠的部分可以通过适当的融合实践来解决重叠。

举例来说，考虑两种实践，一种是通过使用 backlog（advancing the Work alpha）来管理团队即将要进行的工作，一种使用use stories（advancing the Requirements alpha）来定义需求。backlog 这种实践没有描述backlog中的每个条目应该怎么定义，user stories这种实践没有描述团队怎么管理这些story的实现。这两种实践是互补的，可以在一起使用。通过 Essence定义实践使得这些实践平滑，自然地连接起来，任何重叠和冲突会立刻显现。如果我们现在回到 4.2 章节介绍的例子，我们利用内核，可以支持团队以图 2 的方式非常有效地组合成为一个新的方法。这种开发方法团队是完全有自主权的。当环境发生变化时，当团队和他们开发的系统演进的时候，开发方法可以很容易地改进和演进。赋予团队创造力和创新，而不是向传统的开发方法一样，让团队陷入到一种指定的，不合适的开发方法中。

构建一个实践库

在过去几年中，通过和多个软件开发领域的合作，包括嵌入式操作系统、财务系统、电信系统还有很多其他被物联网影响的领域，雅各布森国际（IJI）建立了一个基于Essence的实践库。这个实践库的范围能满足从个人到大型软件开发。这个实践库还在持续的发展，更多的实践都使用Essence的语言来描述。当本文发布时，我们现在有接近30种实践可用，包括：

1. 敏捷的精髓，包括日例会、PO 和敏捷的回顾会议；

2. 通用的敏捷实践，包括Scrum，User Stories 和 Continuous Flow；

3. 架构实践包括UseCase2.0,Architectural Essentials 和 Component-Based Development；

4. 生命周期管理包括Unified Process和Disciplined Agile Development。

所有这些都是在内核的基础上构建的，并且可以自由的组合供你的开发团队使用。例如，企业已经使用了这些实践来创建一个轻量的软件开发方法，鲁棒的软件工程方法，基于流的拉开发方法，灵活的开发方法家族。这些实践被用来创建瀑布和敏捷开发方法，并且共享很多同样的工程实践，但是使用的时候有不同的侧重。

最强大的地方在于这些开发方法共享一个通用的基础，可以随着环境的变化随时改变，可以移除或者增加实践。这些开发方法共享实践，帮助团队对齐他们创建的产品和并且和其他团队和产品协作。

为了使得这些实践容易学习，容易接触到，所有这些实践可以通过实体扑克牌的方式获得，也可以获得电子版的（如图3所示）。这种扑克牌很容易获取相应的实践，而且扑克牌的方式对方法的组合和发布，包括实践的替换和社区的建立都是非常容易的。这些工具帮助你很容易做到：

1. 扩展现有的实践来满足个性化的需求和本地化的标准；

2. 增加自己的实践；

3. 定义和生命周期无关的实践；

4. 定义自己的框架和方法。

允许你利用的不仅是雅各布森国际获取的业界最佳实践，而且你完全拥有关于技术的、财务的、激励的、管理的各方面的最佳实践。

在雅各布森国际实践库从天然上来说是非常普世的，并且对很多软件开发领域都是适用的。这个实践库已经包含 essentials of RUP, Scrum 和 SAFe。当创新的团队和企业创建了领域相关的实践，可以加入到这个实践库中。所以我们创建了一个非常好的实践库起点，而且这个实践库正好是物联网需要的。