围绕一个系统的某个区域的活跃的领域知识才是有保存价值的基本单位，但是这容易被破坏隔离，领域的知识连续性很重要，DDD的有界上下文概念似乎是一个很好的基础。
(特性团队是跨专业的, 面向最终用户交付完整价值的团队，组件团队Component Team, 比如计费团队, 订单团队, 支付团队)
我同意这一点。作为从事基础设施软件工作的人，我发现在结构化方面具有更大的价值：1）保护系统的概念完整性，尤其是防止蜘蛛网的有机增长，以及2）提供跨越系统边界的明晰合同/承诺。
我认为特性团队是不安的中间立场，因为您无法从组件团队或真正的产品团队获得好处。
当您的产品是由高度可识别的功能组成且两者之间有明确的过渡时，特性团队才有意义。如果不是这样，那么它更多是一种敏捷的缩放技术，会导致失望。
以我的拙见，每当我们选择搭脚手架的方式而不是从思维方式转换来解决问题时，都会有一段蜜月期，我们认为我们将其正确处理了，然后大多数人转身离开。但是仍然有一些人声称这种脚手架搭得有效，并将自己视为精英。
我认为，在5年的时间里，软件开发中的思想周期将再次开始，我们将回到ORM（几乎只是瀑布而得名），以此类推，因为大多数开发人员必须再次学习一切。
公平地讲，使用特性团队的建议主要针对严格孤岛的组织。我见过一个公司的功能和组件团队混合在一起，效果很好。
特性团队导致代码质量低下。不幸的是，代码质量低下的痛苦只有在一段时间之后才对管理者显现出来，在此之前已经造成了损害。
特性团队就像大型公司中的微型初创公司。
特性团队曾经而且一直应该被视为一个好主意。该概念有助于“消除”非生产性的反馈循环。