封装vsOrchestration：敏捷中的依赖关系

依赖关系将阻止敏捷在其轨道中死亡。在存在依赖性的情况下，你永远不会达到你想要的敏捷程度 - 除非你对他们做点什么。

所以你在谈到这一点时只有两种选择。您可以封装团队中的依赖项或在值流中，或者您可以协调它们。另一种说明这是你必须打破依赖项，或者你必须管理它们。

不管怎样，如果你有依赖关系，你不能假装它们不存在。

Scrum的假设

那么，Scrum对依赖关系说什么？它假设您没有首先拥有它们。如果你看看Scrum是归档的方式，你会注意到它假设很多，包括每个团队：

• 由六到八个人组成
• 专注于特定的业务问题亚博vip9通道
• 拥有自己的技术堆栈
• 有一个单数输入
• 具有奇异的可测量输出

实际上，Scrum假定您拥有封装的团队，可以通过在Scrum的仪式周围自我组织来解决内部的任何依赖性。然后，它们可以实时解决或优先考虑依赖项，以确保团队可以通过冲刺末尾提供其承诺。

但是，当依赖关系超出团队的范围时会发生什么？

scrum的现实

不幸的是，对于许多大型组织来说，在组建团队时，一个或几个人在多个团队之间跳槽是很常见的。

例如，QA人员分布在六支球队中。这是六个冲刺计划会议，六个日常立宪，六个评论和回顾。在那一点上，QA工作没有空间。

然后，每个团队都必须确保在需要他们完成工作时，该人员随时可用。该团队不再能够立即使用它们，这意味着该团队现在具有规划依赖项和协调依赖项。一个项目和另一个项目之间存在依赖关系，这取决于两个项目是否能够保持正常运行。

从理论上讲，您可以有两个团队满足敏捷团队的大多数标准。但是，如果只有一个QA人员跨越两个团队之间的界限，那么您也有一个依赖关系，这将限制两个团队实现敏捷性的能力。

任何时候我们将依赖性注入系统，我们都会创建必须在团队之外管理的东西。这限制了我们敏捷的能力。

其他流行方法的故障模式

许多方法都承认，依赖性是真实的，并提出了解决它们的各种方式。但是，您选择哪种方法并不重要，因为它们都只是在一天结束时协调依赖性的方法。

以下是一些最流行的方法（Scrum、SAFe和LeSS）如何试图管理依赖关系，但通常仍然失败的详细介绍：

scrums的scrum.

在一个时间点，Scrum提出了这个Scrums的Scrum。这个想法是你有一些团队，每个团队都有自己的克拉克斯托斯特。在某些时候，通常在Sprint的开头，所有斯克拉维人都会在实时协调依赖关系。这是一个有效的构造，适用于某些条件。

问题是，当您有两个团队具有依赖关系，并且您试图实时缓解它们时，您最终会延迟解决依赖关系。这往往会破坏团队的速度。当团队的速度变得不稳定时，您将无法做出并履行承诺。

许多组织都制定了缓冲策略，比如留出额外的时间来处理已知的依赖关系。但是，当您尝试扩展系统时，它变得非常临时且难以管理。所以，尽管Scrum中的Scrum是一个很好的沟通工具，但它并不是消除依赖性的好策略。

安全的

安全建议您需要程序增量（PI）规划。基本上，您将在PI计划的一端拥有某种早期的“大房间”计划和另一端的闭幕式。在中间，您将在某种节奏中提供特色。

当你做一个早期的计划会议时，这个想法是每个人都会进入一个房间并提前解决依赖关系，至少在一些合理的保证水平。但他们将在开始时明白这些依赖关系，希望前面加载它们，以便他们能够更快地解决依赖项。或者，如果他们将失败PI，那么至少他们会知道那么迟早并且可以枢转或扭转。

在大型组织中，当你有一个类似银行平台的东西时，安全的斗争就发生了。该平台负责ACH处理事务、对账、账单支付等。通常，这些平台处理的是难以置信的高容量、大型、健壮的大型机和超高速事务处理。

想象一下，如果您有四个产品，每个产品有七到十个安全团队，每个值流都可能将依赖项注入平台，因此，您所做的就是简单地将依赖关系移出。你没有做任何事情来打破它们。他们还在那里，他们仍然限制了你敏捷的能力。

如果依赖项被封装在价值流中呢？如果是这样的话，在你的情况下，SAFe可能对你有用。但是要注意依赖关系的存在，以确保这始终是一个真实的陈述。因为如果你的价值流是相交的，这意味着你的价值流之间存在依赖关系，那么你的价值流可能设置不正确。

或者也许您确实存在，并且这些依赖项实际存在，并且您需要在价值流中管理它们。

安全通常使用4层的治理模型设置。但是，如果每个层都是在它们下方编排层的依赖关系，那么该模型仅适用。并且那个级别的管弦郎变得昂贵，而且你结束了一个团队的层次。

依赖关系不是你的朋友。即使你到达有效管理它们的地方。

较少的

