PDF打破方法论的牢笼！解放实践！
精髓：一种新的思维方式，有望解放实践并实现真正的学习型组织
Ivar Jacobson 和 Roly Stimson，Ivar Jacobson International
我们开发软件的方式难以跟上技术和业务的变化。即使在敏捷兴起之后，人们仍然在一种品牌方法和另一种品牌方法之间摇摆不定，将好的和坏的一起抛弃，行为更像是宗教狂热分子，而不是科学家。
问题在于，多年来开发和完善的专业实践，共同代表了我们行业共享的知识和经验，却常常被囚禁在专有的方法论牢笼之中。开发组织和团队认为自己唯一的选择是全盘采用这种方法或那种方法，并拒绝所有其他方法——然而，实际上，组织和团队需要的是自由地选择他们需要的专业实践，无论这些实践在何处定义，并在任何适合的排列和组合中使用它们，以应对他们面临的确切情况和挑战。
有一种简单的方法可以打破方法之间不健康的竞争循环——这些方法之间的相似之处远大于差异——那就是将实践从方法论的牢笼中解放出来。解放实践，让它们凭借自身的优点而兴衰。解放实践，让团队可以试验、创新和即插即用成熟的实践，以创建他们今天需要的工作方式，并无缝演变为他们明天需要的工作方式。
本文解释了为什么我们需要打破这种重复的、功能失调的行为，并介绍了 Essence，一种新的思维方式，有望将实践从方法论的牢笼中解放出来，从而实现真正的学习型组织。
引言
世界开发软件已经超过 50 年了。作为一个整体，软件行业非常成功。我们可以选择感到高兴，并继续我们正在做的事情。然而，在表面之下，一切并非那么美好：太多的尝试失败了，所有领域的质量普遍偏低，成本太高，上市时间太长等等。显然，我们需要更好的工作方式，或者换句话说，我们需要更好的方法。
作为一个行业，我们一直在寻找更好的方法，遵循从范式到范式，从方法到方法，曲折前进的道路，变化非常像时尚行业激发衣橱变化一样。例如，在 20 世纪 70 年代和 80 年代，结构化方法占主导地位；在 20 世纪 90 年代，面向对象或组件方法受到青睐；自 2000 年左右以来，敏捷方法一直占据主导地位。目前，最受关注的是扩展敏捷方法。在这个领域，有许多相互竞争的方法：例如，SAFe（规模化敏捷框架）、Nexus 和 LeSS（大规模 Scrum）。它们都很流行，并被世界各地的组织使用。它们以重叠的方式和特定的方式为用户组织交付价值。
现在，如果它们都很好，那么问题是什么呢？
1. 方法本质上是单体的
也许最受限制的因素是，大多数方法都是单体的，这意味着它们的设计并非易于让你用另一种方法的实践替换一种实践，并保持其他实践不变。一个方法可能是模块化的，但这些模块对于该方法是唯一的，不能被另一种方法重用。
2. 方法具有本土化的呈现方式
每种方法都有其独特的用户体验和结构，并使用其自身的风格和术语来描述其选择的实践。方法的拥有者自行决定了这些重要方面，而没有遵循任何标准。因此，其实践与其他方法的实践不兼容。比较或混合方法就像比较或混合文化一样——如果不是不可能，那也充其量是非常困难的。
3. 方法没有共同的基础
虽然每种方法都有一些独特的实践，但它与其他方法有很多共同之处。毕竟，它们都处理软件，因此应该有很多共同点。事实是，它们共享的内容是隐藏的且不明确的，因此在没有深入检查的情况下，似乎它们几乎什么都不共享，甚至连基本内容都不共享，例如：什么是软件？什么是软件开发？什么是需求、设计、测试？什么是团队，工作方式？
4. 实践被锁在方法论的牢笼中
今天，一种方法内的实践被锁定在该方法中——它们在方法论的牢笼中——并且不能轻易地在其他方法中重用。事实上，要将一个实践纳入一种方法，最有可能需要重写它以适应该方法本土化的风格。
5. 方法论的牢笼由方法论的狱卒——大师——控制
大师们控制着哪些实践应该组合到他们的方法中。他们扩展了他们的方法，其中包含了从其他方法“借用”和“改进”的实践。引号表示发生的并不完全是“借用”，而且并不总是“改进”，但由于对原始实践的误解或重新解释，它可能会变成对原始实践的歪曲或混淆。
该方法反映了其大师的特定视角、偏见和经验，可能不是开发社区集体学习到的东西。
让我们明确一点，大师们不一定是在争取他们所处的位置。由于今天所有的实践都被描述为我们所说的本土化的，因此，想要从其他地方“借用”实践的大师被迫重写“借用”的实践，使其适合他或她的方法，并在这样做时“改进”它。
6. 我们已经经历了 50 年的方法论战争
“借用”和“改进”的实践的所有者自然会觉得他们的实践被“误解”了。这种所谓的“借用”并不能促进大师之间的合作。考虑到这些实践的所有者在时间和资本上的投入，他们必须捍卫自己的领地，从而导致方法论战争。这些战争始于 50 年前，并且仍在继续，看不到明确的结束迹象。
这六个问题说明了我们在方法论方面的工作方式有多么不成熟。我们将这些问题统称为“世界上最愚蠢的事情”，这里的“世界”当然是指软件开发方法。
我们需要做什么才能摆脱这种愚蠢的境地？
前一节中确定的六个问题已按照图 1 所示的方式得到解决。
1. 发现一个标准内核
显然，一个标准“内核”需要包含“事物”，这些“事物”在任何方法中都是或应该是普遍存在的1，例如，我们始终使用的和始终产生的基本事物是什么，以及我们在开发软件时始终需要的基本能力是什么？设计内核的团队开始指定标准、原则和特征，这些标准、原则和特征应指导他们创建标准的工作。详细介绍这些内容超出了本文的范围，但让我们提及一些（引用的材料来自博客和工作文档）
上述基本事物，即内核元素，应该“无论正在开发的软件的规模或范围如何，也无论参与开发的团队的规模、范围或风格如何，都适用。”
“本质上，它[内核]为思考和推理我们拥有的实践以及我们需要的实践提供了一个与实践无关的框架。内核的目标是建立对软件开发核心的共同理解。”
内核元素应具有：通用性、重要性、相关性、精确定义、可操作性、可评估性和全面性。相关性解释为“可供所有软件工程师应用，无论其背景和方法论阵营（如果有的话）如何”，全面性“适用于内核元素的集合；它们必须共同捕捉软件工程的精髓，提供一张地图，支持软件工程团队的关键实践、模式和方法。”
以下一般原则被认为是找到内核必不可少的：质量、简洁性、理论、现实主义和可扩展性、合理性、可证伪性、前瞻性视角、模块化和自我改进。理论意味着“内核应建立在坚实、严谨的理论基础上”；现实主义和可扩展性意味着“内核应适用于实际项目，包括大型项目，并尽可能基于经过验证的技术”；自我改进意味着“内核应配备使其自身能够进化的机制。”
此外，内核应具有以下特点：与实践无关、与生命周期无关、与编程语言无关、简洁、可扩展、可扩展和形式化规范。可扩展解释为内核支持最小的项目——一个人为一个客户开发一个系统——但它也必须支持最大的项目，其中可能存在系统之系统、团队之团队和项目之项目。可扩展意味着内核需要具备添加实践、细节和覆盖范围，以及添加生命周期管理和定制内核本身以使其特定于领域或将软件开发工作集成到更大的努力中的能力。
在这些指导原则的指导下，团队着手寻找内核。图 2 显示了要处理的基本事物——阿尔法。1
阿尔法存在于客户、解决方案和努力三个不同的关注领域。阿尔法不是有形的，因此它们不代表诸如文档之类的工作成果，但它们具有状态，这些状态说明你处于阿尔法生命周期的哪个状态。每个状态都由一个清单定义，该清单与任何特定方法无关。该清单不衡量已执行哪些活动或已编写哪些文档，而是衡量实际结果。例如，“团队”阿尔法在“组建”状态下具有以下清单要素：招募到足够的成员、理解角色、理解如何工作等。因此，阿尔法与任何方法无关。
除了阿尔法之外，内核还有其他类型的元素，但它们不是理解本文讨论的关键。
2. 指定标准语言
为了能够重用现有的实践，实践不能以本土化的方式描述，即特定于使用它的方法。我们需要一种通用语言——一种通用语——一种具有语法和语义的形式语言。
与内核一样，期望的内容被表述为对语言的要求。例如：“该语言应为开发人员社区设计（不仅仅是流程工程师和学者）”，这是一个要求，要求在使用方法和实践时获得简单、可视化、直观且引人入胜的用户体验。借助图 3 中的语言，我们将能够描述实践，以便任何方法都可以重用它们。
语言和内核共同构成了一个共同的基础，这是我们软件工程多年来一直缺失的东西。2014 年，OMG（对象管理组织）将其采纳为标准，称为 Essence。4
3. 模块化方法
团队需要就什么是实践达成一致。例如，他们说：“实践是方法的一个独立关注点”；“每个实践，除非明确定义为持续活动，否则都有明确的开始和结束”；并且“每个实践都为其利益相关者带来定义的价值。” 团队设计的Method架构如图 4 所示。实践成为一等公民。
最底层的两层由 Essence 表示——语言和内核。第三层由使用 Essence 描述的实践组成，内核是标准词汇表。
4. 将实践从其方法中解放出来
方法的本质化意味着：（1）识别方法的（通常是隐藏的）实践；（2）将它们彼此分开（即使它们不是独立的）；（3）使用 Essence（内核和语言）描述每个实践；（4）构建和维护健全的实践架构（解决实践之间的依赖关系），以促进实践的灵活重组；以及（5）确保方法所有者同意本质化真正反映了他们的意图，或者修改直到满足此条件。对于显而易见的原因，后者是这项工作中最困难的部分。
本质化将实践从方法中解锁，并使它们可以自由选择和创建任何需要它们的方法。
5. 不再有方法论战争
按照本节中第 1-4 点提出的建议解决问题应大大减少方法论战争。战斗将不再是关于方法。相反，辩论将转向讨论哪些实践在特定情况下最合适。这才是应该进行战斗的地方——在各个学科的专家之间，就他们真正擅长的课题进行讨论。今天，战争的重点不太明确。没有必要创建具有自身价值观的新文化。讨论应邀请所有有话要说的人参加。
如何摆脱愚蠢的问题
从想法到有形结果是一个漫长的旅程。我们首先必须找到一个共同的基础。
Essence——软件工程的共同基础
为了回应“世界上最愚蠢的事情”，从众多问题中寻找逃生路线的工作于 2006 年在 IJI（Ivar Jacobson International）开始。2009 年，SEMAT（软件工程方法和理论）社区成立，2011 年，这项工作转移到 OMG，最终催生了软件工程中的一个标准共同基础，称为 Essence。4 Essence 于 2014 年成为被采纳的标准。因此，Essence 并非像宙斯眉头一皱那样突然出现，而是在 2010 年 SEMAT 创始人撰写的愿景声明的基础上精心设计的。
我们也受到了米开朗基罗的启发：“在每一块大理石中，我都看到一座雕像，它清晰可见，仿佛它就站在我面前，姿态和动作都塑造得完美无缺。我只需要凿掉囚禁这可爱幻影的粗糙墙壁，向其他人的眼睛揭示它，就像我的眼睛看到的那样。” 我们觉得，从所有这些方法的大量堆积中，我们必须找到本质，因此我们改述了米开朗基罗的话：“我们正在从整体的负担中解放本质。”
还有安托万·德·圣埃克苏佩里的名言：“当没有什么可以添加的时候，你就实现了完美，而是当没有什么可以拿走的时候。” 在决定内核中应该包含什么以及内核外部应该包含什么时，我们采取了一种非常保守的方法。向内核添加新元素比从中删除元素更容易。
使用 Essence
我们将通过展示在 Essence 之上描述的实践来展示 Essence 的用法，而不是给出 Essence 背后的完整理论，我们已经多次这样做1——使用 Essence 作为平台来呈现实践。我们选择了用户故事作为 Essence 实践的示例，这里称之为用户故事要点，如图 5 中的全貌所示。
此实践的流程如下
• 首先我们需要查找用户故事。此活动识别一个或多个用户故事，每个用户故事都记录在故事卡上，其中包含足够的信息以确保用户故事表达了其价值。
• 在逐个故事的基础上，我们将选择一个我们希望接下来完成的用户故事，然后我们使用“准备用户故事”活动使其为开发做好准备，其中还包括详细说明相关的测试用例。（请注意，我们使用约定，即用户故事阿尔法以轮廓形式出现在其后期阶段，以表明这不是一个新元素，而是与之前通过其状态相同的用户故事。）
• 此实践描述的最后一个活动是我们如何工作以接受用户故事，成功完成该活动后，用户故事就完成了。
我们的目的不是描述整个用户故事实践，而是提供对本质化实践外观的良好理解。
本质化的实践或方法是使用 Essence 描述的，Essence 将描述重点放在本质上。这并不意味着改变实践或方法的意图。本质化提供了重要的价值。我们作为一个社区可以创建许多来自不同方法的实践。团队可以混合和匹配来自多种方法的实践，以获得他们想要的方法。如果你对新实践有想法，你可以只专注于本质化该实践并使其可供其他人选择；你无需重新发明轮子来创建自己的方法。这会将该实践从单体方法中解放出来，它将打开方法论的牢笼，让公司和团队走向开放的世界。
用户故事实践在本质化后，以 14 张卡片的形式呈现。图 6 显示了一组具有代表性的五张卡片，此处简要描述如下。
用户故事要点（索引卡）
这提供了
• 简要描述，深入了解我们可能使用该实践的原因（好处）和时间（适用性）。
• 内容列表，显示实践中所有元素的命名实践元素图标（每个元素都用自己的卡片描述）。
请注意，颜色编码立即直观地指示了实践的应用范围。在本例中，我们看到该实践由以下内容组成
• 主要是黄色卡片，Essence 颜色编码表示解决方案关注领域——告诉我们此实践关注我们正在构建的软件系统及其需求。
• 一张绿色卡片，Essence 颜色编码表示客户关注领域——告诉我们该实践还关注我们如何与客户关注领域（如机会和利益相关者）进行交互。
• 没有蓝色卡片。Essence 有三个关注领域，第三个关注领域用蓝色编码，代表努力关注领域。“用户故事要点”实践在此领域中没有卡片。
另请注意，在本例中，“用户故事要点”解决的解决方案和客户关注领域与努力关注领域之间存在很强的关注点分离，努力关注领域包括团队以及我们如何管理工作等关注点。实际结果是，此实践可以与任何数量的不同管理实践一起使用，这些管理实践主要在蓝色努力关注领域中运行，例如时间盒 Scrum 风格的工作管理方法或持续流 Kanban 风格的方法。
本质化的实践可以以不同的详细程度描述。此实践中的卡片并未尝试提供新手团队成功应用该实践所需的所有信息。如果历史教会了我们什么，那就是
• 没有多少书面流程能够使新手在没有专家支持的情况下取得成功。
• 文字越多，任何人阅读它们的可能性就越小。
• 当涉及到更大量的详细支持指南时，与其“借用和重写”其他人的文字，不如简单地参考此指南的原始来源。
像这样的本质化实践基于以下原则：新手团队需要专家教练的支持才能成功。这些卡片成为专家教练用来帮助团队采用、调整和评估其团队实践的工具，或者供专家团队以相同方式使用的工具。
用户故事（阿尔法）
这是我们处理的关键事物，我们需要推进它，并且它的进展是项目的关键可跟踪状态指标——将阿尔法视为你期望在看板上流动的事物，具有
• 简要描述，清楚地说明这是什么以及它的用途。
• 项目所经历的一系列状态——在本例中，从“已识别”到“准备开发”，再到“已完成”。（将这些视为看板上的候选列——尽管团队可能希望根据其本地工作实践来表示其他临时状态。）
• 多个用户故事都与之相关的“父”内核阿尔法（在本例中为“需求”）。
故事卡（工作成果）
工作成果卡片提供了关于我们应该生成的真实物理事物的指导，以使基本信息可见——在本例中，用户故事方法的关键定义特征是我们使用非常有限的“房地产”，索引卡或电子等效物，作为捕获关于我们想要构建到软件系统中的内容的主要信息的机制。工作成果具有
• 简要描述。
• 我们逐步详细说明的详细程度——在本例中，指示我们最初确保我们已捕获并传达了用户故事的价值，并且我们还需要在某个阶段继续列出验收标准——第三级详细信息的虚线轮廓表示我们可能或可能不会捕获相关的对话——例如，如果我们是分布式团队，则在电子工具中。
• 工作成果描述的阿尔法——在本例中为用户故事。
查找用户故事（活动）
这为团队提供了关于他们实际应该做什么的指导，就（在本例中）而言
• 活动的描述。
• 活动成功执行所需的能力和能力水平的指示。例如，该卡片要求利益相关者代表能力达到 2 级，分析能力达到 1 级（所有这些都在 Essence 内核中定义）。
• 活动运行所在的活动空间的指示（即，“它帮助我们做什么样的事情”（在本例中为“理解需求”）。
• 活动的目的的指示，表示为它实现的目标状态——在本例中，用户故事被识别出来，并且生成了物理故事卡，其中描述了与用户故事相关的价值。
请注意，活动至关重要，因为没有活动，实际上什么也做不成；令人惊讶的是，许多传统方法用姿态和理论淹没了读者，而没有真正给他们他们需要的东西，即关于他们实际应该做什么的明确建议！
>客户团队（模式）
模式提供与其他元素和/或这些元素如何相互关联的支持性指导，就（在本例中）而言
• 文本描述，概括了模式提供的指导的关键方面。
• 命名关联，显示模式主要与哪个或其他元素相关——在本例中为用户故事。
• 指向资源卡上的命名参考的参考链接，该参考卡又提供了一个或多个指向更多指导或信息来源的指针。
将它们放在一起
我们现在描述了用户故事要点实践中使用的不同类型卡片的一个具有代表性的子集，因此我们将不再描述其他卡片，因为这个故事很快就会变得熟悉和重复。这是使用简单、标准语言来表达我们所有实践指导的一部分价值。
现在我们了解了所有卡片的含义，我们也需要从高层次上理解整个实践是如何运作的。卡片本身为我们提供了关于元素如何组合在一起以提供端到端故事的所有线索——哪些活动推进了哪些阿尔法并产生了哪些工作成果——但从端到端流程的角度讲述连接的故事也很有用，通过不同的活动。图 5 给出了实践流程的这样一个概述，我们在此重复并总结如下
• 首先我们需要查找用户故事。这将创建一个或多个处于初始“已识别”状态的用户故事，每个用户故事都记录在故事卡上，其中包含足够的信息以确保用户故事表达了其价值。
• 在逐个故事的基础上，我们将选择一个我们希望接下来完成的用户故事，并使用“准备用户故事”活动将用户故事推进到“准备开发”状态。这包括确保我们在故事卡上列出了验收标准，在此期间我们可能还会捕获任何支持对话。作为同一活动的一部分，我们还详细说明了相关的测试用例。
• 此实践描述的最后一个活动是我们如何工作以接受用户故事，成功完成该活动后，用户故事将移动到“已完成”状态。
请注意，这种活动链，主要通过它们推进的事物的状态，并不过度约束整体流程。例如，它并不意味着单程、严格的顺序流程。我们可能会以不同的方式迭代不同用户故事的不同活动。我们具体如何做可能会作为采用其他实践的一部分而受到进一步约束。例如，如果我们像非常常见的那样，将用户故事实践与 Scrum 结合使用，我们可能会同意以下一般规则作为团队
• 在我们开始第一个 Sprint 之前执行“查找用户故事”活动，但也允许这种情况持续临时发生。
• 在第一个 Sprint 之前以及在每个 Sprint 期间，为下一个 Sprint 的用户故事执行“准备用户故事”活动，以便及时进行 Sprint 计划。
• 目标是在用户故事完成后立即接受用户故事，以便在 Sprint 评审结束之前完成为 Sprint 选择的所有用户故事。
Essence 区分了健康和进展的要素与文档要素。前者称为阿尔法，后者称为工作成果。
每个阿尔法都有一个生命周期，从一个阿尔法状态移动到另一个阿尔法状态。工作成果是描述阿尔法并为其阿尔法状态提供证据的有形事物；它们是实践者在进行软件工程活动时产生的东西，例如需求规范、设计模型、代码等等。需要活动才能实现任何目标，包括推进阿尔法和生成或更新工作成果。活动空间组织活动。要进行活动，需要特定的能力。模式是典型问题的解决方案。模式的一个示例是角色，它是概述工作职责问题的解决方案。
Essence 在仅定义通用标准“共同基础”时，不定义工作成果、活动或模式，因为这些都依赖于实践。它定义了七个阿尔法，每个阿尔法都具有定义的状态、15 个活动空间和六种能力，所有这些都与实践无关。在 Essence 之上定义的实践引入了标准内核元素类型的新元素或子类型。
本质化实践的关键特征和优势
用户故事要点示例说明的本质化实践的一些关键特征和优势是
• 该实践范围很窄。它告诉我们如何做好一件事。特别是，该实践不会约束或限制我们关于我们可能想要使用以处理我们努力的其他方面的其他实践（Scrum、Kanban 等）的任何其他选择。
• 该实践以简洁的方式表达。用户故事要点示例中仅显示了卡片的子集，但实际上，实践中的卡片总共大约相当于一张 A4 纸的大小。
• 该实践是可访问的，并且可以通过卡片进行交互，卡片以各种方式使用。这包括使团队的工作方式立即可见，自我评估本地实践的充分性，以及确定改进领域的优先级。
• 该实践以简单、标准的方式表达。当你理解用户故事要点中的这四张卡片时，就没有任何障碍可以理解来自任何其他来源的任何其他本质化实践。仅仅因为你喜欢这个用户故事实践，你现在就不会被囚禁在其方法论的牢笼中。相反，你可以自由地在开放市场上漫游，从任何其他来源选择任何其他实践。
• 该实践是根据 Essence 标准内核描述的，从而确保它以明确定义的方式与任何其他本质化实践互操作。
• 同样的事实使任何实践的范围和覆盖范围都可以立即评估。我们的实践将活动添加到 Essence 内核活动空间“理解需求”和“测试系统”中，但没有添加到 Essence 内核概述的其他 13 个活动空间（“实施系统”、“部署系统”等）中。因此，如果这是我们采用的唯一实践，那么很明显，我们没有就如何做其他事情达成一致或定义的方式。这可能不是问题，但至少这是一个清晰可见的事实。
• 该实践包含所有要点。如果你没有以某种形式按照这些要点工作，那么你就不能合理地声称自己正在将用户故事要点作为一种实践来做。
我们做什么
Essence 共同基础已获得行业和学术界的认可。
富士通英国公司和慕尼黑再保险公司多年来一直在使用 Essence，并为其发展做出了贡献。世界上一些最大和最负盛名的公司正在走向本质化——例如，塔塔咨询服务公司、红帽公司和东亚一家主要的电信供应商。与 Scrum 的共同创始人 Jeff Sutherland 合作，Scrum 已经本质化。同样，与 Scott Ambler 合作，DAD（学科敏捷交付）的关键实践正在被本质化。
在学术方面，我们引用 Pekka Abrahamsson 教授（NUST）的话：“……我们已成功地在软件工程课程中向 460 名学生教授了 Essence……Essence 使学生能够控制他们的项目、工作方法和实践。我们终于超越了 Scrum 和 Kanban……我未来的软件工程教育将由 Essence 驱动。”
世界各地的大学已经在某种程度上教授 Essence（例如，卡内基梅隆大学西部、佛罗里达大西洋大学、哥本哈根、奥斯陆、斯德哥尔摩、维也纳、首尔、北京、约翰内斯堡、麦德林、圣保罗、墨西哥城、圣彼得堡、惠灵顿）。一个名为“面向一年级学生的软件工程本质化”的项目于近三年前启动，并催生了一本同名新书，即将出版。该项目吸引了全球 50 多位大学教师的参与，其中 25 位以上是活跃的。
反思
当我们表现得更像时尚行业而不是工程专业时，我们真的能够启用和授权我们的团队并成为真正的学习型组织吗？当我们不断攻击彼此，并像老嬉皮士试图与时尚潮流保持同步一样，不断地重塑品牌、重新发明和重命名一切时，我们真的能把自己看作是一个开放、多元化和协作的社区吗？我们是否注定要被锁定在永无止境的方法论战争中，并希望出现一种真正的方法来统治一切？
答案当然是否定的。通过本质化当今存在的最有趣的方法并解放实践，实践的生态系统将使我们能够创建我们需要的方法——也包括现在已经存在的优秀方法——并在新的或改进的实践可用时升级这些方法。
我们有理由抱有很高的期望。早期证据表明，团队将能够更快地学习并快速上手。项目可以独立于他们使用的方法来衡量努力的进展和健康状况。人们将获得一种跨产品线使用的通用语言。最重要的是，采用 Essence 的组织有望成为永久学习型组织，并将从主要依靠软件开发作为一种技能转向成为一门工程学科。2,3
似乎这还不够，基于系统工程专家的浓厚兴趣，特别是来自INCOSE（国际系统工程委员会）社区几位关键领导者（如 Bud Lawson）的兴趣，已经有关于如何修改 Essence 内核的提议，使其也能支持系统工程实践。 为什么不将实践应用于任何人类活动呢？
参考文献
1. Jacobson, I., Ng, P.-W., McMahon, P. E., Spence, I., Lidman, S. 2012. 软件工程的本质：SEMAT 内核。acmqueue 10 (10); https://queue.org.cn/detail.cfm?id=2389616.
2. Jacobson, I., Seidewitz, E. 2014. 一种新的软件工程。acmqueue 12 (10); https://dl.acm.org/citation.cfm?id=2693160.
3. Jacobson, I., Spence, I., Seidewitz, E. 2016. 工业规模的敏捷：从手工艺到工程。acmqueue 14 (5); https://queue.org.cn/detail.cfm?id=3012428.
4. 对象管理组织。2014. Essence—软件工程方法的核心和语言； http://www.omg.org/spec/Essence/.
相关文章
与 Steve Bourne、Eric Allman 和 Bryan Cantrill 的对话
三位 Queue 编辑委员会成员讨论 XP 和敏捷，以及软件工程的实践。
第 1 部分： https://queue.org.cn/detail.cfm?id=1413258
第 2 部分： https://queue.org.cn/detail.cfm?id=1454460
打破主要版本发布的习惯
敏捷开发能让你的团队更有效率吗？
Damon Poole
https://queue.org.cn/detail.cfm?id=1165768
这是 Foo 字段
比特的意义和避免升级瓶颈
Kode Vicious
https://queue.org.cn/detail.cfm?id=2566971
Ivar Jacobson 获得了瑞典皇家理工学院（KTH Royal Institute of Technology）计算机科学博士学位，2003 年获得查尔姆斯理工大学（Chalmers）颁发的 Gustaf Dalén 奖章，并于 2009 年在秘鲁圣马丁德波雷斯大学（San Martin de Porres University）获得荣誉博士学位。他同时拥有学术和工业职业生涯。他撰写了 10 本书，发表了 100 多篇论文，并且是世界各地会议的常任主题演讲嘉宾。他是组件和组件架构之父，这项工作被爱立信公司采用，并促成了瑞典历史上最伟大的商业成功故事，至今依然如此。他是用例和 Objectory 之父，在 1995 年 Rational Software 公司被收购后，Objectory 促成了 Rational 统一过程（Rational Unified Process），这是一种被广泛采用的方法。他也是 UML（统一建模语言）的三位原始开发者之一。 但所有这一切都已成为历史。Jacobson 创立了他目前的 Ivar Jacobson International 公司，该公司自 2004 年以来一直专注于以智能、超轻量级和敏捷的方式使用方法和工具。这项工作使 Jacobson 成为全球网络 SEMAT 的创始人和领导者，SEMAT 的使命是基于软件工程内核彻底革新软件开发。该内核已实现为名为 Essence 的正式标准，这是本文描述的关键思想。
Roly Stimson 是 IJI (Ivar Jacobson International) 的首席顾问，在将软件方法应用于复杂开发挑战方面拥有 30 多年的经验。在过去的 15 年中，他一直参与迭代、增量、精益和敏捷方法。他为 IJI 基于内核的 EssUP 实践、SEMAT 的 OMG Essence 标准以及 IJI 基于 Essence 的 Agile Essentials 和 Agile at Scale 实践的开发做出了贡献。
版权 © 2018 归所有者/作者所有。出版权已许可给 。
最初发表于 Queue vol. 16, 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 - 用例至关重要
虽然软件行业是一个快节奏且令人兴奋的世界，新的工具、技术和技巧不断被开发出来以服务于商业和社会，但它也是健忘的。在其快速前进的匆忙中，它容易受到时尚的 whims 的影响，并且可能会忘记或忽略某些它面临的永恒问题的经过验证的解决方案。用例，最早于 1986 年引入并在之后普及，就是这些经过验证的解决方案之一。
© 保留所有权利。