Scrum团队已经发展得太大了，它应该如何分裂？

Question

我工作的保险公司在过去几年中一直在进行一个软件开发项目，该项目被分成多个项目。

1. 软件包:我们正在使用的套件被分成几个主要的包，它们是独立的，但彼此绑定在一起，每个包都有自己的域:一个用于计费，一个用于索赔，一个用于策略，另一个用于联系人，每个包被单独管理，并按业务进行进一步细分。
2. 业务线:我们实际上有3条业务线，我们一直在单独推出每一条业务线。团队被进一步分解；他们被按工作类型分类。
3. 工作类型: 我们已经根据包之间的集成、单个包的配置和文档生成来划分工作类型。这些分裂并不是普遍的，例如，在我们已经推出的第一线业务上，我们从来没有一个我所了解的集成团队(这个项目是在我参与到团队之前就开始的)。我们遇到的问题是，我们已经推出了3条业务线中的2条，在我们这样做之后，我们将scrum团队从这些业务线合并到了一个软件包中。这意味着我们有4个单独的scrum团队，现在我们有了1个scrum团队。很明显，这是一个错误；现在我们的scrum大师不知所措了，scrum会议只与出席的人中的一部分相关，导致人们注意力不集中的时间太长了。因此，现在继续向前推进，已经有了一些反击，让这个超级团队重新回到它以前的组件部分，至少部分原因是，在业务2直播之前完成的大部分粒度化，以及配置和集成之间的界限要混乱得多。我们一直在讨论如何继续进行，但在提出这一问题时，大多数人都保持着震耳欲聋的沉默。为了让一个人对问题的范围有一个概念，上面提到的超级团队大约有35人，如果我们按照我们的方式把它分开，几个关键的人必然会组成多个团队。此外，如果我们按原来的方式分割，我们的团队仍然会比理想的团队规模更大，但是我们越分散他们，就需要更多的人员共享。最终可能导致我们所有的时间都花在会议上。我们该怎么做？我们如何决定在哪里划定界限，以及如何解决让一些人加入多个团队的需要，而不管我们是如何划分团队的？

Answer 1

有两件事要记住：

• 一方面，虽然每天的scrum会议是有用的，但对于某些项目来说，每周举行一次或两次会议就足够了。
• 第二，让人们参加多个scrum会议本身并不是一件坏事(让人们在项目之间分配他们的时间是没有效率的，但有时这就是生活/业务)。

Scrum/站立会议应该足够小，这样在场的每个人都真正对每个人必须说的话感兴趣。这通常是五个人或更少。产品经理/利益相关者可能很乐意举行一次会议，但开发人员会讨厌它(而且他们应该这样做)，而且讨论的质量也会受到影响。

我建议把事情分解成微小的scrums/standups，并减少它们的频率，使每个开发人员平均每天不超过1.5Scrum/standups。然后，您还可以每周(或每隔一周)举行一次会议，让团队领导出现(或任何团队决定发送的人)，并向利害关系方和其他团队提供更多相关的更新/演示。这将节省时间，并有望产生更有意义的对话。

Answer 2

这个问题提到了Scrum。我们可以从那里开始。

如果你问一个Scrum纯粹主义者，他们会告诉你，Scrum团队是自组织的。这意味着，如果您要在一个组织中组成一个或多个Scrum团队，则应该允许团队适当地构造自己。Scrum硕士(或其他类型的教练)将教导团队的角色，团队的规模，并将帮助团队确保他们是跨职能的或有一个计划得到跨职能。

现在，Scrum是围绕一个由4到11人组成的团队构建的(参见我在这里的回答是)。对于如何处理多个团队，Scrum没有很多指导。但是，有些框架确实支持多个团队。尼克斯被设计成所有使用Scrum的3-9个团队。LeSS(大规模Scrum )是另一个帮助将Scrum原则扩展到多个团队的框架。SAFe(规模敏捷框架)为不同规模的组织提供了几种不同的风格。有纪律的敏捷交付(爸爸)提供了一个框架，它考虑整个组织在一个精益或敏捷的环境中运行，以及不同的交付生命周期和对组织非技术方面的考虑。

如果您查看Nexus、LeSS和SAFe的详细信息，就会发现推荐更小的团队。Nexus和LeSS是围绕Scrum团队形成的，所以团队应该在4到11人之间，都在标准Scrum中工作。SAFe推荐5-10人，并将团队在Scrum之外的工作作为他们方法的基础。不过，DAD对几个团队都有考虑，包括中型队伍 ( 25到30人之间的团队)和中型团队 ( 12到50人组成的分组)的两种方法。

所以，在这个问题上-你怎么分解一个团队。

几乎每一种敏捷方法都考虑跨功能团队。这个问题提出了三种分解团队的方法。似乎第三种方法，按工作类型划分团队，与敏捷实践最不一致，因为团队更有可能不是跨功能的。任何组织团队的方法都应该给予团队所有必要的技能，以向涉众提供有意义的价值。

我的建议是按可交付组件(包)对团队进行分解，并让团队中已经具备或能够在这些特定组件中构建能力的开发人员组成团队。您还应该形成“元团队”来协调和共享团队之间的知识--对于您的产品经理和架构专家来说尤其如此，以确保团队之间有一个共同的愿景和方向。只要您可以为每个团队配备一名指导/领导角色、一个产品负责人、一个架构所有者和少数开发人员，您就可以应用敏捷原则。为了促进一个完全跨功能的团队，我建议确保有足够的专家(比如独立测试人员、用户体验设计师和工程师，类似的)来支持每个团队。

我建议你把爸爸当成基金会。一般情况下，Scrum离Scrum很近，对于大多数参与的人来说，转换是很顺利的，但是确实可以指导一些情况，在这种情况下，您可能会分解一个团队，但是仍然会有规模太大的团队，而传统的Scrum方法也会崩溃。