利用敏捷可预测
敏捷不是真的关于敏捷。这是关于创造业务结果。亚博vip9通道
在我们的业务驱亚博vip9通道动程序驾驶员驾驶员驾驶员，迈克科尔梅勒Mike Cottmeyer，Mike深入了解六个关键的企业司机，以发现敏捷如何使组织能够将这些驱动程序连接到更好的业务结果。
在这个第一个网络研讨会中，我们从可预测性开始。尽管我们倾向于将敏捷性视为几乎是适应性的代名词，但我们看到组织的最常见目标之一是实际上可预测性。
好消息是，转型的许多方面是可定义的和可重复的，所以它们可以是可预测的。在这个网络研讨会中，我们讨论如何创造更多的可预测性，以便我们能够满足我们对客户的承诺，并与来自内部利益相关者的所有人建立信任，向客户提供整个市场。
查看可预测性网络研讨会，然后单击下面的访问接下来的五个网络研讨会，这些研讨会涵盖了五个额外的随需应变业务驱动因素，包括：质量、成本节约、早期投资回报率、产品适配性和创新。亚博vip9通道
成绩单
所以，有趣的是在最后一个网络研讨会系列和这个网络研讨会系列中，我们真正做的是我们真的又回到基础知识。所以最后一次，我们谈到了平衡能力和需求和处理信任和可信度的问题，这些想法处理您所知道的与您不知道的事情以及封装与管制的想法。我们通过了。
蒂姆是要去如果你们是不是网络研讨会系列的一部分人后来落个链接给你，因为我觉得我们要引用一些。但是，他的想法是，让我们继续前进，让我们开始探索一些的真正基础的东西是什么让敏捷的工作，让他在范围内工作，什么是我们真正想要实现，正确的，这样的东西。所以，我认为我们会做的是一种沿着主题这里未来六周，并谈了一些引起我们想采用敏捷的司机继续。
我认为很有趣的一件事是，在过去的10年，15年，甚至可能是，我们听到我们谈论的一些事情，在我们的社区中优先考虑的事情，已经有了一些反应。我想我们很多人有时候会迷恋敏捷文化，或者敏捷思维，或者敏捷为我们创造的工作环境。所有这些都是千真万确的。我们希望为优秀的员工创造良好的工作环境，让他们能够为自己效力的公司尽自己最大的努力。
但是很多时候，我们现在在哪里，我的意思是，它只是有趣的，我们就像20年的几乎到签署敏捷宣言。和那些签署那件事的人，他们改变了世界。他们做了很大的工作，让消息出来scrum，Scrum认证做了很大的工作。我们开始看到写作的HBR文章。我认为他们在过去几年中有两三个。而且不仅像CIO有兴趣但首席执行官都很兴趣，而且财务人员对产品感兴趣，人们都对市场感兴趣，还有很多感兴趣的东西。
所以通常会发生什么会发生的是我们有这种假设，我们说，如果......从笔来到这里，对吧？那么，如果我们做敏捷，对吧，我们要去获得业务结果，好吗？亚博vip9通道那是一个假设。然后我们说，“好的，好吧，这真的是什么意思？”这是否意味着我们改变文化，对吧？这是否意味着我们开始做Scrum，对吧？如果我们出现，我们会出现冲刺和日常立场和一切，我们将获得我们想要的业务结果吗？亚博vip9通道好吧，答案是，大多数事情，这取决于。
如果你是一个小团队，如果你是一个6到8人的公司，你可能会从计划和Scrum案例中获得大量的商业利益。亚博vip9通道采用一种适应性的文化可能会给你带来很多商业利益。亚博vip9通道但是我们学到本能地在过去的10年是当你进入特别大,复杂的组织,采用这些实践或采用的心态并没有真正把业务结果,我们想要的,因为我们知道,对吧,因为很多人,我想如果你在这里,亚博vip9通道在这些大型机构工作有很多东西根本就坏了。
所以，从我们如何治理，我们如何做项目规划，我们如何做组织结构，所有这些事情，对，所以这是一个大飞跃。很多时候我提到，有一幅漫画，我应该把它准备好，因为我一直在谈论它。两个科学家坐在董事会上这里有一堆数学运算这里也有一堆数学运算中间有一团云在说，奇迹发生了。一个科学家对另一个说，我认为你在第二步需要更具体。这有点像我们从这个想法开始如果我们做这些事情，就会得到这些商业结果但并不总是那样的，对吧?亚博vip9通道
所以，这就是我们如何从敏捷获得对业务结果真的是第二步在我的说法，对不对？亚博vip9通道这是我们该怎么做呢？所以我们整个的模型，一切，我一直在很长一段时间来谈论是关于你如何摆脱它在哪里成为什么样的组织，可以采取这些驱动程序的优势，对一个组织？所以这就是我们进入最后一次，对吗？
我们讨论了如何平衡团队层面的能力和需求和组合层面的程序，以及封装、编排和依赖等问题。因为这些东西从根本上阻碍了我们如何治理，如何处理交叉问题。这些都是阻碍Scrum在许多组织中不起作用的因素。所以这些事情很难克服。
所以这就是我们开始的地方。The six things that we’re going to cover, and there’s probably more as I was actually noodling on kind of an outline for what I wanted to go over, is we’ve learned… I’ll go through the six that we’re going to cover and then maybe we can [inaudible 00:05:52] and go a little bit more. But what we’re going to talk about today is the idea of predictability, okay? And so, predictability is really all about figuring out how to make and meet commitments and how to do what you say you’re going to do. So we’ll go deep into this one today.
下周我们要讲的是质量，对吧?敏捷如何带来更好的质量，不仅仅是接受它可以带来更好的质量的事实，而是字面上的，敏捷的机制是什么，敏捷实践如何带来质量?
投资早期回报率，好吗？所以我们谈到能够将产品放在客户面前，并能够获得反馈，而是落后的大型司机是我们希望在客户面前提前销售产品，以便我们可以销售，使组织可以开始接收资金those and fund further development because it’s a pretty expensive proposition to do three to four years of development, excuse me, or even a year and a half of development or, gosh, even at this point, six months of development without getting any validation or revenue out of that.
因此，我们将讨论敏捷企业或敏捷的各个方面将导致投资早期回报。然后是一个有趣的，这将是我可能会在一点点跳舞的那个，是我们正在寻找的很多次是节省成本。所以，节省成本很难，因为大多数组织都是真的，真的过载。因此，还有10倍的工作要做而不是组织实际上。
所以，真的很难进来说，是的，敏捷将帮助我降低成本，所以你开始谈论吞吐量和最高价值，并部署资源，人力和金钱等东西，到最有价值的东西，对吗?亚傅体育app所以我们在节省成本的问题上摇摆不定。这是我最初的四个。这些是我在八到十年前谈论的第一批。
然后我们有点进步，我们开始谈论创新，对吧，因为这是人们想要的一件大事，对吧?那么我该如何利用这个传统的组织，使它更有创新性，使它有能力扰乱市场甚至蚕食我们现有的业务，对吧?亚博vip9通道因此，有一些敏捷模式和敏捷规模要么导致创新，要么导致创新，我们将讨论这个问题。
产品匹配的理念。我们是否建立了我们的市场想要购买的正确的东西，我们如何知道，对，这种东西？然后，当我们深入到Tim之前提到的提升敏捷对话中时，真正吸引人的是，我们正在与高管们讨论他们关心的是什么，我们开始讨论一些事情，我可能会称之为战略协调，对吗？
我们如何以最大化我们推进战略目标的能力最大化的方式部署组织？敏捷有话要说。这不是我进入产品的特点，但它是关于我组织开发的能力以及我在哪里投资美元，以便我能够实现这些大市场转移种类的目标，右。
然后最后一个，我在想一点，我有点看着我的笔记，所以我们谈论战略对齐。这可能是一件事，我没想到这一点清楚，但我几乎想要这些话，我想使用等投资优化。所以，很多时候，这就像我们对我们想要做的事情真的很好看，但这真的是它的MVP是什么？我们可以做的最小的事情是实现价值，因此我们使得最小的投资可以最大限度地提高市场的投资回报率？
所以我打算把类似的东西价值优化在这里，好不好。因此，似乎就没有今天的家伙在你面前拼。所以，这两个将要出的那种范围。但是，我们要打击的，我们要打击预测性，质量，早日回报的投资，节约成本，创新和产品契合。今天，我们将开始与可预测性。和的事情之一，我想了很多，对不对，这是值得人们问我不少。他们不问我这个问题了像我如何才能有兴趣做我的敏捷高管，因为这就像一个七，八年前的问题。
这在某些时候对某些人来说是相关的但不是主要的问题。主要的问题是我如何让我的高管在这方面花钱或者我如何让我的高管完全参与到转型中来?我怎样才能让我的主管们真正关心我，投入时间和精力，去参加会议等等?总的来说，答案是我鼓励人们谈论高管们真正关心的事情，以及让他们夜不能寐的事情。
有时我会把可预见性的概念放到，你想想你的CEO，你的CEO或CIO或任何对市场做出承诺的人。他们告诉客户公司有能力做什么。他们依赖于这样一个事实:所有的计划过程、所有的项目管理、所有的敏捷或其他任何东西，都将帮助他们做出承诺，明白吗?他们关心这一点是因为当高管对市场做出承诺时交付机构却没有违背这些承诺，那么CEO实际上是对市场撒谎了，对吧?
也许没有故意显然，但这是他们没有交付。那是个人的东西，对吗？人们不喜欢在他们做出承诺的情况下，他们不能保留它。所以，从一个非常人性化的角度来看，我们想要做的是，我们希望把我们的管理人员在一个位置，该组织是一个可靠的，值得信赖的合作伙伴，高管可以合理肯定地说，这就是我们能够提供的和这是我们能够提供它的时候，好吗？因此，可预测性的想法就是我在说的话。
所以，再一次，如果你在我们做的前几次演讲，最后一系列的演讲，不可避免地会有重复的主题。所以我想在接下来的六个星期里我们要做的是讨论一些共同的主题，如果你关注我的东西，我一次又一次地讲，但是我们要把不同的视角放在它们上面，好吗?当谈到可预见性时，我们要讲的第一个镜头或第一组基本的东西是三件事的想法，团队，backlog，工作测试软件。
等等，如果您想到一个可预测的敏捷团队，一个可以制定和达成承诺的团队，这将能够做到它所说的事情，对吧？该团队需求的第一件事是在积压下需要清晰。好的？这意味着，在某种形式或时尚，我们需要有一个我们将要构建的堆栈等级列表，好的，产品积压，也许是用户故事。现在，请记住，我的焦点现在是超级狭隘的。我不是在谈论企业敏捷性。我不是在谈论提升谈话。我在谈论团队水平敏捷性。
所以基本建筑块，右，团队级敏捷。我们如何获得一个团队能够制定和满足承诺，对吧？那么，团队通过堆叠用户故事堆栈排名列表来达到承诺，对吗？我们通常希望估计这些故事，对吗？我们希望能够将它们带入Sprint规划并围绕它们进行对话。该团队对他们被要求建立的东西清楚起来。他们了解验收标准。他们能说，“是的，这是我认为我们可以拉出的合理性，”对吗？
然后我们希望团队有能力负责任，对吧。所以我们要派一队人来，对吧?什么是团队?我为什么要用负责这个词，对吧?好吧，因为敏捷团队，正如Scrum指南中描述的那样，当他们说5个加减2个时，我通常喜欢用6到8个差不多。它是一群人，他们拥有一切和所有必要的东西，能够交付一个工作的，经过测试的软件增量或任何你正在构建的产品，明白吗?
所以，因为我们通常是在软件领域，6到8个人拥有所有必要的东西和每个人来构建一个工作的、经过测试的软件增量，就像待办事项列表所描述的那样，对吧?如果团队拥有一切必要的东西和每个人，能够交付工作测试增量，那么Scrum就应该按照描述的那样工作。他们从积压的工作中抽出一大块来。他们进行sprint计划，也许他们会分解工作。在冲刺的过程中，他们挤在一起。他们交付产品，然后与产品负责人讨论，产品负责人同意，然后他们就可以获得积分，对吧?
而且，再次，还有其他方法可以将猫皮肤，对吧？但是你明白了，对了吗？那是一种方式，对吧？那么，一个可以建立稳定的速度的团队，我今天不能写的，反对一个已知的积压可以开始说，“好的，很酷，”对吧？我们知道我们可以生产的每一个冲刺。为什么接受标准或完成或部署的定义甚至甚至将其扩展到我们实际上已与客户部署？为什么这重要？因为当我们到达我们有一个真正明确的定义时，我永远不知道如何绘制一个软件。有时候我想像一个盒子一样绘制，但这会变得疯狂，对吗？但是你们知道这个想法，对吧，软件。
所以数据库表，对吗？那种东西。这是一个屏幕。所以想法是我们生产这种工作的增量。验收标准是如此重要的原因是因为如果我们对此积压项目的清晰，并且我们了解其相对尺寸的想法，我们将它拉成一个完整的跨职能团队，拥有所有必需的一切和所有人能够提供这组用户故事。
我们确认它符合验收标准,满足了“完成”的定义,这意味着没有像影子积压新兴这里,基本上都是我们真的没有完成的事情,需要部署,缺陷,技术债务,未实现的功能,对吧?当你在建造东西的时候所有不同的小碎片都在积累，对吧?
如果我们不这样做，我们实际上已经完成了，那么敏捷工作的数学是在团队层面上的，对吗？所以我们知道积压的数量。我们知道一个团队的速度，然后我们就可以开始计算需要多少冲刺来完成积压工作，或者在预定的冲刺次数中我们可以完成多少积压工作，对吗？因此，这使我们能够在团队层面可靠地做出并履行承诺。现在，想想这在实践中是如何经常起作用的，好吗？
产品所有者不太在场或者产品所有者被委派给BA。BA并没有真正的决定权。待定项一开始是不确定的?如果我不知道待办事项的规模，我就无法知道我能完成多少待办事项，或者需要多少个sprint。让我们想想另一种经常发生的模式，产品负责人完全不在场，滑进sprint计划会议，就像每次sprint一样匆匆完成一些事情，对吧?
在这种特殊情况下，即使他们写了非常清楚的待办事项，我们也无法看到剩下的内容，明白吗?不同的组织对可预见性有不同的需求，对吧?在我的组织LeadingAgile中，我有一个软件开发团队，我不需要可预测性，就像不需要可预测性。我们正在构建一个内部工具。这完全是对概念的验证。我们用它作为我们咨询团队的推动者，我们对市场没有任何承诺。只要我们投资学习，我的生活就很好，只要我们取得了合理的进步，我的生活就很好，我就会继续对这个团队进行投资。
真的不同于需要在四分之一市场准备贸易展的商人的某些功能的人，真的与有成熟的客户群的人不同，并且谁需要能够发布路线图，正确的，使他们的企业级客户可以开始计划与他们加班的不同集成，对吗？因此，很多组织都不需要确切地知道他们将在哪里，但他们必须拥有一个非常好的主意，他们将在那里。
Or let’s say you’re bidding on a fixed price contract for the government or something and you’re going to be locked into fixed time, fixed costs, fixed scope, you need even more predictability, right, more ability to figure out how to make tradeoffs within constraints, and all that kind of stuff. So different organizations have different needs for predictability. So, if you’re an organization that doesn’t need any predictability, this is probably a wrong talk for you, right? If you’re an organization that needs three to six months out, this is valid strategy. If you’re an organization that needs a year or a year and a half roadmap, that’s the next level up in the conversation, right?
所以，可预测性是无处不在的。有时候我发现，这也是我们对高管的误解，高管想要的是可预测性。作为敏捷者，我们以一种非常精益的创业心态来处理它，我们说，这是敏捷，你没有可预测性，对吧?如果你是一名顾问，这肯定会让你离开公司;如果你是一名内部员工，这肯定会让你被边缘化。
如果组织想要可预测性，并且要求可预测性，并且允许您作为敏捷教练团队提供可预测性，您可能会说，“我们是敏捷的，您需要改变对可预测性的需求。”就像，“好的，很酷。”如果你想打这场仗，那就打吧，但你赢的可能性很小，明白吗?
所以一般来说,策略是满足组织的地方,这在整个转型战略,满足组织的地方,帮助它变得可预见的使用敏捷工具和技术,然后找出如何帮助减少批量大小和更迅速地做出决定,对吧?当我们讨论早期投资回报的时候我们会讲到这个?
让我们回到我们的故事，好吗?那么，让我们考虑一些反模式。所以，产品负责人来了，backlog没有很好地定义，团队不知道如何计划它，不能稳定速度，构建软件，开始在不工作的东西后面积累这些垃圾，破坏了我们的可预见性，对吧?或者，假设一切都是正确的，但是产品负责人在最后一分钟出现，给了我们一个冲刺。
Like my work in some environments would work for me, right, in LeadingAgile, my software team, but it would not work for an organization that’s trying to hit a tradeshow in a couple months, right, because we don’t know we’re it going to get. Or is trying to deliver on something that they promised the customer, it’s not going to work that way, right? So we have to put a lot of effort into grooming that backlog further out so that we can establish predictability.
在什么球队能够是可预测的，正确的方式得到？所以，我种过很大的篇幅去讲的团队是一群六到八人已经一切必要每个人都能够提供的软件测试工作的增量，好吗？所以，如果我没有什么大家和一切必要的？在某种形式的时尚，这意味着我有一个依赖。So when I have dependencies between my team and somebody else’s team, or my team and somebody else’s resource pool, then I am dependent upon them to be able to do what they say they’re going to do so that I can make and meet commitments and establish stable velocity.
所以，当我们采用敏捷时，我们努力追求的一个重要标志是，以这样一种方式将团队拉到一起，以这样一种方式设计团队，使团队拥有所有必要的东西和每个人，这样就可以建立稳定的速度。希望随着时间的推移速度是稳定的，对吧?显然会有变化，但如果你能得到一个很好的滚动平均，这可能就足够好了，让你能做出权衡，对吧?但是依赖关系，外部资源，技术依赖或各种不同的依赖关系，阻碍了建立稳定的速度。亚傅体育app
如果您无法建立稳定的速度，则无法预测。现在，这是一个非常常见的事情，对吗？所以人们说，“但是我的团队，我们就像典型的敏捷团队，”对吗？所以我们建立产品，我们支持产品，以便我们预测产品的构建方，对吧？也许我们非常擅长做用户故事和估算和释放规划级别的东西。我们真的很棒稳定的速度，我们有一个完整的跨职能团队，但我们的一部分是中断被中断驱动。
这是一个有趣的问题，对吗？因为任何时候你混合，我称之为决定性的积压和不确定的积压，然后你必须基本上部署缓冲策略，对，所以这会变得复杂。因此，很多时候，团队会做的是，如果中断/修复工作是可预测的，对吧，它是在一个平衡的流程中进行的，并且你与产品所有者有良好的关系，你只是缓冲一些时间，对吗？我见过一些团队为他们的产品开发运行Scrum，然后通过看板队列来限制过程中的工作，就像他们在一旁运行的看板队列一样。
我见过团队轮换团队成员，或者让像他这样的人负责，像他负责分类。回到我在VersionOne的时候，这个家伙，他还在那里，我想现在是CollabNet，一个叫约翰的家伙。他就像一个支持人员，所以他们会在每个sprint中为John分配一个开发人员，他们称之为John-that-sprint，我觉得这很有趣。约翰号上有一个人，但这是他们的策略，他们在团队中进行分类，让一个人单独处理大部分的中断/修复工作。
现在，如果你的软件非常混乱，你要处理大量的中断或修复的东西，而且它完全不确定，只是一个疯狂的波动，那就变成了一个不同的问题。因为现在，你将无法做出和履行承诺。所以现在你不是在说，我该如何使用Scrum，好吗?你会想，我该如何稳定我的代码库?我如何稳定我的产品，使我不处于这种情况，或者你有一个更大的问题，而不仅仅是弄清楚如何使用Scrum或组建团队之类的，对吧?
我也在那些情况下队伍，对吧？在您处理这些类型的限制时，很难成功。所以，我的许多心理模式都不说，你在面对不可能的情况下如何做斯克里姆？就像我的许多心理模型一样，这是绝对要求是可预测的，您必须为该组创建要预测的条件。
因为除非你为可预测性创造条件，否则你是不可预测的。这就是已知的积压工作，无论规划范围如何合适，都是一个稳定的跨职能团队，几乎没有依赖关系，然后能够定义“完成”，对吗？
对已完成的定义实际上是没有缺陷，潜在可交付，对吧，不同的情况是不同的，对吧?我喜欢你每两周做一次产品但在很多情况下这是不现实的，ERP和其他东西有更长的应用发布周期，对吧?但基本上，原则是让它到达一个地方你不会在后面处理这些不确定的积压，对吧?好的,很酷。
我们已经讲了一半了。我总是想知道我是否能够用整个小时来谈论这些微小的话题，但这是不可避免的，对吧?因为其中的一些原则,我也觉得自己很多时候我重复,因为就像我们一直在讨论这些想法很久了但是我仍然,蒂姆提醒我基于搜索流量和人们参与的东西,这些仍然是非常常见的问题。我要做的是，再次强调，即使它们是常见问题，它们的解也不是平凡的。
但是，再次，你们不得不带来的心态是，如果你想要敏捷，你希望它能够提供这个特殊的业务驱动程序，这种可预测性，CEO，CIO的能力和达成承诺，这些是条件亚博vip9通道你必须创造，对吗？所以现在，当你开始扩展这个对话一点点时，我们经常像这样谈论它，对吧？所以我们会说，我称之为三件事，对吧？所以我们谈到了团队，积压，工作测试软件。
我希望我将第一次把它脱落，因为积压团队工作测试的软件，因为那么我通常会如何绘制它，但它只是不是，对吧？所以它可能是一个永远的不一致，对吧？所以，团队，积压，工作测试软件。当您开始思考规模并在大型方面进行预测，那么好，现在我们正在处理我们所谓的结构，右，这是多个团队彼此相关的方式。积压成为治理。和工作测试的软件和今天它可能仍然工作测试软件，但我谈过的是指数，对吗？我们如何测量多个团队的价值？
它都归结为同样的基本概念。但是现在在我们开始规模时，我们有一个略有不同的阶级问题。我们有更多的类似限制性问题。我们在系统中有瓶颈问题。现在，如果你回到其中的一些早期思想家，我甚至不知道你是否早点考虑这些家伙，因为每个人还在外出和做事。但是，我按照一些早期的施瓦尔的东西，其中一些[听不清00:30:58]，克雷格温暖的鳞片上的scrum，现在在大规模的Scrum框架中出现了什么样的东西。
那些方法，我认为，真的是现场，对吗？我认为他们带来了很多智慧进入我们的社区。挑战是我认为这有点像大多数组织，至少最初是产品，或者对我，投射组织，对吗？他们批准了项目支柱的美元，对吗？他们在组织中有很多依赖性和大量的错位。And so, the way I look at a lot of those models is if you are a well-formed organization, and you don’t have a lot of dependencies, and you are doing team or business capability or value stream-based funding, then I think those methodologies are spot on.
但是你在一个你拥有的系统中做了什么，我会打电话，对团队一级的投资不均匀，对吧？The reason why people want to move people around and not form the right kinds of teams and not build the right kinds of backlogs is because they want to deploy resources, people, I apologize if that offends anybody but it’s kind of ingrained in me from 30 years as a project manager, right? If you want to deploy people into projects, right, then what you end up having to do is you have to slice people and slice teams into little bits to be able to get them to fit right into the project metaphor.
翻转，这是一个大的，这真的是一个高水平的战略事项，也许我们会谈到该系列的尽头。But it’s like one of the big things that we’re trying to get a lot of our large transformation customers to do is to, after they’ve established this Agile enterprise, really get the governance to stop thinking about funding projects as an investment vehicle but funding products. And products can be a lot of things, right? It can be a business capability, it can be a value stream, it can be a subcomponent. There’s lots of different platform strategies and different things like that. But the idea is that you’re funding teams, right? You’re not funding projects.
这要追溯到20年前的敏捷。就像我们想要做的是把项目带到团队中，而不是把团队带到项目中。所以这种心态的转变仍然非常重要。但当你处于过渡阶段时，或者当你处于一个不平衡的，没有团队资助的环境时，你最终会得到这样的结果，对吧?你最终会有多个团队，对吧?假设你都做对了，好吗?所以现在我们在一个确定的基线上，对吧?每个人都有完美的待办事项。每个人都有6到8个人组成的小组，他们拥有所有必要的东西，每个人都能够交付产品的工作测试增量，每个团队都能够在sprint的最后产生一个工作测试增量，对吧?
所以，现在我们讨论的是团队层面的完美执行，对吗？所以，这就是为什么这么难。所以Tim在谈论我们即将召开的提升敏捷会议。去年我们进行了一次有效的试点。而且，我的意思是，我们有一些非常非常酷的演讲者，我们的客户像是，副总裁，高级副总裁，企业架构，对吧，所有这类的东西，完全了解扩展和治理的概念，就像我如何做到这一点，我与他们合作了很长时间。但这就像是，最困难的是每个人都想从团队层面开始，因为这是基础，对吗？如果你没有做好团队层面的工作，那么要做好更高层次的工作真的很难吗？
但这是问题。这就是为什么我们正在做这个提升敏捷的事情。就像你开始谈论团队一样，你就失去了业务，对吧？亚博vip9通道所以我有点和你说话，因为它的内部人士就可以了解这个问题。团队级敏捷是绝对的团队水平可预测性，以确保我们在这种背景下真正锚定。团队水平可预测性对于企业级可预测性绝对是必不可少的。你必须得到积压的直线，你必须得到球队成立的，你必须得到依赖的依赖，你必须让每个人的团队能够在Sprint结束时生产经过工作测试的递增，好吗？
但是团队级别的敏捷性对于企业级的敏捷性是不够的。我们来谈谈为什么?因为在某种程度上，你有一个项目，它得到了很高的资助，对吧，一些管理结构，一些高管团体批准了一部分资金。我不经常使用“部分”这个词在这次通话中我用了三次，所以我不知道我是否需要评估我的词汇。这部分资金与项目有关，因为项目通常是我们考虑实现商业成果的事情，对吧?亚博vip9通道
因此，心智模型是，是业务将这一主动性带到桌面上，我想在软件堆栈中这样做。亚博vip9通道我要要钱，因为我的想法是，我会从背后得到更多的钱，对吗？而且，从本质上说，最终发生的事情，是我们把人从这些团队中带出来，我们把这些人分配到这里，然后我们去，我们派他们去做。好吧，假设我们有了这一层，我们修复了结构，我们达成了协议，我们不会为了交付项目而解散团队。但是现在我们要解散这个项目，以便能够将组件发送给团队，好吗？
那会是什么样的呢?所以你有一些关键，我喜欢称之为史诗。我认为项目就像史诗。我知道有些人认为史诗是较低层次的，就像宏大的故事，但我倾向于认为史诗是对业务有价值的东西，对吧?亚博vip9通道所以我要用我自己的话，对吧?所以，我们把我们的史诗分解成特征，对吧?然后这些功能被分配给用户或者被分解成用户故事。
让我们说这个特别的史诗，对，是非常沉重的，我要换个颜色，对第一组来说是非常沉重的。这应该是一个T，它看起来像一个疯狂的Y，对吧?第二组的任务很重，第三组有工作要做，对吧?第四组不行，第三组和第五组不行，对吧?所以,我们发现很多时候我们分手这样的工作结束了,我们最终得到的团队比他们能做更多的事情要做,我们有团队,有很少的,正确的,所以他们要做的,对吧?
所以你开始说，“好吧，让我们弄清楚下一个事情，”对吗？好吧，如果下一个史诗般，右，那是最高的商业价值，它就进一步加剧了这个问题，对。亚博vip9通道所以我们有人，我们有部署的团队进入这些能力，即我们饿了团队。很多时候会发生什么，两件事中的一件事发生了吗？这是令人着迷的。我们搞清楚，所以我们经历了，我们经历了所有举措的堆栈等级列表，它只是第20次倡议，对，这需要团队三和团队五，好吗？但第20次倡议还需要从团队中的一点点，从团队中有一点，四个团队四个。
所以我们说，好的，我们想要团队三，五忙，所以我们加载他们的积压。但这是现实，这里的这个小的工作在这里从未完成过，对吧？所以所有这项工作都是三队和团队五的工作正在处理......这很有意思，我们几乎就像我屏幕上的墨水点。他们永远不会意识到业务价值，对吗？亚博vip9通道所以它不像是一个优先级问题。这不是依赖管理问题。这不是一个承诺问题。这是你从来没有足够高的队列，以引起这些约束团队的注意力。它只是不去，对吗？
因此，我们倾向于雇用的策略是平衡投资组合水平的东西，并制定了意识到这些团队的能力的投资决策，对吧？因此，如果我们可以在基本上说，看看的投资组合水平高度假设，我们对这些高价值团队的容量有限，我们在较低级别的团队中有大量的能力，以及我们要做的是我们必须做的balance our portfolio to make sure that we’re not overloading the high value teams and we’re not assigning work. And I say low value teams but teams that are working on things that are not the highest priority or strategically aligned with the organization, right?
那么，接下来会发生什么呢?看看我能不能再做一次这样我就能挪开了。这就是这些多层次投资组合策略的作用所在。所以,你想要,我通常代表什么,尝试使用控制模型,对的,这里,正确,这是史诗和有效的小型项目,希望两到三个月,对的,因为我们想批大小限制在制品,所有这些东西,对吧?你甚至可以做门1，门2，门3，门4因为这里通常有看板类型的流程，对吧?
这些东西被转换成了一个中间层，我已经有一段时间没有做过了，但是，很有挑衅性的是，我把分析、设计、构建、测试、部署都放在了中间层。我有一个有趣的故事。有一次，我在一篇博客文章中写到这一点，可能是在10年前，当时我可能在VersionOne。我把看板命名为瀑布式小批量。还有大卫·安德森，发明看板的人，他发推特或短信给我，我当时记不得了。他说，当我读标题的时候，我想对你大发雷霆，但当我读你的文章时，它实际上已经死了，对吗？
因为这不是瀑布，对吧?不是大批量的，也不是大的交接之类的。但是，您可以有效地采用一个特性，并通过分析、设计、构建、测试和部署看板来运行它，而完全不需要更改组织结构。在不同的度量标准中，小批量和限制在过程中的工作实际上会使工作流更有效地通过系统。所以，我认为史诗被分解成特征，对吧?然后分析和设计的结果就会归结到你的Scrum团队和用户故事上。
那么，让我们来看看全球范围内的可预测性，对吧?要在整个企业中进行预测，你需要的是你需要一种能力来查看组织中出现的工作组合，并做出一些假设，做出一些猜测，做出一些假设，建立一些约束，这基本上可以断言下面的组织，基于这些独立Scrum团队的可预测交付和性能，因为他们现在有了可靠的交付能力，基于他们可预测的可靠交付能力，我们可以开始对组织能够交付什么进行一些打赌。
因此，我们将投资组合级别与较低级别团队的执行能力相结合。但我们知道它不会是完美的，对吧，因为会有变化。不可避免地会出现一些我们没有预料到的问题。这就是中间层出现的地方，对吧?所以，这个中间层正在经历一种滚动的波浪计划，对吧，把最高价值的史诗，分解成特性，对吧，把它们分解成能够在更高层次的约束下生存的方式。然后将这些用户描述从特性中分解出来，并将它们分配给团队和产品所有者，基本上就像供给系统一样。
Dean Stevens称之为，喂养敏捷的野兽，对吧?这就是你如何满足团队的需求并与策略保持一致，对吧?所以你有一个工作小组，就像它在实时分解工作基于团队的能力，这样团队就得到了正确的东西，比如当他们构建它并得到验证时，有一个稳定的功能流从背后出来。当这些功能被交付时，会有一股稳定的史诗流涌向这一边，对吧?对多层架构的工作方式进行了非常战术和机械的解释。
但在可预测的背景下，有几个因素在起作用，对吧?所以，一个可预测的敏捷企业绝对需要可预测的团队，否则其他任何方法都不起作用，对吧，这行不通，对吧。这就是我们在屏幕上讨论的其他东西的地方，对吧?我们在这里讨论的所有事情，所有那些规则仍然适用，但现在我们在处理大规模的对话。所以现在，我们有了一个敏捷团队的可预测的基础，我们必须确保我们正在为那些团队准备好待办事项。所有的规则都是一样的，对吧，三到四到五次冲刺，不管你需要多少次来应对翻滚的波浪。
然后能够在这些backlog中进行权衡，以平衡团队之间的约束。然后当这些功能交付时，我们会在功能层面进行权衡，以确保我们在最高水平交付史诗。让我告诉你一件我一直以来都不同意的事，关于迪恩和SAFe的事。我也当面反对过他。所以如果他碰巧看了这个，或者我怀疑他在电话里，但如果他在某个时候看到了这个，我不认为有任何事情会让他对我的想法产生怀疑。
我认为SAFe没有做得特别好的一件事，就是讨论团队的架构，这样我们才能在这个级别上创建稳定可靠的团队。现在，不要误解我。这绝对是隐含的。如果你回头看看你最初的Scrum材料，绝对是有暗示的。但在实践中，我认为，很多人并没有把它作为一个基本构件，对吧?这就像我们几周前进行的封装，编排，信任与可信度的对话，对吧?所以你必须坐在这里。
另一件事是我认为有点谬论是，当你用pi计划包装这个问题时，正确的，所以我们都与你们一起聚在一起两天，右，两天，对，也许是审查一个事物。如果您在KANBAN中运行这一点，则暗示的是，在过程中有一个限制，并且有流程和优先级和排序。所以我们可能会做一个依赖图，右，在这个规划级别，对。但问题是，就是，在实践中，我难以区分规定的是有时练习的内容的内容，因为很多它发生了变化。但是这个想法是几乎就像我们都会聚会。我们都将要这样做这个为期两天的计划，然后为所有人提供一种自由。然后我们回到了背面和[听不清00:48:13]。
我认为这其中有两个挑战，我认为这里没有足够的反馈，我也不认为两天的时间足够让所有人达成一致。我理解我们为什么想这么做我也理解为什么这样感觉很好，好吗?但至少,我想要做的是我想有一个后台线程,这就是我建议安全团队不少,因为我想要一个后台进程运行,基本上说的是,我们要走在这个会议。当我走进来的时候，我们会让每一个团队都意识到自己的依赖性，做好待办事项。
我想知道这些依赖关系在系统中的什么地方。我希望在发布的早期就预先加载依赖项。这样，其他团队的依赖关系就能尽早解决和处理，这样当我进入后期发布时，我就不会太担心这些依赖关系的本质或者是后期中断的依赖关系给我带来的问题，明白吗?但是当你这样做的时候，在我看来，我的理解可能不是很完美，你在某种程度上打破了这个框架你创造了更多的这个框架。
通常在早期阶段的转换,可预见性就像一个目标数量对我们尤其是在一个组织,因为很大一部分的原因你需要先预测,除了组织要你预测的目标,对,这就是CEO的关心,这就是他们愿意资助和支付的东西。他们愿意资助和支付的一件事是，它是可预测的，也建立了与组织的信任。所以我们说，“嘿，我们要做敏捷，它会解决你所有的问题，”然后它就混乱了，对吧，它会侵蚀信任。
如果我们能进来并开始使用Scrum敏捷看板和这些度量方法和稳定系统,让它确实可预测的大门,即使在依赖关系和团队的存在并不完美,我们建立了很多信任的组织。所以，很多时候，我们最终要做的是在这个层面上创建一个工作组，我过去称之为产品所有者团队。他们工作的很大一部分，也许不是全职工作，他们不像真正的Scrum团队，他们更像看板团队。他们的工作是分解工作，并验证连续模式中的完成情况。
所以，我喜欢由一群独立的人，在发布计划中不断梳理backlog的想法。所以，在实践中，我有一个团队，在分析和设计阶段不断分解。在看板上有一小批我正在排队等待发布的工作。现在我已经准备好了发布版的工作，所有的依赖关系，横切关注点，负载平衡等等，对吧?然后我会在为期两天的计划会议中把它带到一个团队中，让他们解决细节问题。
所有的工作都将在发行版中进行排序，这样可怕的高依赖性的工作就会提前完成，低风险的工作就会推迟完成。这是一个很好的策略。然后我降低了风险。所以发布结束在这个构建阶段，但我们可能会在构建和测试之间循环，这是有意义的，对吧?然后在发布的最后我们会做一个部署，类似的事情，对吧?
非常简单。我们快没时间了。如果有问题我会问蒂姆。但是就像这两件事一样，在团队层面，团队，积压，软件的工作测试，对吧?对于任何企业敏捷感来说，先决条件绝对是正确地实现团队级别的敏捷性。然后，一旦你获得了团队级别的敏捷性，它实际上是关于平衡投资组合和分解过程，以确保我们正在以一种最大化其创建流程能力的方式利用交付组织的能力。
如果我们投资组合项目分解成小块,和我们这一组,将投资组合的东西分解成项目水平特性规律的节奏,即使我们标记在一个安全的世界,是的,我们分批释放然后进入像一个大房间里,大的发布计划,完全好,对吧?我只是开了些前后的药，对吧?没事的,对吧?有时我叫它安全加，对吧，因为在依赖和更复杂的环境中，有时你需要更多一点，很酷，对吧?
但是，这些方法在这里是什么事情基本上建立在企业层面的流动，并再次利用在团队模式的流程。如果系统的这两个方面都不能协同工作，我们并没有真正得到我们想要的可预测性。然后我就只是一种放在一个句点，我们就叫它在这里完成。But it’s like you can be predictable and perfect at your Scrum team level and the organization sees no predictability and value at the enterprise level because you didn’t build the structures in place to make sure that the system was getting fed in a way they basically kind of funneled everything through from an early release perspective, okay?
所以可预见性非常重要。它建立了信任，高管们想要它，他们愿意为此付出代价。如果你们能够向他们展示敏捷是如何为他们解决这个问题的，以及他们需要做的事情，那么你们就为转型提供了一个强有力的理由。希望这就是你们从中得到的。
蒂姆，在我们结束之前有什么问题要问吗?
是的。我认为你可能会谈到这一点，但有人问道，这是一个相关的问题。他们说，如果我的团队正在做Scrum并依赖其他瀑布的其他球队怎么办？
是的。这是一件很困难的事情，对吧?这是一个更高级的组织设计问题，对吧?但你必须意识到，当你设计一个非常快的东西时，把它和一个非常慢的东西混合在一起，你最终会在两者之间。好吧。我们经常看到这种情况，对吧?
从历史上看，我们有很多金融服务业的客户，现在也有很多制造业的客户和制药行业的客户。但就像在金融服务行业，那是我成长的地方，你最终会像大型主机一样做瀑布式的东西，或者你会有像瀑布式的客户，集成合作伙伴，你需要有一个非常酷的前端团队，对吧?
所以你倾向于尝试做的是让瀑布团队稍微少批量工作，也许就像三个，四个月的批次而不是18个月的批次，所以你试图压缩它们一点点。而且你也试图让他们发布路线图，因为瀑布从未喜欢完美的瀑布。通常在迭代中通常有一些增量。然后你最终完成的是，敏捷团队最终进入到那之内，但随后沿途同步点，对吧？
There’s some strategy around that but there’s just no world in which if you’re building an integrated product with Agile teams and waterfall teams that you’re going to get the release performance and the predictability and everything that you would have if you had a full blown Agile organization. It just not going to happen, right? Again, fast stuff and slow stuff. It’s a little bit like where I talked about is like predictable stuff and unpredictable stuff is going to, you’re going to end up someplace in the middle, is what it comes down to.
惊人的。好吧，谢谢，家伙。我欣赏大家加入我们的人。我们将在下周见到你。