这个实验并不复杂，就是模仿大家日常工作中最常见的、项目小组的结构化组织形式，小组包含一个"老板"，一个项目经理，多个团队成员。由“老大”发号施令，让项目经理指挥自己团队的人执行，然后看结果。等15分钟的时限过去，“老板”揭示“成果”，小组成员要当众发表感想。难以想象，平时我们认为那么自然的组织结构，竟然有这么多缺陷！

　　老板感言：我以为大家知道的事情，原来他们根本不了解，不知道，信息完全不对称。

　　项目经理：太累，不懂领导到底要啥。

　　团队成员：闲得无聊，不知道要干什么。对工作没有积极性，不主动。

　　这样的结果就是：领导和项目经理的个人能力，基本决定了项目成功的可能性。

　　然后大家开始分析为什么会这样，原因在哪里，于是就引入了MSF的团队模型。

　　当然这个实验模型为了突出问题，做了很多简化，但在实际环境中，这些缺陷是确确实实存在的。

　　MSF的团队模型中，分成了6个角色，这6个角色是：程序管理、开发、测试、发布管理、用户体验、产品管理。每个角色之间是平等的关系，没有上下级的行政差别。

　　这几个角色并非一定要和人一一对应，当你没有足够的人手时候，一些角色可以重叠，由一个人兼任，但开发不推荐和其它角色兼任，这是因为要保持开发的封闭性。

　　当你的团队人数众多，规模比较大的时候，可以把大团队划分成小团队，再由核心团队总揽。既可以按照软件功能、特性来分成功能团队，也可以根据职能划分，例如，程序管理角色有多个人担任。这充分体现了MSF非常灵活、务实的一面，适应性很强。可以用于几个人的小TEAM，也可以适用于规模很大的团队。

　　敏捷软件开发理论适应性就弱些，大家公认不太适合超过10人的团队组织，而且，对成员的要求更高。

　　在另外一个模型-过程模型里面，MSF敏捷的一面又显露了出来。通过把复杂的项目分成多个版本进行迭代开发，来充分的简化项目难度。每个版本都有自己要完成的功能范围，可以看成一个"小项目"，项目小了，复杂度、难度自然大大下降，当然成功的概率就高的多。而且，和项目相关的人能很快的评估项目成果，来决定项目的"下一版本"方向。

　　在每个项目过程中，都包含一个很完整的阶段，项目构思、项目计划、项目开发、项目稳定、项目部署。从项目构思到项目部署结束，每个环节都有很多的所谓"里程碑"成果。就是每个阶段都有很明确的要求，到底要拿出什么成果。而这些成果，是需要团队成员共同努力来取得的，正好和团队模型相互结合。

　　在项目的任何一个阶段，每一个团队成员都要有成果，大家是并行工作的。这样一来，就避免了传统组织方法的很多弊病，如开发没结束，测试难以进行。在这样的模型中，不再是一个上司发号施令，下面的人去被动执行，已经演变成了大家都能积极主动的参与进来，每个人都有事情可以做。不同的角色在不同的项目阶段，分别起到主导作用。

　　课程中还有一个很重要的MSF原则贯穿其中，那就是风险。所谓风险，简单的说就是事件有可能发生，但是不确定何时何地。

　　团队最早开始做的事情之一就是管理风险，我们通过分组，在课堂上模拟了一遍，很有意思。每个人根据实验要求，挖空心思，冥思苦想，想象在项目过程中到底会发生什么事情，判断可能性和后果。连团队成员怀孕，无法继续工作这种事情也被找了出来，戏剧性的是，一个学员就承认，自己的团队就遇见了这样的麻烦，而且还不知道到底应该怎么办。