逃避方法论的监狱 - Ivar Jacobson

50多年来，全世界都在开发软件。软件几乎改变了我们生活的方方面面，所以我们离不开它。因此，软件业一直非常成功。我们可以选择快乐并继续做我们正在做的事情。
然而，表面上一切都不是那么美好：太多失败的努力，所有领域的质量一般都太低，成本太高，速度太低等等。显然，我们需要有更好的工作方式，或者我们需要更好的方法。

这不是一个新观察。在这50多年的时间里，我们一直在寻找更好的方法。在某些方面，我们开发软件的方法随着时间的推移发生了巨大的变化，在其他方面它们保持不变。作为一个行业，我们遵循从一个范式到另外一个范式，从一个方法到另外一个方法的曲折道路，非常像时装业的变化激发衣柜的变化。采用每种新方法通常都是非常昂贵，令人沮丧的事情。它很昂贵，因为它意味着重新培训软件开发人员，团队及其领导者。在某些情况下，甚至可能必须重写现有软件，以便更有效地使用新软件。它令人沮丧，因为更有经验的开发人员认为他们必须重新学习他们已经知道的东西。

公司，尤其是大公司，意识到一种好的方法可以提供竞争优势 - 即使它不是您需要的唯一产品。他们还意识到必须解释和明确他们的方法，以便可以在整个组织中一致地应用它们。而且，他们意识到一种尺寸并不适合他们所做的一切 - 他们需要多种方法。

1.什么是方法监狱
让我们看一下用于扩展敏捷的四种最著名的方法（称为方法框架）：Scaled Agile Framework（SAFe），Scaled Professional Scrum（SPS），Disciplined Agile Delivery（DAD）和Large Scrum（LeSS） 。

它们都受到世界各地组织的欢迎和使用。它们以重叠的方式和特定的方式为其用户组织提供价值。重叠意味着它们包含相同的实践，具体意味着它们具有一些可以产生差异的特殊实践。如果组织采用这些方法中的一种，则其用户通常不了解其他替代方案。

那么问题是什么？
它们都是单片的 - 非模块化的。

大多数方法（不仅仅是这里讨论的四个方法）是单片的，意味着它们不是以模块化方式设计的。这意味着您无法轻松地将一个模块与另一个模块交换，并保持其他模块不变。

相反，我们想要的是一个可重用模块库，随着用户学习越来越多而不断更新。由于每种方法都只是实践的组合，我们需要可重用的实践。团队和团队团队应该能够通过混合和匹配他们想要从库中使用的实践并将它们组合在一起，轻松地就自己的方法达成一致。

2.     他们有自己独立的演讲风格。
每种方法都有其独特的特定结构，并使用自己的风格和术语来描述其选择的实践。该方法的所有者已经为自己决定了这些重要方面，而没有遵循任何标准。因此，其实践与其他方法的实践不相容。

3.     他们有很多共同点-但是隐藏的。
此外，尽管每种方法都有一些独特的实践，但它与其他方法有很多共同之处。每种方法都“借用”其他方法的实践并“改进”它们。因此，常见的是隐藏在新术语和“新”功能背后。我们使用引号来表明它并不是真正的“借用”，它并不总是“改进”，但由于对原始实践的误解或重新解释，它常常变成原始的变态或混淆。同样地，“新”特征通常不是全新的，而是用于演变或改变先前存在的实践的新名称（“装旧酒的新瓶”）。

4.     每一个方法是有一个控制监狱长 - 大师
Master决怎么做，并在某些情况下，扩展实践，并“借用”其他方法“改良”的方法。该方法反映了其大师的特殊观点，偏见和经验，而不是我们作为发展社区共同学习的内容。方法应该重用团队或组织针对其特定挑战和目的考虑的最佳实践，而不是独立于这些考虑因素的单个大师选择的那些方法。

5.     每种方法都有品牌标识，通常是商标和版权。
如果其用户喜欢其他方法的做法，则被迫“借用”这些做法并“改进”可能被重复使用的内容。相反，这种工作方式并不能激发与其他大师的合作。鉴于这些其他方法的大师对时间和资本的投入，他们必须以狂热的决心捍卫他们的地盘，导致方法战争。

