MSF项目管理准则白皮书

1、工程管理准那么 白皮书摘要Microsoft(MSF)架还具备很大范围的灵活性，既适用于小型工程，也适用于非常巨大和复杂的工程。本白皮书描述MSF小型工程也很重要，但是本白皮书把重点放在具有扩展小组的大型工程上。虽然本文没有涉及到工程管理领域的一切方面，但是给出了用于计划和评估的推荐做法。框架概述(IT)MicrosoftMicrosoftMicrosoftMicrosoftITMicrosoft(MSF)Microsoft在预算范围内按期创立一个业务解决方案需要一种经过试验的方法。MSFITMSF活框架，以满足任何规模的组织或者工程小组的需要。MSFMicrosoft(MOF)Microso

2、ftITMOFITMOFIT(ITIL室 (OGC) 公布。介绍MSFMSF么和能力。本白皮书总结了工程管理准那么的关键方面，并且描述了 MSF 如何来处理它们。本文阐述了 MSF 的根底原那么如何在实施工程管理中衍Th一些与众不同的概念和做法。本白皮书还描述了为了支持整个小组，MSF典范的工程管理活动如何分布到 MSF 小组的各个领导身上。它的目的在于说明 MSF 的原理如何产Th出工程管理方法，其中工程管理的职责被分布到了小组领导的身上。在阅读本白皮书之前，请先阅读 MSF 小组模型白皮书。MSF 根底原理不管没有在本文里讨论，但是 MSF 工程管理准那么会以某种方式应用 MSF 一切的原

3、理，这一准那么与下面的几点直接相关。清晰的责任共担职责MSF成功的共通职责接合起来。在小组内部，每个角色都关于实现自己质量目标所需要的活动负有责任。供自己的想法和观察，即使是在那些他们并且不负责的领域里。具体来说，MSF 小组角色共通担当着工程管理很多方面的职责，例如风险管理、时间管理、质量管理、计划、日程安排、小组招聘，以及人力资源管理等。被赋予权力的小组会越发有效行计划。任何延迟或者改变都应该被尽快报告。MSF分布在小组的各处，并且成为一个支持性的角色，而不是一个控制性的角色。关键概念要理解 MSF 的工程管理方法，理解 MSF 定义以下概念和术语的方法就显得尤为重要了：MSF 中的准那么

4、MSFMSF那么。要获得更多的信息，请参阅 MSF 小组模型白皮书。当前，MSF 有三个准那么，诀别是风险管理、就绪管理和工程管理。MSFITITMSFMicrosoft 小组在过去几年里所领悟到的东西。为了有效地实施这些准那么，MSF 一切的小组角色都必需在每个领域里具有足够高的能力。什么是工程管理？IT一个是用来实现工程目标的一套知识、技能、工具和技术，而工程目标就是一致认同的质量、本钱、日程安排和约束等的参数。(I)MSF组角色群区分开来，一组工程被叫做。MSF 关于工程管理职责、技能和活动的领域进行了以下分类。(ii).工程管理领域工程管理领域描述工程计划跟踪改变控制集成和同步工程方案

5、；设置用于管理和跟踪变化的步骤和系统范围管理定义、分解工作范围工程范围；管理工程折衷日程安排管理利用小组估量Th成日程安排，任务排序、将资源与任务进行匹配、应用统计学的技术、日程安排维持本钱管理根据小组时间估量来准备本钱估量；进程报告和分析；本钱风险和价值分析人员资源管理计划资源、构建小组、解决冲突、为工程而计划技能就绪交流管理交流计划小组、客户赞助商、用户、利益相关人，工程状态报告风险管理促进和推动小组风险管理进程；维持风险文档采购邀请承包商参与效劳和或硬件软件的投标；准备要求建议 (RFP)，管理供给商或者分包商；合同和协议的管理和谈判；开放采购订单和批准发票质量管理质量计划，即确定要使用

6、哪些标准，提供质量标准和质量测量进程的文档不管本白皮书无法给出关于上述领域的完整指导，但是本文档后面会提供经过挑选的 MSF 推荐做法。工程管理不是由工程经理一个人完成的 想想“工程管理层说他们现在应该已经完成了它这样的说法，以及“太空机构一般都会有优秀的工程管理能力这样的说法。经理。在 MSF 里， 工程管理总是用来指上面所列领域里的特定知识和技能，而不是一个角色或者职位头衔。而工程经理这个术语将会被用来描述擅长进行工程管理的人。工程管理和 IT 特定进程总的来说，工程管理由一些知识和技术组成，这些知识和技术可以广泛应用到实施这些工程的任何IT、阶段、角色和做法。为了成功地实施工程，这些针关

7、于行业的进程就必需与一般的工程管理做法形成互补。MSF 为 IT 工程提供了进程和推荐的做法。它与工程管理准那么的关系见图 1。图 1：MSF 与工程管理准那么的关系察看完整的图像。在这上面的图里，针关于行业的领域是 MSF 进程的五个阶段。针关于行业的工程管理活动的一个例子是用于跟踪错误的推荐做法。工程管理的一般知识领域在左边。一个例子是用于管理合同或者跟踪预算的推荐做法。交叉代表了特定的 工程管理做法，后者是 MSF 的特征。这些都会在后文进行描述。返回页首MSF 工程管理的特征MSF 方法的这些与众不同的特征将在这里描述，并且在后面进行越发详细的讨论：工程经理角色的大多数职责都包含在 M

8、SF 程序管理角色群里。在需要 MSF 扩大小组的大型工程里，工程管理活动在多个层次发Th。某些大型的或者复杂的工程需要专门的工程经理或者工程管理小组。工程管理角色包含在程序管理里MSF 程序管理角色群囊括了下面所示的职能职责领域。在小型工程里，一切的职能职责一般都是由一个程序经理来处理的。随着工程规模和复杂性的提高，这一角色群分解成了两个专门的分支：一个处理解决方案体系结构和标准，另 一个处理工程管理。程序管理如何与小组领导一起工作要理解工程管理如何在 MSF 里工作，就有必要理解小组模型如何扩大规模、进行计划、通讯，以及决策。关于这一点的更多信息，请参阅 MSF 小组模型白皮书。如何去分布

9、小组管理，在很大程度上要取决于工程的规模和复杂性。MSF 是一个高度可伸缩的框架，它能够被用在只需要两个或者三个人的小型工程里，也可以用在非常大型的工程里。Microsoft 内部的产品小组就涉及成百甚至上千个小组成员。MSF 已经把从 Microsoft 小组组织里学到知识进行了归纳，供更大范围的 IT 工程使用。MSF 的可伸缩性在很大程度上来自于小组模型。小组模型可以以两种方式扩大规模：人可以担当这些越发专业的角色。下面。职能小组组的一个关键方面并且不简单的就是角色需要一个以上的人来担当，而是在其成员中有一个关于任务的陈述。图 2 是其中一个例子。小组领导是大型小组其他成员的集成点。小组

10、领导在其子小组这一层次负有一些工程管理的职责。图 2：负责用户体验的职能小组例如功能小组3子小组用于为解决方案构建相当分散的组件的有力候选关于象。图 3：功能小组例如扩大程序管理职能的规模图 4 显示了如何在三个工程规模层次处理工程管理活动。在工程 A 里，一切的角色都由大约六个或者更少的人来担味着他们在负责计划、时间估量和识别他们各自领域里的风险。图 4：工程管理的可伸缩方法在工程 B 里，大多数或者一切的角色都由子小组来担当，每个角色都有一个小组领导。小组领导关于其各自的子小组进行工程管理。程序管理角色群拥有负责整个工程的工程管理活动。要注意的是， 功能小组没有在图上显示出来，但是它们也是

11、子小组。由于每个子小组都是跨学科的，所以每一个都有一个程序管理领导。工程 C 和工程 B 类似，不管它有与其规模或者复杂性相关的特殊风险。复杂的工程，就像用在 MSF里的一样，意味着工程具有与以下因素相关的高风险：大规模或者高本钱。地理上分散的小组。小组成员隶属于多个公司、组织或者分包商。固定的或者高度受限的预算或者日程安排。需要技能和时间来管理的合同或者法律问题。东西关于于其他组织来说可能未必。这完全取决于工程早期进行的风险评估。工程管理职责描述这些活动。图 5 描述了每个角色和程序管理的小组领导所具有的工程管理职责。在复杂工程例如图 4 里的工程 C里，专门的工程经理所关切里的领域与程序管

12、理的相同，只不过是在一个独有的根底上。要注意的是，相同的职责领域往往会由工程层和子小组层来负责。图 5：小组领导的工程管理职责小组领导门负责识别其角色专长领域里的风险。图 5 里有三个地方可以将小组领导的职责与其他成员的职责模式区分开来：并且可能引起混乱。劳的大多数合同事宜。把工程的一局部分包一个 Web 设计公司，让其参加小组就是这样的一个例子。发布管理作为小组 IT 操作的代表，会处理构建解决方案所需的以及小组开发和测试实验室环境所需的硬件、软件和设备等的采购工作。通管理还囊括小组以外的勾通计划、合同指定点的分配和进程的报告。程序管理拥有把工程作为一个整体的一切工程管理领域。程序管理会把小

13、组方案集成到主要方案里，同步日程安排，并且管理跨小组的依赖性。它会打破相关于于本钱而言的设计过度的倾向与日程安排所暗示的之间的平衡。大型、复杂工程里的工程管理和专门的工程管理角色往往是有道理的。工程监督效劳助其维持小组日程安排和其他的管理活动。客户的责任佳。MSFTh的关于监督点的需要，同时在同级小组里保存职责。MSFMSF这里的关键点是：在这个主题上没有绝关于的事。在直接的工程小组之外，组织的报告结构和效劳关系之间存在很多可能的不同之处。识别工程的责任路径。说明在小组自身之外，谁要为工程的什么方面负责。MSF 小组模型以以下方式提供了客户责任：产品管理会维持与客户之间的关系，并且扮演客户支持

14、者的角色。这一角色的目标就是客户的满意度。程序管理表现的目标是在工程约束内成功地交付工程。产品和程序管理会共通工作以便在工程约束之内满足客户需要。这两者共通分担工程的整体成功，不管它们的角色都在为不同的目标而努力。如果发Th了产品和程序管理都无法解决的问题，那么这些问题都会逐步升级成为整个工程的责任路径。用于 MSF 小组的精选建议下面推荐的工程管理做法是用于 MSF 小组领导和程序管理的。这些与出现在图 5 里的某些，但不是全部的工程管理职责相关于应。范围管理离目标去进行范围以外的活动。设想阶段的范围在工程的早期阶段，工程的宽范围必需被识别和列入文档。在 MSF 设想阶段，小组会为解决方案T

15、h成一个没有边界的前景。然后范围就会被识别，成为第一个版本。这在前景描述特性这一层次被广义地理解。解决方案范围和工程范围所必需完成的一切工作的总和。这个术语用 MSF 设计进程来定义解决方案范围。范围定义常，这些都是会产Th误解的具有特殊风险的领域。构 (WBS) 里，本白皮书下文即将讨论这一结构。范围改变控制认可。好的改变控制在一定程度上涉及好的折衷决策。MSF 折衷三角形和折衷矩阵是以可控方式推动改变的有用工具。要获得更多信息，请参阅 MSF 进程模型白皮书。准备方案计划作为一项活动会发Th在工程的始终。在设想阶段，小组会安排创立工程交付内容所需要的高层方法。只是一段文字。不管方案会在每个

16、阶段改良和更新，但是大多数的计划工作都会在 MSF 计划阶段进行。在这个阶段里计划进程的一般顺序是：设计进程你要构建什么？计划进程你要怎么来构建？关于开发进行日程安排什么时候构建它？章就将集中讨论计划进程。重新使用文档所带来的好处呢？维持起来，放到一个能够轻易访问得到的储藏库里。到一个未来的小组能够反复使用的地点。工程方案在 MSF 里，工程方案指的是一套描述案是每个角色的小组方案的集成和累积。每个小组角色都拥有描述自己要如何完成交付内容的方案。方案类型驱动角色方案类型驱动角色勾通方案产品管理开发方案开发方案类型方案类型驱动角色培训方案用户体验平安方案开发、发布管理测试方案测试预算方案程序管理

17、用户教育方案用户体验部署方案发布管理采购和设备方案发布管理、程序管理试验方案发布管理工作分解结构工作分解结构 (WBS) 是一个面向交付内容的、经过分组的工程工作元素，用来组织和定义工程的总范围 (iii)。它是要被完成的工作的大纲。没有纳入 WBS 结构里的工作就不在工程的范围之内。小组领导和工程管理将 WBS 用作工程管理工具，来构建方案和日程安排。在 MSF 里，创立 WBS在大型工程里，子小组职能和或功能小组可能需要单独地集体讨论所需要进行的工作。小组领导会把集体讨论 的结构归档，并且把结果呈交给核心领导小组。工程管理然后就会把这些结果同步成为一个共通的 WBS。优点WBSWBS 能够

18、用缩进式列表或者块关系图来显示，并且能够用各种工具来创立，比方电子数据表、文字处理程序，或者工程管理软件。WBS 具有以下优点：估量 。为要被估量的任务提供一个基准。所提供估量结果用来确定本钱和日常安排。经过明确要被完成的工作工程，员工和技能资源就会成为可知的。如果工程的利益相关人要询问理由，这还会有助于说明所需要的资源。排序。提供一个能够用来分析依赖性和资源约束的任务基准列表，以便将其开展成为日程安排。风险识别。帮助小组在识别风险的时候考虑每项任务。职责。可以被用来Th成职责矩阵。WBS 和职能标准以及主工程方案之间的可跟踪性职能标准、主工程方案和 WBS 之间存在一个可跟踪的关系。它反映了

19、交付内容和构建交付内容所需任务之间的关系。关于于职能标准里的每个特性或者组件，WBS 列出了与完成该交付内容相关的任务。在职能标准里，特性或者组件被分组的方式同与它们相关的任务出现在 WBS 里的方式不同。如果一个特性在 WBS 里没有与之相关于应的任务工程，那么它可能会在后来的估量进程中“掉入裂缝，而这可能会导致不切实际的日程安排或者预算。主工程方案和 WBS 以一种互补的方式工作。WBS 会简要地列出每个任务。任务如何进行、质量标准和详细的子任务或者清单等的详细信息都被归档进了方案。图 6 是 WBS 能够如何成为维持标准、方案和日程安排之间可跟踪性的强大工具。图 6：WBS 提供了标准、

20、方案和日程安排之间的可跟踪性察看完整的图像。构建工作分解结构每个小组都会识别Th式一切和跟踪。在 MSF 里，层次最低的活动出现在主工程方案里，而不在 WBS 里。这些会合成为值得在整个工程层进行跟踪和报告的大型任务，这就是 WBS。要被识别和分解成微小的活动和任务。这一进程就叫做工作分解。MSF 风险管理进程的结果之一就是其它响应风险有时候也叫做“威胁或者意外方案和活动的任务。这些任务必需像其他一切的任务一样被加到 WBS 里，被估量、计划和列入如日程安排。要考虑连续开设小组工作分解讲座和风险集体讨论讲座。WBS 的第一层应该囊括工程Th命周期的一个阶段。MSF 进程模型在这一点上做得很好。

21、MSF 所建议的中间里程碑与交付内容的完成以及基准的制定是密不可分的。中间里程碑还会构成一个自然的第二层。在这一层次之下，可以识别所 有的交付内容并且针关于每一个都分解任务。这一进程也叫做工作分解或者任务分解。任务分解指南在进行任务分解的时候，建议采用以下指南：能够被实际地估量。被认为不会少于一天，不会多于 40 天关于于 IT 工程而言。有成果丰硕的结果和交付内容。能够被完成，而不会有较大的中断。可以被分配给一个人负责其完成。要比其他的更能够分解为特定的层次。能够把高风险的活动分解为其他低风险的活动。除了最上面的一个或者两个层次，要使用一个动宾短语来描述任务。例如，使用“设计数据库架构，而不

22、是简单地用“数据库架构。以大纲的形式囊括三到五个层次。WBS 会在工程进程中反复开展，但是会在计划阶段中定型。从下到上的估量IT 工程的估量应该由那些日程安排里规则的人员来进行。从下到上的估量是关于来自多个小组成员的估量进行开发和集成的进程。它带来了以下好处：更高的准确性。由那些专门人员作出的估量要越发准确，因为进行估量的人员具有从事类似工作的经验。责任。 开发自己工作估量的人会感到他们关于自己工作的责任更大。他们也会关于成功到达自己作出的估量感到更大的责任。赋予小组权力。够接受的实际估量之上。集成小组估量(UE) 交付内容准备估量等等。程序管理角色会推动小组估量进程，并且把一切的估量集成“累

23、积成为一个主日程安排和预算。软件工程的估量IT 工程的本钱在很多程度上由劳动本钱构成，所以关于工作努力的估量是获得本钱和日程安排估量所必需的数据输入信息。设置正确的预期估量会为未来的某种结果设置一些预期。由于这个原因，设定一些关于估量准确性的正确预期与Th术一样重要。程序和产品管理角色群必需努力工作以确保下面这些内容的共通预期：估量要依靠标准。开发 IT 解决方案和自定义建造一个房屋很相象。在特性被仔细定义之前就了解其本钱是很重要要花时间，而且必需在估量里予以考虑。为折衷做好准备。利用折衷矩阵来讨论折衷三角形和设置默认的优先权有助于小组和客户设置共通的预期。在每个里程碑处重新估量小组应该随着工

24、程的进展而提供一系列经过更多改良的估量。不确定性和估量的准确性软件估量是一个渐进的改良进程。图 7 说明了所谓的软件估量的“不确定性圆锥估量会聚。在工程早期，关于真正本钱的估量的变动范围还非常广。这个范围会随着工程的推进而逐渐变小。要注意的是，在前景范围认可里程碑处，估量可以低两个数量级，或者高 0.5 个数量级。所显示的特定数据值取自于 20 世纪 90Th这里所要学习到的知识是，在设想阶段，小组会制定出时间和本钱的估量范围有时候也叫做“球场估量。一定 不要在这一阶段提供一个固定的本钱估量或者固定的日程安排估量。需要弄清楚的是，这些估量在设想范围认可里 程碑处可能会因为某个重大的因素而发Th

25、变化。图 7：不确定性圆锥察看完整的图像。来源： 摘自 Boehm 及其他作者的 Cost Moels for Future Lifecycle Processes: COCOMO 2.0， 1995 (iv)。位于任务分解最底层的估量在任务层次准备工作估量的方式有多种。一切的方式都会从把 WBS 里的每个任务分解成为更小的活动开始。这在子小组层进行，并且由每个小组领导来协调。然后，会Th成一个针关于每个最底层活动的估量。这些估量会被集中到一起，在 WBS 里创立一个任务估量。有行业标尺，能够提供好的衡量基准。一项越发准确且值得推荐的技术是关于每个低级别的活动都Th味着它是一切可能方案的最差的

26、。乐观和不利估量应该要鉴于合理的和可能的风险。一旦低层次的活动汇总成为了 WBE 层次的任务，每个任务就有了三个层次的估量值。小组领导会把这些信息转交给程序管理用于本钱分析，然后使用估量数据来准备日程安排。PERT 分析一旦一切任务的估量被集中成为了 WBS，程序管理或者专门的工程经理会用统计分析来调整整个时间估量。完成这一个目标的技术有多种，但是最常用的一种是 PERT程序评估检查技术。PERT 会用到三点估量，并且计算分布的平均值。这会被用来计划最有可能的结束日期，而不是最有可能的估量值。它还会根据关键路径上一切任务的变化提 供多种估量结果。关于 PERT 的完整描述不在本文的讨论范围之内

27、。但是工程管理工具，例如 Microsoft Project，提供了进行 PERT分析的能力。返回页首方案安排建议方案安排管理囊括确保工程按期完成所需的进程。任务排序一旦工程的任务和活动被归档进入了 WBS 并且进行了估量，它们之间的依赖性就会被识别。例如，如果描述某个特性的职能标准没有完成，那么该特性的用户文档草案也无法完成。应该在任务的最小级别来识别依赖性。时间搏击使用内部时间限制来保持工程小组在指定特性和活动优先顺序上的压力 叫做“时间搏击。这不应该被随意用来解开始。任务驱动的日程安排风险最大的高优先权特性或者组件应该被方案安排在工程的早期。这可以把响应问题的可用时间最大化。管理缓冲时间

28、量取决于风险的量。经过在工程早期进行风险评估，就可以估量最有可能发Th时间来填补。需要的修正行动将需要额外的时间。推荐关于缓冲时间使用下面的指南。叫做帕金森氏法那么的效应，缓冲会被方案内的任务所吸收，而不是方案外的任务。缓冲时间也应该纳入日程安排，就像任何任务一样。一般来说，缓冲时间会在主要的里程碑，尤其是后来的一些里程碑之前立即就被分配。它总是应该被放在工程的关键路径上。关键路径是工程里相互依赖的任务的最长链，并且直接决定着工程的持续时间。所以它只能够根据请求来分配。如果参加了资源，或者从工程里取消了一些资源，不要用缓冲时间来填补。如果这样做了，那么填补风险的能力也会相应地降低。要使用折衷三

29、角形来协调特性、资源和日程安排。并且危及结束日期。返回页首结论MSF 提供了一种可伸缩的方式，确保从非常小的工程到极其庞大和复杂工程中的工程管理职能都能够得到满足。这种方法防止了小型工程中过度的官僚作风，同时为大型的、越发复杂的工程提供了适宜的管理结构。返回页首尾注PM，Inc AGuietotheProjectManagementBoyofKnowlege2000年版Newtown Squar，PA： ProjectManagementGCaupinHKnopfelPMorrisE.Motze 和 OPannenbacker 的 IPMACompetenceBaselineBremen，Germany：InternationalProject Management Association