Microsoft 解决方案框架版本 3.0 概述
关于 Microsoft 解决方案框架的更多信息，请参阅 http://www.microsoft.com/china/technet/itsolutions/techguide/msf/default.mspx
致谢
撰稿人
GTD Ltd. 董事：Geoffrey Lory
Microsoft 产品经理：Derick Campbell
Microsoft MSF 总监：Allison Robin
Microsoft 技术编辑：Gaile Simmons
Volt Technical Services 技术编辑：Patricia Rytkonen
审阅者
MSFmentor：Jeff Carter，美国
Microsoft Consulting Services：Nathan Dolly，美国
Logic Control：John S. Dranchak
Microsoft： Holly Dyas
C2 Consulting：Paul Glen，美国
LLC Framework Deliveries：Tom Gordon
Microsoft：Paul Haynes
Microsoft Consulting Services：Hiroshi Koisumi，日本
LIH Ltd.：Eran Kolber，以色列
Microsoft Premier Support：Shawn LaBelle，美国
Microsoft Consulting Services：David Millet，美国
Systemgroup Management Services：Ed Musters，加拿大
Microsoft Consulting Services：Alex Nicol，加拿大
Gainsford Associates：David Preedy，英国
Thomson West：Jane Marie Rief
Microsoft Consulting Services：Dolph Santello，美国
本页内容
 | 摘要 |