因此，采用一种方法 - 已发布或自行开发 - 意味着你会被一块巨石所困，它以其独特的风格，使用许多常见的但却不知道的做法，由一位为其方法打上烙印的大师守卫使其难以重复使用。您的方法无法轻松地重用全局实践库中的实践。相反，你陷入了一个方法监狱。
你一直坚持跟随你的方法大师决定事情。在这里要清楚，我们并不是说大师们有意识地试图让你进入方法监狱; 他们只是继续做我们作为一个行业自我们起源以来所做的事情，因为我们不知道更好的事情。

因此，一旦你采用了一种方法，你就处于由该方法的大师控制的方法监狱中。Ivar Jacobson是本文的作者之一，他曾经是统一流程监狱的大师之一。他意识到这是“世界上最愚蠢的事情”（当然还有软件世界），它不值得任何行业，特别是像软件行业这样庞大的行业。最近其他人也表达了类似的想法。

作为软件专业人士，我们需要制止这种荒谬的发展。我们希望具有创造性实践想法的人们进行协作，并共同为全世界提供可重复使用的实践库。我们希望他们为整个行业服务，而不是被迫创建品牌方法。 

2.方法和方法监狱的历史
曾几何时，我们有大量不同的符号来描述软件工程中的元素。然后我们在1997年获得了统一建模语言（UML）标准，并且所有这些不同的符号都被一个标准所取代 - 符号战结束了。符号只是方法的一个方面，因此我们需要一个类似的方法用于方法的所有其他方面，这是一种允许方法所需的所有多样性的标准。
软件行业遵循从范式到范式以及从方法到方法的曲折路径。

1. 随着每一个主要的范式转变，例如从结构化方法转向对象方法，从后者转向敏捷方法，基本上整个行业都抛弃了他们对软件开发的几乎所有知识，并重新开始，新的与旧的术语。旧的做法被视为垃圾，新的做法被炒作。通过培训，指导和工具的形式，使软件行业从旧到新的转变成本极高。
2. 随着每一项重大的新技术趋势，例如面向服务的架构，大数据，云计算，物联网，方法作者也“重新发明轮子”。他们创造了新的术语和新的实践，即使他们可以重用现有的术语。成本不像前一点那么大，因为有些变化并不是我们所做的一切都是根本性的，因此影响仅限于云开发，但仍然存在重大而愚蠢的浪费。

从早期计算中使用的临时方法来看，瀑布方法就出现了。发表了数百篇。一些最流行的是结构化分析和设计技术（SADT），结构化分析/结构化设计（SA / SD）和信息工程（IE）。他们从1960年到2000年都有他们的伟大。

瀑布方法受到建筑项目管理实践的严重影响 - 口头禅是“找到建立像土木工程师建立桥梁的软件的方法”。他们将软件开发项目描述为经历了诸如需求，设计，实现（编码）和验证（即测试和错误修复）等多个阶段。 

在2000年左右，它们越来越多地被最近由Barry Boehm的软件开发和增强的螺旋模型引入的迭代方法以及诸如RUP和DSDM之类的方法所取代，后来通过XP和Scrum等敏捷实践进行了简化和进一步推广。前面介绍的所有四种方法，SAFe，SPS，DAD和LeSS都应用了迭代生命周期。 

当然，所有不同的方法都伴随着方法监狱，我们依靠大师并使方法战争永久化。

我们在软件工程方面有三个主要时代（年份只是近似值）：

• 1960-1980：结构化方法时代，
• 1980-2000：对象方法时代，
• 2000年 - 现在：敏捷方法时代

结构化方法时代
在这个时代，最流行的方法，如（例如SADT，SA / DT，IE），都将功能过程逻辑与数据设计分开。他们之所以这么做是因为当时有很好的理由 - 因为当时的计算机设计与此完全相同 - 具有独立的程序逻辑和数据存储结构。它们被用于各种软件开发 - 包括“数据处理”和“实时”系统，遵循当时的通用说法。功能/数据方法的价值当然是设计的接近实现 - 到机器 - 你编写的程序与你设计数据的方式分开。这些系统难以开发，甚至更难以安全地更换，并成为这一代方法的“致命弱点”。 

