冬季的剃刀和敏捷框架
偶尔（或ockham's）剃刀是我们在14世纪回到奥克姆威廉的原则。原则指出“不应该不必要地乘以”的原则。流行的解释是，最简单的解释通常是正确的。
它激发了许多表达，包括“简约的假设”，“简单的原则”，“KISS原则”(保持简单，愚蠢)。
奥卡姆的大部分原则来源于哲学。也许这就是为什么您现在会在设计原则的基础中找到许多方法(特别是简单性原则)。
在功能等同的两种选择中设计，应该选择最简单的一个。在OCKHAM的剃刀中隐含是不必要的元素降低设计的效率，并提高了意外后果的可能性。[¹]
比较时技术执行相同的功能，一个设计更简单的将倾向于更容易建造和修复。此外，它将倾向于需要更高的技能来使用，而一项技术，需要较少的技能将倾向于更复杂的设计，更复杂的建造和修复。例如，直剃须刀在设计和制造上相对简单，但需要相当多的技能来使用，而电动剃须刀在设计和制造上相对复杂，但需要很少的技能来使用。(²)
敏捷框架
现在，回去重读两个引用的段落，替换设计和技术和敏捷框架．我也喜欢直剃刀的比喻，主要是因为我用直剃刀刮胡子。我只割了自己一次(很严重)，我才意识到我需要真正的技能来使用这样一个简单的工具。与此相反，我在复杂的组织中经历了几次失败，才意识到使用复杂的敏捷框架并不能转化为简单的实现。
尽管我同意Scrum可以解决复杂的适应性问题，但我认为它在受控的团队级环境中也能做到这一点。我不认为它在复杂的组织层面的环境中能很好地工作。就像用剃刀刮牦牛一样。
在光谱的另一端，我们有SAFe, LeSS, DAD(在这里输入你的缩写)。我认为，这些框架出现的部分原因是，复杂的组织期望复杂的解决方案。我们用苏斯博士引以为傲的电动剃须刀给牦牛刮胡子。
我的想法
首先，虽然大型组织通常很复杂，但我们不需要让敏捷框架变得更复杂。似乎很少有顾客在意如何他们完成了工作。他们只是关心他们按时提供产品或服务，并在预算范围内。如果您正在寻找添加控制点来处理和治理，请查看风险较低并提高值吞吐量。使流程尽可能简单，允许工作流过您的交付系统。简单性（通过删除依赖项）是密钥。依赖关系打破敏捷．但是你应该注意不要在过程中添加太多的控制点，这会给每个人带来不必要的工作。另外，也不要太过简化，这会导致混乱。专注于系统地消除依赖，并寻找合适的中间方法。因此，您可能只需要三件事．
小心别割伤自己。
[¹] http://www.visualgui.com
[²]http://www.omick.net
评论（4）
Mark Levison
德里克 - 我完全同意你的笔记。一个小点少不像其他人。它要求您简化，它要求除垢，需要了解精益和系统思维。所有这些似乎都与您的评论一致。所以我对他人的绝望感到困惑。
干杯
标记
马克,
非常感谢您的反馈。我的博文中有夸张之处，因为我把它和其他博文混为一谈了。谢谢你叫我出来。问题是，其他框架的支持者也会这么做吗?
内存
我同意马克的看法。不那么彻底地简化了“多于一个团队”的产品开发，并消除了该过程中的大量浪费(包括非增值角色)。你不需要一个红色的纱线来管理依赖:)
红色的纱线评论让我大声笑。极好的补充。谢谢，公羊。