开发系统

MSF的最大特性是商业化,并一直体现在项目的实施过程中。所谓商业化意味着客户的商业利益。客户投入多少，得到多少回报，客户要用到哪些最新的技术，最后如何把项目计划(Project)变成产品(Product)直至产生效益，等等，这些都是MSF要考虑的问题。

MSF是一个经验知识库，它包括以下方面的内容：

* 企业结构设计方案—采用交互的方式，侧重于制定长期规划，同时也能完成短期目标。

* 项目开发准则—包含组队模型和过程模型，用于建立高效的项目组，管理项目的生命周期。

* 项目设计过程和多层结构的应用程序模型—用于支持设计复杂的分布式企业应用。

* 企业信息基础设施的实施方法—使用组队模型和过程模型支持实现、操作和技术上的方案。

它是一种框架结构

框架结构重点解决一个基本的问题：它提供解决总体问题和作出有效决策的轮廓。

框架结构可以增强分析和开发大型项目的能力。MSF能够确定项目最大的风险在何处，强调制定计划和确定进度，确保成功发布一个产品所必备的条件。

MSF基于一组工作模型，这组模型是由微软公司及其合作伙伴，在与客户成功开发分布式计算和客户服务器应用程序的经验得来的。

框架结构不是一种预先决定工作结构、工作任务和发布产品具体方法的方法论，而是提供了灵活的方式、应用有创造力的方法去解决实际存在问题的思想。

象任何明确定义的工作模型一样，MSF积累了三个关键的成功因素：

* 一种帮助提供技术决策指南的观点。

* 一组反复跟踪、监控和管理项目及其进展的参考方法。

* 一致的重用性保证在灵活的计算环境中有效的利用已有的知识和技能。

一个资源的集合

MSF收集了一组集成的资源和准则来指导项目组走向成功。它包括明确的概念、详细的工作指南和微软最好的实践经验，保证您能立即开始工作。

这些资料可由以下途径得到：

* 联机资料

*CD-ROM知识库

* 教学课程

* 完整的参考手册

因为CD光盘中的内容是由HTML文档组成，所以要使用Microsoft Internet Explorer阅读这些资料。此外，CD光盘中还有更详尽的指南讨论在参考手册中提出的概念。

MSF框架

MSF框架包括一个集成的整体使用的多个组件：基础原理、模型、准则等等。MSF中比较关键的模型为组队模型和过程模型，下面分别进行介绍。

组队模型着重于解决在复杂软件工程项目中如何组建项目组、分配合适的角色、项目组的管理、职责划分和质量控制等问题。虽然组队模型是起源于软件开发过程中的规范和准则，但它也同样被成功的应用于基础信息结构设施的实现过程。标准的产品开发团队中包括开发、测试、用户体验、产品管理、程序管理、发布管理等角色。在MSF4.0中还包含一个后勤的角色.

同等关系的组队角色 MSF组队模型定义了相互依赖、相互协作、同等角色关系的工作模型。每个组中的成员在项目中都有一个明确定义的角色，并且关注于一种特定的任务。这种方法鼓励各个角色的所有感，最终结果是产生更好的产品。每种角色小组的领导者负责管理、指导和协调，小组中的成员专注于执行他们的任务。基于项目的大小，每个角色被分配给一个人或有人领导的一个小组。同样，一个人也可以承担多种角色。

MSF过程模型包含四个主要的里程碑，每个里程碑都是一个阶段的终结点。

预想和构思阶段在“前景/范围核准”里程碑上到达了终结点。一旦一个新的产品（在信息基础设施实现的项目中，这样的产品可能是某项服务）吸引了大家的兴趣并得到了允许构建的批准后，项目组开始集中起来定义产品。前景描述文档清晰地阐明了产品或服务的最终目标，并提供了明确的方向。

设计阶段在“项目设计核准”里程碑上到达了终结点。项目设计包含功能规定文档、每种角色职能组的计划组合（如在MSF组队模型中定义的开发、测试、用户教育、系统实施、程序管理和产品管理）和时间进度安排。功能规定提供给项目组足够的细节情况确定需要的资源并作出承诺。在项目设计核准里程碑上，客户和项目组在要交付的内容上及如何进行构建达成一致。这是一个重新评估风险、建立优先级和对时间进度和资源调配情况做最终估计的非常重要的机会。

开发阶段在“范围完成/第一次使用”里程碑上到达了终结点。经过核准的功能规定和相关的项目计划提供了开始开发的基准线。开发组设置了一系列内部交付的里程碑，每个内部里程碑都要经过全部的测试/诊断/排错的过程。在这个里程碑上客户和项目组评估产品的功能，验证产品过渡和支持计划。同样在这个里程碑上，所有新功能的开发都已经结束，推迟开发的功能记录下来作为下一个版本功能的参考。

稳定阶段在“产品发布”里程碑上到达了终结点。测试工作是伴随着代码开发工作进行的，在稳定阶段因为集中注意力于寻找错误和修改错误，所以测试活动成为主要的工作。在产品发布里程碑，产品正式转交给操作和支持组。通常情况下，项目组或者开始下一个版本的产品开发，或者拆散加入其它的项目开发组。

不同之处

MSF过程模型在下面的许多方面不同于传统的开发模型：

● 强调“系统前景/范围”，而不是需求。

● 面向客户的里程碑，而不是面向开发的里程碑。每个里程碑是项目组重新校准客户期望值的同步点。

