跳转到主要内容

保存的帖子

交付系统:我们的治理模型简介

Dennis Stevens |领导敏捷
丹尼斯史蒂文斯
阅读: 交付系统:我们的治理模型简介


乍一看,我们的治理模型和团队设计可能有点复杂。然而,在我们的交付系统中有很多意图,以确保您在正确的时间解决正确的问题,以最大限度地提高吞吐量和交付给客户的价值。

在本次演讲中,我们的首席方法论家Dennis Stevens将为您消除这些干扰,并带领您了解我们的治理模型和团队设计,以帮助您更好地理解LeadingAgile交付系统。

查看丹尼斯的系统的交付甲板

视频成绩单

So what I’m going to talk about today, I’m going to talk about our system of delivery and the intentionality that’s built into it to solve the types of problems that organizations run into that make it difficult for them to respond to markets, difficult for them to deliver value to their customers.

当您第一次看到我们的治理模型或我们的一些团队设计时,它可能看起来很复杂,可能看起来真的很忙。但有趣的是,如果你能理解治理模型和团队设计如何确保我们在正确的时间解决正确类型的问题,以最大限度地提高吞吐量——最大化交付给客户的价值——它就开始变得更有意义了。

我来简单讲一下。

我们谈论敏捷的目标。刚刚简要介绍,走过这一点,你知道:可预测性,质量,早期投资回报率,较低的成本,创新产品适合。你会听到我们谈论你交付的方式是通过设计你的组织来有效地定义治理——我们管理组织中价值流动和做出经济权衡决策的方式。

我们谈论该结构 - 我们如何形成团队以及团队如何共同互动 - 很清楚,我们谈论拥有正确的指标和工具。但我们实际解决了什么问题?我们将要讨论的五类问题可能会阻碍一个组织解决问题。

第一个是关于风险的,更确切地说是关于范围的。我们是否解决了正确的问题?为了得到正确的结果,我们是否投入了正确的工作组织。在组织中发生了一件非常有趣的事情我们花了大量的时间试图弄清楚范围,我们没有注意到其他一些类别。

我们是否了解我们的能力以及我们投入到系统中的工作量的影响以及我们的可预测能力以及我们实际能交付多少?所以我们必须能够谈论能力并真正了解我们能做多少工作。

我们倾向于做出战略决策和项目决策,这些决策不被所涉及的技术债务或技术发现的数量所通知,直到决策过程的后期。所以我们希望能够这些技术债务和技术发现谈话早期和在正确的水平上,正如分解工作并通过系统喂养它。

然后依赖,依赖会害死我们。最终,我们想要摆脱所有的依赖关系,但当我们做不到这一点时,我们必须非常有意识地确定我们什么时候识别它们,什么时候管理它们。

最后一个是解的质量。我们什么时候才能知道他们的产品是否解决了问题?我们什么时候才能知道它是否会像设计的那样工作?在很多情况下,我们都知道,在解决这个问题的时候已经太晚了。

所以,如果我们看看我们的治理模型这个四层治理模型,首先要弄清楚的是治理这个词在很多组织中都是超负荷的。很多人将治理看作是,“您需要完成什么工件?”有哪些行为,你需要上交什么样的检查表?”

要真正清楚地说明,这里的治理模型从控制工件的移交和责任转移到让组织关注价值流。试图创造周围的意向性是谁在什么时候进行对话,设计交付方式,这样我们才能获得尽可能多的价值。

我们也做这些团队设计。谁是投资组合团队成员,谁是产品团队成员,谁是交付团队成员?所以当他们作为工作流程通过这种方式,他们将治理模型分层。房间里有合适的人,有合适的谈话。因此,我们的治理模型和我们的团队设计,与治理模型交互,关注价值流,并管理这五类风险,就是我们的治理模型和团队设计

我们谈论的是交付系统,这是我们正在努力的方向。

我将对三层治理模型做一个简单的演练,以展示如何做到这一点工作流程通过。然后我会详细讲解这五种风险处理。所以这是治理模型的三层版本。投资组合团队获得史诗。它可能与产品团队合作,它可能来自组织以外,但史诗开始于投资组合对齐。在与产品团队和摄入的事情谈话中,我们专注于获得达成协议.这是下一个最重要的工作,这是我们实际需要解决的问题吗?我们理解这个问题?

这个史诗然后转移到投资组合的优先级,基于一个高层次的估计和所有其他在管道中的事情,以及我们当前的能力,这是组织开始分解的下一个最重要的事情吗?

由于史诗移动到解决方案定义,我们开始将其分解为详细的功能。我们实际上要介绍该组织的变化,以实现史诗中所定义的结果。

随着容量开始才能使用这些功能,我们将将功能移动到释放规划中。

