大规模敏捷团队的结构，治理和指标

好了，让我们来回顾一下我的上两篇文章。我在这个小片段中的第一个帖子叫做基于团队的Scrum的潜在机制。“在那篇文章中，我试图让案例使Scrum的规则，仪式，工件和角色......而scrum的一个组成部分......不是什么scrum真的。Scrum真的是关于我们将至少几个星期的建造来极度清晰。Scrum真的关于形成一支拥有生产产品所必需的一切的人团队，并对实际生产它负责。最后，Scrum是关于具有可以测量和比较我们所开放的产品的产品的工作，测试的增量。这样我们就知道我们已经到了多远，我们已经离开了多远。

我的下一个帖子是基于团队的Scrum的失败模式。“在上一篇文章的三个主题上探讨了我们看到Scrum团队争取清晰，问责制和可衡量进展的许多方式......特别是在更大，更复杂的组织中。大多数公司挣扎让合适的人民一起制作一个良好的优先考虑的积压。大多数组织真的挣扎在一起完成完整的交叉功能团队。Even in the presence of a well-groomed prioritized backlog and a complete, cross-functional team… many organizations struggle to produce a working tested increment of the product every couple of weeks, and have no idea what they’ve produced or how much software is left still to build.

那么这会让我们留在哪里？好吧，在许多组织中，我们在我们甚至可以真正考虑做Scrum之前要弄清楚一些事情。首先，我们需要弄清楚我们计划形成的哪些团队以及我们将如何形成形成它们。接下来，我们需要弄清楚团队将在哪里获得积压，他们需要多少细节，以及许多相互依存的团队的积压将如何聚集在一起综合整体。最后，我们需要弄清楚我们将如何衡量和我们将如何衡量它。这在团队级别非常简单，但可以随着我们开始整合几个团队的工作，这可能会变得更加复杂，这些团队必须在集成产品上融合在一起。

记住，我们还会再看一遍。在你开始你的敏捷转换之前，你需要了解你将如何构建敏捷团队……我们将如何管理待办事项从哪里来……以及我们将要度量什么，以便我们知道我们正在相对于集成的交付物取得进展。在一个简单的、单团队的Scrum实现中，这很可能是一个跨功能的团队，一个被授权的产品负责人负责创建待办事项安排，以及根据已知的待办事项安排，以稳定的速度，有规律地产生一个经工作测试的产品增量的方法。Scrum的这种规范表达是在许多较小的组织中起作用的“结构-治理-度量”三合一的一个例子。

在较大的组织中，这个单一团队比喻可能会破裂。我们将需要一个不同的构造，一个更广泛的构造调色板，可以表达更复杂的企业的结构 - 治理 - 指标需求。As I’ve been noodling on these ideas over the past few weeks and sharing some of my ideas with Dennis and others on my team, we’ve been talking about the other more heavy-weight agile approaches out there, and using them as a way to understand our industry’s attempts at putting together patterns for doing agile at scale. If you think about it, frameworks like RUP, FDD, DSDM… and more recently SAFe… are all attempts at putting some language around the Structure-Governance-Metrics challenges we have with agile in large companies.

好了，在我们结束今天的工作之前，我想在接下来的几篇文章中使用一些语言。当我谈到结构时，我真正谈论的是企业组建团队的模式。我想在下一篇文章中，我们将讨论在大型敏捷企业中可能需要的不同类型的团队。接下来，当我谈论治理时，我真正谈论的是组织如何定义企业要从事的工作，以及该工作如何与团队协调和沟通。最后，当我们讨论度量时……我们需要从产品交付的角度，以及测量、评估进展的方法，以及知道我们是否正在变得更好的方法上达成一些共识。

我想在接下来的三篇文章中，我们将探索“结构-治理-度量”框架，并讨论如何为大规模的组织做出这些决策。一如既往，谢谢你和我一起坚持下去。

看看下一篇文章，如何构建您的敏捷企业。

看看之前的帖子，基于团队的Scrum的失败模式。