“ 最好的架构、需求和设计来自自组织团队。 ”—— 敏捷宣言背后的原则
我跟随许多人的脚步，他们长期以来一直对这些简单词语的含义感到疑惑，就好像它们是来自高处的教条。 出现 ？ 自组织 ？深刻的，可以肯定的。但是我们真正理解这句话是什么意思呢？
首先让我在整个教条的事情上泼水。敏捷宣言及其原则的全部要点是
不要
对我们如何构建好的软件教条主义。所以我真的不在乎那些受人尊敬的工匠们所说的
涌现
和
自组织
究竟意味着什么。
相反，我真正关心的是如何帮助我们的组织实现他们的目标——尤其是如何变得更加敏捷。可以肯定的是，构建出色的软件是这个故事的一部分。碰巧的是， 涌现 和 自组织 是可以推动我们前进的基本原则，尤其是在许多企业都在努力进行数字化转型的情况下。
涌现 的概念出现了
让我们从 emergement 及其动词形式 to emerge 的令人惊讶的多方面定义开始。词典定义emerge是 通过进化形成的；从中升起，出现在视野中。 所以马上我们就有了几个相关的概念。
也许 emergent 指的 是 coming into being ，从不存在到存在。
或者也许 to emerge 意味着 进化 ，就像从不太成熟或先进的状态到更成熟或先进的状态，而不是静止不动。
然后是 出现在视野中 的概念，就像从隐藏到可见一样。它一直在那里，只是从阴影中出现。
但是还有其他字典定义没有完全捕捉到的出现感。例如， 零碎组装 的概念。当我们把拼图拼在一起时，拼图上的照片就出现了。
然后在涌现架构的讨论中流行一种涌现感： 无意 的概念。换句话说，一方面是突发架构，另一方面是有意架构，其中有意架构本质上是 预先计划 和 有目的的 ，而突发架构在某种程度上是 偶然的 。
尽管在含义上存在所有这些微妙的差异，但大多数人在架构或设计的上下文中使用 emergent 时显然想说的是： 通过将重要的架构和设计决策推迟到最后负责的时刻，您可以防止不必要的复杂性破坏您的软件项目 （我在 ibm developerworks 上找到的引述，但如果您知道谁先说了这句话，请通过评论填写我们所有人）。
因此，这种软件构建原则在组合中引入了另一个概念： 延迟 的概念。人类的决策制定负责驱动架构和设计，因此这种架构和设计的出现仅仅是因为我们在不得不做出决定之前不会对任何事情做出决定。
然后它可能会出现，或进化，或出现。虽然做出这样的决定显然是有意为之，但至少在工作开始时并不是有意为之，因为团队没有预先计划任何事情。
房间里的大象出现了
上述定义的所有细微变化都遗漏了一个重要因素： 自组织 的作用。当然，人们通常更愿意自己组织起来，而不是让别人为他们组织，所以自组织的团队可能比经理为他们组织的团队更有效率或更具协作性。
然而，如果您阅读了我 最近关于自组织的一些文章 ——或者我的书 《敏捷架构革命 》——您会在这里看到一幅更大的图景：在 复杂自适应系统 (cas) 的背景下 涌现 。
在这种情况下，cas 的紧急属性是 整个系统的属性，而不是该系统的任何子系统的属性 。
自组织是复杂系统背后的主要驱动力之一。从蜂箱到星系的自然系统都有自组织子系统。或许最初的敏捷者在这个 皮层 的顶部写下这句话时，正在考虑这种出现的感觉。
也许不是。但无论最初的敏捷主义者是否考虑过 ca，自宣言出现以来的过去 15 年中，许多人都将这种联系联系在一起，无论好坏。
从表面上看，涌现设计或架构的吸引力是复杂系统所展示的那种涌现，这很诱人，就好像涌现是某种秘密魔法一样。我们需要做的就是让我们的团队自我组织，看！紧急设计和/或建筑从虚无中涌现！
要是这么简单就好了，对吧？
不幸的是，从 emergent-as-deferred-and-evolving 跳到 emergent-as-property-of-cas 有严重的问题。首先，在 cas 上下文中，emergence 适用于复杂系统的属性。对于从事某些软件工作的软件团队，不清楚复杂系统的位置，更不用说它具有什么属性了。
此外，将架构或设计视为系统的单一属性是一种延伸。也许它们代表了软件系统的一系列属性——可伸缩性、性能等等——但架构代表的不仅仅是系统的属性。一个组件如何与另一个组件通信可以被认为是架构的一个元素，而不是可扩展性是系统属性的一种属性。
无论如何，没有普遍的理由将软件系统视为复杂系统，因为它们的体系结构或设计的属性在它们的组件中很明显。即使软件系统的属性是整个系统的属性，它仍然很可能是该系统组件的属性——因此它不是涌现属性。
识别复杂的自适应系统
这就是我喜欢在复杂系统的背景下思考涌现的方式：如果你过于仔细地观察一个 cas，你就看不到涌现的属性。相反，您必须退后一步——有时是退一步——从整个系统的大局来看，以了解其涌现的属性。换句话说， 模式是从大局中浮现出来的 。
如果你研究蜜蜂个体的行为，你将永远看不到蜂巢的结构。如果你观察单个恒星，你将永远看不到银河系的形状。如果你检查水分子，你永远不会知道潮湿意味着什么。
当我们考虑自组织团队可以构建的软件系统种类时——即敏捷世界所青睐的双披萨团队——我们离组件级别还不够远，无法获得任何紧急意识特性。
底线：无论个人团队的自组织程度如何，在 cas 涌现的意义上，他们所产生的软件设计或架构不会有任何特别涌现的东西。
现在，请不要举起手来断定我完全没有理解本文开头那句话的要点。事实上，我指出了整个敏捷宣言的一个微妙但关键的方面。它根本与软件无关——或者至少， 不仅仅是 软件。
敏捷宣言实际上是关于 人 以及人如何与软件交互的。开发人员如何与利益相关者合作创建它并确保它满足组织的持续需求。
然而，即使我们查看自组织团队本身以及他们创建的软件，我们仍然离得太近，看不到任何涌现的属性。我们必须放开脚步，从整体上审视本组织。
组织必须有多大是很难定义的。它可能是整个公司，也可能是一个大部门或业务单位。然而，大到足以让涌现的属性显现出来。
intellyx采取
当我们从整体上审视我们的企业时，我们可能会注意到一些涌现的特性，既有积极的也有消极的。然而，我们不太可能看到针对企业的新兴设计或架构——至少，如果不扩展我们对这些术语的定义，使其远远超出其通常的应用范围，是不可能的。
然而，在我看来，设计和建筑都没有出现并不重要。相反，我将架构视为一组有意的行为，旨在影响组织以展示理想的紧急属性，其中业务敏捷性是最重要的。
我喜欢将这种方法称为 敏捷架构 ，这是对企业架构的重新发明，它会影响组织中人员和技术子系统的行为，从而将其新兴行为转变为业务敏捷性。但 业务敏捷性 是出现的属性，而不是架构。
intellyx 为公司的数字化转型计划提供建议，并帮助供应商传达他们的敏捷故事。截至撰写本文时，本文中提到的所有组织都不是 intellyx 的客户。图片来源： 哈勃遗产 。
