转自:http://blog.csdn.net/xuwedo2003/archive/2009/08/03/4402974.aspx
参考:
1. 清晰的责任，共同的职责
MSF 将工作进行中需要共同承担的职责和确保工作如期完成的责任结合起来。子团队中的每个角色都代表了对项目的一种独一无二的观点，但是没有哪个个人能够完全代表所有的不同质量目标。
2. 赋予小组成员权力
在一个高效的团队里，所有的成员都被赋予权力以便根据他们自己的承诺交付任务，并且充分信任团队的其他成员也能实现各自的承诺。MSF团队赋予成员权力以帮助他们履行承诺。
3. 聚焦业务价值
MSF 团队模型提倡将团队决策建立在：（１）团队对客户业务全面的认识（２）项目交付过程中客户能动的参与之上。“产品管理”角色在团队中担当客户的拥护者，这个角色常常由客户组织中的成员来担任。
4. 共同的项目设想
MSF 全力提倡采用一个共同的设想，以便把注意力放在团队的工作方法上。
对项目和过程的目标有一个清晰的了解是很重要的。因为一个共同的设想将使成员对软件的猜测明确化，并确保所有参与者都在为完成相同的目标而努力着。共同的设想是 MSF 团队模型的基础之一。
当所有的参与者都了解了这一设想并朝着这一设想工作的时候，团队便能够根据成员使自己的决策与小组意图相吻合，从而获得他们的权力。
没有共同的设想，团队成员可能出现与目标相抵触的观点，团队成员很难确定自己的成功，因为这种成功依赖于他们评价成功的设想。
5. 保持灵活，预测变化
MSF 认为事情在不断发生变化，将一项 IT 解决方案交付项目与这些变化相孤立是不可能的。
6. 推动开放式沟通
MSF 提出一个开放式的真诚的沟通方式，这种沟通存在于团队内部之间。开放的信息流不仅减少出现误解的频度，而且确保了所有成员可以降低项目周边环境中存在的不确定性。
（五）如何将MSF团队模型运用到我们公司的团队组织上？
MSF的团队模型中有两种变通的方式：
1. 比例缩放MSF团队模型
这种运用MSF团队模型的方式是将一个大型团队的人，按MSF团队模型的角色分解成小型的、功能齐全的小组。各小组内部成员都做同一种与角色相匹配的工作。这些小组并行工作，并经常进行同步工作信息。
这种组织方式适合于比较小的团队，可以充许一个人同时担任两个或两个以上的角色。
下面重点讨论，用这种方式组织实际的小团队时所涉及到的“角色的合并”问题：
由 前面的介绍的知识可以知道“产品管理”这个角色是靠近客户的，因此这个角色的团队成员一般不能与靠近程序实现的角色相合并，因为这两种角色分别代表了一个 相对比较“对立”的工作和思维方法和思维方式，如果把这样的角色进行合并，一个团队成员最终会哪一种角色的工作也做不好。于是乎“产品管理”与“程序管理”、“开发”角色就不能合并。
另一种情况是“开发”角色和“程序管理”角色也不能合并。原因是：
（1）、“程序管理”角色负责“交付满足项目约束的解决方案”，这个角色要进行项目管理、确定解决方案的体系结构、保证软件开发的过程、管理资源配置、管理项目工作日程表、风险管理、促进团队内部的交流和会议、跟踪项目进度和管理项目状态报告等等与项目的总体情况有关的管理工作。
（2）、 “开发”角色的需要“根据规格说明书创建解决方案”，也就是说这个角色的主要目标就是实现规格说明书中所描述的功能要求。“开发”角色作为软件的构建者， 开发低级别的解决方案和功能设计。除此之外，这个角色还担当了如同“技术顾问”一样的服务责任，因为功能是这个角色实现的，当然在提供技术问题的答案时， 这个角色给出的答案最为准确和权威。
这样就使得“开发”角色的专业性非常强，不适合与“程序管理”角色合并。实际上由于“开发”角色的专业性，“开发”角色与其他任何角色均不适合合并。
结合上面两点来看，一个比较侧重于项目总体把握与管理，一个侧重于在计算机世界中功能的实现与对外提供技术服务。这样如果将这两种角色进行合并，一个人即要掌控宏观又要了解微观，对人的要求很高，而且也不利于工作的质量。
下面是一个三个人的小团队的例子：
从中可以看出，“用户体验”、“产品管理”、“测试”角色等侧重于保障工作的角色进行了合并。
将“程序管理”、“发布管理”的侧重于项目控制的角色进行了合并。
“开发”角色，由于专业性很强，不与其他任何角色进行合并。
下面是一个四个人的团队的角色合并情况：
2. 功能小组
由于第一种按比例缩放团队模型的方式在组织成员数比较多的大团队时有一些缺点，比如各角色内部分工不明确，很多人同时做同一种工作时会造成人力资源的浪费等方面的问题。微软推荐使用“功能小组”的方式来组织实际公司内的组织。
功能小组的方式就是把一个大团队中的成员分成各角色以后，再对每个角色中的成员，按MSF团队模型的指导，再分成更小的“功能小组”。
“功能小组”是在一个角色内部存在的小组。它们的存在是因为一个小组或项目的人员过多，以至需要将一个角色内部的员工根据职能来进行基于小组的分组。如下图所示：
上 图中就描述了这样一个事例：程序管理角色中的人员比较多，而且所负责控制的功能也很多，这时就可以将该角色中的成员按照“桌面功能团队”、“文件和打印功 能团队”、“消息传递功能团队”这样以“功能”为导向的方式来将重新组织，每个小团队都是一个“功能小组”。每个“功能小组”中又可以按照自身的需要将MSF按照“按比例缩放”和“功能小组”两种方式之一进行组织。
这样做的优点就是各个“角色功能小组”内部的子团队的责任明确，在灵敏的授权和团队的平衡性上均具有很好的优越性。所以，这种“功能小组”的成员会变得有责任。
（六）MSF 组队模型不是一张组织结构图
当应用MSF团队模型进行实际的组织团队的时候，一个很重要的问题一定要解决，那就是“谁是项目主管”?
MSF团队模型描述了团队中的主要角色以及项目组的责任，但是它没有从全体职员管理的角度来定义管理结构。组织结构图是描述上下级关系，MSF团队模型不是结组结构图。
在MSF中“程序管理”角色的首要目标就是在项目限制下完成交付成果。时间就是其中的一个限制。“程序管理”这个角色要完成这个目标，就会在很多时间里成为最高的决策下达者。
在MSF中， 真实的做法是：领导的地位是不固定的，这自始至终是会被共享的。在不同的时期，不同的内外部环境，不同的问题上，领导的地位是变化的。所有角色都会理解这 种必要性，因为只有专某件事的角色才最为了解某一方面的问题，做出的决策最为合理。当某问题一旦被解决，各角色达成一致，立即共享领导地位，这是一种无分 层的组织方法。
但， 我个人理解，我们不能完成照搬这样的做法。在国外的开发团队中或许这种方法可以行得通，因为这是一种比较理想化的组织团队的方法。在我公司，应该根据现有 的人员、环境、公司的管理体制，去掉这一部分的“共享领导地位”的做法。建议采用“程序管理”角色作为“项目主管”。