MSF有8个基本原则，我把它们都翻译成中文，并加上了我的理解。下面来分别讨论：

（1）推动信息共享与沟通（Foster open communications）

（2）为共同的远景而工作（Work toward a shared vision）

（3）充分授权和信任（Empower team members）

（4）各司其职，对项目共同负责（Establish clear accountability and shared responsibility）

（5）重视商业价值（Focus on delivering business value）

（6）保持敏捷，预期变化（Stay agile, expect change）

（7）投资质量（Invest in quality）

（8）学习所有的经验（Learn from all experiences）

1、 推动信息共享与沟通

第一个原则，用大白话来说，就是所有信息都保留，并公开，讨论要包括所有涉及的角色，决定要公开，并告知所有人。当然，对牵涉到技术机密、安全性等信息要采取必要的保护措施。

看不到所有的信息，那么项目进度以及项目中存在的各种问题就不能及时让所有人知道，这样MSF中其他的原则也就不能实行了。没有开放的信息，也就谈不上“授权”，或者“建立清晰的责任和共同的职责”，以及“保持敏捷，预测变化”。这也是为什么“推动信息共享与沟通”是第一个基本原则。

MSF团队模型和MSF过程模型也是建立在“信息共享与沟通”原则上的。

2、为共同的远景而工作

“共同的远景”是指产品的远景。我们做一个产品，不管是应用软件、行业软件，还是通用软件，要明确项目的目标是什么。

（1）这个目标必须是明确的，没有二义性；

（2）这个目标不是当前就能达到，必须是通过努力才能达到的；

（3）这个目标不是空泛的，它应该对项目成员每天的工作都有指导作用。每天你来上班，如果发现你做的事情对项目的远景没有帮助，你应该跟老板提出来。

一般是由“有远见的人”提出，然后公开讨论，在讨论的过程中，可以消除误解，凝聚共识。这是一个项目的关键，是项目第一阶段要达到的主要目标。

3、 充分授权和信任

这一点的关键是“授权”这个词，英语是Empower，是什么意思呢？

授权（Empower）有两个意思：一是给某人权力和权威（Give authority to somebody：to give somebody power or authority）；二是给予某人更多自信和自尊（Inspire somebody with confidence：to give somebody a sense of confidence or self-esteem）。

在一个高效的团队中，所有的成员都应该能得到充分的授权，他们有权力在自己的职权范围内按照他们自己的承诺完成任务，同时，他们也充分信任其他同事也能实现各自的承诺。类似地，团队的顾客（包括内部和外部的顾客）也认为团队能兑现承诺，并进行相应的规划。

充分授权的管理方式是MSF的核心观念之一。MSF团队模型就是建立在以下两个原则上的：

（1）平等协作——成员之间、团队之间是平等协作的关系；

（2）充分授权给团队和成员。

这就是为什么MSF团队模型是网状，而不是层次结构。

这样做有什么好处？好处有两点：

（1）被授权的人会承担起自己对项目的责任，同时也期望同事们也同样对项目负责；

（2）MSF提倡自下而上的计划，每个人有充分的权力估计并决定自己的任务需要多长时间，而不是上级交给的时间，这意味着让真正做这件事的人按照自己的估计去完成任务。这样做的结果是啥？是人人都会支持项目的计划和时间表，因为这个时间表是每个人自下而上订出来的！

这要靠工具的支持，在VSTS系统中，由于所有工作的进展都记录在案，任何延迟都会被及时发现，这样组长（或其他层次的领导）就不用把精力花在“询问”上，而在“帮助解决”上，在最关键的时候提供指导和帮助。领导在项目中的角色是“支持成员完成任务”，而不是“控制成员，迫使他们完成任务”。充分授权在MSF团队模型的另一个含义是：信任，鼓励团队成员成长，每人都可以在某一时段、某一领域当领导。比如二柱是程序安全性的专家，他就可以带领其他成员对项目进行安全性检查。如果测试工程师斯坦刚刚学习了如何做压力测试，他可以带领其他测试人员对产品进行全面的压力测试。