所以这里你看到了两个特性和发布计划,我们正在分解故事和那些特性,开始为它们做好准备。这部史诗巨作已被定为发行目标。我们已经想好什么时候交付了。我们现在开始与团队互动来分解故事。当我们开始完成故事并为消费做好准备时,一旦这个特性中的所有故事都准备好了,这个特性就会转移到“特性准备好了”,我们就可以开始构建史诗了。

在这里,我们看到了一个史诗过程而且交付团队正在建立故事......完成其中的所有故事......移动它。并且在故事结束时,您将看到功能移动到“功能验证”。我们拥有超过的所有功能,并完成所有功能。我们验证了史诗,史诗搬到了完全的

这里有一些重要的东西。一个是,我们试图在这个过程中保持工作不变。我们并不是在第一天就开始写每一个特性,然后在最后一天提交它们。所以这些特征的顺序是很重要的。

此外,通过使工作如此可见,并具有我们的会议和规则清晰度的节奏,我们知道在我们开始编写代码之前,请参阅投资组合优先级的方法是什么。我们没有启动代码,我们会弄清楚我们的问题,并实时解决它们,因为这在大型复杂的组织中刚刚不可思议。

所以我们稍微打破这一点。五种风险:我们是否解决了正确的问题?我们是否以根据我们的能力优化可预测地通过组织提供最大价值?我们的技术堆栈是否启用或阻碍我们的变化步伐?我们是否在协调我们的解决方案组件?并且,我们的解决方案是否解决了定义的问题,并根据预期工作。

当我们进入“我们解决了正确的问题吗?”,有很多产品管理工作可以做,这里你可以看到22个潜在的工件的列表,可能正在被建立。有些是为每一部史诗而建的。他们中的许多人是坚持不懈的,但是在我们围绕它进行对话的时候被提到。围绕每一件作品。我们要讲的一个例子是,在投资层面有一个机会讨论为什么这是我们追求的市场,解决这个市场意味着什么以及这个机会对公司有多重要。

在投资组合层,我们正在把机会画布变成史诗——一个我们将交付给市场的结果,这将帮助我们实现市场战略。在程序层,他们将史诗分解成功能。我们需要向市场提供什么样的功能,才能实现我们想要的战略。这些都是相互联系的。

因此,重要的是,通过理解在哪里产生这项工作,以及在各个层之间发生了哪些协作,我们实际上知道了什么工件,什么人员事先要做什么,要带来什么——以确保我们产生了共享的理解。

再次,它非常重要:目标不是产生伪影。目标是确保我们有正确的对话,在正确的时间内具有正确的信息。这就是治理模型所强迫的。

当我们开始讨论容量风险时,我们遇到的挑战有一个练习我们有时称之为飞机游戏在飞机游戏中是3号站。

这四个站的工作要经过所有四个站才能到达客户,而第三站有很多工作要做。他们的工作比另一个站更难做。所以当我们开始模拟的时候,你会发现在某个时间点,大量的工作开始堆积起来。这意味着在某个时间点之后,很难预测下一项工作何时会通过系统。因为它被三号站的一堆飞机挡住了。您可以想象这是一个组织中的开发人员、需求或测试。重点是,向系统中注入物质的速度比向系统中抽出物质的速度快会使系统变得非常不稳定。这使得预测变得非常困难。而且,越早开始工作反而会让你慢下来,产生问题。它不会加快你的速度。

我们对看板的可视化让您开始了解您的最大吞吐量是多少,以及组织中实际的工作状态是什么。在3号基地,在3号站堆积的工作,在这个例子中,在3号站,实际上是使系统不稳定,不可预测,影响质量的工作,并且使人们普遍感到痛苦。

我们想做的是,我们想平衡能力和需求。所以我们需要了解我们的能力。我们需要按照我们可以追求的速度投入系统。Kanban帮助我们这样做。治理模型使得可行。我们遇到的另一个问题是,当我们有多项工作要做的时候,这些工作都是同等重要的。

在这个例子中,您可以看到我们正在通过一个团队处理所有三个工作,所有的工作都在同一时间完成,所有的工作都在Period 9中交付。这样做会让我们失去所有的选择。没有办法申请学习.我们没有办法真正测试和验证我们所构建的是正确的东西,直到最后。所以我们想要做的是,我们想要以一种更有凝聚力的方式进行工作。

这限制了在制品和制造工作流程.遵循治理模型可以帮助我们实例化这个新组织。它也开始让我们真正明白我们的能力是什么以及何时应用它。这里有一个例子,我们已经完成了工作,我们已经交付了第9期的所有内容。另一个例子是实际工作和完成工作,计划工作完成和完成它,这完成了一切理论上讲,和之前的版本是同一时间。实际上,它可能完成得更快,因为我们不必处理增加的协调和任务切换的影响,以及同时处理所有事情给整个组织带来的负担——所以,我们实际上可能会更快地完成工作。

