PDF工业规模敏捷 - 从手工艺到工程
Essence 在推动软件开发走向真正的工程学科方面发挥着重要作用。
Ivar Jacobson、Ian Spence 和 Ed Seidewitz
Roly Stimson 在其题为“工业规模敏捷”的论文9中，将工业规模敏捷描述为
• “任何规模的敏捷”。
• “敏捷是规则，而不是例外”。
• “可持续地、永久地敏捷”，而不仅仅是不可重复的“一次性”事件。
这意味着能够可持续地将敏捷策略适当地应用于任何可以从中受益的事物。 这包括
• 能够根据需要进行“规模化敏捷”。
• 在可能/适当时进行小规模敏捷。
• 发展整个应用领域，而不仅仅是单个应用程序。
虽然规模化敏捷很重要，并且是工业规模敏捷的必要先决条件，但这并非此处的挑战。 相反，重点是如何实现以下方面的可持续性
• 在团队不断变化的情况下，工作方式。
• 在快速变化的情况下，系统。
• 整个应用领域。
• 个人及其职业生涯，以及整个开发组织。
• 对 IT 的长期投资。
有很多很多方法可以说明 IT 投资是多么脆弱。 您只需看看，即使在教育和指导方面投入了巨额资金，许多组织仍在努力将其敏捷实践扩展到整个组织——或者其他组织正在努力维持其敏捷实践的势头，因为他们的团队发生变化并且他们的系统成熟。
另一个常见的不可持续的例子是，许多公司正面临他们必须支持的应用程序数量不受控制地激增，以及 IT 整体拥有成本的上升。
因此，工业规模敏捷需要的不仅仅是能够规模化敏捷。 它还意味着采取有纪律的方法，确保 IT 投资为生产组织及其客户带来可持续的利益。
这涉及对敏捷性的许多方面采取不同的方法。 我们需要超越小规模敏捷，超越独立的竞争性敏捷卓越岛屿，超越个人手工艺和英雄团队，超越似乎是许多善意但以自我为中心的敏捷团队关注的短期即时满足感。 我们称之为从手工艺到工程的这种更全面的方法的采用。 （我们已尽力使本文简短，但对于不熟悉此领域的读者，我们推荐“一种新的软件工程”3以获取更多背景知识。）
从手工艺到工程
向敏捷性的转变为软件行业带来了许多好处。 它打破了规范性瀑布方法对软件工程的暴政，这种方法导致越来越多的大型项目失败，并且它使软件开发人员能够跟上对更具创新性的 IT 解决方案不断增长的需求。
它使许多公司能够做出伟大的事情，但在许多情况下，它导致了一种权利文化、英雄式编程和威胁到母公司及其所依赖的 IT 解决方案的可持续性的短期思维。 很少或根本没有考虑可维护性，英雄们成为潜在的单点故障，而维持运营的成本却不断增长。
我们需要的是一种在保持敏捷性价值的同时，使软件开发更像是一门工程学科，而不是一种手工艺的方法——一种适合互联网时代的新型敏捷软件工程。
什么是手工艺和工程？
手工艺一词通常适用于从事小规模生产定制商品和行业的从业者，在这些行业中，技能由师傅亲自传授给学徒。 另一方面，工程在维基百科（https://en.wikipedia.org/wiki/Engineering）中定义为“应用数学、经验证据和科学、经济、社会和实践知识，以便发明、创新、设计、建造、维护、研究和改进结构、机器、工具、系统、组件、材料和流程。”
关于工程一词是否应应用于软件开发，以及软件工程师是否真的是工程师，已经进行了许多讨论。 然而，随着云计算、大数据和物联网的兴起，很明显，有许多类型的软件和软件开发的许多方面将受益于工程方法。
在她 1990 年发表的开创性论文“软件工程学科的前景”7中，Mary Shaw 建议软件工程的定义应包括以下条款：“通过应用科学知识……为实际问题……创造具有成本效益的解决方案……建造事物……为人类服务。” 她还谈到软件工作“大多数任务是例行的而不是创新的”，但它“更常被视为原创而不是例行”，这意味着“如果我们通过编纂我们已有的知识（甚至可能是自动化）来捕获和组织我们已有的知识”，则在提高质量和缩短上市时间方面存在很大的潜力。
她的观察仍然非常重要； 在 2015 年阿姆斯特丹 GoTo 软件开发会议上，她谈到了在建立软件工程学科方面取得的进展。 根据 Shaw 的说法，工程的特点如下
• 有限的时间、知识和资源迫使人们在权衡中做出决定。
• 最好的编纂知识，最好是科学，塑造设计决策。
• 参考资料使知识和经验可用。
• 设计分析预测实现的属性。
虽然软件开发具有工程学科的许多特征，但我们尚未达到目标。 除非我们止步于此，否则敏捷的兴起不是问题。
为什么需要更多工程？
为什么从手工艺转向工程如此重要？
这样做将帮助我们应对日益自动化、互联互通的世界中不断增长的挑战——在这样的世界里，软件性能的微小改进可能会决定盈利还是亏损； 在这样的世界里，稳健性、可扩展性和安全性的声誉可以为股价增加数百万美元； 在这样的世界里，软件越来越成为企业的公众形象。
工程学科的编纂知识和专业精神对于以下方面是必要的
• 通过技术、团队和供应商的变化来维持和发展交付能力。
• 将运营从早期原型可预测地扩展到全球推广。
• 控制投资并知道何时转向更有可能带来良好回报的解决方案。
• 系统地提高解决方案组件和系统的重用性和互操作性水平。
• 生产拥有成本可承受的长寿命解决方案。
也许并非所有人都需要从手工艺转向工程。 正如 Mary Shaw 所说，“对于完全自动化且在无人值守状态下运行的软件系统，以及故障后果是灾难性的软件系统，对工程学科的需求最大。 例如，电信设备、核安全装置、医疗植入物、自动驾驶汽车和股票交易程序。 软件开发中对工程的需求取决于事情出错时后果的严重程度，以及人类是否可以及时采取行动来最大限度地减少后果。” 电子商务、金融、电子病历甚至人力资源使用的工程系统也有强烈的需求。 这些系统中的故障后果可能不包括立即丧生，但对于企业或受影响的个人来说，它们仍然可能是“灾难性的”。
因此，对于许多组织和软件系统来说，手工艺是不够的。
好消息是，有一种前进的方法，可以在保持敏捷性价值的同时，使软件开发更像是一门工程学科，而不是一种手工艺。 它包括
• 软件工程。 这意味着对所有软件进行整体工程设计，以改进整个应用领域以及单个点解决方案。 需要实践来帮助团队设计其软件，以捕获需求和开发旨在工程化优秀产品的软件。 这也意味着鼓励大规模和小规模的创新——新的业务和新产品机会的创新，以及解决影响整个组织的总体拥有成本的创新，而不仅仅是单个用户和应用程序。
• 方法工程。 应该对方法进行工程设计，以支持当今和未来面临的各种开发挑战。 新兴的最佳实践应以易于在团队之间沟通和共享的方式捕获和编纂，并使每个团队都能够从这个不断增长的可重用、经过验证的实践集中组合他们所需的方法。
此外，从手工艺转向工程为鼓励、建立和维持真正的组织敏捷性提供了强大的平台。
软件工程
如果手工艺已经成为真正的工程学科，软件将如何开发？ 与其他工程学科一样，它将通过使用普遍接受的、一致的实践来设计，这些实践将得到基于共同基础知识的模型和分析的支持。
过去，这种工程思维方式被误解为意味着“大型前期设计”，其下游的一切都类似于制造而不是工程。 事实上，对于物理人工制品（如建筑物、桥梁和汽车）的工程设计，前期蓝图通常是必要的。 这样做是为了可以对前期模型和蓝图进行适当的分析，因为建造这些东西所需的资本成本以及一旦建成后更改它们的难度。
软件开发中的敏捷性利用了这一特性，允许以快速且增量但仍可靠的方式开发软件； 然而，敏捷开发方法中存在有纪律的设计的位置。 只是对于软件，开发人员还可以进行分析并随着他们构建软件系统本身而逐步演进设计。
实际上，需要的是敏捷思维方式与工程思维方式的融合，将增量开发与基础知识的学科应用相结合。 在这种方法中，并非每个人都必须成为工程师，但开发人员将继续被视为熟练的工匠，而不是工厂工人。 （请参阅边栏“手工艺和工程”。）
在敏捷方法中，通常会谈到软件系统设计随着系统的迭代开发而涌现。 这是演进式设计的具体体现，而不是大型前期设计。 它在允许团队创造性地探索替代方案的同时，仍然收敛于具有清晰整体设计的良好解决方案方面非常有效。
然而，这种涌现式设计倾向于为特定团队生成点解决方案。 然而，严肃的软件开发组织几乎总是处理在企业级应用领域内的多个项目上工作的多个团队。 各种项目级解决方案需要适应这个不断发展的领域。 实际上，大型软件系统的开发通常需要多个团队，这些团队的产品是必须组合在一起以创建整体系统的组件。
在这个层面处理设计是软件架构的领域，无论是在系统级别还是企业级别，软件架构都可以而且应该仍然是演进式的。 然而，关键的架构决策（在开发路线图中呈现）通常需要在相应的开发工作之前做出，以便为跨项目和团队提供通用指导。 这就是工程实践尤其重要的地方，它允许基于对业务利益与工程成本的仔细分析，进行有益于整个组织的创新。
方法工程
从手工艺转向工程依赖于知识的编纂和共享。 组织需要工程化其方法，以便更有效地工程化其软件。
当今使用的大多数方法都处于极端状态，要么是单体式的，要么是隐式的。 敏捷领域正在经历许多相互竞争的单体式规模化敏捷方法的兴起，例如 DAD（规范化敏捷交付）、SAFe（规模化敏捷框架）、LeSS（大规模 Scrum）和 SPS（规模化专业 Scrum）。 所有这些方法都有其特殊的优点和缺点。 它们都有自己的支持者阵营，但它们的单体特性使得从彼此那里借鉴想法变得不切实际，更不用说借鉴完整的编纂实践了。 这种情况与我们过去使用 RUP（Rational 统一过程）、Open、结构化分析和设计等方法时的情况非常相似。 我们还观察到，在许多大型组织中，隐式应用的敏捷实践的成功导致先前使用和编纂（记录）的方法已被未记录的敏捷民俗所取代。
这里的悖论是，没有记录在案的方法所引起的不适导致许多组织寻求用新的单体式方法之一来取代他们的隐式敏捷方法。 他们没有意识到的是，它最终会被拒绝，就像最初的方法一样，因为团队寻求创新并应对其系统和环境中固有的日常挑战。 这通常会导致方法不断更迭，几乎没有任何理由或理由。 行业不断在无方法和最新的“唯一正确方法”（这种弊病可悲地甚至影响了敏捷社区）之间切换的习惯不是前进的方向。
相反，组织需要一种有效的方法来利用他们从一次努力中学到的东西，并将其应用和适应于新项目。 盲目地从一种时尚方法转向另一种时尚方法无法为构建共同知识提供一致的基础。 然而，为所有项目强制执行一刀切的流程不支持持续学习和适应的需求，并且会抑制手工艺和创造力。
从手工艺转向工程首先需要解放实践，以可访问、可重用的方式呈现它们，使工程师能够自信且可预测地为他们的环境和他们试图解决的问题选择正确的工程实践。
Essence：对美好未来的希望
软件开发是一项多维度的努力——人类的才智与人类的需求相遇，集体的努力与编纂的知识相遇——这将受益于工程实践的明智应用。 从手工艺到工程的道路通过科学学习不断进步——从临时的实践到编纂的专业工程实践。
这种转变的关键是能够轻松地捕获、共享和改进实践。
什么是 Essence？
Essence 是一种简单的直观语言和基础元素内核，用于捕获、描述和组装实践和方法。 Essence 的工作已经进行了 10 多年——在过去的六年里在 SEMAT（软件工程方法和理论）社区内进行——最终在 2014 年被 OMG（对象管理组织）采纳，成为一项新的国际标准5。 它超越了仅仅为描述实践提供语法和符号，而是建立了一个坚实的共同基础——一个内核——使团队能够
• 在通用的共享内核之上描述他们的实践。
• 轻松共享、调整和即插即用他们的实践，以创建他们需要的创新工作方式，从而脱颖而出并不断改进。
• 了解和可视化其努力的进展和健康状况，无论其工作方式如何。
（有关 Essence 的更多信息，请参阅本文末尾列出的其他资源。）
Essence 在从手工艺转向工程的过程中发挥着多种作用
• 帮助在软件工程工作中实现适当的平衡。
• 帮助编纂和捕获工程实践。
• 充当新型工程社区的基础。
仅使用 Essence 不会将手工艺人变成工程师，但其采用将有助于组织进行这一重要转变，而且，有助于行业为未来做好准备。
平衡进展和健康状况
Essence 提供了一个元素内核，该内核为开展软件工程工作建立了共同基础。 这可以以多种方式使用，以提高软件工程团队的效率，包括以下方面。
积极监控工作的健康状况。
内核定义了任何软件工程工作都关心的七个方面：机会、干系人、需求、团队、工作、工作方式和软件系统本身。 对于每个元素，Essence 都定义了一系列状态，并附带清单，代表健康的进展。 如图 1 所示，这些可以用于创建与实践无关的健康监视器，可用于检查工作是否步入正轨并以健康的方式进行。 在顶部，雷达图（交互式在线版本，包含清单1）将进度表示为从中心增长； 在底部，在里程碑地图上（可从 App Store 下载 Ivar Jacobson International 的 Alpha State Explorer 应用程序），所有状态都从上到下按顺序排列，已实现的状态以填充显示。 第二个示例还显示了用于确认软件系统可演示状态的实现的清单。
内核还可用于创建轻量级治理和合规实践，以帮助确保团队达到所需的工程严谨程度。 通过将治理和合规性建立在内核本身之上，可以在与实践无关的方式中实现这一点，从而使团队能够安全地创新并拥有自己的工作方式。 图 2 显示了慕尼黑再保险公司创建的现代基于实践的软件开发方法 Munich Re Essentials 的核心四个不同的治理生命周期4。 这四个生命周期是探索性、功能增长、维护和支持，每个生命周期的检查点（里程碑）由每个 alpha 要达到的状态定义。
评估方法的有效性。
Essence 从根本上给出了软件工程的详细定义。 在寻找 GTSE（软件工程通用理论）6的过程中，一些研究人员将 Essence 用作这样的定义，并且预计这项工作将取得更多成果。 这种理论提供的关键方面是预测能力。
建筑工程师可以使用材料科学和结构理论来尽早了解拟议的建筑物是否有可能站立或倒塌。 类似地，使用 Essence，人们可以了解拟议的方法是否结构良好，其实践中是否存在任何差距或重叠，以及如果存在差距或重叠，如何解决它们。
内核具有许多方法分析机制，其中最简单的一种由其高级活动地图提供。 这是一组 12 个活动空间，组织到三个关注领域中。 活动空间是特定于方法的活动的通用占位符。 如图 3 所示，这些活动空间可用于评估团队活动的范围。 在此示例中，团队已向地图添加注释以指示其活动，并添加红色圆形标记以突出显示危险区域。
注意：在不理解 Essence 语言的含义的情况下，用尖头箭头表示活动空间的符号会使它们看起来是顺序的，这不是预期的含义。 活动空间及其包含的活动当然可以迭代地、并发地或以实践所需的任何顺序应用。
这些只是内核功能的一些简单示例，但它们说明了内核可以帮助团队和组织评估其方法有效性的多种方式。
编纂和捕获工程实践
除了内核之外，Essence 还提供了一种语言，用于在内核之上创建实践，然后从这些实践中组合方法。 这对于从手工艺转向工程非常重要。
如前所述，当前大多数实践都嵌入在相互激烈竞争的单体式方法中。 他们不是承认他们共享实践并鼓励重用和交叉传播，而是故意诽谤和相互剽窃。 更糟糕的是，从工程的角度来看，他们都关注开发组织的设计和可持续性，而不是所生产系统的设计和可持续性。 这并不是说前者不重要。 实际上，它对于任何开发组织的成功都至关重要。 然而，随着软件集成到我们日常生活的结构中，对经过验证的可重用工程实践的需求也在增长。
需要实践来帮助团队设计其软件：用于处理需求的实践，例如用例、功能和故事； 用于开发组件和服务； 用于应用适当的模式或框架； 用于测试复杂的分布式系统； 鼓励重用的实践； 以及帮助工程师充满信心地编码的实践。 特别是，需要实践来处理架构问题，例如并发性、安全性、用户体验、微服务和数据保护，以及解决更广泛的架构问题，例如企业架构、产品线架构、面向服务的架构和系统架构系统。 许多这些实践已经以 Essence 语言编纂（请参阅关于共享实践：方法和实践库的部分）。
这些工程实践需要精简（精益）、敏捷，最重要的是，可组合成完整的方法，以为使用复杂系统的大量实践的团队提供指导。 它们需要帮助处理现代软件工程的复杂性。 无论他们是单独工作、在小型团队中还是在更大的团队中工作，无论采用何种团队工作或工作管理实践风格，所有工程师都需要它们。
在全球范围内，我们希望拥有一个强大而灵活的编纂专业工程实践库，该库反映了软件开发的多维度性质，并且可以用于支持当今和未来正在开发的许多不同类型的软件。
这些实践只能来自在技术前沿工作的工程团队，并且这些团队需要一种更好的方法来捕获、沟通和共享他们的实践。
一种新的方法架构
以 Essence 内核为共同基础，您可以使用 Essence 语言来描述任何实践，包括工程实践，从而使它们能够无缝地组合在一起以形成方法。 图 4 说明了一个三层方法架构，内核作为基础，通用实践在中间，特定领域的实践在顶部。
从堆栈的底部开始，这三层是
• Essence 内核。 这为所有实践和方法提供了共同基础，并为实践的定义和组合提供了基础。
• 通用实践。 这些实践适用于许多软件工程领域。 通用实践的示例包括 Scrum、用例、用户故事、测试驱动开发和验收测试驱动开发。 许多工程实践将是通用的，但许多最有价值的实践将是特定领域的。
• 特定领域的实践。 这些实践明确针对特定领域，例如商业智能、数据仓库或电信。 特定领域的实践与通用实践同等重要，甚至更重要。 例如，开发物联网解决方案需要许多特定领域的实践； 这些实践迎合了诸如资产集成架构和不同技术概况之类的东西。 正如通用实践扩展了内核以提供特定指导一样，特定领域的实践通常是通用实践的扩展/专业化。 例如，资产集成架构实践可以作为通用敏捷架构实践的扩展来呈现。
通用实践与特定领域实践的分离有助于团队找到他们需要的实践，并帮助组织建立组织和跟踪其工作的通用方法。 组织标准化一小组通用实践作为其所有团队方法的基础的情况并不少见。
以这种方式解放实践非常强大。 一旦实践在 Essence 中编纂，团队就可以拥有其工作方式的所有权，并开始组装自己的方法。 这甚至可以从一个简单的实践库开始，如图 5 所示。
以允许与流行的管理实践（敏捷或其他）一起应用的方式捕获和共享工程实践（包括通用和特定领域）提供了支持真正软件工程学科所需的编纂知识。 它也是摆脱单体式管理方法和孤立工程实践的关键。
共享实践：方法和实践库
很容易说团队将能够即插即用地使用实践集来构建自己的方法并拥有其工作方式的所有权。 但是实践将从何而来呢？
让我们看两个具体的例子。
敏捷方法
行业内涌现并推广了大量的通用敏捷实践。不幸的是，这些实践大多“归属于”某种方法，即使它们共享相同的价值观，也很少以一种能够良好协作的方式呈现。在规模化敏捷方法领域尤其如此，每种方法都包含许多相同的实践，并与一些新的、独特的、创新的实践纠缠在一起，以至于几乎不可能安全地分离出新实践以供其他方法使用。
相比之下，图 6 概述了一个基于 Essence 的敏捷实践入门包，名为 Agile Essentials。2 它包括来自 Scrum、看板和 XP（极限编程）的实践。
这是一个包含七个实践的小型库，当它们组合在一起时，就构成了一个团队敏捷方法的起点。Scrum、用户故事和用例也已被“本质化”，可以与 Agile Essential 实践一起使用。
因此，借助 Essence，可以创建一个通用的、可重用的实践库，团队可以从中选择他们想要使用的实践，并将它们组合在一起以快速启动他们自己的方法。
Ignite 物联网方法论
Ignite 是一种为物联网开发的 методология。8 它支持多种不同的方法，并试图弥合“机器专家”和“互联网专家”之间，以及“五年思考”和“持续 Beta”之间的差距。Ignite 可以很容易地描述为一组建立在 Essence 内核之上的实践。图 7 展示了使用 Essence 呈现的 Ignite 的外观。
这张图清楚地说明了许多关键点
• Ignite 显然包含并重用了许多通用实践，这些实践比物联网领域更广泛适用，包括那些已经作为 Agile Essentials 实践库一部分提供的实践。
• 成功的物联网开发需要许多特定领域的工程实践。
• 每当有人想要创建一种新方法时，他们目前都必须重写、重新呈现，并且在许多情况下，重新命名已经建立的通用实践。
• 方法越全面，就越不可能有人使用它的全部内容。例如，没有人会同时使用所有这些实践。显然，可以使用 Ignite 方法论中包含的实践构建许多方法，但如果不使用 Essence，团队将很难做到这一点，甚至是不可能做到。
许多其他实践可能对开发物联网的团队有用。其中一些将是在撰写本文或创建 Ignite 时未知的创新。这很容易导致该方法过时和不流行。将 Ignite 展示为一个实践库，允许实践集响应用户的需求，用户可以定期添加新实践并淘汰不再需要的实践。
从现有方法或方法论中提取实践的过程称为本质化。Essence 旨在让人能够提取任何方法或实践的本质，因此方法的本质化意味着识别方法的实践和实践架构。此外，每个实践都根据 Essence 中的元素和 Essence 语言进行描述/编纂，并根据需要添加新的特定于实践的元素。截至撰写本文时，统一过程已完成本质化，DSDM（动态系统开发方法）正在进行中。其他几种方法正处于计划本质化的阶段。世界各地的许多公司现在都在使用 Essence 标准来本质化他们的方法。
本质化的价值在于，人们可以轻松了解实践的真正重要之处，将其与其他实践进行比较，将其组合成一种方法（与许多其他经过验证的实践一起），并随着新知识的出现轻松修改/更改该方法。应用 Essence 还使您更容易管理组织中的方法，从而创建一个有效的学习型组织。此外，本质化的方法不仅仅是一个静态描述，还可以在团队实际使用该方法时提供帮助，使他们能够在努力的任何时刻衡量进度和健康状况。
为了弥合工艺和工程之间的差距，在捕获特定领域的实践方面做得还不够。正如早先看到的，这些概念可以使用 Ignite8 和其他流行的方法论来说明，但一个充满活力和投入的工程社区必须充实和完善必要的工程实践集。
有两种方法可以加速转型
• 将流行的方法分解为实践，并设计这些实践，使其可以以团队想要的任何合理方式组合，可能产生一种包含来自 DAD、SAFe、LESS 和 SPS 等多种现有方法的实践的方法。
• 编纂现有或新的实践，使其可以与其他实践组合以形成完整的方法。世界上已经有数百种实践，但它们的描述方式无法使其易于组合。现在，无需描述完整的方法即可完成此操作。
在这两种情况下，Essence 都是关键，因为它为这项工作以及行业从工艺到工程的成功转型提供了基础。
结论
随着软件对世界日常活动变得越来越重要，现在是软件开发超越基于工艺的方法，发展成为真正的工程学科的时候了。
这将需要一个共享的、编纂的工程实践库，该库可以在各种技术领域和各种类型的软件中重用；这组实践将随着更好的软件开发方式的出现而发展和适应。
这不会一蹴而就，但这对于我们行业在成熟和发展为超越敏捷和其他当前实践的事物时，需要迎接的挑战。
我们仍然需要工艺的奉献精神、创新和发明，体现在
• 技艺精湛的专业人士，对他们的学科充满热情，并致力于掌握新的、复杂的、快速发展的技术。
• 了解复杂问题的当地专家，并快速响应不断变化的需求、看法和挑战。
然而，我们也需要工程学科的编纂知识和专业精神，以便能够
• 通过技术、团队和供应商的变化来维持和发展交付能力。
• 可预测地将运营从早期原型扩展到全球推广。
• 控制投资，并知道何时转向更有可能带来良好回报的解决方案。
• 系统地提高解决方案组件和系统的重用和互操作性水平。
• 生产具有可承受拥有成本的长寿命解决方案。
这就是我们所说的从工艺到工程的转变——一个需要逐个实践、逐个领域进行的旅程。感谢 Essence，我们所有人的旅程都可以从今天开始。
参考文献
1. Graziotin, D., Abrahamsson, P. 2013. 用于 SEMAT Essence 软件工程理论的基于 Web 的建模工具。Journal of Open Research Software 1(1); e4; http://dx.doi.org/10.5334/jors.ad.
2. Ivar Jacobson International. 2015. Agile Essentials; https://www.ivarjacobson.com/sites/default/files/field_iji_file/article/agile_essentials_paper.pdf.
3. Jacobson, I., Seidewitz, E. 2014. 一种新的软件工程。acmqueue 12(10); https://queue.org.cn/detail.cfm?id=2693160.
4. McDonough, A. 2014. Munich Re 和 ESSENCE - 软件工程方法内核和语言：案例研究。Object Management Group; http://www.omg.org/news/whitepapers/Munich_Re_Essence_Case_Study-2014-12-01_JP.pdf.
5. Object Management Group. 2014. Essence - 软件工程方法内核和语言 (Essence); http://www.omg.org/spec/Essence/.
6. Ralph, P., Johnson, P., Jordan, H. 2012. 关于第一届 SEMAT 软件工程通用理论研讨会 (GTSE 2012) 的报告。 SIGSOFT Software Engineering Notes 38(2): 26-28.
7. Shaw, M. 1990. 软件工程学科的前景。IEEE Software 7(6): 15-24.
8. Slama, D., Puhlmann, F., Morrish, J., Bhatnagar, R. 2015. 企业物联网：互联产品和服务的策略和最佳实践。O'Reilly.
9. Stimson, R. 2015. 工业规模敏捷——挑战和解决方案策略。Ivar Jacobson International; https://www.ivarjacobson.com/publications/white-papers/industrial-scale-agile-challenges-and-solution-strategies.
Ivar Jacobson 博士是组件和组件架构、用例、面向方面的软件开发、现代商业工程、统一建模语言和 Rational 统一过程之父。他对软件行业的最新贡献是一个正式的实践概念，该概念将实践提升为软件开发的“头等公民”，并将方法（或过程）简单地视为实践的组合。Jacobson 也是 SEMAT（软件工程方法和理论）社区的创始人之一，该社区的使命是重塑软件工程。他是七本有影响力的畅销书和大量论文的主要作者。他被授予 Gustaf Dalén 奖章（“小诺贝尔奖”），并且是秘鲁圣马丁德波雷斯大学的荣誉博士。
Ian Spence 是 Ivar Jacobson International 的首席技术官，也是 SEMAT（软件工程方法和理论）内核开发的团队负责人。作为一名经验丰富的教练，他已将数百个项目引入迭代和敏捷实践。他还领导了许多成功的大规模转型项目，与多达 5,000 人的开发组织合作。他目前的兴趣包括大型项目的敏捷、敏捷外包以及通过敏捷测量推动可持续变革。
Ed Seidewitz 是 Ivar Jacobson International 前美洲区首席技术官。他在商业和政府部门的敏捷系统架构和开发方面经验丰富。他的工作范围从业务流程分析到系统架构，再到企业级信息系统的全面实施，这些系统部署在数据中心或云端。他在 UML（统一建模语言）方面拥有领先的专业知识，包括参与标准的持续演进，并且在最先进的信息系统技术方面拥有背景。
版权 © 2016 由所有者/作者持有。出版权已授权给 。
其他 Essence 资源
为了帮助真正理解 Essence 是什么、如何使用它来构建实践和方法，以及使用它带来的价值，我们建议您阅读
Jacobson, I., Ng, P.-W., McMahon, P. E., Spence, I., Lidman, S. 2012. 软件工程的 Essence：SEMAT 内核。acmqueue 10 (10); https://queue.org.cn/detail.cfm?id=2389616.
您可以补充阅读以下内容
Jacobson, I., Ng, P.-W., McMahon, P. E., Spence, I., Lidman, S. 2013. 软件工程的 Essence：应用 SEMAT 内核。 Addison-Wesley.
Jacobson, I., Ng, P.-W., Spence, I., McMahon, P. E. 2014. Major-league SEMAT：为什么高管应该关心？acmqueue 12(2); https://queue.org.cn/detail.cfm?id=2590809.
Jacobson, I., Spence, I., Ng, P.-W. 2013. 敏捷和 SEMAT：完美的合作伙伴。acmqueue 11(9); https://queue.org.cn/detail.cfm?id=2541674.
侧边栏：工艺和工程
与工艺相关的概念是工匠精神，由实践或精通工艺的人执行。软件开发将始终需要工匠精神，它可以或多或少地建立在科学、工程和结构化知识的基础上。例如，我们会将工程师描述为在软件开发中使用工程实践的工匠。新的软件工匠精神运动支持许多工程实践——例如，他们是设计和架构模式、领域驱动设计等的坚定支持者。他们以使用正确的工具、技术和设计方法来实现高质量的软件为荣。他们不相信英雄主义，而相信工作质量和工具。他们相信可持续性，并保持系统“清洁”并能够吸收变化和返工。然而，工匠精神运动并未完全解决整个工程领域，特别是如何系统地增长关于该学科的知识。
侧边栏：一些定义
方法领域中使用的术语通常定义不清或容易混淆。例如，方法 (method) 和方法论 (methodology) 之间有什么区别？实践 (practice) 和过程 (process) 之间呢？
Essence 提供了以下简单的定义，这些定义贯穿本文，但在关于 Essence 的部分尤其相关。
实践 (Practice)：一种针对特定目标，可重复地做事的方法。
方法 (Method)：团队工作方式的文档记录。方法可以使用或不使用 Essence 进行记录。如果使用 Essence 记录，那么它是 Essence 内核和一组为实现特定目的的实践的组合。方法可以属于单个团队，也可以在团队之间共享。
Essence 内核 (Essence kernel)：软件工程的可操作参考模型，为实践的定义和方法的组装提供框架。
工作方式 (Way of working)：这是一个团队实际所做的事情。它可能与也可能不与其方法相符。
方法论 (Methodology)：一组已知共享一组共同价值观并能良好协作的实践的集合。它是一种实践库的形式。
实践库 (Practice library)：一组可能相互竞争的实践的集合。例如，需求管理实践库可以包含许多不同的竞争实践，例如声明式需求、用例和用户故事。
入门包 (Starter pack)：一种部分构建的，通常是不完整的方法，团队可以用作框架来播种他们自己的方法。
组合 (Composition)：将实践合并到实践和方法中的过程。重要的是要理解，实践是通过合并操作而不是通过消息交互的组件来组合的独立关注点。
本质化 (Essentialization)：将方法或实践简化为本质并使用 Essence 语言捕获它的过程。
最初发表于 Queue vol. 14, no. 5—
在 数字图书馆 中评论本文
更多相关文章
Catherine Hayes, David Malone - 质疑评估非密码哈希函数的标准
虽然密码哈希函数和非密码哈希函数无处不在，但在它们的设计方式上似乎存在差距。存在许多由各种安全需求驱动的密码哈希标准，但在非密码方面，存在一定程度的民间传说，尽管哈希函数历史悠久，但尚未得到充分探索。虽然针对现实世界数据集的均匀分布很有意义，但在面对具有特定模式的数据集时，这可能是一个挑战。
Nicole Forsgren, Eirini Kalliamvakou, Abi Noda, Michaela Greiler, Brian Houck, Margaret-Anne Storey - DevEx 行动
随着领导者寻求在财政紧缩和人工智能等变革性技术的背景下优化软件交付，DevEx（开发者体验）在许多软件组织中越来越受到关注。直观地看，技术领导者普遍接受良好的开发者体验能够提高软件交付效率和开发者幸福感。然而，在许多组织中，改进 DevEx 的拟议举措和投资难以获得支持，因为业务利益相关者质疑改进的价值主张。
João Varajão, António Trigo, Miguel Almeida - 低代码开发生产力
本文旨在通过展示使用基于代码、低代码和极端低代码技术进行的实验室实验结果，研究生产力差异，从而为该主题提供新的见解。低代码技术已清楚地显示出更高的生产力水平，为低代码在短期/中期内主导软件开发主流提供了强有力的论据。本文报告了程序和协议、结果、局限性和未来研究的机会。
Ivar Jacobson, Alistair Cockburn - 用例至关重要
虽然软件行业是一个快节奏且令人兴奋的世界，其中不断开发新的工具、技术和技术来服务于商业和社会，但它也很健忘。在其快速前进的匆忙中，它容易受到时尚的摆布，并且可能会忘记或忽略针对它面临的一些永恒问题的成熟解决方案。用例于 1986 年首次引入，后来普及，是这些成熟的解决方案之一。
© 保留所有权利。