对象方法时代
下一个范式转变发生在20世纪80年代早期，受到一种新的编程隐喻的启发 - 面向对象的编程，由一种新的编程语言Smalltalk触发。Smalltalk背后的关键思想更为古老，已于1967年得到Simula的支持。大约在1990年，对物体概念的补充得到了广泛接受。具有良好定义的接口的组件可以连接到构建系统，成为一种新的广泛接受的架构风格。组件仍然是大多数现代方法背后​​的主要隐喻。
通过对象和组件，一系列全新的方法得以发展。旧的方法和他们的做法被认为是时尚和抛弃。在许多情况下，进入的是类似的做法，但有一些显着的差异，但是有了新的术语，因此几乎不可能追溯到他们的祖先。一种新的时尚诞生了。在20世纪90年代早期，出版了大约30种不同的面向对象方法。它们有很多共同之处，但由于每个方法作者都创建了自己的术语和图像，因此几乎不可能找到共性。
在20世纪90年代后半期，对象管理组（OMG - 见omg.org）认为，现在是时候至少要标准化如何表示软件的图纸 - 用于开发软件的符号。这导致创建了一个特别工作组来推动这一新标准的发展。这项工作产生了统一建模语言（UML）。这基本上杀死了除Unified Process（以Rational Unified Process（RUP）名义销售）之外的所有其他方法; 统一过程在2000年左右统治了软件开发世界。这又是一个令人沮丧的步骤，因为除了一些统一过程实践之外，许多其他方法都有非常有趣和有价值的实践。然而，统一流程变得时尚，其他一切都被认为已过时，而且或多或少被抛弃了。是的，这是多么愚蠢。

敏捷方法时代
敏捷运动 - 通常被称为“敏捷” - 现在是软件开发中最受欢迎的趋势，并被全世界所接受。敏捷运动将重点从技术实践上转移开来，将团队，工作和人员放在首位和中心位置。 
虽然听起来很奇怪，但在之前的时代采用的方法并没有过多关注人为因素。当然，每个人都理解该软件是由人们开发的，但很少有关于如何让人们在开发优秀软件方面获得积极性和能力的书籍。最成功的方法书在这个主题上非常沉默。基本上假设这是管理层的任务。随着敏捷，许多新人的实践开始发挥作用，例如自组织团队，结对编程，每日站立。
鉴于敏捷对程序员赋权的影响，很容易理解敏捷已经变得非常受欢迎并且是最新的趋势。此外，鉴于敏捷对我们软件开发的积极影响，毫无疑问它应该成为最新趋势。而且，虽然一些敏捷实践将被其他更好的实践所取代，但敏捷作为一种哲学和态度并不是一种会消失的时尚。在可预见的未来，它将与我们同在。

虽然不同的时代已经贡献了知识和经验，并且其中很多都是针对每个时代的，但它们都导致了由少数大师控制的方法战争的延续。

3.如何逃脱方法监狱
大多数方法包括（或暗示）生命周期，技术实践和人员实践有一些共同点。然而，这是隐藏的并且不容易被发现，因为不同的大师使用不同的词汇和语言来描述这些事物。因此，我们寻找的共同点包括词汇和语言。我们将词汇称为内核，将语言称为内核语言。

共同点=内核+语言=本质

从内核开始
鉴于内核旨在帮助描述方法和实践，它需要包含在任何方法中始终普遍存在或应该被视为“事物”。从本质上讲，我们始终拥有的东西，在开发软件时总能做到并始终产生。

在2009年，SEMAT社区成立，其任务是“重新发现软件工程...... [1]包含广泛认可的元素内核，这些元素可以针对特定用途进行扩展”，我们SEMAT志愿者团队（来自世界各地的约20人）与内核合作，同意这些事情称为普遍性应该是“适用的，无论开发中的软件的大小或规模，以及参与开发的团队的规模，规模或风格”。“从本质上讲，它提供了一个独立的实践框架，用于思考和推理我们所拥有的实践和我们需要的实践。内核的目标是建立对软件开发核心内容的共同理解。“  

作为2010年寻找核心工作的输入，SEMAT的三位创始人（Ivar Jacobson，Bertrand Meyer和Richard Soley）撰写了一份愿景声明。我们三个人都明白，找到内核需要遵循标准和原则。我们首先就内容中包含元素的一些标准达成一致。

要素应该是：普遍的，重要的，相关的，确切的，可操作的，可评估的和全面的。  

相关内容被解释为“所有软件工程师都可以使用，无论背景和方法阵营（如果有的话）”，并且“ 全面地”适用于内核元素的收集; 他们必须共同掌握软件工程的本质，提供支持软件工程团队关键实践，模式和方法的地图“。

我们还确定了以下被认为对于查找内核至关重要的一般原则：质量，简单性，理论，现实性和可扩展性，理由，可证伪性，前瞻性观点，模块性和自我改进。