● 不同版本方式的发布，而不是第一版就包含全部的功能特色，快速变化的技术会不断增强系统的功能，强化PC使用者的能力。不同版本的发布方式在基于PC的计算环境中是良好的平衡投资的方法。

MSF过程模型鼓励项目组将正在开发中的项目，想象成为一个产品，将新特色的开发和旧特色的维护作为不同版本的发布。这种概念会影响如何设定期望，以及整个项目如何设计、规划和管理。第一个版本的发布交付了一系列核心特色。随后的版本发布逐渐增加新的特色，直到完成了产品的全部前景和期望。不同的版本发布不一定需要前后衔接（也就是版本1发布后，版本2才开始）。当项目组成熟后，他们通常会采用重叠的发布方式（在版本1发布前版本2就开始了）。

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团队模型和关键质量目标

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

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

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

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

◆  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团队模型定义了小组同级成员的一些角色和职责，如图2-2所示。

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

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

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

（1）发现产品的问题；

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

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

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

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

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

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

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

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

那有冲突怎么办？

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

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

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

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

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

除了项目的各个角色之外，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上，不必额外去为了文档而再写一些东西。

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其他的一些意义

MSF(Master of Science in Finance)：是金融学硕士的简称，MSF是属于纯金融类的硕士

MSF如何帮助解决问题　MSF通过五个基本模型的应用，帮助企业认识到采用新技术的优点。这些模型适用于规划、构建和维护整个过程中不同方面的问题。（参见图1)

图 1：MSF强调的几个领域

MSF企业总体结构

MSF企业总体结构模型提供了一系列指南，用于规划企业的基础技术设施，流程化商业的运作过程，并鼓励重用性。这种模型是描绘构建于用户服务、事务服务和数据服务基础上的，多层应用开发的MSF应用模型的基础。

图 2：企业总体结构模型

Microsoft Solutions Framework - 概述3

图 3：MSF应用模型

MSF组队模型

MSF组队模型展示了如何组织项目队伍，在时间控制和连续不断发展计划的要求下，有效的交付系统的解决方案。它描述了六种基本的角色（程序管理、产品管理、开发、测试、系统实现和用户教育）。

图 4:MSF组队模型

MSF过程模型MSF过程模型解释了如何基于：范围、进度和资源，规划和控制面向结果的项目。它是基于四个可见里程碑交互的、允许修改的过程模型。过程模型中的“设计”阶段在面向商业解决方案内容，结合过程模型、组队模型和应用模型的组件方案设计过程（Designing Component Solutions Process）中，进行了详细的介绍。

图 5：MSF过程模型

图 6：组件方案设计过程

MSF的组成元素

规划

企业总体结构规划

应用三个基本模型可以帮助整体的理解企业。企业总体结构规划提供了分析企业组织机构运作和商业应用集成和处理的基准。

企业总体结构是包含四个方面的框架：事务、应用、信息和技术。

这些模型不仅仅描绘了企业总体结构的组成部分，还通过以上各个方面在集成系统中的应用，帮助企业有效地实现每一个方面。企业总体结构规划的过程，提供、揭示了商业运作的标准和所受的局限，使商业运作过程更易管理、费用更有效。

MSF的方法以“边规划、边设计”为基础，这意味着企业总体结构规划过程，一直伴随着商业需求变化和技术发展的连续过程。企业总体结构规划使用了MSF的一些基本原则，如：风险控制的时间安排、固定的产品发布时间、基于活动的设计、外部可见的里程碑、小组模型、并行的结构设计、最大的限制、连续的方案开发和结果实现。对比以往的自上而下的方法，项目不仅由企业模型所控制，它们还将直接受企业总体结构发展的影响。

构建

方案开发准则--Solutions Development Discipline (SDD)

软件开发是一种复杂的、有创造力的过程。在较大的开发队伍中，采用自上而下的方法，将会抑制创造力、有效的交流和真正的方案开发。SDD通过在软件开发过程中应用MSF基本模型，帮助软件组织克服这些障碍。

组件方案设计--Designing Component Solutions (DCS)

DCS详细解释了MSF过程模型中“设计”阶段的内容。DCS基于方案设计过程，覆盖了为给出满足商业需求的功能设计，所必需进行的设计活动。DCS的概念帮助理解和融合使用者和商业的需求（在项目层次上）。它强化应用程序的逻辑结构，以达到简化复杂性的目标。

这种设计过程允许有效地分派各种具备专业技能的人，以使特定的需求得到满足。这种技术同样保证在设计过程中维护应用程序的一致性。整个设计体系使用场景分析描绘概念设计，使用对象和服务描绘逻辑设计，使用组件描绘物理设计。

重用性设计--Designing for Usability (DFU)

DFU提供了大量简明的概念和实际的经验，进行以用户为中心的基于Windows的程序设计。它侧重Windows应用程序的物理设计，强调用户界面和操作衔接等原型技术。

维护

基础设施实现和维护

MSF建立起对三个基本MSF模型中的角色、关系和应用的一致理解，解决实现、管理和维护技术基本结构的问题。

MSF包含IT基础结构实现要求的、有效的组队模型和过程模型，确定了关键的项目构成因素和最终交付的成果，强调一致的规划和管理模型给系统带来的好处和费用的降低。

成功因素

一种帮助提供技术决策指南的观点。

一组反复跟踪、监控和管理项目及其进展的参考方法。