处理广泛的领域差距?

你好,

也许更重要的是，我问对问题了吗?

我不确定。Scrum只是向您展示了您在Scrum之外有一个主要问题，您可能需要解决这个问题。也许你可以和你的团队坐在一起，看看是否有其他方法来创造你正在处理的产品。毕竟，您很可能不需要Python、c++等等，但您希望在一天结束时能有一个工作的产品。

这导致故事被划分到一个特定的硬件团队(不好)，或者它们落在跨职能团队的硬件开发人员身上——有效地创建了一个子团队(也不好)。

如果你不能马上解决潜在的问题，想想以下几点:你的团队中总是有专业人才。这一点不会改变。但是，每个人的愿景和目标都应该是一样的。现在想想一个产品负责人，他要确保每个人都能用心和用心地理解愿景:然后你的所有团队成员会一起工作来实现它吗?不管有没有子团队，他们都将遵循相同的目标。有可能您的“用户故事”现在实际上没有水平切割。

在过去，我有几个团队同时处理硬件、固件和软件。他们最终都有自己的特殊技能，并相应地分配他们的任务。然而，优秀的团队自行组织，并始终保持在轨道上。我们只需要注意悄悄蔓延的瀑布:如果有些人不得不等待其他人完成某件事，就会发生这种情况(“我在这个Sprint中负责硬件，你在下一个Sprint中负责固件，再下一个Sprint中我们就从软件开始……”)。Sprint目标，以及最常见的产品待办事项项，都是跨职能的，并且允许团队围绕它们形成。
顺便说一句:一段时间后，团队总是开始分享技能，所以如果出现瓶颈，非专家可以支持专家。但同样，这是团队自己解决的问题。

希望这能有所帮助

杜米尼克