理论意味着“内核必须依靠坚实，严谨的理论基础”，现实性和可扩展性“内核应适用于实际项目，包括大型项目，并尽可能基于成熟的技术”，自我改进 “内核应该是伴随着促进其自身发展的机制“。

此外，愿景声明还阐述了内核应具备的功能：实践独立性，生命周期独立性， 语言独立性， 简洁 性， 可扩展性，可扩展性和正式指定。可扩展性得到解释，因为内核必须支持最小的项目 - 一个人为一个客户开发一个系统 - 它还必须支持最大的项目，其中可能有系统系统，团队团队和项目-of项目。  可扩展意味着内核需要具备添加实践，细节和覆盖范围的能力，以及添加生命周期管理和定制内核本身以使其特定于域或将软件开发工作集成到更大的工作中。

根据这些标准，原则和功能SEMAT团队着手寻找内核。(banq注：从哲学上看，现象就是本质，内核是否存在还没有经过论证，就开始寻找内核了)

其次是语言
为了解释内核中的普遍性以及实践和方法，我们需要一种语言。仅仅使用英语并不够精确，所以我们需要有一种语法和语义的形式语言。
该语言必须为其主要用户设计，他们是参与软件开发工作的专业软件开发人员。该语言还必须允许有能力的从业者创建和改进实践，而无需学习高级语言。  
该语言应支持四个主要应用程序：描述，模拟，应用和评估。“国家概念可能在核心语言中发挥重要作用，代表工作进展。”

同样的愿景陈述对语言提出了相当具体的要求。例如“语言应该为开发人员社区（不仅仅是流程工程师和学者）设计”，这是一个重要的要求，要求在使用方法时提供比现在更加直观和更具吸引力的用户体验。另一个要求的例子是语言必须提供“验证机制，以便有可能评估声称应用给定方法元素的项目是否真正做到了，而不仅仅是对它进行口头服务。”

我们需要的不仅仅是内核 - 我们需要实践和方法
内核和内核语言的作用将用于描述具有共同点的实践和方法。为了实现这一目标，必须在描述大量方法时应用一个有用的共同点。我们需要就实践和模式是什么达成一致。我们举例说：“一种做法是一种方法的独立问题。例子是......迭代开发，基于组件的开发“，”每个实践，除非明确定义为连续活动，否则具有明确的开始和结束“和”每个实践为其利益相关者带来定义的价值“。
凭借这些原则，价值观和要求，SEMAT团队已经清楚了解逃离方法监狱需要什么。
(banq注：难道让大家跟着SEMAT团队逃离方法监狱，进入你的布袋吗？)

4.如何逃离方法监狱
从想法到有形的结果是很长的路要走。我们首先必须达成共识。

本质 - 软件工程的共同点
作为对“世界上最愚蠢的事情”的回应，2006年在Ivar Jacobson International（IJI）开始了关于方法监狱逃生路线的工作。2009年，SEMAT社区成立，并于2011年将工作转移到OMG，最终在软件工程中产生了一个名为Essence的标准共同点

Essence在2014年成为采用的标准。因此，Essence并非像“宙斯的眉头”那样闪光，而是根据愿景声明精心设计的。

使用Essence
我们将通过呈现在Essence之上描述的实践来展示其用法，而不是将整个理论置于Essence之后 - 使用Essence作为展示实践的平台。 

我们选择将用户故事描述为Essence实践的一个示例 - 在此处将其命名为User Story Essentials。下面的图2显示了（不详细阅读）14张卡片的集合，这些卡片代表了练习的标题要点。

我们不打算在这里描述整个练习，而是让您对基本练习的外观有一个很好的理解。
因此，我们选择了下面简要描述的一组代表性卡片。  

（1）用户故事要点User Story Essentials（概述卡） - 概述了以下方面的做法：

• 简要说明，让我们深入了解为什么（好处）和何时（适用性）我们可能会使用这种做法
• 内容列表 - 显示练习中所有元素的命名练习元素图标（每个元素都用自己的卡描述）。

请注意，颜色编码可以直接显示实践的应用范围 - 在这种情况下，我们看到的做法是：

• 主要是黄卡 - 解决方案领域的Essence颜色编码 - 告诉我们这种做法与我们正在构建的软件系统和/或其要求有关。
• 一张绿卡 - 关注客户领域的Essence颜色编码 - 告诉我们这种做法也关注我们如何与商业/客户领域的关注，如机会和利益相关者。
• Zero Blue蓝卡片 - Essence有三个关注点，第三个颜色用蓝色代表Endeavour区域。User Story Essentials练习在此区域没有卡片。