我们通过这种方式运行的另一件事是开始获得适应选项的能力。所以我们已经完成了。部分是一项批判新的要求进来了。在这种情况下,我们可以在D,而且在不扰乱任何工作的情况下都是如此。然后,我们可以继续通过,并在完成完成后完成较低的优先级功能。

在这种情况下,我们仍然能够按时交付B和C。事实上,因为我们最小化了B项目的工作量,这就为我们创造了完成a项目的能力,所以我们仍然按时完成了所有的工作。我们在系统中创造了一些适应性。这就是我们学习管理能力的方法。

在治理模型中,这来自于理解功能何时完成,我可以多频繁地在后台交付工作测试产品,不仅仅是我可以多快地编写代码,而是我可以多快地准备好交付它。然后我们在做发布计划和故事映射时使用这些信息。我们的治理模型实例化了流,但也为我们提供了有效管理流所需的数据。

这是一个关于精益度量和我们将要测量的问题的数据类型的例子——从把所有的东西都推到这个流模型,你会看到整个组织的所有这些度量的改进。

技术债务和发现问题是,通常当我们开始工作时,我们不仅不知道容量,我们已经定义了技术上不知道的策略。我们不知道我们的努力将是为了发现或技术债务的阻碍。而且,我们真的没有足够的时间来预先做这类研究。那么,当我们在组织中流动工作时,我们如何有效地进行计划呢?

还有几件事 - 有一种技术权衡矩阵,我们将谈论这是:好的,这是我穿过的工作,它正在改变我系统的这一部分。它在哪里符合建筑的适用性相对于未来所需的变化步伐?如果它是较差的架构,那么改变并不是很容易,但我们不会经常改变它。我们将采取不同的方法修复体系结构和管理技术债务。

如果它是破碎的架构的东西,但变化的步伐会很高,我们需要在模型中建立时间,以便去做这种发现和修复技术债务。这种权衡矩阵允许我们在解决方案验证时进行对话,开始真正弄清楚这项工作的影响以及飞行中的一切。

往往会扼杀组织的一件事是,无论是在代码开发中,还是在测试中,都没有为技术债务的影响做计划。我一会儿也会讲到测试。但是,通过晚些时候发现这些东西,并且已经让我们的组织完全致力于未来,任何减慢我们速度的事情都会自动导致一个问题,使容量问题变得更糟。所以,通过真正清楚我们什么时候需要管理技术债务,并在将工作提交到系统中之前进行这些对话,我们可以更好地管理我们的流程。

我们看依赖关系。我们也在寻找解决方案验证,并一直到工作就绪,真正理解依赖关系在哪里,我们如何排序工作,以最大限度地提高功能流程和史诗。在我们对任何一项工作做出承诺之前,我们已经召集了所有合适的人,进行非常强烈的对话,并告知工作的先后顺序。

所以我们的治理模式让这一点非常明确解决方案验证、故事映射和工作准备。然后我们开始对产品进行测试。测试有很多种类型——测试象限在敏捷社区中得到了广泛的应用。在一个完美的世界里,一个团队可以按下一个按钮,在最后一分钟运行所有这些测试,我们总是知道我们在哪里。务实地说,这在组织中是行不通的。因此,关键是,在解决方案验证、解决方案展望和需求计划中,我们必须讨论我们需要如何减缓工作,以最大限度地进行测试和修正,而不仅仅是构建代码。这里有一个例子,我们取测试象限的不同象限讨论它们在工作中什么时候发生,这些定义已经成为工作在通过系统之前完成的意义的一部分。

再一次,首先看看治理模型,它看起来真的很忙。如果不理解在正确的时间和正确的人一起做出正确的决定以确保你在组织中最大化价值之间的意图是很难理解的。看看导致我们失败的五类事情:不明确的范围,不平衡能力和需求,不考虑技术发现和债务,不管理依赖性,不验证我们的工作,直到为时已晚。所有这些在工作的状态,谁需要参与,会议的节奏中都会变得非常清晰

因此,我们的治理模型,我们的团队设计,我们的指标汇集在一起​​创建一个系统,明确,故意管理倾向于使组织在产品工作中失败的事情。

下一个>质疑敏捷教条

作为敏捷首席运营官和联合创始人,Dennis Stevens在过去25年里一直在帮助企业解决与更大、更复杂的企业产品开发相关的挑战——在许多全球企业中领导了重大项目和敏捷转型。他帮助将敏捷引入PMI:担任PMI敏捷认证执行者的指导委员会成员,担任PMI全球实践社区的前任领袖,目前是项目管理知识体系的软件扩展副主席。

发表评论

您的电子邮件地址将不会被公布。必填字段被标记*