功能小组
功能小组是在一个角色内部存在的小组。它们的存在是因为一个小组或项目的人员过多，以至需要将一个角色内部的员工根据职能来进行基于小组的分组。Microsoft 公司就是一个例子，它的一个产品开发小组通常拥有一个产品规划人员与一个产品生产人员。两个工作都是产品开发的一个方面：一个致力于取得客户真正需要的功能，另一个则集中注意力把产品的优点向潜在的用户传达。
这对开发同样是正确的，开发者可以通过他们工作的服务阶层来分组：用户、业务、或者数据。通常开发者还可基于他们是解决方案构建者还是组件构建者来分组。组件构建者通常是低级语言 C 的开发者，他们构建的可复用组件可以由企业调节。解决方案构建者来通过把这些组件封装在一起来构建企业应用软件。解决方案构建者通常使用像 Microsoft® Visual Basic® 这样的高级语言来工作。
功能小组常常被包含在工作组内部的一个层次结构种。比如在程序经理向一组程序经理进行汇报的同时，他们还通过领导程序经理向上进行汇报。像这样的结构同样可以在功能领域出现，且要优于角色群集层次。要牢记的重要事情就是：这个层次不可以阻碍项目级别的组队模型。角色的目标和它们的整个项目小组的责任性都被保留下来。
共享角色
即使组队模型由六个角色组成，一个小组还是不需要达到六个成员的最小值。它也不需要每个角色一个成员。关键的地方是每个小组中的六个目标必须被表现出来。有代表性的是，每个角色有一个成员可以帮助确保有人照顾到每个角色的利益，不过不是所有的项目都可以从这样的填满每个角色的情形中受益。通常，小组成员必须共享角色。
在小型小组中，角色必须被小组成员共享。两条原则指导角色共享。第一条原则是开发小组成员不能共享一个角色。开发人员是项目构建者，他们不能从他们的主要任务中分心。为开发小组添加附加的角色时，由于产生了这些附加的责任，只不过增加了偏离计划的可能性。
第二条指导原则是尽量不要使有内部利益冲突的角色被组合。例如，产品管理和程序管理因为有利益冲突而不能被组合。产品管理希望满足客户，相反的，程序管理希望按时按预算交付。如果这些角色被组合，同时客户又要求变革，那么出现的风险不是变革没有达到预期以维持客户满意，就是在没有理解给项目带来的影响的情况下被接受。拥有不同小组成员，表现了这些角色帮助确保了每个观点都受到了平等对待。如果尝试组合测试与开发，这一条同样是适用的。
下列表格说明了组合角色的风险(由"Not Recommended"或"Unlikely symbols"标识）和促进作用(由"Possible"记号标识），不过对任何小组的做法，成功的角色共享还涉及到现实成员自身和他们带来的经验和技能。
msftm303.gif" width=335 border=0>横排和纵排交叉处是 N 的，表示这些角色不被推荐来进行组合。因为有利益方面的冲突，除非有绝对的必要，或者关联的风险可以被关联风险的缓解与应变计划处理。很显然，这些角色的目标在多个层次上都有冲突，这将使组队模型不稳定，并增加了组合时出现问题的可能性。角色组合并不罕见——如果小组选择小巧的组合，并积极的管理相关风险，问题发生的几率将会降至最低。
逐步升级与责任性
MSF 组队模型不是一张组织结构图
当应用 MSF 组队模型的时候，一个问题经常被问起：“谁是主管？”。一张组织结构图描述了谁是主管以及谁向谁负责。与之不同的是，MSF 组队模型描述了主要角色以及项目小组的责任，但是没有从全体职员管理的角度来定义管理结构。在很多案例中，项目小组的成员来自于几个不同的组织，在行政上对不同的管理者负责。
这里有几个确定的情况可能会出现，尽管如此，小组仍然不能对其中的观点达成一致。在付出了应有的努力达成一致后，就到了程序管理角色逐步提高，并为项目的向前推进进行重要领导的时候了。 程序管理角色的首要目标是在项目限制下完成交付，时间就是其中的一个限制。因而，这个角色和小组要完成这个目标，程序管理角色会有很多次临时成为的最高决策下达者，以便使项目回到轨道上来。在这些图例中，领导地位特有的至始至终都被共享，这些角色理解这种变动的必要性，它为组队构建了一种更为健壮的可接受的层次并通过权威决策大宗买进，以达到实现项目目标的目的。这个问题一旦被解决，小组就可以达成一致，并立即共享领导地位责任。现在已经证明了同等级组队的灵活性与可适应性足够处理这些挑战，并为项目组队留下了一种无分层方法。
外部协调——谁应当负责？
为了保证组队的成功，还必须和其他外部工作组相互影响、交流、以及协调。这些工作组的范围涉及顾客、用户、还有其他开发小组。在多数案例中，那些与小组在某点上联系的顾客都会要求解决方案存在明确的责任性。虽然同等级的小组在解决方案的成功交付中要求共享责任，不过对于交流规划中的责任性和报告结构文档的清晰的区分是很重要的，因为这样顾客和开发小组都能懂得小组中谁对促进这个信息负责。
下列图表说明中列举的具有代表性的责任，不是协调业务中心就是协调技术中心。程序管理、产品管理、用户经验、以及发布管理是主要的促进者。这些角色都是内在和外在的中心，尽管开发和测试都是以内在的中心并与外部交流相隔绝。
不过这并不意味着开发者和测试者将会与外部世界相隔绝。对于 MSF 小组期望达成的建立以客户为中心理念的来说，与顾客组织和真正的用户的接触是无价之宝，特别是在早期的项目成形阶段。不管如何这种交流都不能沦为形式，因为在项目后期，这将使致力于解决方案交付的开发小组和测试小组遭遇麻烦。
本图表描绘了一个高水平的前景。富有特色的是，小组必须同更多的像质量保证、财政、法律这样的外部工作组协调。与外部工作组的接口的清楚与明了是很重要的，开发与测试继续保持隔绝，这样可以保证它们不受干扰的进行有效的工作。
另外，有一个重要的地方需要强调，当进行外部协调的各种角色能够提供输入与建议的时候，不要让单个的成员或是作为整体的小组拥有修改项目交替使用的，像功能、计划以及资源这样的优先级和细节的权限。这些改变都是项目客户与监护人的特权，并由项目小组执行。这也为由均等伙伴和对等者组成的小组通过组织权限、层次、和结构，如何服从与结盟提供了一个例子。
小结
MSF 组队模型并不能保证项目一定成功。除了小组结构之外，有着更多因素决定着一个项目的成功与失败。不过小组结构仍然是很重要的。
在 快速开发中，Steve McConnell 举例说明了这一点：
“即使您拥有了有技术、有动力、辛勤工作的员工，错误的小组结构也能够消弱他们的努力，而不是飞速的前往成功。一个不良的小组结构会增加开发时间、降低质量、使士气低靡、增大周转期间，最终导致项目取消。”
MSF 组队模型正好是来处理这个问题的。恰当的组队结构是成功的基石，贯彻这个模型并且运用它的优先原则能够帮助小组，使之更加有效，因而取得成功。
尾注
(1)参阅 Jim McCarthy Dynamics of Software Development (Redmond, WA: Microsoft 出版, 1995)以便在设计中分享更多的最优化的小组的经验。
本文档中的信息代表 Microsoft Corporation 到发布之日对所讨论问题的最新观点。由于 Microsoft 必须对不断变化的市场情况作出反应，这些信息不能解释为 Microsoft 一方的承诺。Microsoft 不保证所提供的任何信息在发布之后仍然正确。
本指南只用于提供信息。MICROSOFT 不对本文档的信息做任何明示或者暗示的保证。
用户有责任遵守所有生效的版权法。根据版权法的规定，如果没有 Microsoft Corporation 的书面许可，不得以任何形式或者利用任何手段（电子、机械、影印、录音带或其他方式），为了任何目的，对本文档的任何部分进行复制、存储、在检索系统引用以及传播。
Microsoft 对本文档中的所有内容都拥有专利、专利应用、商标、版权或其他知识产权。除非 Microsoft 通过书面许可协议明确提供，此文档并不意味着授予您对这些专利、商标、版权或其他知识产权的任何许可。
© 2002 Microsoft Corporation。保留所有权利。
Microsoft 和 Visual Basic 是 Microsoft Corporation 在美国和/或其它国家/地区的注册商标或商标。
这里提到的真实的公司名称和产品的名称可能是它们各自所有者的商标。
文章来源于领测软件测试网 https://www.ltesting.net/