另请注意，在这种情况下，解决方案和客户关注点之间存在强烈的关注点，即用户故事要点解决的问题和Endeavour空间，其中包括团队和我们如何管理工作等问题。实际影响是，这种做法用于主要在蓝色Endeavour空间中运行的不同管理实践，例如时间框，Scrum风格的工作管理方法或连续流程，看板式方法。

（2）客户团队Customer Team（模式卡） - 模式提供与其他元素相关的支持指导和/或这些元素如何相互关联：

• 文本描述 - 封装模式提供的指导的关键方面。
• 命名关联 - 显示模式主要与哪些其他元素相关 - 在本例中为User Story元素。
• 参考链接 - 参考资源卡上的命名参考 - 它反过来提供一个或多个指向更多指导或信息来源的指针。资源卡是图2中描述实践的14张卡之一。

• 没有专家支持，任何书面流程都无法使新手成功。
• 语言越多，阅读其中任何一个的可能性就越小。
• 在涉及更详细的详细支持指导时，不要“借用和重写”其他人的话，最好简单地参考本指南的原始来源。

像这样的基本实践的工作原则是新手团队需要专家教练的支持才能获得成功。这些卡片成为专家教练的工具，用于帮助团队采用，调整和评估他们的团队实践，或者让专家团队以相同的方式使用。

(3)查找用户故事（活动卡） - 根据（在这种情况下）指导团队实际应该做的事情：

• 活动的描述。
• 表示我们成功执行活动所需的能力和能力水平。例如，该卡需要第2级的利益相关者代表能力和第1级的分析能力（所有这些都在Essence内核中定义，并且可以立即从电子可浏览的HTML和卡中钻取）
• 活动所处空间的指示 - 即“它帮助我们做什么”（通用内核“活动空间” - 在这种情况下“了解要求”）
• 表示活动目的的表示为它实现的最终状态 - 在这种情况下，识别用户故事并生成表达与用户故事相关联的值的物理故事卡。

(4)用户故事（Alpha） - 我们合作的一个关键因素，我们需要进步，并且其进展是项目的关键可跟踪状态指示器 - 您可以将Alpha视为您希望看到的东西看板，在这里描述：

• 一个简短的描述，清楚地说明了这个东西是什么以及它用于什么。
• 项目进展的一系列状态 - 在这种情况下，从通过准备开发到完成来识别。（将这些视为看板委员会的候选专栏 - 尽管团队可能也希望代表其他临时状态，具体取决于他们当地的工作实践）。
• 多个用户故事都涉及的“父”（内核）Alpha（本例中的要求）。

• 简要说明。
• 我们逐步详细阐述的细节层次 - 在这种情况下表明我们最初确保已经捕获并传达了相关价值，并且我们还需要在某个阶段继续列出验收标准 - 第三个虚线轮廓详细程度表明我们可能会或可能不会捕获关联的对话 - 例如，如果我们是分布式团队，则在电子工具中。
• 工作产品描述的Alpha - 在这种情况下的用户故事。

把它们放在一起
我们现在已经描述了用户故事要素练习中使用的不同类型卡片的代表性子集，因此我们不会描述其他卡片，因为故事会很快变得熟悉和重复。
现在我们了解所有卡片的含义，我们还需要从高层次了解整个练习的工作原理。卡片本身为我们提供了所有关于元素如何组合在一起以提供端到端故事所需的线索 - 哪些活动可以进展并产生哪些元素，但是用这些术语来讲述联合故事也很有用。通过不同的活动进行端到端的流程。

• 首先，我们需要查找用户故事。这会在初始识别状态中生成一个或多个用户故事，每个用户故事都由故事卡记录，其中包含足够的信息以确保用户故事的值已表达。(banq注：寻找需求，通过角色扮演等方式)
• 在逐个故事的基础上，我们将选择我们希望接下来完成的用户故事，并使用准备用户故事活动来推进用户故事以便开发，这涉及确保我们有接受在故事卡上列出的标准，在此期间我们也可以获得任何支持对话的捕获。作为同一活动的一部分，我们还充分阐述了相关的测试用例。
• 此练习描述的最后一项活动是我们如何努力接受用户故事，成功完成将用户故事移至完成状态。