少谈团队层面的执行，以及它向更大的事情发展的方式。但是，为了减少实现，您必须在团队级别进行大量的封装，并在升级时进行非常少的编排。

那么，LeSS如何解决依赖关系呢？

好吧，让我们说你有一些前端团队和一些后端球队。您可能有一个PO团队，他们正在分解和排序这些团队的工作，并遵守依赖感知积压。

宝团队开始将所有团队加载到功能1项。然后有2个项目。但是，它变得有趣的是，当你到达第3个而不是所有团队都有工作要做的那种功能。你对没有工作的团队做了什么，但容量有能力？你将它们移动到功能4吗？如果没有能力的团队有4个工作，你就不能。

所以，你在每个团队都可以成为瓶颈或饥饿的情况。倾向于加载具有非增值工作的能力的团队只是为了让他们忙碌，但这可能不是最好的时间。

理想情况下，您要做的是将容量转移到瓶颈。但是，在现实中，由于技能在团队中的分布，这通常是不合理的。一个团队的技能可能不适用于其他团队正在做的工作。

那么，为什么不只是将它们倒入一个完整的跨职能团队，可以为所有组件提供服务吗？

如果后端在COBOL中，前端在.NET中是什么？你有多种技术问题。

另一方面，如果你在一个不仅仅是关于技术和技能集的环境中，那么工作也是关键任务，永远不会破坏？

当你进入这些纯粹的游戏时，任何团队可以触摸任何东西的环境，你必须问自己，你有正确的测试安全水平吗？你能不断部署它吗？你能确定它从未被打破过吗？

您是否有合适的体系结构，合适的组织对齐来以这种方式操作，并安全地完成它?如果其中任何一个答案都是否定的，那么您就具有依赖性。

补偿控制

由于您可以从迄今为止所阅读的内容中收集，因此依赖性是组织正在处理的真实事物。在看到最受欢迎的方法的一些常见故障模式之后，希望您开始看到，虽然大多数是在尝试解决这个问题的时候，但并非所有的方法都在所有环境中工作。那么，当你的选择方法没有为你的特定环境规定行动方案时，你做了什么？

要真正敏捷，根据定义，您必须拥有封装的团队。这是理想的状态，但它也可能不是你当前的现实。

如果它不是你当前的现实，那么你知道你需要管理依赖关系，但很多人都不喜欢那样，因为它感觉不太敏捷。

所以，组织感受到这种紧张，他们会问自己我能做什么吗？

答案是您必须将某种补偿管制提供到位。什么是补偿控制？补偿控制是您在所选方法的顶部实现的任何编排机制，以帮助您到达所需的终端状态。

你想是多么敏捷？那有多快？

Understanding where you are today vs where you’re going and acknowledging that dependencies are going to get in the way means that your Transformation journey isn’t about implementing a methodology that’s too heavy for your future end state, or establishing a set of compensating controls that are going to hinder your Agility in the long term.

相反，您的转型之旅是今天创造正确的条件，这将帮助您开始以增量和迭代的方式为明天创造正确的条件。

现实是，这一切都不会发生一夜之间。但是，了解你想去哪里和有临时计划的计划，让你的组织决定哪些依赖项是值得休息的钱。肯定会有可能永远不值得休息的依赖关系，或者在经济上足以打破。

因此，您将必须在您的方法之上做点什么，以确保您收获方法的好处，直到遵循依赖性。

当您开始从封装和编排的角度来看待您的转换时，您开始看到每种方法都只是在不同程度上攻击同一问题的不同方式。

当您开始在封装和管弦郎之间取得平衡时，您可能会意识到您的理想终止是某种多种方法环境，这取决于团队的需求及其应用。

无论哪种方式，一旦你在这个心态，你就可以开始做出更好的决定来让你到你想要的最终状态，并且你可以做出关于休息的依赖关系的战略决定。同时，您可以控制到位，最大限度地在组织的部件中最大化敏捷性，在那里您仍然存在依赖关系，直到它是时候弃用这些控件。

依赖的组织影响

不了解如何平衡封装和编排的组织没有可行的管理或解决依赖项。因此，他们不可避免地充满了向方法和团队级别和工作级实践加倍。他们最终无法在其他基本的构建块上交付。

Because when you have unmanaged dependencies, you’re not going to be able to establish a stable velocity at the team level, so the organization isn’t going to know how much demand to put into the system, so the net effect is that the organization is going to overload it.

当您无法了解团队对已知积压的能力时，它使得在基于系统的已知能力之后，我们非常困难地提出知情的投注和权衡，以便我们可以对它的需求达到它。

然后我们就到了团队不值得信任的地步，因此组织很难信任他们。许多敏捷专家说，我们需要信任团队，但我们真正的意思是，我们需要让团队处于可以信任的位置。这主要意味着我们必须为它们创造合适的条件，这意味着我们必须创造一个将它们封装在其中的生态系统。

依赖性会扼杀敏捷性，因此，您必须找到一种方法将它们封装在团队中，或者找到一种方法来协调它们。