MSF 团队模型的建立是基于这样一种前提，即任何技术项目都必须达到特定的关键质量目标才能够被认为是成功的项目。如果任何一个角色无法实现其目标，这都会将危及整个项目。因此，每个角色都被认为是同等重要的，重要的决定都要共同作出。相关的目标和角色见下面的表格。
表 1：MSF 团队模型和关键质量目标
|
关键质量目标 |
MSF 小组角色 |
出口条件 |
|
按约束条件内交付产品 |
程序管理 |
我们的项目是在时间/资源的条件内交付的么？ |
|
按产品规格说明交付产品 |
开发 |
我们是否按照功能说明完成了各项功能？ |
|
保证所有问题都得到处理 |
测试 |
我们发现了所有的问题，而且都有处理方案？ |
|
产品部署和后续管理 |
发布管理 |
客户是否能快速方便地部署产品和进行后续管理？ |
|
让产品更好用 |
用户体验 |
产品是否适应用户的使用习惯？易学易用？ |
|
让客户满意 |
产品管理 |
客户是否（在总体上）满意我们的项目？ |
说白了，一个项目要到达的目标很多，MSF 团队模型 把这些目标让不同的角色去实现。在一个项目结束的时候，每个角色都问自己这样的问题 – 我是否达到了我的质量目标？
最后比如 – 测试团队（角色：测试）要保证“我发现的所有问题都得到解决”，那么测试团队就会做以下的两件事：
1．发现产品的问题
2．保证这些问题都得到处理
要注意的是，保证这些问题都得到“处理”和得到“解决”是不一样的，有些问题目前不能得到完美的解决，但是可以有让用户满意的处理方案，项目团队不能回避这些问题。
问：我们发现了问题，但是我们目前的“处理”不能让用户满意，怎么办？
答：测试团队就要和别的角色（如: 产品管理/程序管理/开发）一起研究用户需求，在可能的方案中选出一个：
1． 按照目前的状态交付，向用户说明（如：在某个操作系统/浏览器版本下，某个功能不能正常工作）
2． 推迟交付时间，让团队有足够的时间来解决问题。
3． 修改产品的约束条件（如要求客户的操作系统/浏览器必须是某一个版本以上，或者增加一个附加条件，产品发布后半年会出新的插件解决问题）。
在讨论处理方案的时候，每个角色从自己的质量目标出发，对自己的质量目标负责。
问：那有冲突怎么办？
答：那就吵呗 （众笑）。各个角色的利益是有一定的冲突的，MSF 没有掩饰这一点。MSF 团队模型的核心是，成功的技术项目必须符合各种利益相关人完全不同的，且常常对立的质量观点。
问：这么说在团队中有矛盾是正常的了？
答：对！例如，用户代表觉得新增加一个功能很酷，因为新功能“让产品更好用”，但是程序管理角色觉得会影响“按约束条件内交付产品”的目标，测试会觉得“保证所有问题都得到处理”的目标受到威胁，用大白话说，就是“我没有时间测试你的新功能，因此不能加这个功能！”。这就要各方在整个项目的共同利益之下，协商解决。
问：我原来认为测试人员说“我没有时间测试你的新功能，因此不能加这个功能！”是态度问题，会被开发人员鄙视的。
答：这是对产品质量负责的态度，你要代表你角色的利益，如果你有充分的授权和信任，你就要直言不讳。
除了项目的各个角色之外，MSF 团队模型还可以推广到包括操作、业务和用户等外部因素。在对立中寻找共同利益，在冲突中达到平衡。MSF 团队模型推动了不同利益代表在追求共同利益过程中的融合。
MSF 过程模型
每个项目都要经过一个生命周期，下面是 MSF 过程模型生命周期的一个简图。
MSF 过程模型是从传统的软件开发瀑布模型和螺旋模型发展而来的，它把瀑布模型中基于里程碑的规划的优势与螺旋模型中增量迭代的长处结合了起来。
MSF 过程模型的基本元素是阶段和里程碑。所谓“阶段”，就是在这一段时间里团队集中精力做某一类事情，每个阶段的结束都代表了项目的进展和团队工作重心的变化。比如在“开发阶段”结束后，团队就不再允许设计/实现新的功能，除非有充分理由的“变更请求”。
问：我觉得这样也太理想化了，一个十多人的团队，不可能在某月某日同时完成某一阶段，然后第二天进入下一阶段。
答：对，各个阶段之间会有缓冲区，团队中各个功能组的进度是各有区别的，不必强求一律。
团队用里程碑来检查工作是否结束和同步各个角色的进度，以此来确定当前阶段的目标是否已经实现。
此外，里程碑标志着每个阶段的结束，团队在此时应该引导成员转移工作的重心，并鼓励队员以新的视角来看待下一阶段的目标。在上一个阶段产生的各种交付内容，将成为下一阶段的起始点。
MSF敏捷开发模式
在Visual Studio 2005中，MSF演化为以下两个分支：
我的感觉是，MSF敏捷开发模式吸收了近几年来在软件业界流行的各种“敏捷”开发模式的优点，认识到目前大部分软件是以网络应用相联系，强调和用户更紧密地交流，快速叠代，避免不必要的过程。
在继承MSF3.0 基本原则的基础上，MSF 敏捷开发模式和以前有什么不同？有以下几点：
项目的商业价值要由用户说了算，那些“我觉得用户会喜欢”的东西要及早和用户交流。因为“我觉得”和“用户觉得”是两码事。
小飞：我说一句可能不太中听的话，我觉得有时用户好像很，嗯，很蠢。和他们交流有时好像对牛弹琴。
二柱：那就派大牛去弹好了。。。
大牛：有这么几种情况：
用户也不懂他想要什么
有些用户只有一个模糊的需求，他们说：我们企业要上ERP！你给我整出来。这种情况下，我们得和用户一起做需求分析。
用户想要的和商业价值无关
比如有些用户说，我想让每个按钮都是半透明的，还要有三维效果，就像一些网络聊天软件一样酷！这些要求和他的企业管理项目的价值没有直接联系。也许这个用户代表是一头牛，而不是用户代表，我们要找管牛的人。
用户想要的我们还不懂
这种情况下，我们是牛，用户是对我们弹琴。
防止缺陷的发生成为团队质量控制的首要任务，所有的角色都对防止缺陷的发生，和确保缺陷被修复负责。
有一些团队把开发和测试有意无意地对立起来，好像二者是矛盾的，一个典型的例子是，有时开发人员不想给测试人员足够的信息，好像不想“帮”测试人员找到缺陷；测试人员一旦找到缺陷，会有一些得意的表示 – “看，你写的代码那么臭，我又发现了N 个bug”。
一个大公司内部作过统计，在一个中大规模的团队中，一个“缺陷”从发生到被改正，中间经过了10个人，平均花费的时间是60 分钟。 有时我们吹嘘 “我改正了 N多的bug”， 也许要自省一下为什么会出现这么多。 最好的事情，是可能的缺陷在设计阶段之前就讨论过，并且在代码中已经避免了，因此在“缺陷跟踪系统”中，并且没有出现很多缺陷记录在案。但是软件的质量仍然很高。
保持随时可以发布的高质量
如果用户说：时间到了，网站要上马，我们应该很快地交给用户一个可用的版本，也许有不少功能没有加入，但是版本中包括的功能都可用。
这就要求我们必须保证项目的质量是“随时可用”
重视产品的安装和发布 – 产品要尽早能够达到随时安装，发布。我们以前的项目中，安装和发布都是最后阶段才作，这就导致下列问题 -
1．在开发过程中，测试团队很难安装产品，阻碍了测试团队的进展。很多情况下，测试人员不得不从多个源头拷贝不同的文件到测试环境中，才能测试
2．很多关于安装的缺陷得不到重视 – 用户拿到一个Beta 版，意见最大的就是 - 安装不上！或者好不容易装好了，却卸载不了，不得不重新安装系统。
二柱：好像这个VSTS 早期的版本就有这个问题，真是具有讽刺意义呀。
鼓励团队在实战条件下使用产品，就是“吃自己的狗食”，或者叫“自作自受”。大栓说：所谓“dogfooding”，也不难理解，比如我们小学食堂的伙食都很差 – 可以和“狗食”媲美。 （众人大笑），但是食堂职工无动于衷，因为食堂的领导和职工都是吃自己的小灶。如果食堂的领导实行“dogfood”，身体力行，和食堂员工一起吃给学生做的大锅饭，大锅菜。我想这个问题应该很快得到解决。
小飞：我们要做的项目，怎么dogfood?
大栓: 那我们就自己注册成为用户和商户，然后在系统上作一些交易吧。
阿超：这就要求我们的安装程序能够随时安装最新的版本，同时对于我们服务器端的数据迁移提出了很实际的要求。
实战条件下的质量的另一方面是 - 进行经常性的迭代（小的里程碑），使用户能够及时看到产品，给予评价。
问：这不就是快速原型法？
答：这不完全等同于快速原型法，用户看到的功能应该是能够马上使用的，而不只是一个原型。
我们一帮人在吭哧吭哧干活是为了什么? 主题是什么？是为了解决用户的问题。用户给项目投资了成千上万，不是为了看到一堆过时的文档。
同样，在团队成员之间的交流要简明，不必为了交接而搞出许多文档。另外一个重要的因素是 – 如果团队在整个软件生命周期都使用团队协作服务器（TFS），那么很多活动，决定，文档都自然地记录在TFS 上，不必额外去为了文档而再写一些东西。
// 这是我正在写的书的一段
// 故事情节纯属虚构
// 版权所有，不许转载