我们可能以不同的方式围绕不同用户故事的不同活动进行迭代。例如，如果我们将用户故事练习与Scrum结合使用，这是非常常见的，我们可能会将以下一般规则作为一个团队达成一致：

• 在我们开始第一次Sprint之前查找用户故事，但也允许在临时基础上进行此操作。
• 在第一个Sprint之前准备用户故事活动，然后在Sprint规划期间为每个Sprint准备下一个Sprint的用户故事。
• 目标是在完成后立即接受用户故事，以便在Sprint Review结束之前为Sprint完成选择所有用户故事。

• 这种做法是严格限制的 - 它告诉我们如何做好一件事，并且在涉及我们想要在其他空间（Scrum，Kanban，......）中使用的其他实践时，不会限制或限制我们的任何其他选择。
• 这种做法非常简洁 - 它在上面的图形中有点压缩，但是实践中的卡片大致相当于A4的一面。
• 这种做法是可以访问的，并且可以与之交互 - 卡片以各种方式使用 - 包括使注释团队的工作方式立即可见，自我评估当地实践的充分性和优先改进领域。
• 这种做法以简单，标准的方式表达 - 现在您了解了User Essentials中的这4张卡片，从任何其他来源理解任何其他Essence练习都没有障碍 - 只因为您喜欢这个用户故事练习，您现在不是在其方法监狱中被俘 - 您可以自由地在公开市场上漫游，从任何其他来源选择任何其他做法。
• 该实践“插入”Essence标准内核，从而确保它以明确定义的方式与任何其他基本实践互操作。
• 同样的事实可以立即评估任何实践的范围和覆盖范围（我们的实践将活动添加到Essence内核活动空间“理解需求”和“测试系统”中，但不会对Essence概述的其他13个活动空间添加任何内容内核（“实施系统”，“部署系统”，......） - 所以如果这是我们采用的唯一做法，很明显我们没有商定或定义的方式来做这些其他事情（可能是也可能不是一个问题，但是是清晰可见的事实...）。
• 它包含所有必需品 - 你可能会或可能不会做很多其他事情，但是如果你不是以这种方式做这些事情（或者是本地修改的等价物，或者可能明确地没有明确地做一个特定的方面理解和明确的理由）那么你可以合理地声称自己在做“用户故事”吗？

5.离开方法监狱
许多公司现在正在对其现有方法进行本质化。例如，用塔塔咨询服务公司（TCS）的话说：“TCS已与其所有核心行业合作伙伴（如SAP，甲骨文，微软和其他公司）以及TCS的客户合作，并正在与这些公司的核心方法团队合作。帮助促进Essence标准的协作采用，并将这种非法标准转变为事实上的标准。“
这些公司在实践库中获得可重用的实践。团队和组织能够混合和匹配不同方法的实践，并创建自己的工作方式。今天，我们相信在Essence之上描述了大约一百种做法。Ivar Jacobson International已经开发了大约50种实践，并在https://practicelibrary.ivarjacobson.com的实践库中提供了25种实践。 
那些公司正在退出方法监狱。他们不再依赖大师了。他们不会沿着曲折的道路前行，但他们期望可持续发展。方法战争结束了。然而，退出方法监狱并不是他们所期望的全部。他们有更高的抱负。他们正走在工业规模敏捷的道路上 - 将软件开发从主要是工艺转变为主要是工程学科，但在软件开发和使用方法方面仍然敏捷。 
为了取得成功，我们仍将依靠我们授权团队的工艺，但这将以编码工程实践的共享基础为基础，可以在不同的技术领域和项目类型的不同排列和组合中重复使用。这将使我们能够在所有项目中始终如一地保持高水平的工艺，并通过未来的挑战和变化无限期地维持这一点。
我们还需要一个支持组织，其学习文化对新想法开放，并且对实验很满意。讨论这个问题超出了本文的范围，但我们参考已发表的论文（见[8] - [10]）。
精华也在学术界取得进展。世界各地的大学都在不同程度上教授精华。来自Pekka Abrahamsson教授的话，“在斯堪的纳维亚最大的技术大学之一，挪威科技大学在特隆赫姆，2017年春天，我们成功地向460名学生讲授了软件工程专业课程。...精华赋权学生们可以控制他们的项目，工作方法和实践。我们终于超越了Scrum和看板....数据和结果让我信服，因此我未来的软件工程教育将由Essence推动。“ 
也许转向Essence是这些公司和大学“世界上最聪明的事”。