特性团队vs组件团队
嗨,所有
虽然在Scrum指南中没有明确提到，但我认为可以公平地说Scrum中的规范开发团队是一个“功能团队”。这当然是Scrum Primer中确立的立场，并且它很适合根据用户故事和其他支持业务价值增量交付的抽象来组成产品待办事项列表的实践。
还有一种替代方法，那就是使用“组件团队”。例如，每个团队可能负责架构组件，从而充当接口守护者和组件质量的保证人。
现在，我注意到，随着敏捷团队走向规模化，“特性团队”模型会增加某些技术风险，并变得相当弱。问题是为了交付功能，每个团队必须拥有整个代码库，他们的工作通常会交叉许多组件。这是一个进入“代码合并地狱”的真正危险，其中不稳定性被不经意地引入，可交付成果的质量受到影响。我相信你们很多人都看过这个。迁移到“组件团队”理论上可以最小化这种风险，尽管以增加业务风险为代价，因为团队变得更加专注于技术。
至少有一个框架(是的，它是SAFe)提供了大规模使用“组件团队”。Larman和Vodde再次指出，“功能团队”应该继续存在。其他人对这件事有什么看法?
在Scrum联盟的网站上有一篇非常好的文章详细介绍了这个话题……
与组件团队合作:如何驾驭复杂性:
http://www.scrumalliance.org/亚博一百送一百community/articles/2012/september/working-..。
争论的焦点是组件团队确实是个问题，他们应该尽快被功能团队所取代。
本文还讨论了Mike Cohn关于让组件团队履行产品所有权角色的想法。我必须承认，我过去也试过，但没有太大成功……所有权太弱，本质上是因为它没有足够直接地代表商业利益。
我的想法是组件团队通常是一个功能障碍。Larman/Vodde在本书中很好地阐述了组件团队的缺陷:
http://www.amazon.com/Scaling-Lean-Agile-Development-Organizational/dp/..。
我认为Cohn在他的书中也很好地阐述了这一点，尽管我希望他能进一步推动Feature团队。
我对SAFe的一个问题是，它在图像和其他方面过于纵容组件团队。如果你有一个相当固定的组件团队，那么敏捷就很难实现，因为每隔几周/几周就很难交付端到端特性。
其他一些评论:
问题是为了交付功能，每个团队必须拥有整个代码库，
我不确定这是不是真的。在任何产品中，整个产品组(所有致力于该产品的Scrum团队)共同拥有整个代码库，并共同共享相同的“完成定义”。
>的想法，让组件团队履行产品所有权的角色
这种情况很快就会变得很糟糕，而且有一个致命的重大缺陷。对于任何给定的产品，只有一个产品负责人或者一个“首席产品负责人”(如果你喜欢这样称呼的话)。此人对单个产品待办事项列表的顺序有最终决定权，包括任何“组件团队的”待办事项列表项。整个产品组共享相同的产品待办事项列表和相同的首席采购订单。现在，如果您想要组件团队的团队级PO，那可能是可以的，只要这个人回答首席PO对backlog的订购。
这种方法的另一个致命缺陷是产品负责人是一个人，而不是一个团队。这是Scrum指南中非常严格的规则。如果您必须走这条路，我的偏好是将消费团队视为重要的涉众，并帮助与生产者团队协商定义组件的接口。但是，请记住，对于组件团队来说，PO要控制“什么”(可能是接口——输入、输出、异常等)，而组件团队要控制“如何”(接口级别以下的一切如何工作)。
我强烈倾向于只使用特性团队，将团队转移到特性团队，并教会特性团队如何合作以实现共同的目标。Larman在上面的书和这本书中有一些关于这方面的好东西:
http://www.amazon.com/Practices-Scaling-Lean-Agile-Development/dp/03216..。
我应该提一下，Larman的书不适合Scrum新手，但扩展Scrum也不适合新手。
对于任何给定的产品，只有一个产品负责人，如果你喜欢这个称呼，也可以叫“首席产品负责人”。
这很重要，因为首席采购官能够有效管理产品总投资回报率的唯一方法是，他/她对单一、统一的产品待办事项的顺序也有最后的发言权。
也许关于这个主题的一个很好的具体例子是Spotify如何在内部将Scrum付诸实践:
https://dl.dropboxusercontent.com/u/1018963/Articles/SpotifyScaling.pdf
我认为功能团队和组件团队都可以使用，在“Scrum和企业”中都有描述。如果您有组件团队，您可能会有一个集成团队，负责集成和测试组件，并将发现的错误报告给组件团队，在组件团队中以高优先级进行修复。关键在于，您需要一个完整的增量，以满足完成每个sprint的共同定义。如果你能做到这一点，我不认为组件团队本身存在功能障碍。
我强烈支持功能团队，因为在多个组件团队中，你不确定在每个sprint之后都能得到可交付给客户的产品。我同意它在依赖关系方面增加了一些开销，但这些可以在工具和流程(如SoS)的帮助下进行管理。
干杯
桑杰
伊恩，你能否确认一下“外管局是如何大规模使用‘组件团队’的”。我的理解是，外管局也没有做出推断。
那是6年前的事了，但我可能指的是:https://www.scaledagileframework.com/features-and-components/
我赞成“功能团队”的方法，因为Scrum的本质是在Sprint结束时交付可发布的功能。这反映了产品的演进过程以及它如何满足用户需求。话虽如此，我同意Ian关于“代码合并地狱”的观点，当我们采用特性团队的方法时，许多人在处理同一段代码时，“代码合并地狱”是不可避免的问题。我相信Ian想强调的是这两种模式的优缺点以及如何管理缺点这样产品的交付就不会受到质量或客户满意度的影响。
为了补充Ian的观点，您可能更担心您的团队成员是否具有足够的知识来处理每个不同的组件。假设组件A是用Java开发的，而组件B是用LINC开发的。市场上是否有同时掌握这两种语言的开发人员?
因此，这可以归结为如何管理这种方法在规模化产品交付中的缺点。也许你需要问问自己，考虑到现有的知识、工具和能力，多个团队是否能够维持“功能团队”的概念。“代码合并地狱”可能是一个相对较小的问题，因为我们有自动化的版本合并工具(Git、SVN等)，可以向开发人员发送警报，以便他们解决问题并尽早做出反应。同样的观点也在伊恩给出的超链接中得到了强调。
因此，我更倾向于采用“特性团队”的方法来保留Scrum的精髓。我承认现实是有局限性的，但不应该太过弯曲，直到失去本质。
组件团队对其他团队创建了无法解决的依赖关系。
特性团队将通过技术解决方案来解决依赖关系:康威斯定律通常会导致微服务架构。
我认为什么是与敏捷相一致的，这是非常清楚的，因为我认为依赖是它邪恶的孪生兄弟。
我的想法是组件团队通常是一个功能障碍。Larman/Vodde很好地掩盖了组件团队的缺陷……
我完全同意Charles的说法，Larman/Vodde描述得很好。他们关于特性团队的章节可以在网上找到:
https://www.craiglarman.com/content/feature-teams/feature-teams.htm