当我最初给某个位于加州的游戏工作室做咨询的时候，它的团队是按照存在于他们开发的游戏中的具体的内容和对象来组织的。对于每个角色有一个单独的团队，比如包括武器团队、车辆团队等。这带来了一些问题，比如武器太弱以至于不能够杀死怪物，颜色太暗以至于不能显示秘密通道和障碍，这样的问题，即使是那些最耐心的玩家也会感到沮丧。
在更传统的企业应用项目上，当团队结构是几乎按照应用程序分层来划分的时候，我们看到了同样的问题。举例说明，一个典型的项目早期阶段的错误，它将有4个团队：一个富客户端团队，一个Web客户端团队，一个中间层团队，以及一个数据库团队。创建一个这样的组件团队会带来各种问题，它们包括
• 减少了各个层次之间的沟通
• 基于合约的设计的感觉更明显
• Sprint结束的时候无法提交可交付的增量产品功能
如果说按照系统的分层来组织一个团队的架构是一个错误的方法，那么有什么更好的方法呢？不是按照组件来组织团队结构，而是让项目中的每个团队理想地负责一个可工作特性(经过测试的)的端到端的交付，这是一个更好的方式。一个特性团队工作在一个图10.4展示的应用程序上的时候，比如，他们的工作会贯穿整个架构的所有层次。他们可能开发一个特性，它涉及到数据库层，服务层，以及富客户端用户界面。同样在下个Sprint，他们可能开发一个特性去贯穿Web客户端，服务层，以及数据库层。
在一个多团队的项目中引入特性团队，有许多的优势：
• 特性团队能够更好地评估设计决策带来的影响。
在一个Sprint结束的时候，一个特性团队可以构建一个端到端的功能，遍历应用程序涉及到的所有的技术。这最大化了他们对自己做出的产品设计决策的了解（是否用户喜欢他们开发的功能？），以及关于设计的技术决策（这些实现的方式对我们来说是否有效？）
• 特性团队降低了交接带来的浪费。
一个群体或个人向另外一个群体或者个人交接工作是一种浪费。在组件团队的情况下，有一些风险，包括过多或者过少的开发功能，或者错误的开发功能，或开发一些根本不需要的功能等等。
• 它确保了正确的人在讨论。因为特性团队包括了从想法到可以运行，以及测试某一个功能所涉及到的所有技能，它确保了拥有这些技能的团队成员至少可以每天进行沟通。
• 组件团队会制造一些进度方面的风险。
组件团队的工作只有在它被特性团队集成到产品后才是有价值的。集成组件团队的工作的工作量必须由特性团队来估算，这些工作将会发生在当前的Sprint（最好），或以后的Sprint。估算这种类型的工作量是困难的，因为这需要特性团队在不知道组件质量的情况下估算集成的工作量。
• 它保持了对交付特性上的关注点。一个团队回到Scrum实施之前的习惯是极具诱惑力的。按照交付功能的方式来组织团队，而不是按照架构元素和技术，它能持续地提醒Scrum关注每个Sprint的功能交付。.
学会如何识别小的功能块是一个新的Scrum团队遇到的最大障碍之一。我记得在我的第一个Scrum项目中，最初很多次我们都在努力寻找一些我们可以在6周内交付的东西。很多年后，回头来看那个系统，我现在明白，我们可以有许多方法分割工作。事实上，如果我们想做一个一天的Sprint也是有可能的，我们有足够多的方法分解我们的工作，使它们可以在一天内完成。当他们获得经验以后，团队成员会发现很多方式去拆分功能，同时仍然可以在每个Sprint交付端到端的功能。如果这样做不太可能，则常常是因为团队的结构不是很合理。在放弃之前，重新考虑一下团队的成员以及他们的技能。
保守地使用组件团队
尽管你应该坚决赞成使用特性团队，有些场合创建一个组件团队是有好处的。一个组件团队，我这里用的这个术语是指一个团队开发软件给项目的另外一个团队，而不是交付给用户。组件团队的例子包括一个团队在应用程序和数据库之间开发一个OR－Mapping（对象-关系映射）层，或者一个开发可复用用户界面工具的团队。
有一点至关重要，一个组件团队在每个Sprint结束的时候还是要交付高质量的、经过测试的、潜在可交付的代码。尽管如此，一个组件团队交付的新的功能通常对他们自己来说是无意义的。回想一下我刚才给出的例子，一个组件团队开发的OR-Mapping层，只有在特性团队将它运用到上下文环境之后，最终的用户才会感兴趣。但是，一个开发可复用界面工具（比如客户化的下拉列表、数据录入表格等）的团队如何？这些工具也只有放到了特定的功能环境下，最终的用户才会感兴趣。比如，一个新的数据录入表格，除非它被放到了一个页面或者屏幕上，否则最终用户不会对它感兴趣。
只有在特性团队要求的时候再去构建组件
因为一个组件团队的工作要交付给另外一个团队，那些团队对于组件团队来说，通常扮演的是产品负责人的角色。如果你的团队需要我的团队的交付，那么你将扮演我的团队的产品负责人。这样你将拥有一个好的产品负责人所有的职责。在一个Sprint的开始，你将需要去帮着为我们的工作排列优先级；在Sprint结束的时候，你将接受或者拒绝它，对我们所做的工作提出反馈意见。
如果我的团队工作太超前，那么你将很难对我的工作进行排序或者提供反馈意见。正因为这样，在一个或者多个特性团队已经准备好使用它们之前，组件团队不应该开发新的功能。当一个组件团队所做的工作远远超前于特性团队的需要的时候，他们会开始猜想接下来会有什么需要，这样常常导致组件或者框架对特性团队来说是没有用的。所有的功能，包括这些组件团队开发出来的，需要在一个外部可见的环境中开发。
Rob是一个组件团队里的一名高级开发人员，他们为一个项目的15个特性团队开发一个OR-Mapping层。Rob的最初的任务是在自己开发这个技术还是使用一个商业的或开源的产品中做出一个选择。他们做出一个有疑问的决定——自己来开发。由于急切地想去证明这个决定的正确性，Rob和他的团队积极的尝试超前于特性团队的需要，而不是与一个或者多个特性团队紧密合作，Rob的组件团队对这个宏伟设计做出了一些大胆的猜测。在两个月（2个Sprint）中，他们没有交付任何内容给特性团队。 在3个月之后，当他们终于发布了一个初始版本，但它并没有满足特性团队的需要或期望。
Rob的团队应该和特性团队非常密切的合作，根据特性团队将要交付的功能的环境来增加新的功能。这将迫使组件团队和特性团队之间的紧密协作，增大交付真正需要的功能的几率。比如说，Rob的团队可以在第一个Sprint中只交付向数据库中写入固定长度的文本数据的功能。接受这个功能的特性团队不能向数据库中写入数值、日期类型等数据。他们也不能读取任何数据；但是，特性团队可以做一件事情——写入固定长度的文本数据，并从这里可以开始提供一些组件可用性方面的反馈给Rob和他的团队。
也许，在组件团队中配备一个来自于特性团队的人，这是确保一个组件团队能听到可帮助他们开发出有用功能的反馈的最好方式。一个被指派到组件团队中的人，他知道自己很快会回到特性团队，那么他更有可能确保组件团队的工作是有用的。
决定什么时候需要一个组件团队
只要有机会，组建特性团队，而不是组件团队。我喜欢首先假设一个多团队的项目都是特性团队。如果存在组建一个或多个组件团队将给产品带来最佳利益的证据，那么我愿意从那个假设中回来。
我建议只有在如下条件都符合的时候才考虑组件团队：
• 组件团队要开发将被多个特性团队使用的功能.
如果一个组件只会被一个特性团队使用，那么让这个特性团队来开发它。这个确保了在团队需要和期望的环境中开发新的功能，这使得这些实现更有可能被使用。尽管一个组件团队可能开发一个有用的功能给多个团队使用，更好的策略常常是让特性团队开发一个他们需要的功能，然后，当其他特性团队的需要发生的时候，让他们来重构和通用化这个功能。
• 使用一个组件团队可以减少共享的专家。在一些多团队的项目中，一些高专业性的学科被许多团队分享的。尽管专家的分享通常是必要的，但是分享太多，将带来一些不利因素，这些专家的时间变得支离破碎。你也许可以考虑创建一个组件团队，这样做可以使专家们在许多团队间共享的管理变得更容易。