授权不等同于放任不管，领导者在授权之后，要为手下的成功提供各种必要的帮助——技术上的培训，策略上的提醒，以及各方面的信息和资源。

4、各司其职，对项目共同负责

团队中的每个角色都有自己的职责，如果出了问题，这个角色就要负责任。

  MSF团队模型和关键质量目标

关键质量目标

MSF小组角色

出口条件

按约束条件交付产品

程序管理

我们的项目是在时间/资源的条件内交付的么？

按产品规格说明交付产品

开发

我们是否按照功能说明完成了各项功能？

保证所有问题都得到处理

测试

我们发现了所有的问题，而且都有处理方案吗？

产品部署和后续管理

发布管理

客户是否能快速方便地部署产品和进行后续管理？

让产品更好用

用户体验

产品是否适应用户的使用习惯？易学易用？

让客户满意

产品管理

客户是否（在总体上）满意我们的项目？

比如说，如果产品发布后，客户在部署和管理上出现了很多问题，那负责“产品部署和后续管理”的角色“发布管理”人员就要站出来对此负责。

与此同时，团队的各个角色合起来，对整个项目最终的成功负责，为什么？因为每个角色在其职责范围内的失败都会导致整个项目的失败。而且各个角色的工作都是互相渗透、互相依赖的。这种互相依赖的方式也鼓励团队成员在自己本职之外为其他领域做贡献。例如，测试人员可以帮助“用户体验”角色更好地设计用户界面，因为如果用户界面很差，再好的功能也不能发挥应有的作用。

如果我是责任人，最终还要我自己拿主意。别人的意见都只是参考。我的责任是把事情做出来，而不是讨好所有人，让他们知道我按照他们的意见做了。

在项目进展的过程中，对于每一项任务，每个人都要明确以下几点：

◆  Who：谁负责；

◆  What：做什么，具体的执行方案，什么叫做“做好了”；

◆  When：什么时候开始，什么时候结束；

◆  Why：为什么是这样安排（和项目的远景是否吻合），在什么情况下可以变更？

与“信息共享与沟通”原则相呼应，这样的安排能让所有人都明确自己的职责，同时有“大局观”——知道别人在做什么，为什么，以及整个项目的目标。

5、重视商业价值

我们都是搞技术的，但同时我们也是一个商业实体，我们的项目都应该是出于商业目的，如果没有商业的需求，再酷的技术也没有用，商业项目需要重视市场和用户，技术是处于第三位的。

回首望去，很多“高科技”的公司就是过客。怎样衡量一个项目的成功？并不是最酷的技术，而是商业的成功。

一个项目的商业价值只有在它被成功地发布并运行时才能体现出来，所以，MSF过程模式包括了开发和发布阶段。当年在学校的时候，所有课程的项目都没有真正在实际环境中运行过，现在的学生应该有条件这么做了吧？

“Don’t start a business if you can’t explain what pain it solves, for whom, and why your product will eliminate this pain, and how the customer will pay to solve this pain.”

如果你还没有能说清楚你的产品解决了什么问题，为谁解决问题，为什么你的产品会解决这些问题，以及客户怎样付钱让你解决问题，那你就不应该贸然创业。

类似地，如果我们没有搞清楚我们的项目会解决什么问题，为谁解决问题，为什么它会解决问题，以及怎样才能拿到客户的报酬，那我们的项目还不能算是真正开始。

在MSF团队模型中，“用户体验”这个角色代表了用户的利益，保证产品能真正易于使用；“产品管理”这个角色代表了客户的利益，保证了我们的产品能为顾客提供商业价值。搞技术的，要尊重这两个角色，因为他们代表的是我们的衣食父母。

6、保持敏捷，预期变化

软件工程，唯一不变的是变化。所以干脆别幻想客户的需求会在第一时刻很明确，然后保持不会变。要注意，我们是预期变化，不是期望变化。

除开外部原因，团队内部也在变化，我们对技术的掌握每天都在提高，原来认为不可能的事可能变得容易。我们对客观世界和软件系统的了解每天都在深化，原来觉得没问题的小细节忽然成了大问题。甚至原来一起打拼的同事忽然要离开……这些都要求我们团队保持敏捷的身段。

