软件（和产品）开发从来都不是一件简单的事。对于运行了几天并且只涉及少数人的项目，可能会保存。绝大多数项目很容易被认为是复杂的。 “复杂”是指：太多的变量和潜在的（紧急）交互，可靠地预测（近）未来。然而，我们似乎遭受了强大的认知偏见，这使得我们的折扣复杂性与诸如“它不能那么难”，“我们之前已经做过”以及“我们已经非常清楚要做什么”这样的陈述。我经常遇到那些觉得他们的'项目对Scrum来说不够复杂'的人。我坚信这些人是从对复杂性的非常有限的理解中推理出来的。在这篇长篇大论中，我提供了几个模型和框架（如Stacey和Cynefin）来帮助理解“复杂性”并更好地理解为什么Scrum（或其他迭代框架）确实是最好的方法。

扔掉你的计划？

大多数人仅仅通过“了解创造什么”来理解“复杂性”。以最近告诉我他的项目并不复杂的经理为例，因为它涉及重建现有（大型）应用程序。但“知道要创造什么”只是其中一个因素。在我们的专业Scrum硕士培训期间，我们总是要求参与者集思广益，尽可能多地影响项目成功的因素。我们只需几分钟就可以完成这项练习。即使在这种限制范围内，我们也总是设法快速填满整个活动挂图。我敢肯定，如果我们花一整天时间进行这项练习，我们可能会填满整个墙。

为了让您了解人们的想法（最重要的）：

1. 沟通风格和技巧
2. 组织内的授权和支持
3. 团队的技能水平
4. 明确的目标和/或愿景
5. 开发人员的技术技能
6. 涉及的人数
7. 组织文化
8. 知识共享
9. 处理
10. 股东和股东的可获得性
11. 参与客户和/或最终用户
12. 工具
13. 市场的波动性
14. 时间管理技巧
15. 流
16. 动机
17. 时间因素（如项目运行多长时间）
18. 现有代码库（质量，规模，知识）
19. 与重要组成部分供应商的关系

“通过让人们花费宝贵的时间来创造它们，阅读它们并使它们保持最新”，计划是仪式化过程浪费的重要来源。

这个清单上有一些巨大的因素。像组织文化，目标清晰度和技能。您如何能够预先预测这些因素在项目期间将如何表现，以及它们将如何相互作用？现实情况是，面对这种不可预测性，制定计划没有任何价值。通过让人们花费宝贵的时间来创造它们，阅读它们并使它们保持最新，计划是仪式化过程浪费的重要来源。这并不是说我们不应该花时间思考我们将要做什么。我们应该以符合复杂性的方式来做。正如艾森豪威尔所说：

“计划毫无用处，但计划是不可或缺的。” - 德怀特·艾森豪威尔

几个框架可以帮助我们确定哪种方法适合某种程度的复杂性。我将描述最知名的人; Stacey矩阵和Cynefin框架。

关于复杂程度的简短说明

我们将在下一段中谈论很多关于活动的内容。活动发生在不同的层面，从开发新产品（大型）到将列添加到表（小型）。这些活动属于不同的复杂领域。这意味着所有领域或复杂类型可以同时存在，但在不同层面上。这篇文章是在考虑产品或项目级活动的情况下编写的。

斯泰西矩阵

理解复杂性的一种方法是通过由Ralph D. Stacey（管理学教授）开发的Stacey矩阵。多年来，该模型已经以多种不同的形式呈现，但它主要表明复杂性是对所需内容（“什么”）达成一致程度的函数，以及我们如何达到目标的确定性（'怎么样'）。

Stacey Matrix的开发旨在帮助管理者确定其环境的复杂性并调整其决策风格。对于软件开发，Matrix通常沿不同的轴绘制; '要求'和'实施'（或'技术'）。前者取决于我们知道我们需要构建什么的显而易见性（如产品）以及要实现的功能（'什么？'），而后者则取决于实现目标所需的显而易见性。实施/技术条款（'如何？'）。应该指出的是，这种改编并不适合Stacey的原始Matrix。但它确实提供了一种类似的概念方法来理解软件开发环境中的复杂性，以及使用的方法：

