Microsoft 解决方案框架版本 30 概述.docx
《Microsoft 解决方案框架版本 30 概述.docx》由会员分享，可在线阅读，更多相关《Microsoft 解决方案框架版本 30 概述.docx（28页珍藏版）》请在冰豆网上搜索。
Microsoft解决方案框架版本30概述
Microsoft解决方案框架版本3.0概述
发布日期：
2004年06月04日
关于Microsoft解决方案框架的更多信息，请参阅
致谢
撰稿人
GTDLtd.董事：
GeoffreyLory
Microsoft产品经理：
DerickCampbell
MicrosoftMSF总监：
AllisonRobin
Microsoft技术编辑：
GaileSimmons
VoltTechnicalServices技术编辑：
PatriciaRytkonen
审阅者
MSFmentor：
JeffCarter，美国
MicrosoftConsultingServices：
NathanDolly，美国
LogicControl：
JohnS.Dranchak
Microsoft：
HollyDyas
C2Consulting：
PaulGlen，美国
LLCFrameworkDeliveries：
TomGordon
Microsoft：
PaulHaynes
MicrosoftConsultingServices：
HiroshiKoisumi，日本
LIHLtd.：
EranKolber，以色列
MicrosoftPremierSupport：
ShawnLaBelle，美国
MicrosoftConsultingServices：
DavidMillet，美国
SystemgroupManagementServices：
EdMusters，加拿大
MicrosoftConsultingServices：
AlexNicol，加拿大
GainsfordAssociates：
DavidPreedy，英国
ThomsonWest：
JaneMarieRief
MicrosoftConsultingServices：
DolphSantello，美国
本页内容
摘要
读者
介绍
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某些组件之间的关联。
图1：
MSF组件举例
查看完整的图像。
或者，把上面的图标用文字表达出来就是：
MSF的一个基础原理是学习所有的经验。
这一原理在MSF过程模型里的关键里程碑上得到了充分的应用，在过程模型里愿意学习这一关键概念成功应用这一原理所需要的。
愿意学习这一概念通过后里程碑回顾的经过检验的做法在项目里得到体现。
在大型的和复杂的项目里，Microsoft建议是利用客观的外部服务商来确保有一个无过错的环境，并把学习最大化。
相反的，定义和监视风险触发器（Microsoft建议在企业数据库或者存储库里捕捉它们，以便供跨项目使用）的经过检验的做法是持续评估风险这一关键概念的一个应用。
这些做法和概念是风险管理准则的一部分，风险管理准则通过MSF过程模型每个阶段里MSF小组模型的所有成员来运用，这些概念和做法还用到了保持灵巧—预测变化这一基础原理。
基础原理、模型和准则在下面的章节里都得到了进一步的解释，这就提供了它们之间相互关系的背景。
返回页首
基础原理
MSF的核心有八个基础原理：
•
推动开放式沟通
•
为共同的前景而工作
•
赋予小组成员权力
•
建立清晰的责任和共同的职责
•
关注交付业务价值
•
保持灵巧，预测变化
•
质量投资
•
学习所有的经验
这些原理共同传达了MSF观点，构成了一种统一方法的基础，这一方法用来组织项目所需的人员和过程，以便交付技术解决方案。
它们是MSF结构和应用的基础。
尽管每个原理都已经显示出了自身的优势（请参阅本白皮书结尾部分的参考文献），但是它们很多都是相互依存的，因为其中任何一个的应用都对另一个的成功起到了支持作用。
在依次应用的时候，它们建立了一个稳固的基础，使得MSF能够很好地适用于规模、复杂程度和类型都不相同的多种项目。
下面经过挑选的例子说明了MSF如何将每个原理应用到MSF模型或者准则上。
请注意：
本白皮书并不会描述MSF里这些原理的每个应用实例。
推动开放式沟通
“日程安排一团糟、功能不合适、到处都是系统错误，而原因就是左撇子不知道右撇子在做什么……。
那么，小组之间应该如何相互沟通呢？
用尽可能多的方式沟通。
”
FrederickP.Brooks，Jr1
技术项目和解决方案是由人的活动来构建和交付的。
从事某个项目的每个人都会给小组带来自己的智慧、能力和观点。
为了将成员的个人效力最大化，同时优化其工作效率，信息就必须随时可用且能够被积极共享。
如果没有能够从多种渠道获取该信息的开放式沟通，那么小组成员就无法有效地完成其任务，也无法作出正确的决策。
随着项目规模和复杂性的增加，对开放式沟通的需要就变得更加紧迫。
完全基于须知（历史标准）的信息共享可能导致误解的产生，以至于削弱小组交付行之有效的解决方案的能力。
这种受限的交流方式的最终结果可能会是解决方案和预期效果都无法满足要求。
MSF里的开方式沟通
MSF推出了一种开方式和包容式的沟通方式，既满足了小组内部也满足了利益所有人之间沟通的需要，同时能够符合诸如时间约束和特殊环境等条件的限制。
一个畅通的信息流不仅会减少误解和无用功产生的机会，还会确保小组成员都能够致力于通过共享属于各自领域的信息减少与项目有关的不确定性。
在MSF项目里，可以采用任何形式来进行开放式和包容式的沟通。
它是MSF小组模型的基本原理，而前者将它集成到了角色职责的描述里。
当在整个项目生命周期过程中使用的时候，开发式沟通会推动客户、用户和操作等的积极参与。
这种参与也通过将开方式沟通的概念融合到MSF过程模型的关键里程碑的定义里得到了支持。
沟通成为了共同的前景和性能目标能够被建立、测量和取得的媒体。
为共同的前景而工作
“在项目开始之前，小组需要建立一个共同的前景。
如果没有这样一个共同的前景，就无法获得表现优异的小组工作。
对75个小组展开的一项研究表明：
在小组有效运作的每个案例里，小组都对其目标有一个明确的理解。
”
—SteveMcConnell2
所有伟大的小组都有一个明确的和上升的前景。
这一前景通过前景陈述的形式得到了最好的表达。
尽管很简洁—只有一个到两个段落—前景陈述会描述业务的去向，以及所提出的解决方案将如何有助于实现业务价值。
拥有一个长期的和不受限制的前景会激励小组克服其对不确定性的畏惧感，专注于事情当前的状态，取得应该取得的成果。
如果没有共同的前景，小组成员和利益相关人可能会在项目目标和目的的看法上产生分歧，无法形成一个具有凝聚力的小组。
工作努力不协调会浪费和削弱小组的成果。
即使小组生产出了交付内容，成员也将很难评估其是否成功，因为评估要依靠他们测量所需的前景。
为共同的前景而工作需要很多其他原理的应用，这些原理也是小组成功的必要因素。
赋予小组成员权力、职责、沟通，以及关注业务价值等原理中的每一个，都在成功到达共同前景这一困难的和无畏的工作中起到了重要作用。
对为共同的前景而工作的需求是如此重要，以至于Jim和MicheleMcCarthy在其著作SoftwareforYourHead3中提供了一个路标，用于有效地和反复地将小组带往共同的前景。
MSF里的共同前景
共同的前景是MSF小组和过程模型里的一个关键组件，它强调理解项目目标的重要性。
当所有的参与者都理解了共同的前景并为之而工作的时候，他们就能够通过这一前景来表达更加宽泛的小组目的，进而调整自己的决定和工作重点（代表他们角色的观点）。
MSF过程模型的这种反复性要求有一个共同的前景存在，以便指导解决方案朝着最终的业务结果前进。
没有这一前景，解决方案的业务价值就只会走向平庸。
项目的共同前景是小组工作的基础。
建立这一前景的过程会有助于明确目标，减轻并解决可能发生的冲突和错误。
一旦达成一致，前景就会激励小组前进，并帮助确保所有的努力都服务于项目目标。
它会提供一种测量成功的方式。
明确并承担共同目标是如此重要，以至于它成为了任何MSF项目第一阶段的主要目标。
赋予小组成员权力
“在最优秀的小组里，不同的个人会在不同场合下体现出其领导能力，他们会在其专长的领域里担负起领导职责。
没有哪个人是永远的领导，因为如果这样的话，这个人就无法和其他人融为一个整体，而小组的互动会因此而开始分裂。
小组的结构应该是一个网络型的而不是一个层次型的。
”
—TomDeMarco和TimothyLister4
在确定性是标准、且每个个人的贡献都是规定好的和可以重复的项目里，被较少赋予权力的小组会生存下来并取得成功。
但是，即使是在这样的情况下，解决方案潜在的价值也不太可能达到所有的小组成员被赋予权力时能够达到的水平。
缺乏权力的赋予不仅会扼杀创造力，而还降低士气，阻碍建立表现出色的小组的能力。
挑出个人来进行奖励或者责问的组织将会破坏赋予小组权力的基础。
在一个高效的小组里，所有的成员都被赋予权力以便根据他们自己的承诺交付任务，并且充分信任小组的其他成员也能实现各自的承诺。
类似的，客户也能够认为小组将会兑现其承诺，并进行相应的规划。
支持和滋养被赋予权力的小组和小组成员，建立起这样一种文化可能是极具挑战性的，这需要组织的承诺。
在TheEmpoweredManager5里，PeterBlock把权力的赋予叫做“自我兴趣的启迪”，并把它描述成为表达和推动我们朝着这一方向前进的承诺。
MSF里被赋予权力的小组成员
权力的赋予对MSF有着深远的影响。
MSF小组模型建立在同级小组的概念以及这种小组成员所暗含的权利赋予本质之上。
被赋予权力的小组成员认定他们自己以及其他每个人都对项目的目标和交付内容负有责任。
被赋予权力的小组成员都接受项目风险管理和小组就绪管理的职责，因此能够预先就对这样的风险和就绪进行管理，以便尽最大可能确保项目成功。
创建和管理日程安排提供了另一个赋予小组权利的例子。
MSF主张从下到上日程安排方法，这就意味着正在工作的人要承诺它会在什么时候被完成。
这样做的结果就是一个能够得到小组支持的日程安排，因为小组相信自己。
MSF小组成员确信，任何延迟都会在它们被发现的时候被报告，这样就让小组领导能够去扮演一个更具推动性的角色，从而在最关键的时候提供指导和帮助。
对过程的监视被分布在小组里，成为了一项支持性而非控制性的活动。
建立清晰的职责和共同的责任
“每个［小组］成员与小组之间的关系都必须根据可能的角色以及角色所产生的结果来定义。
最终，小组的任何努力都会归结为个人的责任和职责。
”
—CarlLarson和FrankLaFasto6
无法实现对项目职责和责任的清晰理解常常会导致重复的工作或者交付内容的缺失。
这些都是功能紊乱的小组的症状，尽管这些小组投入了大量的精力，但是他们还是无法取得进步。
同样具有挑战性的是专制地运行项目，这样会扼杀创造性，将个人的贡献将到最低，并使小组失去权力。
在人力投资是主要资源的技术项目里，这是失败的主要原因。
跨职能小组的成功都具有清晰的职责和共同责任，这在Larson和LaFasto的一次详尽研究里有详细的文字证实。
7他们的研究显示：
建立对职责和责任的充分理解会减少与“谁、什么、什么时候，以及为什么”相关的不确定性，其结果就是执行变得更加有效和回报也更高。
MSF里的职责和责任
MSF小组模型基于这样一个前提，即小组里的每个角色都代表了对项目的一种独一无二的观点。
但是，对于项目成功而言，客户和其他利益相关人需要一个对项目状态、行动和当前问题等信息的权威来源。
为了解决这一问题，MSF小组模型把对各种利益相关人的清晰角色职责与实现这个项目成功的整个小组的责任结合起来了。
小组的每个角色对小组本身以及各自的利益相关人都是负有责任的，以取得角色的高质量目标。
从这个意义上讲，每个角色对于最终解决方案的质量都负有责任。
同时所有的职责都要在小组的同级之间共同分担，因为任何小组成员都可能导致项目的失败。
它是相互依存的，原因有两个：
首先，需要这样，因为把每个角色的工作分隔开来是不可能的；其次，出于优先的原因，因为如果每个角色都了解全局情况，那么小组的效率会更高。
这种相互的依赖性会鼓励小组成员对由他们责任的直接区域以外的工作作出评论和贡献，以确保小组所有的知识、能力和经验能够被应用到解决方案里。
关注交付业务价值
“经验教会托马斯·爱迪生把商业和技术结合到一起。
爱迪生取得第一项发明专利的‘电子选票记录器’能够快速地记录选票，原先专门用在立法机构里。
但是当他向国会委员会推销这个发明的时候，委员会的主席告诉他说：
”年轻人，这就是我们不想要的。
“（它会破坏阻止议案通过的神圣制度。
）他的机器从来都没有投入生产，所以他决定不再把他的精力放在那些缺乏‘商业需求’的任何东西上。
“
—RandallE.Stross8
忽略、匆忙地或者没有经过深思熟虑就定义项目业务价值的项目会在以后的阶段备受煎熬，因为项目的持续推动力会变得很模糊和不确定。
没有目的的行动让想要获得有成效的结果变得很困难，并最终失去小组这一层的和组织内部的动力。
这可能会导致错过交付日期，或者交付甚至无法满足客户最低要求的东西，或者干脆项目被取消。
通过把注意力放在改进业务上，小组成员的
升级会员 