最近业界有人总结，项目需求的生存期是18个月，就是说如果一个项目的需求是18个月前确定的，而产品还没有做出来，那几乎就可以不做了，因为需求肯定已经发生了很大变化。

7、投资质量

对质量的重视，引起对质量的投资，引起对人、过程和工具的投资。

（1）投资要讲效率。软件开发过程大部分时间花在了解/设计/变更/再了解/再设计的过程中。我们要重视质量，但并不是要不惜一切代价达到最高的质量标准，因为提高人/过程/工具的质量是要花成本的！ 我们不是为提高质量而提高质量。我们要讲投资的效率。比如，在做快速原形的过程中，有些部分可以做得粗糙一点。

（2）投资要讲时机，比如说对于某项技术的培训，最好的做法是在即将需要的时候进行培训。太超前或滞后都不灵。

（3）投资是长期的。和投资股票/不动产一样，真正的投资者看重的是长线的收益；人的成长、团队的成熟都需要时间，不可能短期内立竿见影。 那些“短平快”的东西，叫投机，不叫投资。

8、 学习所有的经验

古今中外，人们对经验的学习还是比较重视的，我们经常听到“忘记过去的人注定会重复过去的错误”等类似的谚语。咱们中国的老祖宗也没少唠叨，哪位能提供一些成语典故？

在学习过去的经验的同时，也要避免让过去的经验妨碍解决现在的问题。

“每一个项目都有自己的特色，不宜生搬硬套”；

“项目的经验都在各人的脑子里”；

“项目结束后，大家都散伙了，没人组织总结，或者写总结的人有偏心”；

“有时总结变成互相指责，搞得不欢而散”；

这一原则有两个含义——

（1）把经验总结出来；

（2）分享经验。

为什么要坚持总结和分享？是为了——

（1）让团队成员从别人的成果和失败的例子中学到东西；

（2）帮助新项目重复以往成功的做法；

（3）培育团队总结的习惯和“批评与自我批评”的文化。

MSF在每一个里程碑结束时都要做一个“里程碑回顾”，这个回顾不必等到整个项目结束才做。这样做的好处是，大家对最近的成败都记忆犹新，能提供比较准确和全面的反馈；如果发现了错误，可以马上研究解决办法，在下一个里程碑中通过实践来验证。另外，一些好的做法可以及时得到总结和推广。

在项目结束时，MSF推荐请团队以外的专家来主持召开“事后诸葛亮”会，这样的专家会比较系统地总结团队的成功经验和失败教训，同时也客观评价团队的一些特性和团队的开发过程管理，这样能促使团队成员以客观、向前看、解决问题的心态来参加“事后诸葛亮”会，避免主观臆断或相互指责。

 MSF团队模型

MSF团队模型定义了小组同级成员的一些角色和职责，如图2-2所示。

MSF团队模型认为，任何技术项目都必须达到特定的关键质量目标才能够被认为是成功的项目。如果任何一个角色无法实现其目标，都将危及整个项目。因此，每个角色都被认为是同等重要的，重要的决定都要共同做出。相关的目标和角色如表所示。

说白了，一个项目要达到的目标很多，MSF团队模型让不同的角色去实现这些目标。在一个项目结束的时候，每个角色都问自己这样的问题——我是否达到了我的质量目标？

最后，比如测试团队（角色：测试）要保证“我发现的所有问题都得到解决”，那么测试团队就会做以下两件事：

（1）发现产品的问题；

（2）保证这些问题都得到处理。

要注意的是，保证这些问题都得到“处理”和得到“解决”是不一样的，有些问题目前不能得到完美的解决，但是可以有让用户满意的处理方案，项目团队不能回避这些问题。

如果发现了问题，但是我们目前的“处理”不能让用户满意，怎么办？

测试团队就要和别的角色（如：产品管理/程序管理/开发）一起研究用户需求，在可能的方案中选出一个，比如：

（1）按照目前的状态交付，向用户说明（如：在某个操作系统/浏览器版本下，某个功能不能正常工作）；