| 读者 |
| 介绍 |
| MSF 起源和简史 |
| MSF 和 Microsoft 操作框架 |
| MSF 关键术语 |
| 基础原理 |
| MSF 模型 |
| MSF 准则 |
| Microsoft 对 MSF 的使用 |
| 实现 MSF |
| 小结 |
| 附录：MSF、行业标准和方法 |
摘要
Microsoft® 解决方案框架 (MSF) 是一种成熟的、系统的技术项目方法，它基于一套制定好的原理、模型、准则、概念、指南，以及来自 Microsoft 的、经过检验的做法。本白皮书将介绍 MSF，概述其基本原理、核心模型以及主要准则，并把重点放在如何应用它们推动技术项目成功上。最后，本白皮书提供的参考内容可以用来获得关于 MSF 的更加深入的信息，以及在组织内部实现 MSF 的指导。在附录里，白皮书会简要地将 MSF 与行业里的其他方法以及标准进行比较，并描述 MSF 能够如何与它们结合起来共同使用。
读者
本白皮书为希望更多地了解 Microsoft 解决方案框架的人员提供了一个起始点。典型的读者群包括：顾问、执行人员、技术专家、开发人员，以及希望领导团队和组织采用最佳做法改进结果的项目经理，或者只想在发布业务驱动的技术解决方案的时候提高其自身工作技能的项目经理。
本白皮书的第二受众包括相同的专家，只不过这些读者对 MSF 已经有所了解。他们感兴趣的是，它与各种行业标准及方法之间的关联是什么样的，以及能够如何被用来与它们一起使用。在附录里对一些著名方法的简要描述将有助于在这个广泛的背景下确定 MSF 的范围和应用。
介绍
按期并在预算范围内创建行之有效的业务解决方案需要一种经过检验的方法。Microsoft 解决方案框架提供了一个适应性的框架，用于以更快的速度、更少的人员、更少的风险来成功地交付信息技术解决方案，同时取得更高质量的结果。MSF 会帮助小组直接解决导致项目失败的大多数常见原因，以提高成功率、解决方案的质量和业务影响。MSF 就是创建用来处理技术项目和环境动态特性的，它能够提高项目实施过程中适应持续变化的能力。
MSF 被叫做框架而不是方法是有特定原因的。和规定性的方法不同，MSF 提供了一个灵活的和可伸缩的框架，其适应能力能够满足任何项目（不论其规模和复杂性）的要求，以规划、构建和部署业务驱动的技术解决方案。MSF 的观点是，没有哪个单一的结构或者过程能够适应所有项目的环境和要求。尽管如此，但是它也认为：对指导的需求是存在的。作为一个框架，MSF 就提供了这样一种指导，而不会强迫实施很多限制性的细节，否则这只会将其用处限制到有限范围的项目方案里。MSF 组件能够被单独应用或者共同应用，以提高下列类型项目的成功率：
| • | 软件开发项目，包括移动、Web 和电子商务应用程序、Web 服务、大型机以及 N 层项目等。 |
| • | 基础结构部署项目，包括桌面部署、操作系统升级、企业消息传递部署、配置和操作管理系统部署。 |
| • | 打包的应用程序集成项目，包括个人生产效率套件、企业资源计划 (ERP)，以及企业项目管理解决方案。 |
| • | 任何以上项目的复杂组合。 |
用于这些不同项目类型的 MSF 指导把重点放在了“人员和过程”的管理以及大多数项目会碰到的技术元素上。由于技术小组的要求和做法是持续变化的，所以 MSF 所收集的材料也都在不断变化和扩展，以便跟上其步伐的。此外，MSF 还与 Microsoft 操作框架 (MOF) 交互，以提供到操作环境的顺利转变，这是长期项目成功的一个要求。
MSF 起源和简史
这一章节将描述对 MSF 需求的产生和它是如何被创建的。
挑战和机遇
总所周知，今天的业务环境的特点是复杂型、全球互连性，以及从客户需求到生产方法再到变化率自身的加速。所有人也都知道，技术对这些因素中的每一个都有所贡献。这也就是说，技术常常是额外复杂性的来源，它支持全球的连接，并已经成为变化发生的主要催化剂之一。理解和使用技术变化所提供的机遇已经成为了组织里时间和资源消耗的主要原因。
信息系统和技术组织（以下简称 IT）已经在受困于时间和精力了，根据技术变化来开发和部署业务驱动的解决方案就需要这些时间和精力。它们正不断认识到低质量的结果所带来的负面影响及其无法接受的业务风险。为了让其工作收到更好的效果，它们从业界的领导者处寻求指导。
技术开发和部署项目可能会极其复杂，这就加大了其难度。技术本身就可能成为项目失败的因素；但是，它极少是主要原因。令人意外的是，经验表明：项目成功这一结果更多的与所涉及的人员以及过程有关，而非技术本身的复杂性。
在把人员和过程的组织和管理分解开来的时候，可以看到它们对项目的下列作用：
| • | 利益相关人和／或到过程里的不规则的、随机的、或者不足的业务输入脱离开来，这就导致无法捕捉住重要的需要。 | ||||||
| • | 不理解业务问题的小组就无法具有定义清楚的角色，也不会努力进行内部的和外部的沟通。
|
克服了这些问题的组织通过更高的产品和服务质量、提高的客户满意度，以及吸引行业最佳人员的工作环境获得了更好的业务结果。这些因素会转化成为对底线的正面影响以及组织战略效力的提高。
改变企业行为以有效地应对这些挑战并取得出色的结果是可能的，但是这需要奉献精神、责任心和领导力。为了实现这一目标，就要需要在 IT 和业务之间建立联系 — 建立理解、责任、协作和沟通之间的关联。但是只有结果才有发言权：IT 必须成为领导角色，以消除自身成功道路上的障碍。MSF 就是设计和构建用来提供框架实现这种转化的。
基于经验的解决方案
Microsoft 解决方案框架于 1994 年首次引入，当时还是一个来自 Microsoft 的产品开发努力和 Microsoft 咨询服务中心参与的最佳做法的松散集合。从那时起，MSF 已经有了发展，这来自 Microsoft 产品组、Microsoft 服务中心、Microsoft 的内部操作和技术组 (OTG)、Microsoft 合作伙伴和客户那里成功的和真实的最佳做法。MSF 元素基于行业著名的最佳做法，并融合了 Microsoft 在高技术行业超过 25 年的经验。这些元素都被设计用来共同工作，以帮助 Microsoft 的顾问、合作伙伴和客户来解决技术生命周期过程中碰到重大挑战。
MSF 使用这套经过内部和外部检验的真实最佳做法，并对这些做法进行简化、整理和检查，以便合作伙伴和客户理解和采用。现在已经成为一个可靠和成熟框架的 MSF 由 Microsoft 里一个专门的产品小组在管理和开发，它同时还得到了国际顾问理事会该方面专家的指导和评论。MSF 还在继续吸收 Microsoft 当前的经验。Microsoft 各种业务线里的其他小组也在日常工作中在内部创造、寻找和共享最佳做法和工具。从这些内部项目工作所学到的知识会通过 MSF 被整理和分发到 Microsoft 之外（的组织里）。
MSF 和 Microsoft 操作框架
Microsoft 操作框架 (MOF) 提供的操作指导让组织能够在基于 Microsoft 产品和技术的任务关键系统里取得可靠性、可用性、可支持性，以及可管理性。MOF 基于一套国际认可的 IT 服务管理最佳做法，叫做 IT 基础结构库 (ITIL)，由英国政府的政府商务办公室 (OGC) 颁布。MOF 可以被看作是 ITIL 标准的超集。
MOF 以白皮书、操作指南、评估工具、最佳做法、案例研究、模板、支持工具、课件和服务等形式提供操作指导。这一指导将用于解决与复杂的、分布式的、差异巨大的技术环境相关的人员、过程、技术和管理等问题。
Microsoft 利用 MSF 发展过程中获得的知识创建了 MOF，把 MOF 建立关于组织结构和过程所有权的 ITIL 最佳做法之上，并为合作伙伴、客户和 Microsoft 内部操作和技术组 (OTG) 所使用的重要成功因素建立模型。.
MSF 和 MOF 共享基础原理和核心规范。它们的不同之处在于这些原理和规范的应用，它们每个都使用独特的小组和过程模型以及专门针对各自领域的、经过检验的做法。MSF 从 解决方案交付的角度体现了小组的结构和活动，而 MOF 从 服务管理的角度体现了小组的结构和活动。MSF 强调的是项目；而 MOF 强调是生产环境的运行。 MSF 和 MOF 提供了解决方案开发域和解决方案操作域之间的接口。
MSF 和 MOF 被设计用来在技术生命周期过程中联合使用，以成功地提供业务驱动的技术解决方案 — 从启动到交付，再到操作和最后的淘汰。MSF 和 MOF 专门用在当今业务的典型组织结构里；它们共同描述不同的部门能够如何最好地在一起工作，以便在一个互相支持的环境里取得共同的业务目标。
MSF 关键术语
作为一个框架，MSF 包括能够被单独使用或者作为一个集成的整体使用的多个组件。它们共同创造一个可靠而且灵活的方法，用来成功地执行技术项目。下面的列表定义了这些组件。
| • | MSF 基础原理。 这些核心原理是该框架的基础。它们是框架所有元素所共有的值和标准。 |
| • | MSF 模型。 这是项目小组和过程的方案描述或者“思想映射”（小组模型和过程模型 — 框架的两个主要定义组件）。 |
| • | MSF 准则。 使用一套特定方法和术语的做法领域（项目管理、风险管理和就绪管理 — 框架里其他几个主要的定义组件）。 |
| • | MSF 关键概念。 这些概念支持 MSF 原理和规范，并且通过特定的、经过检验的最法来显示。 |
| • | MSF 经过检验的做法。 这是在各种实际条件下被技术项目证明有效的做法。 |
| • | MSF 建议。 这是在模型和规范应用中可选的、但是建议采用的做法和指导。 |
下面图表里的例子有助于说明 MSF 某些组件之间的关联。
或者，把上面的图标用文字表达出来就是：
MSF 的一个基础原理是 学习所有的经验。这一原理在 MSF 过程模型 里的关键里程碑上得到了充分的应用，在过程模型里 愿意学习 这一关键概念成功应用这一原理所需要的。愿意学习这一概念通过 后里程碑回顾的经过检验的做法在项目里得到体现。在大型的和复杂的项目里，Microsoft 建议 是利用客观的外部服务商来确保有一个无过错的环境，并把学习最大化。
相反的， 定义和监视风险触发器 （Microsoft 建议 在企业数据库或者存储库里捕捉它们，以便供跨项目使用）的经过检验的做法是 持续评估风险这一关键概念的一个应用。这些做法和概念是 风险管理准则 的一部分，风险管理准则通过 MSF 过程模型 每个阶段里 MSF 小组模型的所有成员来运用，这些概念和做法还用到了 保持灵巧 — 预测变化这一基础原理。
基础原理、模型和准则在下面的章节里都得到了进一步的解释，这就提供了它们之间相互关系的背景。
基础原理
MSF 的核心有八个基础原理：
| • | 推动开放式沟通 |
| • | 为共同的前景而工作 |
| • | 赋予小组成员权力 |
| • | 建立清晰的责任和共同的职责 |
| • | 关注交付业务价值 |
| • | 保持灵巧，预测变化 |
| • | 质量投资 |
| • | 学习所有的经验 |
这些原理共同传达了 MSF 观点，构成了一种统一方法的基础，这一方法用来组织项目所需的人员和过程，以便交付技术解决方案。它们是 MSF 结构和应用的基础。尽管每个原理都已经显示出了自身的优势（请参阅本白皮书结尾部分的参考文献），但是它们很多都是相互依存的，因为其中任何一个的应用都对另一个的成功起到了支持作用。在依次应用的时候，它们建立了一个稳固的基础，使得 MSF 能够很好地适用于规模、复杂程度和类型都不相同的多种项目。
下面经过挑选的例子说明了 MSF 如何将每个原理应用到 MSF 模型或者准则上。请注意：本白皮书并不会描述 MSF 里这些原理的每个应用实例。
推动开放式沟通
“日程安排一团糟、功能不合适、到处都是系统错误，而原因就是左撇子不知道右撇子在做什么……。那么，小组之间应该如何相互沟通呢？用尽可能多的方式沟通。”
Frederick P. Brooks，Jr1
技术项目和解决方案是由人的活动来构建和交付的。从事某个项目的每个人都会给小组带来自己的智慧、能力和观点。为了将成员的个人效力最大化，同时优化其工作效率，信息就必须随时可用且能够被积极共享。如果没有能够从多种渠道获取该信息的开放式沟通，那么小组成员就无法有效地完成其任务，也无法作出正确的决策。随着项目规模和复杂性的增加，对开放式沟通的需要就变得更加紧迫。完全基于须知（历史标准）的信息共享可能导致误解的产生，以至于削弱小组交付行之有效的解决方案的能力。这种受限的交流方式的最终结果可能会是解决方案和预期效果都无法满足要求。
MSF 里的开方式沟通
MSF 推出了一种开方式和包容式的沟通方式，既满足了小组内部也满足了利益所有人之间沟通的需要，同时能够符合诸如时间约束和特殊环境等条件的限制。一个畅通的信息流不仅会减少误解和无用功产生的机会，还会确保小组成员都能够致力于通过共享属于各自领域的信息减少与项目有关的不确定性。
在 MSF 项目里，可以采用任何形式来进行开放式和包容式的沟通。它是 MSF 小组模型的基本原理，而前者将它集成到了角色职责的描述里。当在整个项目生命周期过程中使用的时候，开发式沟通会推动客户、用户和操作等的积极参与。这种参与也通过将开方式沟通的概念融合到 MSF 过程模型的关键里程碑的定义里得到了支持。沟通成为了共同的前景和性能目标能够被建立、测量和取得的媒体。
为共同的前景而工作
“在项目开始之前，小组需要建立一个共同的前景。如果没有这样一个共同的前景，就无法获得表现优异的小组工作。对 75 个小组展开的一项研究表明：在小组有效运作的 每个案例 里，小组都对其目标有一个明确的理解。”
— Steve McConnell2
所有伟大的小组都有一个明确的和上升的前景。这一前景通过前景陈述的形式得到了最好的表达。尽管很简洁 — 只有一个到两个段落 — 前景陈述会描述业务的去向，以及所提出的解决方案将如何有助于实现业务价值。拥有一个长期的和不受限制的前景会激励小组克服其对不确定性的畏惧感，专注于事情当前的状态，取得应该取得的成果。
如果没有共同的前景，小组成员和利益相关人可能会在项目目标和目的的看法上产生分歧，无法形成一个具有凝聚力的小组。工作努力不协调会浪费和削弱小组的成果。即使小组生产出了交付内容，成员也将很难评估其是否成功，因为评估要依靠他们测量所需的前景。
为共同的前景而工作需要很多其他原理的应用，这些原理也是小组成功的必要因素。赋予小组成员权力、职责、沟通，以及关注业务价值等原理中的每一个，都在成功到达共同前景这一困难的和无畏的工作中起到了重要作用。对为共同的前景而工作的需求是如此重要，以至于 Jim 和 Michele McCarthy 在其著作 Software for Your Head3 中提供了一个路标，用于有效地和反复地将小组带往共同的前景。
MSF 里的共同前景
共同的前景是 MSF 小组和过程模型里的一个关键组件，它强调理解项目目标的重要性。当所有的参与者都理解了共同的前景并为之而工作的时候，他们就能够通过这一前景来表达更加宽泛的小组目的，进而调整自己的决定和工作重点（代表他们角色的观点）。MSF 过程模型的这种反复性要求有一个共同的前景存在，以便指导解决方案朝着最终的业务结果前进。没有这一前景，解决方案的业务价值就只会走向平庸。
项目的共同前景是小组工作的基础。建立这一前景的过程会有助于明确目标，减轻并解决可能发生的冲突和错误。一旦达成一致，前景就会激励小组前进，并帮助确保所有的努力都服务于项目目标。它会提供一种测量成功的方式。明确并承担共同目标是如此重要，以至于它成为了任何 MSF 项目第一阶段的主要目标。
赋予小组成员权力
“在最优秀的小组里，不同的个人会在不同场合下体现出其领导能力，他们会在其专长的领域里担负起领导职责。没有哪个人是永远的领导，因为如果这样的话，这个人就无法和其他人融为一个整体，而小组的互动会因此而开始分裂。小组的结构应该是一个网络型的而不是一个层次型的。”
— Tom DeMarco 和 Timothy Lister4
在确定性是标准、且每个个人的贡献都是规定好的和可以重复的项目里，被较少赋予权力的小组会生存下来并取得成功。但是，即使是在这样的情况下，解决方案潜在的价值也不太可能达到所有的小组成员被赋予权力时能够达到的水平。缺乏权力的赋予不仅会扼杀创造力，而还降低士气，阻碍建立表现出色的小组的能力。挑出个人来进行奖励或者责问的组织将会破坏赋予小组权力的基础。
在一个高效的小组里，所有的成员都被赋予权力以便根据他们自己的承诺交付任务，并且充分信任小组的其他成员也能实现各自的承诺。类似的，客户也能够认为小组将会兑现其承诺，并进行相应的规划。支持和滋养被赋予权力的小组和小组成员，建立起这样一种文化可能是极具挑战性的，这需要组织的承诺。在 The Empowered Manager5里，Peter Block 把权力的赋予叫做“自我兴趣的启迪”，并把它描述成为表达和推动我们朝着这一方向前进的承诺。
MSF 里被赋予权力的小组成员
权力的赋予对 MSF 有着深远的影响。MSF 小组模型建立在同级小组的概念以及这种小组成员所暗含的权利赋予本质之上。被赋予权力的小组成员认定他们自己以及其他每个人都对项目的目标和交付内容负有责任。被赋予权力的小组成员都接受项目风险管理和小组就绪管理的职责，因此能够预先就对这样的风险和就绪进行管理，以便尽最大可能确保项目成功。
创建和管理日程安排提供了另一个赋予小组权利的例子。MSF 主张从下到上日程安排方法，这就意味着正在工作的人要承诺它会在什么时候被完成。这样做的结果就是一个能够得到小组支持的日程安排，因为小组相信自己。MSF 小组成员确信，任何延迟都会在它们被发现的时候被报告，这样就让小组领导能够去扮演一个更具推动性的角色，从而在最关键的时候提供指导和帮助。对过程的监视被分布在小组里，成为了一项支持性而非控制性的活动。
建立清晰的职责和共同的责任
“每个［小组］成员与小组之间的关系都必须根据可能的角色以及角色所产生的结果来定义。最终，小组的任何努力都会归结为个人的责任和职责。”
— Carl Larson 和 Frank LaFasto6
无法实现对项目职责和责任的清晰理解常常会导致重复的工作或者交付内容的缺失。这些都是功能紊乱的小组的症状，尽管这些小组投入了大量的精力，但是他们还是无法取得进步。同样具有挑战性的是专制地运行项目，这样会扼杀创造性，将个人的贡献将到最低，并使小组失去权力。在人力投资是主要资源的技术项目里，这是失败的主要原因。
跨职能小组的成功都具有清晰的职责和共同责任，这在 Larson 和 LaFasto 的一次详尽研究里有详细的文字证实。7 他们的研究显示：建立对职责和责任的充分理解会减少与“谁、什么、什么时候，以及为什么”相关的不确定性，其结果就是执行变得更加有效和回报也更高。
MSF 里的职责和责任
MSF 小组模型基于这样一个前提，即小组里的每个角色都代表了对项目的一种独一无二的观点。但是，对于项目成功而言，客户和其他利益相关人需要一个对项目状态、行动和当前问题等信息的权威来源。为了解决这一问题，MSF 小组模型把对各种利益相关人的清晰角色职责与实现这个项目成功的整个小组的责任结合起来了。
小组的每个角色对小组本身以及各自的利益相关人都是负有责任的，以取得角色的高质量目标。从这个意义上讲，每个角色对于最终解决方案的质量都负有责任。同时所有的职责都要在小组的同级之间共同分担，因为任何小组成员都可能导致项目的失败。它是相互依存的，原因有两个：首先，需要这样，因为把每个角色的工作分隔开来是不可能的；其次，出于优先的原因，因为如果每个角色都了解全局情况，那么小组的效率会更高。这种相互的依赖性会鼓励小组成员对由他们责任的直接区域以外的工作作出评论和贡献，以确保小组所有的知识、能力和经验能够被应用到解决方案里。
关注交付业务价值
“经验教会托马斯·爱迪生把商业和技术结合到一起。爱迪生取得第一项发明专利的‘电子选票记录器’能够快速地记录选票，原先专门用在立法机构里。但是当他向国会委员会推销这个发明的时候，委员会的主席告诉他说：”年轻人，这就是我们不想要的。“（它会破坏阻止议案通过的神圣制度。）他的机器从来都没有投入生产，所以他决定不再把他的精力放在那些缺乏‘商业需求’的任何东西上。“
— Randall E. Stross8
忽略、匆忙地或者没有经过深思熟虑就定义项目业务价值的项目会在以后的阶段备受煎熬，因为项目的持续推动力会变得很模糊和不确定。没有目的的行动让想要获得有成效的结果变得很困难，并最终失去小组这一层的和组织内部的动力。这可能会导致错过交付日期，或者交付甚至无法满足客户最低要求的东西，或者干脆项目被取消。
通过把注意力放在改进业务上，小组成员的活动将变得更有可能去做他该做的事情。Tom Peters， Thriving on Chaos 的作者，常常声称组织和小组必须维持一个“业务思想”的氛围。9 尽管很多技术项目都把精力放在技术的交付上，但是技术不是为了技术本身而交付的 — 解决方案必须提供切实的业务价值。
MSF 里的关注交付业务价值
成功的解决方案，无论它们是针对组织还是个人的，都必须满足一些最基本的需要，并向购买者交付价值或者利益。通过把对业务价值的关注与共同的前景结合起来，项目小组和组织能够清晰地理解为什么项目会存在，以及如何以对组织业务价值的形式来衡量成功。
MSF 小组模型主张小组的决定应该以对客户业务的充分理解以及客户在项目过程中的积极参与为基础。产品管理和用户经验这两个角色分别代表着客户和用户对小组的主张。这些角色常常由业务和用户群的成员来承担。
不到被完全部署到生产（环境）里并被有效地使用，解决方案就无法提供其业务价值。由于这个原因，MSF 过程模型的生命周期把开发和部署包括进解决方案的生产里，从而确保业务价值的实现。将强大的、小组对业务的多维表示同对过程中对业务影响的明确关注结合起来，就是 MSF 确保项目满足技术前景的方式。
保持灵巧，预测变化
”思维活跃的经理们知道，在碰到不确定性的时候才去要求确定性是不正常的 。他们会为创造力和创新力的踊跃发展设定目标和约束。“
— Jim Highsmith10
传统的项目管理方法和”瀑布“式的解决方案交付过程模型会假定某一层次的可预测性，在其它行业里很常见的这一点在技术项目里却不是很常见。常见的情况是，交付的结果和方式都没有得到很好的理解，而探索成了项目的一部分。组织越是寻求将技术投资的业务影响最大化，他们就越可能步入新的领土。这片新的土地本来就是不确定的，随着探索和试验带来新的需要和方法，解决方案必须顺应新的变化。在面对这种不确定性的时候要假装或者要求确定性（至少）将会是不现实的，或者（至多）是不正常的。
MSF 里的灵巧性
MSF 主张技术项目的 混乱有序 (chaordic) （即混乱和有序的结合，这个词由 Visa International 的创建者和前执行总裁 Dee Hock 发明）11 的本质。它的一个基本假设是，连续的变化应该能够被预计到，而把解决方案交付项目与这些变化隔离开来是不可能的。例如，它认为项目要求可能从一开始就很难说清，而且它们常常会随着参与者把可能性看得越来越清楚而发生相当大的修改。
MSF 已经将其小组和过程模型设计成能够预计和管理变化的形式。MSF 小组模型通过在关键决策中实现所有小组角色的参与从而加强了处理新挑战的灵巧性，因此确保了从所有重要的角度去探索和审查这些问题。MSF 过程模型通过其构建项目交付内容的反复方法，提供了交付内容在每个发展阶段的状态的清晰状况。小组能够更容易地认清任何变化的影响，并有效地处理它，将任何负面效应降到最低，同时将利益最大化。
近几年来，产生了一些开发软件的专门方法，这些方法致力于将灵巧性的原理和为变化而做好准备的原理最大化。有了这一理念，MSF 会鼓励在合适的地方应用这些方法。MSF 和灵巧方法将在本白皮书后面的章节里进行讨论。
质量投资
”提高质量是一个永无止尽的历程。没有所谓最高质量的产品或者服务。所有的质量都是相对的。每一天，每件产品或者每项服务都在变得相对更好或者相对更差，但是它从来都不是静止不变的。”
— Tom Peters12
质量，或者由此而产生的质量不佳，能够以多种方式定义。质量可以被简单地当作是产品稳定性的直接反映，或者被看作是交付、成本和功能的复杂综合体。但是无论你怎么定义它，质量不是什么突然就发生的事情。只有明确的投入努力才能够确保质量被融入到组织所交付的产品或者服务里。
所有产业的发展都来自对质量的追求，这已经得到了质量管理系统里大量的书籍、教学、理论和方法的证明。有效地提高质量就需要在过程、工具和质量指导方针上的不断投资。提高质量的所有努力包括定义一个过程，用来通过对成果的详尽评估，即测量，把质量融合到产品和服务里。用测量工具来实现这些过程会通过发展结构和一致性来强化它们。
最重要的是，这样的努力会激励小组和个人发展出一种围绕提高质量的思想概念。人们会因为其工作、学习和获得权力而感到骄傲，而提高质量意识就是对的这种基本渴望的一种补充。
因此对提高质量的投资就成为了对人员以及过程和工具的投资。成功的质量管理程序认同这一点，并把质量融入到了组织的文化里。它们都强调对质量进行持续投资的需要，因为对质量的期望会随着时间的推移而不断提升，在原地踏步不是一种可行的选择。
MSF 对质量的投资
MSF 小组模型要求小组里的每一个人都要对质量负起职责，同时承担起测试过程管理的角色。测试角色会鼓励小组在项目期间进行必要的投资，以确保质量水平能够满足所有利益相关人的期望。在 MSF 过程模型里，由于项目交付内容是逐步生产和审查的，所以测试就成为了质量的一部分 — 它从项目生命周期的第一个阶段开始，并延续到其五个阶段的每一个。该模型定义了关键里程碑，并提出了中间里程碑，供测试角色和利益相关人使用小组建立的质量标准对解决方案进行测量。对这些里程碑进行检查可以确保对质量的不断关注，并为在必要的时候进行中途的修正提供机会。
把质量融入到产品和服务里的一个重要因素是学习环境的发展。MSF 通过就绪管理准则来强调学习的重要性。为小组工作而获取合适的技能代表着一种投资；生产工作之外的时间加上课堂培训、课件、辅导，甚至是咨询，可能会是一笔相当大的费用。就绪管理准则通过让成员获得合适的技能来直接对小组进行投资，因为它基于这样一种想法，即对技能的投资会转化成质量的投资。
学习所有的经验
“那些忘记过去的人肯定会重复过去（的错误）。”
— George Santayana13
当你看到技术项目成功率的增长微乎其微的时候，当你认为失败的主要原因没有随着时间的推移而改变的时候，那么可能的情况是：在这样一个行业里，我们无法从（过去）失败的项目中学到教训。在资源有限、期限紧迫的情况下花时间去学习对于小组和利益相关人来说是很困难的，而要去证明其合理性则更困难。但是，不去从所有的经验中学习东西肯定会让我们重蹈覆辙，并自食其后果。
捕捉和共享技术和非技术的最佳做法是不断提高和不断成功的基础，因为它：
| • | 允许小组成员从其他人的成功和失败经验中获益。 |
| • | 帮助小组成员再次成功。 |
| • | 通过检查和回顾等方式让学习制度化。 |
支持学习环境的做法有很多。Peter Senge 的 The Fifth Discipline: The Art and Practice of the Learning Organization14 是关于建立学习文化的最早书籍之一。他最近的一本书 The Dance of Change,15 就是基于他早期的工作。他的书中收入了个人和小组的实践，对该领域里让经理和领导者进行持续学习的倡议进行了深度的说明，并提出了经过充分检验的实际建议。
MSF 里学习所有的经验
MSF 认为，通过学习把精力放在不断提高上会带来更大的成功。从一个项目获取的知识能够成为下一个项目里其他人可以利用的东西，这样就会减少因为信息不足而造成的决策的不确定性。在 MSF 过程模型里对里程碑进行有计划的审查会帮助小组来进行中途的修正，避免重复（过去的）错误。此外，捕捉和共享这一知识可以从工作良好的事物中创造出最佳做法。
MSF 强调在组织或者企业这一层次从项目成果中学习的重要性，它建议对项目进行事后检查，将项目的成功之处以及对成功作出贡献的小组和过程的特点付诸于文字。当从多个项目学到的知识在开放沟通的环境里进行共享的时候，小组成员之间的互动就会有一个向前的、能够解决问题的前景，而不是一个自身倒退和相互责难的未来。
MSF 模型
MSF 模型代表了上述基础原理在技术项目的“人员和过程”方面的应用 — 人员和过程对项目的成功与否具有最重要的影响。MSF 小组模型和 MSF 过程模型是图解式的描述，用来从视觉上显示角色群周围的项目小组的逻辑组织，以及项目生命周期过程中的项目活动。这些模型将基础原则具体化了，并融入了核心规范；它们的细节经过了关键概念的提炼，它们的过程通过成功的做法和建议得到了应用。随着每个模型都得到了描述，底层的基础原理和规范就能够被认识到。
MSF 小组模型
MSF 小组模型定义了小组同级成员的一些角色和职责，这些成员都在以相互依存的跨学科角色进行信息技术项目工作。下面的图表对该模型的逻辑进行了描述。
MSF 小组模型基于这样一种前提，即任何技术项目都必须达到特定的关键质量目标才能够被认为是成功的项目。达到每个目标都需要相关的、不同技能及知识领域的应用，它们每一个都包括在一个小组角色群（通常被简称为角色）里。相关的技能和知识领域被叫做基础领域，它们定义了每个角色的域。例如，程序管理角色群包括项目管理、解决方案体系结构、过程保证和管理服务等职能领域。总体来说，这些角色都具有这样的广度来满足项目成功的所有标准；如何任何一个角色无法实现其目标，这都会将危及整个项目。因此，这个同级小组里的每个角色都被认为是同等重要的，重要的决定都要共同作出。相关的目标和角色见下面的表格。
表 1：MSF 小组模型和关键质量目标
| 关键质量目标 | MSF 小组角色群 |
在项目约束内的交付 | 程序管理 |
对产品规范的交付 | 开发 |
解决所有问题之后的发布 | 测试 |
顺利的部署和前进中的管理 | 发布管理 |
增强的用户表现 | 用于体验 |
满意的客户 | 产品管理 |
MSF 小组模型是行业里用于被赋予权力的小组工作和技术项目的最佳做法的汇编，它把重点放在了取得这些目标上。它们然后被应用到 MSF 过程模型里，以概括活动并创建小组所要生产的具体交付内容。这些主要的质量目标会定义和推动小组进行工作。
要注意的是，一个角色不同于一个个人 — 多个人员可以担当一个角色，或者一个个人可担当多个角色 — 例如，在模型需要缩小规模以适应小型项目的时候。在采用 MSF 小组模型上重要的一点是，所有的 质量目标 都应该在小组里体现出来，而且项目的各种利益相关人都应该知道项目里的哪个人在负责质量目标。
MSF 小组模型解释了这些角色的组合能够如何被用来扩大规模以便利用大量的人员来支持大型的项目，即通过定义两种类型的子小组：职能小组和特性小组。职能小组是由职能角色组织起来的单领域子小组。开发角色常常有一个或者多个职能小组来承担。第二种类型是特性小组，它们是跨专业的子小组，把主要精力放在构建解决方案的特定特性或者能力上。
MSF 小组模型可能是 MSF 里最与众不同的部分。小组模型的核心是，技术项目必须符合各种利益相关人完全不同的，且常常并列的质量观点，这包括操作、业务和用户。MSF 小组模型推动了各种观点的这种融合，因此承认技术项目不单单就是 IT 的工作。
MSF 过程模型
每个项目都要经过一个生命周期，这是一个包含项目里所有活动的过程，而这些活动的发生要到项目结束并过渡到操作状态才会结束。生命周期模型的主要功能是建立活动进行的顺序。正确的生命周期模型能够简化项目，并帮助确保每一个步骤都会让项目更加接近成功。下面是 MSF 过程模型生命周期的一个简图。
MSF 过程模型把来自传统的瀑布模型和螺旋模型的概念结合起来，并利用了两者各自的长处。过程模型把瀑布模型基于里程碑的规划的优势与螺旋模型不断增加的反复项目交付内容的长处结合了起来。
MSF 过程模型以阶段和里程碑为基础。在一个层次上，阶段能够被简单地看作是一段时间，只不过强调了为该阶段生产相关交付内容的特定活动。但是，MSF 阶段要比这复杂；每个阶段都有其自身的特色，每个阶段的结束都代表了项目进展和中心点的变化。阶段可以被先后看作是探索的、调查的、创造性的、专心的和合乎规范的。里程碑是检查和同步点，用来确定阶段的目标是否已经实现。里程碑为小组提供了明确的机会，以调整项目的范围，反映客户或者业务要求的变化，并解决项目过程中可能会出现的实际风险和问题。此外，里程碑是每个阶段的结束，它让指导很多活动的职责进行转化，并鼓励小组以新的视角来看待下一阶段的目标。结束由小组在每个阶段生产的实际交付内容来说明，还有小组和客户对这些交付内容的评价意见来说明。这个结束，以及相关的结果，将成为下一阶段的起始点。
MSF 过程模型允许小组响应客户的请求，并在需要的事后在解决方案的中途作出变化。它还允许小组交付解决方案的关键部分，这要比以往的做法更快，因为它首先集中交付优先权最高的特性，然后转到不太重要的特性上，直到最终发布。过程模型是 MSF 的一个灵活组件，MSF 已经被用来成功地改善项目控制、将风险最小化、提高产品质量，以及加快开发速度。MSF 过程模型的五个阶段让其足以灵活地应付任何技术项目，无论是应用程序开发、基础结构部署，还是这两者的结合。
关于 MSF 过程模型的更多信息，请参阅位于 www.microsoft.com/china/technet/itsolutions/techguide/msf/default.mspx 上的 MSF 过程模型白皮书。
如果能够有效地融入组织里，MSF 过程模型与 MSF 小组模型的集成将会成为一个造就项目成功的强大组合。它们共同为项目的成功交付提供了一个灵活但是确定的路标，后者还包括独特的组织文化、项目类型和个人长处等因素。
MSF 准则
MSF 准则 — 项目管理、风险管理和就绪管理 — 是使用特定方法、术语和方式等的做法。这些准则对于 MSF 小组和过程模型的良好运作十分重要。它们起源不在 MSF 之内；它们在行业内部得到了很好的检验，并有全面的知识体系来支持。MSF 具有与基础原理和模型相配套的特定准则，并在需要的时候用它们对框架的其他元素进行补充。总的来说，MSF 并没有尝试去完全重建这些准则，而是去突出在被应用到 MSF 环境里的时候它们是如何去适应的。这些准则由 MSF 和 MOF 共享，预计在将来会有其他的准则被采用。
MSF 项目管理准则
MSF 对于项目管理有一个分布式的小组方法，这涉及前面提到过的基础原理和模型。在 MSF 里，项目管理做法会提高责任性，并允许从小型项目到非常巨大和复杂项目的大范围伸缩。
MSF 项目管理准则与技术项目领域里的主要项目管理知识体系是相配套的。这包括 项目管理研究院 (PMI®)、国际项目管理协会 (IPMA) 和 Prince2™ (PRojects in Controlled Environments)。这些不同的知名组织在项目管理这个宽泛的领域里提供了大量被广泛认同的最佳做法、标准和认证。
利用 MSF 进行项目管理的方法有几个与众不同的特点，这些特点造就了 MSF 项目管理准则。其中的一些会在这里列出来，并在后面进行更加详细地讨论：
| • | 项目管理是一个包含在一系列被广泛接受的知识领域和活动里的准则，这与角色以及头衔不同。 |
| • | 通常被叫做“项目经理”的角色的大多数职责都被纳入了 MSF 程序管理角色群。 |
| • | 在需要扩大 MSF 小组规模的大型项目里，项目经理的活动会发生在多个层次。 |
| • | 一些非常大型的或者复杂的项目会要求有一个专门的项目经理或者项目经理小组。 |
| • | 在 MSF 里，更多的焦点被集中到了角色的同级本质上 — 例如，在由大多数人来决定的决策上。形成鲜明对比的是，很多传统的项目管理方法强调了项目经理是关键的决策者，他对小组的其他成员具有控制权和权威性。在 MSF 里，像规划和日程安排这样的项目管理活动被分派给最合适的角色来完成。 |
MSF 作为一个致力于技术项目成功的框架认为：完成项目管理所需要的职责和活动不仅限于小组里的单个个人，还需要小组成员领导者以及 MSF 程序管理角色群的职责和活动。对小组的这些活动和职责的要求越普遍，创造高度协作的自我管理小组的能力就越强。但是，项目管理的主要活动和职责被包括在 MSF 程序管理角色群里。这一角色群会把重点集中到项目的过程和约束，以及项目管理准则力的关键活动上。
在小型项目里，所有的功能职责一般都是由程序管理角色群里的一个人来负责的。随着项目的规模和复杂性的增加，程序管理角色群可能会形成两个专门的分支：一个处理解决方案体系结构和规范，另一个处理项目管理。对于需要多个小组或者多层小组的项目来说，项目管理活动在设计上就是可以伸缩的，并允许对任何单个或者集中在一起的小组进行有效的管理。这可能需要在多个层次采取特定的项目管理做法，尽管其它的活动被包含在特定的小组里或者整个项目和小组的特定层次里。项目管理职责的确切分布在很大程度上要依据项目的规模和复杂性。
关于 MSF 项目管理准则更加全面的说明以及 PMI PMBOK® 和 MSF 项目管理准则的白皮书，请参阅 www.microsoft.com/china/technet/itsolutions/techguide/msf/default.mspx 上关于这些主题的白皮书。
MSF 风险管理准则
技术项目由组织来承担，以支持其在新业务和技术领地的风险投资，并期望其投资能够获得回报。风险管理是对技术项目里固有的不确定性的响应，固有的不确定性意味着不可避免的风险。但是，这并不意味着就是要去承认和管理风险就一定会阻碍对机遇的创造性追求。虽然很多技术项目都没有能够有效地管理风险，或者没有考虑到项目的成功交付需要风险管理，但是 MSF 就使用了风险管理来实现项目的成功。MSF 把风险管理看作是 MSF 规范中的一个，它需要被集成到项目生命周期里，并被包含在每个角色的工作里。基于风险的决策是 MSF 的基础。通过给风险排序和制定优先顺序，MSF 会确保风险管理过程是有效的，而不是一个累赘。
预见性的风险管理意味着项目小组有一个确定的和可见的过程来管理风险。这个项目小组对可能出错的东西进行一个初步的评估，确定必须处理的风险，然后实现风险管理的策略（行动计划）。评估活动是在整个项目过程中持续进行的，是所有阶段里进行决策信息来源。被确认的风险（及其行动计划的进展）会被跟踪，直到它们被解决或者变成问题再处理。下面图表就是预见性的风险管理过程。
这个由六个步骤组成的风险管理过程通过对角色职责的定义与小组模型集成在一起，通过指定的行动和里程碑交付内容与过程模型集成在一起，这就创造了一种进行项目风险管理的综合方法。这个过程最终以学习这一步结束 — 项目风险的捕捉与保留、减轻策略和可能性策略，以及未来检查和分析所需要的已完成的行动。这一与风险相关的信息知识仓库是创建学习型组织必不可少的一部分，它能够利用以往的项目知识，并以其为基础。
利用 MSF 进行风险管理的方法与众不同的地方在于， 测量 成功与否的标准是做了什么，而不是填了什么表格。在很多项目里，风险管理是付费的口头服务，它不是被完全忽略了（也许就在一开始草率的风险评估之后），就是被当作了官僚作风。MSF 会避免过于繁重的过程，但是把风险管理放在了项目决策的核心。
MSF 就绪管理准则
Microsoft 解决方案框架的就绪管理准则把就绪定义为对组织里个人当前的知识、技能和能力 (KSA) 与理想状态的测量。这种测量涉及个人在规划、构建和管理解决方案的过程中任何一点的真实能力或者体现出来的能力。
对就绪的测量可以在任何层次进行 — 在组织、小组和个人等层次都可以。在组织这一层，就绪指的是对个人能力进行整体测量所达到的当前状态。这一信息会被用在战略性地规划和评估成功采纳和实现技术投资的能力上。就绪管理指导可以应用到过程的改进和组织变化管理等领域里。
但是，MSF 就绪管理准则会把其主要焦点限制到项目小组的就绪上。它提供了指导和过程，用于定义、评估、改变执行项目和采纳解决方案所需要的知识和能力。
项目小组里担当特定角色的每个人都必须能够完成该角色必备的所有关键功能。个人就绪是对小组每个成员知识、技能和能力当前状态的测量，被指定角色的职责需要个人具备这些知识、技能和能力。就绪管理用来确保小组成员都能够完全满足他们所要从事的工作的需要。
MSF 就绪管理准则反映了开方式沟通、质量投资和学习等原理。这一准则认为，项目本来就会改变它们被开发时所处的环境，同时还会改变它们被部署的环境。通过对这一未来的状态进行预见性的准备，组织将其置于一种更好的交付位置，并能够更快地实现业务价值，这才是项目的最终目的。
Microsoft 对 MSF 的使用
Microsoft 解决方案框架现在是 Microsoft Windows® 工程服务和解决方案 (WESS) 的一部分，并由它来管理和维护。MSF 最近才从 Microsoft 咨询服务 (MCS) 转为 WESS，以便将其作用范围扩展到 MCS 服务之外，并有意将 MSF 的原理嵌入到 Microsoft 产品文档、解决方案加速器和服务产品里。
Microsoft 产品组和服务里的 MSF
Microsoft 产品组利用了一套从不同来源收集到的、成功的做法，这些做法被应用到了 Microsoft 的大多数产品里。MSF 主要被 Microsoft 产品组用来构造和增强其产品、服务产品和解决方案的解决方案交付文档。
检查 MSF 的产品小组能够认识到它和他们工作方式之间的相似之处。他们还认为，尽管 MSF 有一些增强的地方能够让它更适合于客户，但是其基础基本上是相同的。Microsoft 产品组的员工偶尔会把他们正在使用的做法叫做 MSF， 但是更多情况下这些是没有名字的 — 它们就是 Microsoft 工作的方式。
Microsoft 服务中心，尤其是 Microsoft 咨询服务中心 (MCS)，会一般把 MSF 用作与交付技术解决方案相关的参与定义结构，以及他们与客户共享的知识库。事实上，就是出于这样的目的，MSF 原来由 MCS 维护了很多年。有这样的通用应用，MSF 可以有效地满足咨询公司的各种需要，很多 Microsoft 的认证合作伙伴都已经采纳并扩展了 MSF，供它们自己使用。
当 MCS 参与所提供的特定服务无法跨越解决方案交付生命周期（例如质量保证检查）的时候，顾问会有选择地使用 MSF 里合适的元素。如果 MCS 无法主导项目（例如，当它们被转包给另一个有自己参与方法的咨询公司的时候），那么 MCS 也能够在这种背景下工作，它会通过在合适的地方使用 MSF 来增加价值，同时保持原来选择的方法。很多混合型的项目小组会明确地讨论 MSF 和特定的方法能够如何被组合在一起，并被一起用来将正面影响和小组表现最大化。由Microsoft 服务中心交付的服务操作改进项目就使用了 MSF 来构造项目，并利用 Microsoft 操作框架 (MOF) 里的知识库获得了实际的提高。
Microsoft 其它地方的 MSF
在产品组之外，MSF 也被广泛地用于 Microsoft 各种业务线上各种技术服务和解决方案的交付。Microsoft 服务中心大量地使用了 MSF （上面已经描述过了），Microsoft 的操作和技术组 (OTG)、Microsoft 培训和认证、全球范围内的业务操作，甚至是 Microsoft Research 内部的小组也在采用它。
实现 MSF
技术具有让组织变得更有效的潜力，这创造了以前没有的新机会。大多数组织都依靠技术本身来实现这种转变，而有竞争力的优势不仅仅在于被使用的是什么技术，还在于它们被用的有多好。MSF 有助于指导小组来实现这种转换。
有了合适的利益相关人的支持、培训、辅导，在一些技术解决方案里使用 MSF 是相当简单的。用一种反复的方法来实现它有助于保证目标可以实现，从而让小组在前进的过程中能够不断学习新东西。
但是，在组织里使用 MSF 是一项要求相当高的计划，它需要领导的支持和周密的规划。这样可能会给组织文化以及个人习惯带来一些改变。这使得新解决方案的引入在很多方面都很相似，所以很多 MSF 技巧能够被有效地应用到 MSF 自身的实现上就不足为奇了。确切地说，这些包括一个清晰的前景、类似角色的表示、版本化的发布、风险和就绪管理，以及学习经验等。Microsoft 承认这所代表的挑战，并建立了很多渠道，为组织实现 MSF 提供培训和指导。
学习 MSF
客户可以通过多种途径了解 MSF，包括：
| • | MSF 资源库里的 MSF 核心白皮书，请参阅 http://www.microsoft.com/china/technet/itsolutions/techguide/msf/default.mspx 。建议按照下面的顺序阅读该白皮书：
| ||||||||||||
| • | 在 TechNet 和 MSDN® 上还有与 MSF 相关的具体技术文章和产品文档。 | ||||||||||||
| • | MSF 培训，由 MSF Practitioner 来教授。MSF 培训首选的提供商是 Microsoft 学习解决方案金牌合作伙伴，他们会提供下列课程： 1846A：MSF 基础。这是一门三天的课程，向学生介绍 MSF 的原理、模型、准则和成功做法。 |
使用 MSF
在了解了更多关于 MSF 的信息之后，读者现在可能希望在自己的组织里来实现它。当 MSF 首先被应用到一些项目里的时候，组织再去采用 MSF 会容易得多 — 没有什么能够像成功的例子一样去推动变化的成功发生。类似的，成功使用 MSF 的组织，即使只在一些项目上使用了它，也会在最初项目结束之后继续享有能力极强小组和一些机会，可以进行内部共享、领导能力和辅导。
MSF 的领导能力、指导和辅导可以从下面的资源获得：
| • | MSF 咨询服务，由 MSF Practitioners 通过 Microsoft 服务中心和 Microsoft 认证合作伙伴提供。合格的 MSF Practitioners 见 www.microsoft.com/china/technet/itsolutions/techguide/msf/default.mspx 上的列表。 |
| • | 用 MSF 构造的、技术专用的 Microsoft 服务产品和解决方案加速器，由 MSF Practitioners 通过 Microsoft 服务中心和 Microsoft 认证合作伙伴提供。 |
小结
Microsoft 解决方案框架 (MSF) 是一个强大的工具，用来帮助组织解决对技术项目的成功至关重要的关键领域里的问题 — 人员和过程。源自于 Microsoft 及其合作伙伴和客户真实项目的 MSF 为一系列具体原理、模型、准则、概念和成功做法等的应用提供了指导，这些原理、模型、准则、概念和做法已经被证明有助于防止技术项目失败的主要原因的发生。
本白皮书介绍并概述了 MSF 的基础原理、核心模型以及准则，参考了其他材料，以便更加深入探讨具体的主题。它解释了 MSF 于其它行业方法和标准的关系，并推荐了在组织里实现和采纳 MSF 的一种方法以及指导和帮助。
更多信息：
Microsoft 解决方案框架： www.microsoft.com/china/technet/itsolutions/techguide/msf/default.mspx
Microsoft 操作框架： www.microsoft.com/china/technet/itsolutions/techguide/mof/default.mspx
附录：MSF、行业标准和方法
很多组织已经用 MSF 提高了它们解决方案的成功率和质量，而不需要采用任何行业标准或者方法。但是作为一个框架，MSF 已经准备好为先前已经采纳行业标准和方法的组织提供对这些标准和方法的支持和提升，并能够与之共存。MSF 的基础原理提供了一个很好的指示，用来表明特定的方法是否能够与 MSF 兼容。那些具有类似原理的标准和方法一般都能很好地适用。
很多组织具有使用不同行业标准和方法的经验。其中更加常用的几个会在下面列出来，其关键点以及与 MSF 的异同也得到了一个简要的解释。本章不准备提供一个完整的比较；它只是要介绍 MSF 与这些方法或标准之间的关系。
MSF 的目标是交付成功的、高质量的业务驱动解决方案 — 以平衡对灵活性的需要，同时迅速地兑现承诺，管理好成本，并把风险最小化。下面所描述的每一项工业标准和每种方法都有特定的应用，并为独特的目的服务，或者被限制到特定的域里；其目标与 MSF 的目标不同。
由于这些原因，如果首先了解组织希望改进的是哪些特定领域，Microsoft 就不会明确地支持或者推荐使用某个行业标准或者方法。组织也能够从它们的采用中看到了好处；但是如果组织没有首先确保标准或者方法的目标适合于他们自己的业务目标，那么就会出现困难。
MSF 和软件工程学院 (SEI) 的软件能力成熟度模型 (CMMI)
软件能力成熟度模型® 集成 (CMMI®) 是一种协作努力，用来把系统和软件规范集成到一个过程提高框架里。CMMI 模型建立在软件系统工程能力模型 (SW-CMM®)、系统工程能力模型 (SECM) 和集成产品开发能力成熟度模型的最佳做法 (IPD-CMM) 之上，并对其进行了扩展。CMMI 把主要注意力放在了模型的应用上，以支持过程改进，指导质量过程，并为评价关键过程领域里的当前做法提供准绳。CMMI 使用了一种方式来建模、定义和测量软件开发专家所使用的过程的成熟度。它为组织提供了一个基准，用来比较它们的软件项目过程，并改进它们的指导方针。
尽管 MSF 过程模型为在多个领域里改进过程提供了指导和成功做法，但是 MSF 自身并不是以过程为中心的。MSF 被设计成为一种提高项目成功率的灵活方法，它包括前景预测、成立小组和领导能力等非过程的元素。MSF 把重点集中到了创建会利用有效过程进行发布的成功技术项目小组上，但是 MSF 没有像 CMM 那样去解决组织提高或者建立组织过程等问题。
CMMI 和 MSF 在连续提高和学习所有经验以便持续改进最佳做法上具有共同的目标。它们每个都会捕捉对方捕捉不了的做法，但是它们的内容发生了重复。CMMI 通过其过程成熟度的确定阶段使用一个指定性的评价方法，这个方法被设计用来将当前的过程与基准模型进行比较。MSF 没有试图去测量或者评估组织过程的能力和成熟度，但是对于正在发展其能力成熟度以满足 CMMI 要求的组织来说，它已经被证明是一个非常有用的和灵活的框架。
要获得关于 CMM 的更多信息，请参阅 Paulk 及其他作者编写的 The Capability Maturity Model, Guidelines for Improving the Software Process 。
MSF 和灵巧软件开发方法
诸如 Lean Development、eXtreme Programming、自适应软件开发这样的灵巧方法都是采用了多种做法的软件开发方法，这些做法是自适应的或者预测性的、以人员／小组为中心的、反复式的、特性和交付内容驱动的、沟通密集型的做法，并需要业务的直接参与。通过将这些属性与 MSF 的基础原理相比较，MSF 和灵巧方法都非常适合这样的软件开发原理和做法：即在需要高度自适应性环境进行软件开发所要求的原理和做法。
但是，MSF 所涵盖的领域要比灵巧方法大。灵巧方法专门用用于软件开发，并被认为最适合于不确定性很大的项目，对要求的探索和对渐进性的理解最喜欢这种自适应的方法。MSF 提出了一种方法，能够很容易就在合适的地方把灵巧方法的做法合并过来，但是它足够灵活，足以适应这样一些项目，即用于过程优化的更高层次的结构能够产生出更大的产出。
MSF 能够处理的项目问题也更广。灵巧方法发展的做法在项目生命周期过程的设计和开发阶段里最有用，这些做法也主要应用在这些阶段里。MSF 能够很容易地就把这些做法合并到软件开发项目里，但是增加一些对前面活动，以便通过更加有设想性的过程专门捕捉、证明和定义业务价值。类似的，MSF 加入了实现的后端阶段，这包括把软件从开发过渡到操作。
MSF 和项目管理知识体系
项目管理准则，以其在工程、医药和建筑等成熟行业的稳固根基，催生出了多个国内和国际知名的项目管理组织，它们每一个都有自己的知识体系。诸如项目管理学院 (PMI®)、国际项目管理协会 (IPMA) 和PRINCE2 这样的机构向组织提供了项目管理的标准方法。
MSF 把这些知识体系以及相关的技能、工具和技术当作任何项目小组必备的能力。由于这些技能对于技术项目成功的重要作用，所以 MSF 鼓励把项目管理的活动分布到整个小组里。这种项目管理的共同职责是 MSF 与其它方法的关键不同之处，一般的方法会把项目管理限定为一种“从上到下”的方法，其中项目经理常常就是项目“管事人”的同义词。相反的，在 MSF 小组模型里，项目管理活动被分布到跨学科角色身上，这样就维护同级小组里的平衡。
本白皮书里先前描述的MSF 项目管理准则受到了 MPBOK 的影响。但是，仅仅作为整个框架的一个组成部分，MSF 项目管理准则不是 MSF。作为一个完整的框架，MSF 加入了项目管理之外的其它知识领域，例如包括对软件体系结构和设计的指导。MSF 本身是一个更大框架 — Microsoft 企业服务框架的一部分，后者包括一个叫做 Microsoft 操作框架 (MOF) 的操作管理做法，这在本白皮书的上文已经提到过了。
MSF 和国际标准化组织 (ISO)
ISO 9000 标准体系代表了国际上对优秀管理做法的总体看法，这些做法让组织能够可靠地和可重复地交付满足客户质量要求的产品或者服务。起源于制造和过程控制的这些优秀做法已经被提炼成为一套质量管理系统的标准化要求，它能够为任何组织所使用，而不论组织从事什么工作、组织的规模，也不论它是私有的还是公有的。
ISO 9000 为采用系统的方法来管理业务的过程提供了一个框架。ISO 9000 明确了质量系统必须满足的要求是 什么 ，而没有限定组织应该 如何 去满足这些要求。ISO 9000 关心的是组织进行其工作的方式 — 而没有直接关心这个工作的结果 — ISO 9000 标准不是产品标准。这一体系还提供了用于系统审核的模型，以确保组织及其客户的系统在有效地运作。这三个质量保证模型是 ISO 9001、ISO 9002 和 ISO 9003。
与 ISO 标准的大多数读者而言，MSF 的读者群要有限得多 — 那些在 IT 领域里开发和部署技术解决方案的人。MSF 把重点放在了如何把质量融合到组织的服务和产品里，而没有放在满足质量系统的具体要求上。
MSF 和 ISO 标准所共有的一个元素是，它们都是以对成功做法的归档为基础的。但是，ISO 没有指定这样做的特定方法，所以组织可以以任何方式来定义过程，只要这种方式能够最好地将业务置于其控制之下的。MSF 没有在其技术领域里为生产高质量的产品和服务定义一种组织人员和过程，以及遵循 MSF 准则的方法。
Microsoft 解决方案框架的有效应用可以帮助组织去符合 ISO 标准。如果 ISO 方法能够有助于将变化最小化并确保符合过程，那么这种方法就更适用于部署项目，后者的确定性和可重复性要比软件开发项目的更高，当然在软件开发项目里获得更改的产出创造性和独特性是受到鼓励的。不论如何，ISO 方法和相关的标准非常适合于任何技术项目的质量计划，以确保解决方案里更高的可靠性。
1 Frederick P. Brooks, Jr，The Mythical Man-Month: Essays on Software Engineering，Anniversary Edition （Boston，MA：Addison-Wesley，1995），74-75 页。
2 Steve McConnell，Software Project Survival Guide （Redmond，WA：Microsoft Press，1998），86 页。
3 Jim 和 Michele McCarthy，Software for Your Head （Boston，MA：Addison-Wesley，2002），273 页，277 页。
4 Tom DeMarco 和 Timothy R. Lister， Peopleware：Productive Projects and Teams （New York，NY：Dorset House Publishing，20000），155 页。
5 Peter Block，The Empowered Manager （San Francisco，CA：Jossey-Bass Inc., Publishers，1987），108 页。
6 Carl Larson 和 Frank LaFasto，Teamwork：What Must Go Right/What Can Go Wrong （Newberry Park，CA：Sage Publications，1989），55 页。
7 同上。
8Randall E. Stross，The Microsoft Way：The Real Story of How the Company Outsmarts Its Competition （Cambridge，MA：Perseus Publishing，1997），51 页。
9 Tom Peters，Thriving on Chaos（New York，NY：First Harper Collins Publishers， 1987）。
10 Jim Highsmith，"What Is Agile Software Development?" CrossTalk（October 2002），4 页。.
11 同上。
12 Tom Peters，Thriving on Chaos，（New York，NY：HarperCollins Publisher，1987），98 页。
13 George Santayana，The Life of Reason，vol. 1（New York，NY：MacMillan Pub Co.，1981）。
14 Peter Senge，The Fifth Discipline: The Art and Practice of the Learning Organization（Garden City，NY：Doubleday & Company，Incorporated，1994）。
15 Peter Senge、Charlotte Roberts、Richard Ross、Art Kleiner 和 George Roth，The Dance of Change: The Challenges of Sustaining Momentum in a Learning Organization（Garden City，NY：Doubleday & Company，Incorporated，1994）。
本文档中的信息代表 Microsoft Corporation 到发布之日对所讨论问题的最新观点。由于 Microsoft 必须对不断变化的市场情况作出反应，这些信息不能解释为 Microsoft 一方的承诺。Microsoft 不保证所提供的任何信息在发布之后仍然正确。
本指南只用于提供信息。MICROSOFT 不对本文档的信息做任何明示或者暗示的保证。
用户有责任遵守所有生效的版权法。根据版权法的规定，如果没有 Microsoft Corporation 的书面许可，不得以任何形式或者利用任 何手段（电子、机械、影印、录音带或其他方式），为了任何目的，对本文档的任何部分进行复制、存储、在检索系统引用以及传播。
Microsoft 对本文档中的所有内容都拥有专利、专利应用、商标、版权或其他知识产权。除非 Microsoft 通过书面许可协议明确提供，此文档并不意味着授予您对这些专利、商标、版权或其他知识产权的任何许可。
>除非特别提到，本处示例所涉及的公司、组织、产品、域名、电子邮件地址、图标、人名、地名和事件均为虚构，不与任何真实的公司、单位、产品、域名、e-mail 地址、徽标、人员、地点和事件有联系，也不应从中做任何此类联系方面的推断。
© 2003 Microsoft Corporation。保留所有权利。
Microsoft、MSDN 和 Windows 是 Microsoft Corporation 在美国和／或其他国家（或地区）的注册商标或商标。
这里提到的真实的公司名称和产品的名称可能是它们各自所有者的商标。
扫一扫
664
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