简单：

当显而易见的需要以及如何到达时，活动是“简单的”。根据现有的传单或宣传册开发一个基本的1页网站。所需要的东西（'数字化传单'）和如何到达那里（'一些html / css来复制样式'）是显而易见的。最有效的方法最好总结为“只做它”。采取现有的“食谱”或“最佳实践”，应用它，你就完成了。不需要计划，也不需要像Scrum那样的经验框架;

复杂（Complicated）：

如果不清楚需要什么或如何到达那里，活动就很复杂。我经常使用网上商店的例子来购买新类型的产品。这里的实现非常明显，可以通过大量现有的网上商店模块（如Magento或WooCommerce）来回答。但如何最好地展示和推广产品将不那么明显。另一个例子是连接两个系统以交换特定类型的数据。这里显而易见的是（'连接系统'），但实现不太明显（'我们如何映射数据？我们使用什么机制？'）。对于复杂的环境，很难确定一种最佳方法。一些作者表示，计划的方法（分析，设计，执行）可以在这里工作。但根据我自己的经验，我会说迭代方法仍然优于计划方法。虽然复杂性在这里肯定是有限的（对于两个轴中的一个），但仍然有很多未知数。迭代方法提供了一个过程，可以帮助在需要时更快地发现它们并纠正过程;

复杂（Complex）：

当需要的东西和如何到达目的不明显时，活动被认为是复杂的。变量之间的相互作用变得过于复杂，无法准确预测，这使得详细的前期计划毫无意义。而不是试图预先控制和预测活动的流动，更有效的方法是使用“经验过程”。在这些不可预测的环境中，用于决策的最可靠信息是基于已经发生的事情（而不是我们预期会发生的事情）。因此，我们应该采取小的渐进步骤，使用每一步来确定我们是否已经接近解决问题或远离它。 Scrum是这种过程的一个很好的例子;

混乱：

右上角是为一切都在变化的活动保留的。在这些环境中，即使过去也不再为决策提供可靠的信息。如果是大型应用程序的服务台或托管环境的主要中断，这是一个很好的示例。这里最好的方法是“分诊”：优先处理问题，首先解决最紧急问题，然后从那里继续进行（冲洗和重复）。虽然迭代方法仍然是一种有效的方法，但步骤需要更短。认为短期冲刺的Scrum或具有低工作进度限制的看板;

通常添加到模型中的第三个轴（不是Stacy本人）是涉及的人数。这个想法是复杂性随着从事活动的人数的增加而增长。对于一个人来说简单的任务对于一个人来说可能非常复杂。选择要观看的电影很容易，但是对于一群朋友来说，它可能变得非常复杂。

Stacey矩阵的局限性

1. 有趣的是，Ralph D. Stacey已经放弃了矩阵作为理解复杂性的手段。他的主要原因是他现在认为所有活动在某种程度上都是复杂的。即使是最简单的活动也会因为纯粹的（坏的）运气而变得复杂。
2.  
3. 矩阵的第二个问题是，对矩阵的简单解读可以得出结论，即可以通过足够的智力来降低复杂性。如果我们只是花了足够的时间来讨论需要什么，以及如何实现目标，我们最终会将一个非常复杂的问题变成一个简单的问题。换句话说，Stacey矩阵可以用来推断我们只需要在复杂或复杂的环境中进行更广泛的规划和准备。但这与斯泰西试图用他的模型做出的观点相反。
4. 第三个问题是该模型仅将“协议”和“确定性”视为引入复杂性的因素。但是还有许多其他因素会引入复杂性，例如沟通，相关人员的技能，组织文化和纯粹的机会。

Cynefin框架