（2）推迟交付时间，让团队有足够的时间来解决问题；

（3）修改产品的约束条件（如要求客户的操作系统/浏览器必须是某一个版本以上，或者增加一个附加条件：产品发布后半年会出新的插件解决问题）。

在讨论处理方案的时候，每个角色从自己的质量目标出发，对自己的质量目标负责。

那有冲突怎么办？

那就吵呗（众笑）。各个角色的利益是有一定的冲突的，MSF没有掩饰这一点。MSF团队模型的核心是，成功的技术项目必须符合各种利益相关人（stake holder）完全不同且常常对立的质量观点。

这么说在团队中有矛盾是正常的了？

对！例如，用户代表觉得新增加一个功能很酷，因为新功能“让产品更好用”，但是程序管理角色觉得会影响“按约束条件内交付产品”的目标，测试会觉得“保证所有问题都得到处理”的目标受到威胁，用大白话说，就是“我没有时间测试你的新功能，因此不能加这个功能”。这就要各方在整个项目的共同利益之下，协商解决。

我原来认为测试人员说“我没有时间测试你的新功能，因此不能加这个功能！”是态度问题，会被开发人员鄙视的。

这是对产品质量负责的态度，你要代表你角色的利益，如果你有充分的授权和信任，你就要直言不讳。

除了项目的各个角色之外，MSF团队模型还可以推广到包括操作、业务和用户等外部因素。在对立中寻找共同利益，在冲突中达到平衡。MSF团队模型推动了不同利益代表在追求共同利益过程中的融合。

 MSF过程模型

每个项目都要经过一个生命周期，下图是MSF过程模型生命周期的一个简图。

MSF过程模型是从传统的软件开发瀑布模型和螺旋模型发展而来的，它把瀑布模型中基于里程碑的规划优势与螺旋模型中增量迭代的长处结合了起来。

MSF过程模型的基本元素是阶段和里程碑。所谓“阶段”，就是在这一段时间里团队集中精力做某一类事情，每个阶段的结束都代表了项目的进展和团队工作重心的变化。比如在“开发阶段”结束后，团队就不再允许设计/实现新的功能，除非有充分理由的“变更请求”。

各个阶段之间会有缓冲区，团队中各个功能组的进度是各有区别的，不必强求一律。

团队用里程碑来检查工作是否结束和同步各个角色的进度，以此来确定当前阶段的目标是否已经实现。

此外，里程碑标志着每个阶段的结束，团队在此时应该引导成员转移工作的重心，并鼓励队员以新的视角来看待下一阶段的目标。在上一个阶段产生的各种交付内容，将成为下一阶段的起始点。

MSF敏捷开发模式

在Visual Studio 2005中，MSF演化为以下两个分支：

◆  MSF敏捷开发模式；

◆  MSF CMMI开发模式。

我的感觉是，MSF敏捷开发模式吸收了近几年来在软件业界流行的各种“敏捷”开发模式的优点，认识到目前大部分软件是以网络应用相联系，强调和用户更紧密地交流，快速叠代，避免不必要的过程。

在继承MSF 3.0基本原则的基础上，MSF敏捷开发模式和以前有什么不同？有以下几点。

 更强调与用户的交流

项目的商业价值要由用户说了算，那些“我觉得用户会喜欢”的东西要及早和用户交流。因为“我觉得”和“用户觉得”是两码事。

（1）用户不懂他想要什么。有些用户只有一个模糊的需求，他们说：我们企业要上ERP！你给我整出来。这种情况下，我们得和用户一起做需求分析，先把牛找出来；

（2）用户想要的和商业价值无关。比如有些用户说，我想让每个按钮都是半透明的，还要有三维效果，就像一些网络聊天软件一样酷！这些要求和他的企业管理项目的价值没有直接联系。也许这个用户代表是一头牛，而不是用户代表，我们要找管牛的人；

（3）用户想要的我们还不懂。这种情况下，我们是牛，用户是在对我们弹琴；

（4）大家心里想的不是牛，也不想弄清牛想什么，只要有钱就行。例如：

质量——防患于未然

