敏捷方法需要跨职能的团队。 这意味着团队中的每个人都专注于相同的意图。 该意图可能是整个产品。 它可能是较大程序中的功能集。 但是，团队集中在一起。
该跨职能团队是产品团队或功能团队。 我倾向于称它们为功能团队，因为当它们作为程序的一部分工作时，或者随着产品的发展，它们可能会随着功能集的变化而变化。
只要您有相同的意图，我实际上并不在乎您如何称呼这些团队： 团队将共同努力完成产品或功能集的工作。
功能团队没有跨团队的相互依存关系
您可能以前看过我的按功能实现图像。 注意通过体系结构对功能的切片。 当团队对体系结构进行剖析时，他们能够创建小故事，这种小故事可以进行实验和业务价值验证。 （第1部分中的最低要求。）
您的团队可以单独创建功能吗？
但是，我认为团队无法足够频繁地按功能实施。 我经常看到这个组织，其中团队专注于整个架构，而不是整个架构。
平台团队在底部提供红色部分。 平台团队是一个跨职能的团队，由开发人员和质量检查人员（如果需要）和DBA组成。 但是，即使它们具有跨功能，但它们仍然是组件团队，因为它们无法通过体系结构创建功能切片。
中间件团队（深绿色）或应用程序层团队（蓝色）或GUI（蓝绿色）都不能。 （如果您是色盲者，您可以在这里看到任何颜色吗？如果没有，那对您有用吗？谢谢。）
当一个组织基于项目团队时，他们经常会这样组织。 经理们认为，如果各个组成部分团队专注于体系结构的某一层，而不是纵切整个体系结构，则效率会更高。
当组织创建基于组件的团队时，即使团队是跨职能的，他们也需要一起计划所有计划，以了解何时可以使用某个功能。 他们确实需要每个人都可以参加大型规划，在那里他们拥有连接各种相互依赖关系的字符串。 我在第2部分的迭代中对此进行了解释。
计划是一个问题，因为团队配置意味着我们会定期打断团队以进行重新计划。 他们没有使用新功能。 他们花费时间进行估算并进行组织，以准备下周可能需要更改的新计划。
这是一个问题，但对产品价值团队而言更糟。 当团队按组件而不是功能进行组织时，产品价值团队将无法发挥产品的业务价值。
更改团队组织以专注于产品或功能
我确实建议团队从基于组件的团队转移到功能团队。 我建议在给定位置的每个人都可以在一种实验性可能性中做到这一点：从组件团队到功能团队的自我组织 。
产品或功能团队的价值在于，产品价值团队可以创建小的滚动波并重新计划，而无需进行大量的前期工作，包括评估故事的故事。 相反，他们可以使用循环时间。 例如，团队可能总是在一天之内进行一项实验-他们会将工作安排在一天之内，然后在一天之内作为一个团队来进行该实验。
当功能团队不依赖其他人来完成功能时，产品开发中的许多困难将变得更加容易：
- 团队可以自行部署
- 团队可以通过测量或计时来定义其各种周期时间
- 产品价值团队可以更轻松地重新计划
- 每个人在会议和评估上花费的时间都少得多，因为工作更加轻松。
我将不得不写一篇有关创建成本的文章。 哎呀，这个系列越来越长了！
当每个人都专注于基于产品的角色而不是基于项目的角色时，每个人都会获胜。 （您仍然可以做项目。是的，我认为这是下一篇文章的一部分。）
到目前为止的系列：
翻译自: https://www.javacodegeeks.com/2019/04/product-roles-product-feature-teams-project-teams.html
4812
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
