交付系统:我们的治理模型简介
乍一看，我们的治理模型和团队设计可能有点复杂。然而，在我们的交付系统中有很多意图，以确保您在正确的时间解决正确的问题，以最大限度地提高吞吐量和交付给客户的价值。
在本次演讲中，我们的首席方法论家Dennis Stevens将为您消除这些干扰，并带领您了解我们的治理模型和团队设计，以帮助您更好地理解LeadingAgile交付系统。
视频记录
所以我今天要讲的,我将谈论我们的交付系统,内置的意向性解决遇到的问题,组织的类型,使其难以应对市场,困难的顾客交付价值。
当您第一次看到我们的治理模型或我们的一些团队设计时，它可能看起来很复杂，可能看起来真的很忙。但有趣的是，如果你能理解治理模型和团队设计如何确保我们在正确的时间解决正确类型的问题，以最大限度地提高吞吐量——最大化交付给客户的价值——它就开始变得更有意义了。
我来简单讲一下。
我们讨论了实现敏捷的目标。简单地讲一下:可预测性，质量，早期投资回报率，低成本，创新和产品适合。你会听到我们谈论你交付的方式是通过设计你的组织来有效地定义治理——我们管理组织中价值流动和做出经济权衡决策的方式。
我们谈论结构——我们如何组建团队以及团队如何相互作用——是清晰的，我们谈论拥有正确的度量标准和工具。但我们实际上解决的是什么问题呢?有我们将要讨论的五类问题可能会阻碍一个组织解决问题。
第一个是关于风险的，更确切地说是关于范围的。我们是否解决了正确的问题?为了得到正确的结果，我们是否投入了正确的工作组织。在组织中发生了一件非常有趣的事情我们花了大量的时间试图弄清楚范围，我们没有注意到其他一些类别。
我们是否了解我们的能力以及我们投入到系统中的工作量的影响以及我们的可预测能力以及我们实际能交付多少?所以我们必须能够谈论能力并真正了解我们能做多少工作。
我们倾向于做出战略决策和项目决策，这些决策不被所涉及的技术债务或技术发现的数量所通知，直到决策过程的后期。所以我们希望能够这些技术债务以及早期的技术发现对话，在正确的层次上分解工作并将其输入系统。
然后依赖，依赖会害死我们。最终，我们想要摆脱所有的依赖关系，但当我们做不到这一点时，我们必须非常有意识地确定我们什么时候识别它们，什么时候管理它们。
最后一个是解的质量。我们什么时候才能知道他们的产品是否解决了问题?我们什么时候才能知道它是否会像设计的那样工作?在很多情况下，我们都知道，在解决这个问题的时候已经太晚了。
所以，如果我们看看我们的治理模型这个四层治理模型，首先要弄清楚的是治理这个词在很多组织中都是超负荷的。很多人将治理看作是，“您需要完成什么工件?”有哪些行为，你需要上交什么样的检查表?”
要真正清楚地说明，这里的治理模型从控制工件的移交和责任转移到让组织关注价值流。试图创造周围的意向性是谁在什么时候进行对话，设计交付方式，这样我们才能获得尽可能多的价值。
我们也做这些团队设计。谁是投资组合团队成员，谁是产品团队成员，谁是交付团队成员?所以当他们作为工作流程通过这种方式，他们将治理模型分层。房间里有合适的人，有合适的谈话。因此，我们的治理模型和我们的团队设计，与治理模型交互，关注价值流，并管理这五类风险，就是我们的治理模型和团队设计做．
我们谈论的是交付系统，这是我们正在努力的方向。
我将对三层治理模型做一个简单的演练，以展示如何做到这一点工作流程通过。然后我会详细讲解这五种风险是处理。因此，这是治理模型的三层版本。投资组合团队得到了史诗般的成就。它可能来自于产品团队的协作，也可能来自于组织外部，但是一个史诗般的项目组合对齐开始了。在与产品团队和接收人员的交谈中，我们关注的是获得一项协议．这是我们接下来要做的最重要的事情吗?这是我们真正需要解决的问题吗?我们明白问题所在了吗?
这个史诗然后转移到投资组合的优先级，基于一个高层次的估计和所有其他在管道中的事情，以及我们当前的能力，这是组织开始分解的下一个最重要的事情吗?
随着这一史诗般的过程转移到解决方案定义，我们开始将其分解为详细的特性。我们实际上要引入到组织中的改变来实现史诗中定义的结果。
随着完成这些功能的能力开始可用，我们将把这些功能转移到发布计划中。
所以这里你看到了两个特性和发布计划，我们正在分解故事和那些特性，开始为它们做好准备。这部史诗巨作已被定为发行目标。我们已经想好什么时候交付了。我们现在开始与团队互动来分解故事。当我们开始完成故事并为消费做好准备时，一旦这个特性中的所有故事都准备好了，这个特性就会转移到“特性准备好了”，我们就可以开始构建史诗了。
在这里，我们看到了一个史诗过程，交付团队正在构建故事……完成其中的所有故事……将其完成。当故事完成时，你会看到功能转移到“功能验证”。我们已经完成了所有的功能，所有的功能都完成了。我们验证了史诗，史诗移动到完成．
这里有一些重要的东西。一个是，我们试图在这个过程中保持工作不变。我们并不是在第一天就开始写每一个特性，然后在最后一天提交它们。所以这些特征的顺序是很重要的。
同样，通过像这样使工作可见，并且有我们的会议节奏和清晰的规则，我们知道在我们开始编写代码之前，用组合优先级完成意味着什么。我们不会开始编写代码，我们会在运行过程中找出问题并实时解决它们，因为这在大型、复杂的组织中是不现实的。
我们把它分解一下。五种类型的风险:我们解决的问题正确吗?我们是否基于我们的能力对组织进行可预见的最大价值的优化?我们的技术堆栈是推动还是阻碍了变革的步伐?我们是否跨解决方案组件进行编排?我们的解决方案是否解决了定义的问题它是否像预期的那样工作。
当我们进入“我们解决了正确的问题吗?”，有很多产品管理工作可以做，这里你可以看到22个潜在的工件的列表，可能正在被建立。有些是为每一部史诗而建的。他们中的许多人是坚持不懈的，但是在我们围绕它进行对话的时候被提到。围绕每一件作品。我们要讲的一个例子是，在投资层面有一个机会讨论为什么这是我们追求的市场，解决这个市场意味着什么以及这个机会对公司有多重要。
在投资组合层，我们正在把机会画布变成史诗——一个我们将交付给市场的结果，这将帮助我们实现市场战略。在程序层，他们将史诗分解成功能。我们需要向市场提供什么样的功能，才能实现我们想要的战略。这些都是相互联系的。
因此，重要的是，通过理解在哪里产生这项工作，以及在各个层之间发生了哪些协作，我们实际上知道了什么工件，什么人员事先要做什么，要带来什么——以确保我们产生了共享的理解。
同样，这非常重要:目标不是生成工件。我们的目标是确保我们在正确的时间有正确的信息进行正确的对话。这就是我们在治理模式中实施的。
当我们开始讨论容量风险时，我们遇到的挑战有一个练习我们有时称之为飞机游戏在飞机游戏中是3号站。
这四个站的工作要经过所有四个站才能到达客户，而第三站有很多工作要做。他们的工作比另一个站更难做。所以当我们开始模拟的时候，你会发现在某个时间点，大量的工作开始堆积起来。这意味着在某个时间点之后，很难预测下一项工作何时会通过系统。因为它被三号站的一堆飞机挡住了。您可以想象这是一个组织中的开发人员、需求或测试。重点是，向系统中注入物质的速度比向系统中抽出物质的速度快会使系统变得非常不稳定。这使得预测变得非常困难。而且，越早开始工作反而会让你慢下来，产生问题。它不会加快你的速度。
我们对看板的可视化让您开始了解您的最大吞吐量是多少，以及组织中实际的工作状态是什么。在3号基地，在3号站堆积的工作，在这个例子中，在3号站，实际上是使系统不稳定，不可预测，影响质量的工作，并且使人们普遍感到痛苦。
我们想做的是，我们想平衡产能和需求。所以我们需要了解我们的能力是什么。我们需要以我们可以追求的速度向系统做功。看板帮助我们做到这一点。治理模型使之成为可操作的。我们遇到的另一个问题是,当我们有多项工作要做的时候，这些工作都是同等重要的。
在这个例子中，您可以看到我们正在通过一个团队处理所有三个工作，所有的工作都在同一时间完成，所有的工作都在Period 9中交付。这样做会让我们失去所有的选择。没有办法申请学习．我们没有办法真正测试和验证我们所构建的是正确的东西，直到最后。所以我们想要做的是，我们想要以一种更有凝聚力的方式进行工作。
这限制了在制品和制造工作流程．遵循治理模型可以帮助我们实例化这个新组织。它也开始让我们真正明白我们的能力是什么以及何时应用它。这里有一个例子，我们已经完成了工作，我们已经交付了第9期的所有内容。另一个例子是实际工作和完成工作，计划工作完成和完成它，这完成了一切在理论上讲，和之前的版本是同一时间。实际上，它可能完成得更快，因为我们不必处理增加的协调和任务切换的影响，以及同时处理所有事情给整个组织带来的负担——所以，我们实际上可能会更快地完成工作。
我们通过这种方式得到的另一件事是，我们开始获得适应各种选择的能力。我们完成了A。中途，一个关键的新需求出现了。在这个例子中，它是D，我们可以在D的基础上工作，而且它不会干扰任何工作。然后我们可以继续工作，做低优先级的特性，并完成我们的工作。
在这种情况下，我们仍然能够按时交付B和C。事实上，因为我们最小化了B项目的工作量，这就为我们创造了完成a项目的能力，所以我们仍然按时完成了所有的工作。我们在系统中创造了一些适应性。这就是我们学习管理能力的方法。
在治理模型中，这来自于理解功能何时完成，我可以多频繁地在后台交付工作测试产品，不仅仅是我可以多快地编写代码，而是我可以多快地准备好交付它。然后我们在做发布计划和故事映射时使用这些信息。我们的治理模型实例化了流，但也为我们提供了有效管理流所需的数据。
这是一个关于精益度量和我们将要测量的问题的数据类型的例子——从把所有的东西都推到这个流模型，你会看到整个组织的所有这些度量的改进。
技术债务和发现问题是，通常当我们开始工作时，我们不仅不知道容量，我们已经定义了技术上不知道的策略。我们不知道我们的努力将是为了发现或技术债务的阻碍。而且，我们真的没有足够的时间来预先做这类研究。那么，当我们在组织中流动工作时，我们如何有效地进行计划呢?
还有几件事我们要讨论的是一个技术权衡矩阵那就是:好吧，我正在进行的这项工作，它改变了我系统的这一部分。相对于未来所需的变化步伐，我的架构适用性在哪里?如果它是糟糕的架构，它就不太容易改变，但我们不会经常改变它。我们将采取不同的方法尝试修复体系结构和管理技术债务。
如果它是一个破损的架构，但是改变的步伐将会非常快，我们需要在模型中建立时间去发现和修复技术债务。这个权衡矩阵允许我们在解决方案验证时进行对话，开始真正弄清楚对这项工作和其他工作的影响。
往往会扼杀组织的一件事是，无论是在代码开发中，还是在测试中，都没有为技术债务的影响做计划。我一会儿也会讲到测试。但是,通过晚些时候发现这些东西，并且已经让我们的组织完全致力于未来，任何减慢我们速度的事情都会自动导致一个问题，使容量问题变得更糟。所以，通过真正清楚我们什么时候需要管理技术债务，并在将工作提交到系统中之前进行这些对话，我们可以更好地管理我们的流程。
我们看依赖关系。我们也在寻找解决方案验证，并一直到工作就绪，真正理解依赖关系在哪里，我们如何排序工作，以最大限度地提高功能流程和史诗。在我们对任何一项工作做出承诺之前，我们已经召集了所有合适的人，进行非常强烈的对话，并告知工作的先后顺序。
所以我们的治理模式让这一点非常明确解决方案验证、故事映射和工作准备。然后我们开始对产品进行测试。测试有很多种类型——测试象限在敏捷社区中得到了广泛的应用。在一个完美的世界里，一个团队可以按下一个按钮，在最后一分钟运行所有这些测试，我们总是知道我们在哪里。务实地说，这在组织中是行不通的。因此，关键是，在解决方案验证、解决方案展望和需求计划中，我们必须讨论我们需要如何减缓工作，以最大限度地进行测试和修正，而不仅仅是构建代码。这里有一个例子，我们取测试象限的不同象限讨论它们在工作中什么时候发生，这些定义已经成为工作在通过系统之前完成的意义的一部分。
再一次，首先看看治理模型，它看起来真的很忙。如果不理解在正确的时间和正确的人一起做出正确的决定以确保你在组织中最大化价值之间的意图是很难理解的。看看导致我们失败的五类事情:不明确的范围，不平衡能力和需求，不考虑技术发现和债务，不管理依赖性，不验证我们的工作，直到为时已晚。所有这些在工作的状态，谁需要参与，会议的节奏中都会变得非常清晰是．
因此，我们的治理模型、我们的团队设计和我们的度量标准一起创建了一个系统，该系统明确地、有意地管理那些倾向于使组织在产品工作中失败的事情。