Cynefin是一个感觉制作框架，由Dave Snowden（IBM）于1999年开发，旨在帮助领导者和管理者了解他们所处的情况并采取行动。他后来用Cynthia Kurtz（2003年）对其进行了改进（2003年） ）。该模型后来被敏捷社区采用，以更好地理解和解释为什么敏捷和Scrum非常适合软件开发。虽然它看起来比Stacey Matrix更复杂，但它确实提供了一个概念上更强大的论点。

简单地说，Cynefin框架确定了五个复杂的领域，这两个领域是完全不同的。最简单的形式是，框架指出有四种方法可以理解“未知”。每个域都有自己的方式来理解这种情况，需要采用不同的方法来实现有效和不同的管理方式。虽然Cynefin框架通常以2x2模型的形式呈现，但象限下没有维度轴。

显而易见：

当问题得到充分理解并具有明确的既定解决方案时，活动就很明显。因此，诊断问题并找到解决方案不需要专业知识和技能。最好的方法是使用“最佳实践”：诊断情况（感知），将问题分类到正确的“桶”（分类）并应用与该桶相关的最佳实践（响应）。例如，遵循频繁执行部署的清单或使用调用脚本的呼叫中心。在这个领域最有效的管理方式是协调：确保人们知道该做什么以及如何做;

复杂（complicated)：

诊断问题时，活动很复杂，找到一个好的解决方案需要专业知识。需要专业知识和时间来提出正确的问题（“已知的未知数”）并得出问题的诊断结果。一旦知道，就需要专业知识来选择一组有限的解决方案。最好的方法是使用“良好实践”：诊断情况（意识），分析问题（分析）并确定和应用计划的行动（响应）。一个例子是解决应用程序中的错误或连接两个API。最适合此类活动的管理方式是合作：与专家合作;

复杂(complex)：

当问题和解决方案都是未知的时，活动很复杂。在这些情况下，即使找到要问的正确问题也很困难（“未知的未知数”）。理解问题和找到解决方案都需要积极的实验，直到模式开始出现。尽管可以预先预测总体方向，但实际解决方案在找到之前并不明显。最好的方法是积极发现模式（'紧急实践'）：尝试从环境中收集反馈（探测），分析反馈（感知）并回答另一个实验，直到您到达'复杂'域。最适合此类活动的管理方式是共同努力寻找最佳解决方案（协作）;

混乱：

当问题和解决方案都未知时，活动是混乱的。这是一个临时状态。随着时间的推移，约束和结构将自然出现（即使你没有强加主题）。这方面的一个例子是当一个大型网络农场发生故障或发生自然灾害时。几乎没有时间思考，所以专注于找到有效的东西而不是寻找最佳解决方案。最好的方法是应用“分类”：快速确定优先级并解决问题的一部分（行为），分析情况（分析）并继续下一个优先问题（响应）。最适合此类活动的管理方式是立即采取行动，提供清晰直接的沟通和恢复顺序，以将复杂性降低到“复杂”域。 ;

无序：

框架中心的域保留用于未知复杂域的活动。斯诺登添加了这个领域，强调我们必须首先理解环境，使用可用的数据和信息来确定复杂性的类型。如果没有这样的数据或者没有意义，活动仍然是“无序”。这里的首要任务是确定活动属于哪个域。然后使用适合该域中活动的方法。这也强调复杂性不是活动的某些“客观”属性;这是感觉制作过程的结果;

知识，界限以及Scrum适​​合的地方

Cynefin框架的一个关键因素是知识。我们对情况的理解有助于使问题和解决方案更加明显。对每个域使用推荐的方法（探测 - 响应 - 响应等），我们基本上帮助自己更好地理解问题。这有助于我们过渡到复杂的“低级”领域。

假设我们遇到的问题完全出现在“Chaotic”域中，就像以前没有发生过的大型企业应用程序的重大中断一样。我们没有时间坐下来思考最佳解决方案，因此我们必须对情况进行分类并确定要采取的第一步。优先级最高的第一个低工作级看板流程可以在这里提供帮助。这最终会将问题转移到“复杂”域中。

