多功能团队多产品

Question

晚上好。

我们目前有两个功能团队，一个是Web，一个是移动的。他们也有自己的积压。每个人都有自己的产品经理和scrum大师。团队规模为11，包括每个团队的scrum和产品角色。

除了其他项目的产品积压外，我们对交付的需求也在不断增加。有些人会接触网络，有些人会接触手机，有些人会同时接触到两者。

我们已经提出了第三个团队，他将能够从现有积压之外的需求中进行Web和Mobile交付。在空闲的时候，他们将帮助现有的特性团队处理他们的待办事项。

然而，一条线索是说CI/CD的开销会太大，而不是创建第三支球队，我们应该加强现有的团队规模，这是违反教科书的。

我个人反对这样做，因为我相信现有的产品积压也会被推迟，因为外部需求将是一个更高的优先级。

关于如何进行的思考？

Answer 1

CI/CD的开销太大了。

会有很多的。吸收新团队成员的开销将越来越难以跟踪。你不只是因为迟了加入团队成员而违背了规则，你已经超过了团队的规模，一个团队中有11个人。

比萨饼规定，一队人不能再吃比萨饼，这样两个比萨就可以吃了。我的原则是，如果在你的椅子上转过身，和你的团队交谈，感觉就像在公开演讲，那就太大了。如果和你的团队交谈实际上需要把每个人都拖进会议室，那么你只是纸上谈兵。

有了这么大的团队(11，sheesh)，组建第三支队伍不仅是个好主意，还可以从现有的两个团队中分别吸引两名经验丰富的开发人员，与其他4名全新的开发人员组成第三组。

这意味着新的团队将是9，9和10，使新的团队是最大的，这是从书本上。团队意味着收缩而不是成长。

当被迫吸收新的团队成员时，鼓励他们将初级开发人员与高级开发人员配对。不要做艰苦的作业，但要考虑到它。这样就不会让我们的团队失去及时的沟通。即使这样，它也会减缓球队的速度。

他们可能会对这个计划犹豫不决，因为它清楚地表明了这会对现有团队的生产力产生多大的影响，但这正是我支持它的原因。这就清楚了这一举措的影响。如果他们现在不愿意放慢你的速度，以增加未来几个月的产能，他们就应该停止和你捣乱。

如果他们确实让你一个人呆着，那就试试这个:不要纠结于重新排列那些已经被取消优先顺序的工作。你不会因此而得到任何荣誉的。表达推迟的风险，然后继续前进。无论如何都需要做一些工作。只要你不介意不获得学分，就去做。

Answer 2

我认为，第三个团队在这两种产品上都可能存在其他问题：

• 谁来审查代码更改？第三个团队的成员还是专门的产品团队的成员？
• 谁为每种产品做设计决策？

为什么这些其他特性没有在现有的积压中被优先处理呢？我认为正确的做法是保留两个团队，或者将这些“其他”特性高度优先地放在待办事项清单上，或者创建一个专门的故事点桶，每个sprint用于处理这些“其他”特性。如果一个特性涉及到两个产品，并且需要两个团队的工作，那么请使用跨队故事。

Answer 3

这闻起来像是一个政治历史的东西，你有两个PM (=POs?)首先。当然，您应该有一个只有一个积压，只有一个产品具有多通道访问，对吗？

你有22个开发人员，但是，“你还不够快”，所以你正在寻找扩大规模的方法。

这里出了点问题。你最好有一个大产品来解释这种情况。

假设您这样做了，那么返回一个PO和一个待办事项，当然不超过一个SM似乎更合适。然后，您可以有4或5个开发团队，并有一个高级开发协调团队，处理团队间的问题。每个团队都将使用相同的SM和PO进行自己的规划会议。

但是，考虑到现在的组织方式，我怀疑这种改变在您的组织中是不可行的。