Cynefin框架及其各个领域

本章简介   软件项目长期以来一直面临如何应对复杂性的问题，而复杂性正是导致诸多挑战的根源，包括质量低下、项目延期甚至彻底失败。

本章介绍了一种理解不确定性和复杂性的框架——Cynefin。它阐述了Cynefin在顺序式与敏捷式软件问题中的应用。随后，本章提出一种在不确定性与复杂性面前做出决策的模型——OODA。该模型说明了在何种情况下，OODA决策方式相较于传统的顺序式决策方法具有优势。

Cynefin

Cynefin框架（发音为Kuh-NEV-in）由大卫·斯诺登（David Snowden）于1990年代末在IBM创建（Kurtz, 2003），此后由斯诺登及其他研究者持续发展和完善（Snowden, 2007）。斯诺登将Cynefin描述为一个“意义建构框架”。它有助于根据情境的复杂性与不确定性，判断哪些策略会更有效。

Cynefin框架包含五个领域。每个领域都有其独特的属性和建议应对方式。如下图所示：

“Cynefin”是威尔士语，意为“栖息地”或“社区”。这些领域并非严格分类，而是被视为意义的聚类，这也是名称中强调“栖息地”的原因。

在软件开发中，最相关的两个领域是复杂域和复杂但可分析域。以下将逐一介绍全部五个领域，以提供背景支持。

明确域

在明确域中，问题已被充分理解，解决方案显而易见。实际上，所有人都认同唯一正确的答案。因果关系简单直接，属于模式应用的范畴：程序化、流程化、机械化的行为。

该框架对明确问题的处理方式描述为：

$感知 \space \to \space 分类 \space \to 响应$

明确域的典型例子包括：

• 在餐厅下单
• 处理贷款还款
• 给汽车加油

在具体实施层面，软件团队经常遇到大量明确问题，例如：“这个 if 语句应该检查 0 而不是 1。”

但在项目层面，很难找到符合Cynefin定义的明确问题实例。你最后一次看到一个规模较大的软件问题，其解决方案只有一个且所有人一致认可，是什么时候？已有研究表明，当不同设计师面对相同设计问题时，他们实现方案所需的代码量可能相差十倍（McConnell, 2004）。在我的经验中，即使是看似简单的任务如“生成一份简短报告”，也存在显著差异。这与“唯一正确解”相去甚远。因此，除了“Hello World”级别的程序外，我认为软件开发中并不存在真正的明确问题。对于大型软件开发而言，可以安全地忽略明确域。

复杂但可分析域

在复杂但可分析域中，你大致了解问题的形态，知道该问什么问题，也知道如何获取答案。同时，存在多个正确答案。因果关系复杂——必须通过分析、调查并运用专家知识才能理解因果联系。并非所有人都能看清或理解这种因果关系，因此这一领域属于专家范畴。

该框架对复杂但可分析问题的处理方式为：

$感知 \space \to \space 分析 \space \to 响应$

这与明确域的区别在于，中间步骤需要进行“分析”而非简单“分类”后选择唯一正确响应。

复杂但可分析域的典型例子包括：

• 诊断发动机异响
• 准备一道精致菜肴
• 编写数据库查询以获取特定结果
• 修复因更新不完整而导致的生产系统缺陷
• 为成熟系统的第4.1版本优先排序用户需求

这些例子的共同点是：首先形成对问题的理解和解决思路，然后以清晰路径推进解决问题。

许多软件开发活动和项目都属于复杂但可分析域。历史上，这是顺序开发的主战场。

如果项目主要处于复杂但可分析域，采用高度依赖前期规划与分析的线性顺序方法是可行的。但当问题无法被清晰界定时，这种方法就会遇到困难。

复杂域

复杂域的核心特征是：即使对专家而言，因果关系也无法立即显现。与复杂但可分析域不同，你并不清楚该问哪些问题——发现问题是挑战的一部分。任何预先分析都无法解决问题，必须通过实验来逐步接近解决方案。事实上，一定程度的失败是过程的组成部分，决策往往需基于不完整的信息做出。

对于复杂问题，因果关系只能事后才可理解——问题中某些要素是涌现的。然而，经过足够多的实验后，因果关系可以变得足够清晰，从而支持实际决策。斯诺登指出，复杂问题属于协作、耐心以及让解决方案自然浮现的领域。

Cynefin推荐的复杂问题应对方式为：

$探查 \space \to \space 分析 \space \to 响应$

这与复杂但可分析问题不同：你不能靠分析直接走出困境，必须先进行探查。最终分析会变得重要，但不会立刻发生。

复杂域的典型例子包括：

• 为难以挑选礼物的人选购礼物——你送出去时就知道可能需要退换！
• 修复生产系统中的一个bug，调试时诊断工具使问题消失，但在生产环境中依然存在
• 为全新系统收集用户需求
• 开发运行在仍在演进的底层硬件上的软件
• 在竞争对手持续更新软件的同时，更新自己的软件

许多软件开发活动和项目属于复杂域，这也是敏捷与迭代开发的适用领域。如果项目主要处于复杂域，那么可行的方法必须在问题尚未完全定义之前就融入实验与探查。

在我看来，顺序开发在复杂项目上表现不佳，是推动敏捷开发兴起的重要原因之一。

在某些情况下，可以通过足够深入的探查，将原本以复杂为主导的项目转化为复杂但可分析项目。剩余部分可采用适合复杂但可分析域的方法完成。而在其他情况下，项目在整个生命周期中仍保持显著的复杂特性。试图将其转变为复杂但可分析项目，只会浪费本可用于采用合适复杂方法完成项目的时间。

混乱域

混乱域与前三个领域的模式略有不同。在混乱域中，因果关系动荡不定、不断变化。即使反复实验，也难以发现因果关联，即便事后也无法建立稳定联系。你不知道该问什么问题，探查与实验也无法产生一致结果。

该领域还包含时间压力因素，这是其他领域所不具备的。

Cynefin将混乱域定义为果断、行动导向型领导力的领域。推荐做法是迅速在混乱中建立秩序：

$行动 \space \to \space 感知 \space \to 响应$

混乱问题的典型例子包括：

• 灾难仍在发生时提供自然灾害救援
• 在高中食堂制止食物打斗
• 因无法通过分析或探查定位故障原因，只能回滚到旧版本来修复生产系统中的一个缺陷
• 在充满政治博弈的环境中定义功能集，因关键利益相关者的野心导致需求不断变动

在软件项目中寻找符合规模的混乱问题实例非常困难甚至不可能。修复bug的例子具备“无时间分析，只能行动”的特征，但不属于项目级问题。定义功能集的例子虽属项目级，却缺乏极端时间压力，因此不符合Cynefin意义上的典型混乱问题。

无序域

Cynefin图示的中心区域被称为“无序域”，即你对当前问题应归属哪个领域缺乏清晰认知。Cynefin建议的应对方式是：将问题分解为若干元素，分别判断每个元素属于哪个领域。

Cynefin提供了一种识别这些不同元素并分别处理的方法。在复杂域中，你以一种方式处理需求、设计与规划；在复杂但可分析域中，则采用另一种方式。没有一种方法适用于所有场景。

大多数软件项目级问题并不会整齐地落入单一领域，因此请记住：这些领域是“邻里”——意义的聚集区。一个问题或系统中的不同部分可能表现出不同属性：有些可能是复杂但可分析的，有些则可能是复杂的。