产品角色，第5部分：创建切片的组件团队

在我撰写这些产品角色职位时，许多人都询问了如何使用组成团队。您可能有一个安全团队。也许是表演团队。不管我的愿望如何，您都有组成团队。您需要一种更敏捷的方法来管理团队之间的相互依赖性。您希望能够更频繁地交付小功能。

可视化您想去的地方

我喜欢从想要看到的结果开始。首先，还记得组成团队的逐层图像吗？

这说明了我们如何需要组成团队来交付较小的功能。

让我们看看如何进行这项工作。

我有几个可以使用团队的假设：

我说每个团队必须能够检查代码库中有价值的内容的原因是循环时间。

产品周期时间是添加的所有成分团队的周期时间。加成。

这是我的客户的工作方式：

团队努力工作以使此周期时间正常进行。他们没有其他工作。他们的整个周期时间仍然超过两个工作日。

请注意，每个团队的周期时间都不超过一天。因为他们看不到全部功能，并且因为他们做的较厚，可以管理团队之间的交接，所以一切花费的时间更长。

在另一个程序中，程序经理意识到，虽然每个团队都在一天之内“完成”，但是他们对每个功能的最终系统测试又花了两天的时间。

以我的经验，当我们有组成团队时，我们就会相互依赖。相互依赖关系会创建等待状态，即使我们没有上面最佳最佳周期时间图像那样的明确等待状态。

一个团队可能不需要很长时间才能成为一个团队。但是该功能（切片）所需的时间比我们想象的要长，而且比我们想要的要长。

我多年来一直在努力解决这个问题。一些组织根深蒂固的组件团队（跨架构而不是通过架构工作）使我无法轻松解决。

您可以通过以下方法考虑可能发生的情况：

专注于流程。测量整个功能的周期时间。不是每个团队做什么，而是要提供可用的功能。（故事，是某种基于用户的价值形式。）问问自己这段时间是否可以接受。如果是这样，那很好。您已经解决了问题。
如果您的周期时间过长，请查看流量效率系列。这将帮助每个人重新思考他们想要的东西。他们是要专注于个人还是针对功能进行优化？如果他们选择个人，那么您就完成了。
如果确实要优化功能，请邀请团队（而不是经理）解决此问题。考虑使用稀咖啡或开放空间。让团队为周期时间问题制定答案。您可能需要教育他们关于他们之前从未考虑过的可能性。作为该培训的一部分（周期时间，流程效率），请务必考虑以自组织方式共享实验以创建功能团队。一旦团队决定做什么，他们可以告诉经理。经理说：“谢谢”，然后寻找功能。（我需要解释敏捷管理器的角色吗？）

我不喜欢添加更多流程。我乐于解释我想要的结果，并帮助人们探索问题空间，以便他们可以考虑替代方案。

是的，我在本系列中至少还有一个职位。

到目前为止的系列：

翻译自: https://www.javacodegeeks.com/2019/05/product-roles-component-teams-create-slices.html