根据Snowden的说法，Scrum本质上是一种从“复杂”域转变为“复杂”域的方式。通过将一个大问题（如开发新产品）分解为许多较小的问题（短跑或甚至单个PBI），我们最终会降低较小比特的复杂性。

因此，通过调整我们的行为，我们可以增加对情况的理解。这有助于跨越边界转换问题（顺时针方向），从混沌到复杂，从复杂到复杂，甚至可能到简单。当知识丢失或未正确应用时，会发生相反的情况。一个例子是部署复杂的应用程序。手动完成后，活动很容易变得复杂甚至混乱。但是当部署大量自动化时，它可以成为一个简单的活动。底部的小“折叠”或“悬崖”代表了从“明显”直接回归到“混沌”的可能性。当现有的最佳实践过时但仍继续应用时，就会发生这种情况。或者，当负责维护关键应用程序的人员离开公司而不转移知识时。下一次重大问题发生时，人们将争先恐后地解决“混沌”问题。

从这些模型中得出的最重要的教训是，软件开发至少是“复杂的”，可能是“复杂的”，偶尔会在产品或项目层面上“混乱”。当对所需的最终状态（问题）没有明确的理解并且没有明显的方法（解决方案）时，需要一种迭代方法来帮助澄清问题和解决方案。无论我们用多少脑力来预测未来，影响我们工作成功的大量因素使得这些预测几乎毫无意义。因此，在非简单环境中使用计划方法很可能会导致您解决错误的问题或应用错误的解决方案。

在复杂的环境中，为我们的未来决策提供信息的最佳信息来源不在于对未来的预测，而在于已经发生的事情。这意味着需要一个经验的迭代过程。就像科学家如何测试科学理论一样，或者发明家如何通过渐进式原型逐步完成工作直到达到工作模型。需要经常检查不断变化的“当前状态” - 正在解决问题的各个方面 - 以增加我们对问题和解决方案的理解，并为我们未来需要的决策提供信息。通过将较大的问题分解为许多较小的问题（冲刺），我们基本上从“复杂”转变为“复杂”领域。

如果没有清楚地了解所需的最终状态（问题）并且没有明确的联系方式（解决方案），则必须采用迭代方法来澄清问题和解决方案。

那么Scrum呢？

实际上，Scrum是一个提供这种经验过程的框架。这正是Scrum不是“方法论”的原因。方法论是一套完整的原则，但Scrum（仅）为应用于软件开发的经验过程奠定了基础。这需要透明度，检查和适应性。 Scrum需要实施五个Scrum事件，以最大限度地提高透明度，允许检查并促进适应。未实施这五项活动中的一项严重限制了我们为未来做出决策所需的反馈质量。 Scrum绝不是唯一的选择。但它是一个非常受欢迎的选择，拥有大量的从业者社区。如果这篇文章说服你的项目可能需要经验方法，那么试试这个是一个很好的理由。

更新（2017年3月23日）：Dave Snowden回复了Twitter上的帖子。他强调Scrum有助于从复杂问题转变为许多复杂问题（将工作分解为冲刺，然后分解为PBI）。混沌域中的类似Triage的过程有助于将问题从“Chaotic”转换为“Complex”。我已相应更新帖子，感谢Dave的个人意见！

参考

• Snowden, D. J. & Boone, M. E. (November 2007). “A Leader’s Framework for Decision Making”. Harvard Business Review, 69–76. PMID 18159787;
• Snowden D. J., & Kurtz, C. (2003) “The new dynamics of strategy: Sense-making in a complex and complicated world”, IBM Systems Journal Vol 42 No 3, 2003;
• Stacey, R. (1996). “Complexity and Creativity in Organizations”. ISBN: 978–1881052890;

原文：https://medium.com/the-liberators/on-complexity-why-your-software-project-needs-scrum-13c36305c866

本文：

讨论：请加入知识星球或者小红圈【首席架构师圈】