防止缺陷的发生成为团队质量控制的首要任务，所有的角色都要对防止缺陷的发生和确保缺陷被修复负责。

有一些团队把开发和测试有意无意地对立起来，好像二者是矛盾的。一个典型的例子是，有时开发人员不想给测试人员足够的信息，好像不想“帮”测试人员找到缺陷；与此同时，测试人员一旦找到缺陷，会有一些得意的表示——“看，你写的代码那么臭，我又发现了N个Bug”。这种对立情绪，也许在短期内能刺激成员的工作热情，而从长远来看是有害的。很少有人会希望在这种充满对立情绪的环境中工作。

微软公司内部做过统计，在一个中大规模的团队中，一个“缺陷”从发生到被改正，中间经过了近20道工序，平均总的时间开销是12小时。最好的事情，是可能的缺陷在设计阶段之前就讨论过，并且在代码中已经避免了，因此在“缺陷跟踪系统”中，并没有出现很多缺陷记录在案，但是软件的质量仍然很高。

 重视在实战条件下的质量

这一点要求我们保持随时可以发布的高质量。如果用户说：时间到了，网站要上马。我们应该很快地交给用户一个可用的版本，也许有不少功能没有加入，但是版本中包括的功能都可用。

这就要求我们必须保证项目的质量是“随时可用”。为了达到这一点，我们要重视产品的安装和发布——产品要尽早能够达到随时安装、发布的标准。在我们以前的项目中，安装和发布都是最后阶段才做，这就导致几个问题：

（1）开发过程中，测试团队很难安装产品，阻碍了测试团队的进展。很多情况下，测试人员不得不从多个源头拷贝不同的文件到测试环境中，才能开始测试。浪费了很多时间；

（2）关于安装的缺陷得不到重视——用户拿到一个Beta版，意见最大的就是：安装不上！或者好不容易装好了，却卸载不了，不得不重新安装系统。

鼓励团队在实战条件下使用产品，就是“吃自己的狗食（Dogfood）”，或者叫“自作自受”。

精简过程，直奔主题

我们一帮人吭哧吭哧干活是为了什么？主题是什么？是为了解决用户的问题。用户给项目投资了成千上万，不是为了看到一堆过时的文档。

同样，在团队成员之间的交流要简明，不必为了交接而搞出许多文档。另外一个重要的因素是，如果团队在整个软件生命周期都使用团队协作服务器（TFS），那么很多活动、决定、文档都自然地记录在TFS上，不必额外去为了文档而再写一些东西。

 MSF CMMI开发模式

CMMI是什么

CMMI是英文Capacity Maturity Model Integrated（能力成熟度集成模型）的简称。CMMI是CMM模型的最新版本——CMM已经被淘汰了。资料显示，运用CMMI模型管理的项目，不仅降低了项目的成本，而且提高了项目的质量与按期完成率。因此，美国在国防工程项目中全面地推广CMMI模型，规定在国防工程项目的招标中，达到CMMI一定等级的公司才有参加竞标的资格。该模型包括了连续模型和阶段模型这两种表示方法，一个组织根据自己的过程改进要求可以自由选择合适的表示方法来使用。

CMMI有两种不同的实施方法，其级别表示不同的内容。

（1）连续式，主要是衡量一个企业的项目能力。企业在接受评估时可以选择自己希望评估的项目来进行评估。因为是企业自己挑选项目，其评估通过的可能性就较大一点。但是，它反映的内容也比较窄一点。它仅仅表示企业在该项目或类似项目的实施能力达到了某一等级。

（2）阶段性。它主要是衡量一个企业的成熟度，亦即企业在项目实施上的综合实力。就是说处于某一阶段的企业，做大部分项目都要到达某一要求。一般地讲，一个企业要想在阶段性评估中得到三级，其企业内部的大部分项目要达到三级，小部分项目可以在二级，但绝不能够只有一级。阶段性实施方法的难度要大一些。

CMMI虽然源于美国，但在世界各地得到了广泛的推广与接受。CMMI在印度的应用甚至超过了美国。据SEI统计，世界软件企业评估达到5级的共有25个，印度占了其中的16个。（果冻批注：会考试！）这也是印度软件业得以迅速发展的一个原因。

CMMI目前已成为许多大型软件业者用于改善组织内部软件工程所采行的软件评估标准，CMMI也陆续应用于系统工程及软件采购方面，成为国际间通用的一种软件生产程序标准。有专家预测，在未来的几年内，CMMI将成为ISO9000之后的又一个国际标准。

实施CMMI的意义

很多人认为，实施CMMI的意义在于项目工程走向世界，可以在西方国家接到订单。实际上，更为重要的意义则是，CMMI的实施能够提高我国企业的管理水平，降低企业的成本。事实表明，企业实施CMMI技术的投入都会得到丰厚的回报。据SEI统计，用于软件项目上的CMMI的投资，其回报率在5:1到8:1之间。（果冻批注：何以算出来8:1？）由此可见，为什么这么多的企业纷纷实施CMMI项目管理技术。

CMMI一级，完成级。在完成级水平上，企业对项目的目标与要做的努力很清晰，项目的目标得以实现。但是由于任务的完成带有很大的偶然性，企业无法保证在实施同类项目的时候仍然能够完成任务。企业在一级上的项目实施对实施人员有很大的依赖性。

CMMI二级，管理级。在管理级水平上，企业在项目实施上能够遵守既定的计划与流程，有资源准备，权责到人，对相关的项目实施人员有相应的培训，对整个流程有监测与控制，并联合上级单位对项目与流程进行审查。企业在二级水平上体现了对项目的一系列管理程序。这一系列的管理手段排除了企业在一级时完成任务的随机性，保证了企业的所有项目实施都会得到成功。

CMMI三级，明确（定义）级。在定义级水平上，企业不仅能够对项目的实施有一整套的管理措施，并保障项目的完成；而且，企业能够根据自身的特殊情况以及自己的标准流程，将这套管理体系与流程予以制度化。这样，企业不仅能够在同类的项目上成功地实施CMMI，也能在不同类的项目上成功地实施。

CMMI四级，量化管理级。在量化管理级水平上，企业的项目管理不仅形成了一种制度，而且要实现数字化的管理。通过量化技术来实现流程的稳定性，实现管理的精度，降低项目实施在质量上的波动。

CMMI五级，优化级。在优化级水平上，企业的项目管理达到了最高的境界。企业不仅能够通过信息手段与数字化手段来实现对项目的管理，而且能够充分利用信息资料，对企业在项目实施的过程中可能出现的次品予以预防。能够主动地改善流程，运用新技术，实现流程的优化。

由上述的5个级别我们可以看出，每一个级别都是更高一级的基石。要上高层台阶必须首先踏上较低一层台阶。

MSF for CMMI能做什么

能帮助团队加速达到CMMI第三级“明确”阶段。但是MSF的过程模板只实现了第三级所要求的21个过程的17个，因此，它并不能保证团队自动获得第三级的评估，但是，加以一定程度的管理规章和文档管理，第三级应该不难实现。

我的感觉是CMMI 在所有的流程上都加了一个“提议”（Proposed）阶段，通过“审核”或者决定“开始调查”，处于“提议”阶段的工作项可以变为“激活”状态。如果调查的结果不是要开始着手工作，那么工作项可以退回到“提议”状态。

以缺陷类型（Bug）为例

其他的工作项类型如问题（Issue）、需求（Requirement）、复审（Review）、 风险（Risk）任务（Task）都是类似的流程，这里就不一一列举了。

西方管理学大师戴明曾经说：“Eliminate numerical goals, numerical quotas and management by objectives. Substitute (that with) leadership”，意思就是说（在团队中）要消除以数字定义的目标、份额，以及以类目标为基础的管理原则。我们要用领导能力取而代之。

如果这个项目没有任何商业价值，我想你也不好意思照搬商业软件的做法。但是也许这个项目对个人而言很有价值（提高个人技术的价值），那些有心锻炼自己的同学，能够自我驱动，值得你去“授权”和“信任”。

MSF其他的一些意义