微软项目管理 案例分析.

Presentation on theme: "微软项目管理 案例分析."— Presentation transcript:

1 微软项目管理 案例分析

2 提 纲 微软项目管理内容及流程 微软项目管理过程与模板 微软项目管理实务与案例分析 Q&A 2

3 第一部分 微软项目管理内容及流程

4 微软项目管理内容及流程 软件开发的项目管理 微软项目管理的组织形式 同步--稳定法开发模式 微软多里程碑式流程
MSF（Microsoft Solution Framework )

5 软件开发的项目管理 在产品定义与开发过程中，微软件遵循着一种称之为“靠改进特性与固定资源来激发创造力”的战略。该战略可分为五个原则：
将大项目分成若干里程碑式的重要阶段，各阶段之间设立缓冲时间； 运用想象性描述和对特性的概要说明指导项目； 根据用户行为和有关用户的资料确定产品特性及其优先顺序； 建立模块化和水平式的设计结构,并使项目结构反映产品结构的特点； 靠个人负责和固定项目资源实施控制。

6 微软项目管理的组织形式 程序管理和软件的开发,以及测试是产品单位（项目经理部）里主要的技术工作,在产品单位里,程序经理、开发员和测试员以“特性小组”形式并肩“作战”。典型的项目开发小组由一位程序经理（他通常从事不止一个“特性”的设计开发工作）和3至8名开发人员（其中一人为组长）组成,同时还配备平行的测试小组,其成员与开发员组成“搭档”,用户培训专家则作为产品小组的成员进行工作。产品经理负责为产品单位 内的营销部门和产品规划选定人员。客户支持人员虽是另一个独立部门的成员,但他们中的产品专家却与单个产品单位密切合作。

7 同步--稳定法开发模式 微软公司的项目运作方式是把项目分成若干个子项目,并根据功能领域分组同时进行的平行推进工作方式,这种方法集中了里程碑和每日构造这些关键的概念。 微软典型的项目管理（项目的生命周期）包括三个阶段: 计划阶段完成功能的说明和进度表的最后制定; 开发阶段写出完整的源代码; 稳定化阶段完成产品,使之能够批量生产。

8 微软多里程碑式流程

9 微软解决方案框架（MSF） MSF(Microsoft Solution Framework)，它来自于超过25年的微软与众多合作伙伴的最佳应用实践，是一个将软件开发流程、原则和公认的做法完全集成的集合，并且提供了很好 的模板级解决方案实现来支持团队开发。 MSF是一个经验知识库 MSF是一种框架结构 MSF是资源的集合 MSF是一个经验知识库，它包括以下方面的内容： 1企业结构设计方案—采用交互的方式，侧重于制定长期规划，同时也能完成短期目标。 2项目开发准则—包含组队模型和过程模型，用于建立高效的项目组，管理项目的生命周期。 3项目设计过程和多层结构的应用程序模型—用于支持设计复杂的分布式企业应用。 4企业信息基础设施的实施方法—使用组队模型和过程模型支持实现、操作和技术上的方案。 MSF是一种框架结构 框架结构重点解决一个基本的问题：它提供解决总体问题和作出有效决策的轮廓。 框架结构可以增强分析和开发大型项目的能力。MSF 能够确定项目最大的风险在何处，强调制定计划和确定进度，确保成功发布一个产品所必备的条件。 一个资源的集合 MSF收集了一组集成的资源和准则来指导项目组走向成功。它包括明确的概念、详细的工作指南和微软最好的实践经验，保证您能立即开始工作。 9

10 MSF的发展历程 首次提出于1993，当时主要用于对外的咨询服务 客户需要微软的产品和技术 也需要创造这些产品和技术的经验
Version 4 2005 Version 3 2002 Version 2 1998 Version 1 1993 1991

11 MSF的八个基础原理 推动开放式沟通 为共同的前景而工作 赋予小组成员权力 建立清晰的责任和共同的职责 关注交付业务价值 保持灵巧，预测变化
质量投资 学习所有的经验

12 1.推动开放式沟通 问题 “日程安排一团糟、功能不合适、到处都是系统错误，而原因就是左撇子不知道右撇子在做什么……。那么，小组之间应该如何相互沟通呢？用尽可能多的方式沟通。” 开放式沟通特点 即时 有效 形式多样 参与 包容 坦诚、直接 对事不对人

13 2.为共同的前景工作 简单的说就是大家要目标一致 怎样才叫“为共同的前景工作”？ 这个前景是大家一起制定并同意的 -都知道工作重点在哪里
团队任何一个人都能脱口说出前景并且表达一致。 -都知道工作方针是怎样的 工作中随时随刻用前景来指导工作。 -用前景来解决工作分歧

14 3.赋予小组成员权力 “在最优秀的小组里，不同的个人会在不同场合下体现出其领导能力，他们会在其专长的领域里担负起领导职责。没有哪个人是永远的领导，因为如果这样的话，这个人就无法和其他人融为一个整体，而小组的互动会因此而开始分裂。小组的结构应该是一个网络型的而不是一个层次型的。” 每个人都有不可替代的作用！ 每个人都有展示领导能力的时候！

15 4.建立清晰的责任和共同的职责 小组的每个角色对小组本身以及各自的利益相关人都是负有责任的。 每个角色对于最终解决方案的质量都负有责任。
鼓励小组成员对由他们责任的直接区域以外的工作作出评论和贡献。

16 5.关注交付业务价值 项目生产出来的软件要符合客户的需要。 项目组要充分理解客户的需求。 让客户积极参与到项目过程中。

17 6.保持灵巧，预测变化 要从思想上体会这个原则，指导实际工作。 要从过程上适应这种软件开发不确定性的特点。
软件开发具有不确定性，但是可以预测的以及是可控的。 要从思想上体会这个原则，指导实际工作。 要从过程上适应这种软件开发不确定性的特点。

18 7.质量投资 零缺陷意识 -零缺陷文档 -零缺陷开发 -零缺陷发布 全体成员同步到达零缺陷里程碑 一步一个脚印 不断追求高质量

19 8.学习所有的经验 “那些忘记过去的人肯定会重复过去（的错误）。” 捕捉和共享技术和非技术的最佳做法是不断提高和不断成功的基础。
允许小组成员从其他人的成功和失败经验中获益。 帮助小组成员再次成功。 通过检查和回顾等方式让学习制度化。

20 MSF 的模型与准则 MSF2个模型、3个准则。团队模型、过程模型；项目管理准则、风险管理准则、就绪管理准则。 20

21 MSF 的模型与准则 MSF模型准则 描 述 团队模型 组织人员，将每个角色和一个主要项目职责联系起来，用来保证实现所有的项目目标。
过程模型 通过安排时间、将过程分成一系列由里程碑标记的独立阶段来组织过程，从而创建并交付一个解决方案。 项目管理准则 保证项目管理是流水线型。 风险管理准则 预先准备好处理风险的办法。 就绪管理准则 预先确定团队针对每个项目需要的技能，提前进行准备。

22 MSF 团队模型角色群 22

23 团队模型 决策 项目管理 解决方案体系结构 流程管理 管理服务 商业价值 市场 客户代言人 产品计划 设计管理系统架构 和基础设施
技术咨询 具体实施的结构设计 应用程序开发 基础结构开发 MSF团队模型将整个团队人员分成六种核心角色，包括：程序管理角色、开发角色、测试角色、发布管理角色、 用户体验角色和产品管理角色，每种角色承担不同的职责，完成不同的任务，任务之间彼此连接连 续，从而角色之间互有沟通，这样，就加强了团队的合作，提高了工作的效率 辅助功能 国际化 用户代言人 培训/支持资料 可用性研究和测试 用户界面设计 基础设施 支持，运营，后勤 商业发布管理 测试计划 测试实施 测试报告

24 MSF按比例缩放团队模型 “大型项目要求组织实行公式化且简单有效的交流。……所有的进行简单有效交流的方法都依赖于建立各种层次，也就是建立小型的拥有与小组同样功能的工 作组，然后从这些工作组中选定一些代表来相互组合，并与管理相结合。” MSF 提倡把大型小组(那些多于十个员工的小组)分解成小型的、功能齐全的小组。这些小型小组并行工作，并经常进行同步工作。 功能小组可能被用于一个要求多种资源来适应需求的特别角色，并因此被组合在这个角色中 24

25 MSF按比例缩放团队模型 大规模管理团队关系
在组队模型中，每个角色群都由组合在一个层次结构中的一个或多个资源组成（尽管它们是尽可能的扁平）。测试人员向一个测试经理或领导汇报就是一个例 子。 覆盖在这个结构之上的是功能小组。这都是些小型的下级小组，它们把来自每个角色的一个或更多的成员组合进了一个模块组织中。然后这些小 组被赋予了一个具体的功能，并对它所有的方面负责，包括设计与计划。例如，一个特征小组可能被指定去设计和开发印刷服务。 Steve McConnell 写进 快速开发： “功能小组在授权、责任性、以及平衡上具有优越性。小组可以被灵敏的授权，因为它代 表性的包含了……每个相关的人员。小组在它的决策中包含了所有的观点，因而很难出现一个超越它的决策的基础。” “因为同样的原因，使这种小 组变得有责任。他们所有人员需要的，制定好的决策的权限。如果他们没有制定出好的决策，除了自己他们谁也无法责备。这种小组是平衡的。您不能期望开发、市 场、或者质量保证在一份产品说明书中各有一个独立的最终说辞，不过您可以从每个种类包含的一组代表性的说法中取得一个平衡。” 备注： 本图例并不是描绘组织功能小组的需求。举个例子，并不是所有的功能小组都需要用户经验角色；这些小组都是为了迎合它们的解决方案关 注的目标而按需组织的。 大规模管理团队关系 25

26 MSF按比例缩放团队模型 适合小型项目的角色组合
该图说明了组合角色的风险(由"Not Recommended"或"Unlikely symbols"标识）和促进作用(由"Possible"记号标识），不过对任何小组的做法，成功的角色共享还涉及到现实成员自身和他们带来的经验和技 能。 横排和纵排交叉处是 N 的，表示这些角色不被推荐来进行组合。因为有利益方面的冲突，除非有绝对的必要，或者关联的风险可以被关联风险的缓解与应变计划处理。很显然，这些角色的 目标在多个层次上都有冲突，这将使组队模型不稳定，并增加了组合时出现问题的可能性。角色组合并不罕见——如果小组选择小巧的组合，并积极的管理相关风 险，问题发生的几率将会降至最低。 适合小型项目的角色组合 26

27 MSF团队模型逐步升级与责任性 MSF 团队模型不是一张组织结构图
外部协调 -为了保证团队的成功，还必须和其他外部工作组相互影响、交流、以及协调。这些工作组的范围涉及顾客、用户、还有其他开发小组。 27

28 MSF MSF过程模型 项目是否可以进行资源转换，实现价值？ 部署完成 部署 构思 发布就绪认可 远景/ 范围 认可 项目是否该做？
功能 版本3 版本2 版本1 部署完成 时间 部署 构思 发布就绪认可 远景/ 范围 认可 项目是否足以稳定，可以发布？ 项目是否该做？ MSF 稳定 计划 开发 项目计划认可 范围完成 项目是否能按时，按预算完成？商业可行性是否得到验证？ 项目是否按预先的设想和目标建造？

29 MSF 构思阶段概述 目标：创建一个关于项目的目标、限定条件和解决方案的概要视图 团队的工作重点 – 确定业务问题和机会
– 确定所需的团队技能 – 收集初始需求 – 创建解决问题的方法 – 确定目标、假设和限定条件 – 建立配置与变更管理 29

30 MSF 构思阶段的里程碑和交付成果 交付成果 – 远景/范围文档 – 项目结构文档 – 初始风险评估文档 30

31 MSF 构思阶段成功要素 共同远景建立 收集概要需求（描述要做什么） 用户档案建立 解决方案概要（解决问题的概要描述）
干系人和团队要在项目动机、远景、 范围、概要、项目团队和组织结构等方面达成一致 文档记录限定条件和目标 完成初始风险评估 建立变更控制和配置管理过程 得到发起人或关键干系人的正式认可 31

32 MSF 计划阶段概述 • 目标：创建解决方案的体系结构和设计方 案、项目计划和进度表 • 团队重点 – 尽可能早地发现尽可能多的问题
– 知道项目何时收集到足够的信息以向前推进 32

33 MSF 计划阶段的里程碑和交付成果 交付成果 – 功能规格说明书 – 主项目计划 – 主项目进度表 33

34 MSF 计划阶段成功要素 技术验证 创建解决方案体系结构和设计方案 功能规格说明书 风险发现解决（风险驱动调度法） 主项目计划（WBS）
主项目进度表（自下而上估算） 成本估算 开发、测试环境建立 34

35 MSF 开发阶段概述 目标：完成功能规格说明书中所描述的功 能、组件和其他要素 • 团队主要工作 – 编写代码 – 开发基础架构
– 创建培训课程和文档 – 开发市场和销售渠道 35

36 MSF 开发阶段的里程碑和交付成果 交付成果 – 解决方案代码 – 构造版本 – 培训材料 – 文档 • 部署过程 • 运营过程
• 技术支持和疑难解答 – 营销材料 – 更新的主项目计划、进度表和风险文档 36

37 MSF 开发阶段成功要素 解决方案验证 完成所有功能 构造版本 所有元素构造完成 代码评审 测试 更新主项目计划、进度表和风险文档 37

38 MSF 稳定阶段概述 目标：提高解决方案的质量，满足 发布到生产环境的质量标准 • 团队的工作重点 – 提高解决方案的质量
– 解决准备发布时遇到的突出问题 – 实现从构造功能到提高质量的转变 – 使解决方案稳定运行 – 准备发布 38

39 MSF 稳定阶段的里程碑和交付成果 交付成果 – 试运行评审 – 可发布版本 • 源代码和可执行文件 • 脚本和安装文档
• 最终用户帮助和培训材料 • 运营文档 • 发布说明 – 测试和缺陷报告 – 项目文档 39

40 MSF 稳定阶段成功要素 提高解决方案的质量 解决准备发布时遇到的突出问题 实现从构造功能到提高质量的转变 解决方案稳定运行 准备发布
试运行 40

41 MSF 部署阶段概述 目标：把解决方案实施到生产环境之中 • 团队的工作重点 – 促进解决方案从项目团队到运营团队的顺利过渡
– 确保客户认可项目完成 41

42 MSF 部署阶段的里程碑和交付成果 交付成果 – 运营及支持信息系统 – 所有版本的文档、装载设置、配置、脚本和代码 – 项目收尾报告 42

43 MSF 部署阶段成功要素 核心技术部署 站点部署 稳定整个解决方案 向运营和技术支持的过渡 客户验收签字表示认可 调查用户满意度。 43

44 MSF 过程模型是一个迭代方法 通过把一个大项目分为几个版本将风险减至最小 44

45 按版本发布的好处 在特定版本范围内管理项目的变更和不确 定因素 • 保证功能的持续增加和完善 • 缩短交付时间
• 为团队成员设立明确而可达到的目标 • 着力解决项目问题 45

46 项目管理准则 “项目管理就是将知识、技能、工具和技术运 用于项目活动，以满足项目的要求。 •项目整合管理 •项目范围管理 •项目时间管理
•项目成本管理 •项目人力资源理 •项目沟通管理 •项目风险管理 •项目采购管理 •项目质量管理 46

47 项目管理准则 MSF 项目管理的特征 项目经理角色的大多数职责都包含在 MSF 程序管理角色群里。
某些大型的或者复杂的项目需要专门的项目经理或者项目管理小组。 项目管理可以被用来描述一个角色以及在某个领域里的技能和专长，这里要注意，项目管理不是项目经理一个人来完成的，它作为一种活动由很多人来共同完 成。 MSF 用一种分布式的小组方法来进行项目管理，通过将小组角色抽象成为一套职能职责，而不是特定的职位描述，这样可以提高责任性，并允许大范围的可伸缩性，既适用于小的项目，也适用于非常巨大和复杂的项目。 47

48 项目管理准则 MSF 使用两种类型的里程碑 • 主里程碑表示前一阶段结束，后一阶段开始 • 中间里程碑用于阶段内部，它把一项工作
分成便于管理的几部分 48

49 使用里程碑确保方向的正确性 里程碑用来计划、监控项目的进展情况并制 定主要交付成果的交付时间 • 在项目中设立里程碑有以下好处：
– 帮助同步工作成果 – 使项目团队外的人员也可以看到项目的进展情况 和质量情况 – 可在项目进行中纠正偏差 – 着重于评审项目目标和交付成果 – 增加阶段性的审批环节，只有在审核通过后，才 进入一下一个阶段 49

50 MSF 风险管理准则 MSF 风险管理过程的六个阶段是： •识别 •分析和分级 •计划和调度 •跟踪和报告 •控制 •学习
风 险识别让个体可以发现风险，进而使项目团队意识到潜在的故障。作为风险管理过程的输入，风险识别应该尽可能早的执行，并在项目的生命周期中频繁地 重复。 风险分析将风险识别过程中发现的特定项目风险估计量或数据转化为一种可被项目团队用来确定优先决策的形式。风险 排序让项目团队可以负责项目资源从而对最重要的风险进行管理。 风险计划提取风险分析中获得的信息并用其明确表达策 略、计划和工作。风险调度可以确保计划被认可并融入标准的日常项目管理进程和基础设施中，从而确保风险管理作为团队日常工作的一部分执行。 风险调度明确地利用项目计划与风险计划关联。 风险跟踪监控特定风险的状况以及它们各自工作计划中的进展情况。风险跟踪也包含 监控变化风险的概率、影响、暴露程度以及其他因素，这些变化可能改变优先级或风险计划、项目特性、资源或是进度表。风险跟踪从风险等级的角度定义风险管理 过程在项目中的可见度，这与标准业务项目管理过程任务完备化的角度恰恰相反。 风险报告确保团队、发起人和投资人明白项目风险的状态并管理 它们的计划。 风险控制是执行风险工作计划和相关现状报告的过程。风险控制也包含项目变化控制请求的初始化，而风险状况或风险 计划的更改可能导致项目特性、资源或进度表的更改。 风险学习使知识和相应项目案例及工具正式化，并在团队和企业内部以可再度 使用的形式提取知识。 注意，这些阶段属于逻辑阶段，对于任何给定的风险，您都并不需要严格地遵循这些阶段。项目团队将经常在识别-分析-计 划三步中循环往返，而仅仅周期性地进入学习这一阶段来为企业捕获知识。 从这个图表中得出的“所有项目风险都会固定地经过这些阶段”的结论是 错误的。相反地，MSF 风险管理原则鼓励每个项目在 MSF 过程模型的项目计划阶段定义风险管理过程将于何时，以何种方式发起，以及各阶段间的转化将在怎么样的环境下发生 50

51 MSF 风险管理准则 MSF 风险管理过程的六个阶段是： •识别 •分析和分级 •计划和调度 •跟踪和报告 •控制 •学习
风 险识别让个体可以发现风险，进而使项目团队意识到潜在的故障。作为风险管理过程的输入，风险识别应该尽可能早的执行，并在项目的生命周期中频繁地 重复。 风险分析将风险识别过程中发现的特定项目风险估计量或数据转化为一种可被项目团队用来确定优先决策的形式。风险 排序让项目团队可以负责项目资源从而对最重要的风险进行管理。 风险计划提取风险分析中获得的信息并用其明确表达策 略、计划和工作。风险调度可以确保计划被认可并融入标准的日常项目管理进程和基础设施中，从而确保风险管理作为团队日常工作的一部分执行。 风险调度明确地利用项目计划与风险计划关联。 风险跟踪监控特定风险的状况以及它们各自工作计划中的进展情况。风险跟踪也包含 监控变化风险的概率、影响、暴露程度以及其他因素，这些变化可能改变优先级或风险计划、项目特性、资源或是进度表。风险跟踪从风险等级的角度定义风险管理 过程在项目中的可见度，这与标准业务项目管理过程任务完备化的角度恰恰相反。 风险报告确保团队、发起人和投资人明白项目风险的状态并管理 它们的计划。 风险控制是执行风险工作计划和相关现状报告的过程。风险控制也包含项目变化控制请求的初始化，而风险状况或风险 计划的更改可能导致项目特性、资源或进度表的更改。 风险学习使知识和相应项目案例及工具正式化，并在团队和企业内部以可再度 使用的形式提取知识。 注意，这些阶段属于逻辑阶段，对于任何给定的风险，您都并不需要严格地遵循这些阶段。项目团队将经常在识别-分析-计 划三步中循环往返，而仅仅周期性地进入学习这一阶段来为企业捕获知识。 从这个图表中得出的“所有项目风险都会固定地经过这些阶段”的结论是 错误的。相反地，MSF 风险管理原则鼓励每个项目在 MSF 过程模型的项目计划阶段定义风险管理过程将于何时，以何种方式发起，以及各阶段间的转化将在怎么样的环境下发生 51

52 MSF 就绪准则 就绪管理是 MSF 中的核心准则，其最终的目标是预先确定团队针对每个项目需要的技能，提前进行准备。这一准则所采用的方法将用于对规划、构建和管理成功解决方案的知识、技 能和能力进行管理。持续的就绪管理将给企业组织带来巨大的技术架构储备，也给远期企业组织的发展带来不可估量的基础能量。就绪管理需要有规划有重点分类别 进行持续操作，随着就绪管理工作的深入，企业在项目过程中也会减少障碍，提高效率，建立越来越大的知识库。 52

53 在项目中运用MSF 过程模型 过程模型可以根据项目的不同情况进行调整 • 团队可以依据下列指导方针来决定项目需 要哪些中间里程碑：
– 由项目类型决定 – 考虑外部事件和风险 – 避免长时间没有里程碑 – 将里程碑与交付成果结合起来 – 仅使用适合项目情况的MSF 推荐的里程碑 现在在国内已经有很多MSF应用或MSF思想得到认可的实 例。比如,用友公司是内最著名的财务软件公司,以往大多是最终使用客户购买用友软件,而现在有很多系统集商来购买用友财务软件。这些集成商在用友软件的基 础上开发出更能满足不同客户的千万别的需求的产品,帮助它们达到自己的商业目的。而用友只需提供财务软件核心,让其它集成商在此基础上进行再开发。这对用 友、集成商和客户都是有利的。 53

54 利用里程碑评审项目和总结经验 里程碑评审会议 – 在客户、干系人和团队之间取得一致 – 获得对项目阶段性成果和继续向前进展的认可
• 后里程碑评审会议 – 交流团队的经验 – 改进后续阶段的工作 54

55 每个阶段中的团队分工 • 所有角色在各个阶段都要参与 • 每个角色在每个阶段都有交付成果 • 不是所有团队成员在每个阶段的工作量都相同 55

56 不同的角色在不同的阶段 起主要推动作用 56

57 MSF 各角色在不同阶段中的职能 57

58 第二部分 微软项目管理过程与模板

59 MSF过程模型特点 MSF 过程模型是从传统的软件开发瀑布模型和螺旋模型发展而来的，它把瀑布模型中基于里程碑的规划的优势与螺旋模型中增量迭代的长处结合了起来。 MSF 过程模型的基本元素是阶段和里程碑。所谓“阶段”，就是在这一段时间里团队集中精力做某一类事情，每个阶段的结束都代表了项目的进展和团队工作重心的变化。 团队用里程碑来检查工作是否结束和同步各个角色的进度，以此来确定当前阶段的目标是否已经实现。里程碑标志着每个阶段的结束，团队在此时应该引导成员转移工作的重心，并鼓励队员以新的视角来看待下一阶段的目标。

60 MSF 过程模型 项目是否可以进行资源转换，实现价值？ 部署完成 部署 构思 发布就绪认可 远景/ 范围 认可 项目是否该做？
功能 版本3 版本2 版本1 部署完成 时间 部署 构思 发布就绪认可 远景/ 范围 认可 项目是否足以稳定，可以发布？ 项目是否该做？ MSF 稳定 计划 开发 项目计划认可 范围完成 项目是否能按时，按预算完成？商业可行性是否得到验证？ 项目是否按预先的设想和目标建造？

61 过程模型 阶段0 阶段1 可重复 阶段 最后阶段 项目初建 Project Setup 计划 Plan 计划 Plan 计划 Plan
开发 Development 开发 Development 开发 Development 测试 Test 测试 Test 测试 Test 反馈 Feedback 反馈 Feedback 发布产品 Release Product

62 过程模型 阶段：Iteration （里程碑：Milestone） “阶段”用来计划和监控项目的进展，并确定主要成果的交付时间
有利于项目各单元的协同 对外提供项目进展和质量情况 不断纠正偏差 注重评审项目的目标和成果 阶段性审批，通过后才能推进到下一阶段 不断得到用户反馈

63 发布部署 主角：产品管理，销售，推广和支持
流程模板 Beta 项目起动 推荐版发布 测试编码完成 编码开始 发布 编码完成 M0： 功能定义 M1： 设计文本 和测试计划 M3： 稳定与技术预览 M2： 编码 M4： Beta M5： RC M6： RTM 早期计划 发布部署 构思 主角：市场，项目管理人员 设计 主角：项目管理人员，开发人员 编码 主角：开发人员 测试，稳固 主角：测试和发布管理人员 发布部署 主角：产品管理，销售，推广和支持

64 MSF for Agile Software Development
迭代和渐进模型 基于“情景”(Scenario-driven) 针对中小型团队的模型(大型项目利用团队协作，渐进式的演化模型) 服务需求的质量 风险控制 利用情景驱动(context-driven)测试去不断的接近成功 (based on test metric thresholds) 64

65 MSF for CMMI® Process Improvement
软件工程研究所 (SEI) 能力成熟度模型集成(CMMI® 强调流程+路径优化+正确的人) 持续的能力改进模型(CMMI:阶段式/连续式) MSF for CMMI® 帮助组织满足CMMI® level 3(KPA 7 to 14)的要求 基本覆盖21个主要的领域 为轻量级的组织机构设计的模板和文档 Elaborates on the MSF for Agile Software Development process 更多的工作项 可扩展的报告 65

66 MSF Agile vs. MSF CMMI 敏捷版——MSF Agile 强调“进化和改变” 适用于竞争性环境 依赖于人的持续改进
计划和进行的迭代 CMMI版——MSF CMMI 强调“计划和优化” 对于稳定的环境比较理想 以来于流程的改进 强调预先计划 CMMI Quality Oriented Cost Agile 66

67 第三部分 微软项目管理实务与 案例分析

68 微软EPM解决方案简介 Microsoft Office 企业项目管理（EPM）解决方案让用户能够在整个企业范围内有效管理与调整项目及其相关资源。微软专门为那些需要战略性项目组合功能、强大的团队协调功能、项目与计划管理标准化功能、集中资源管理功能以及高端分析与报表功能的企业设计了 EPM 解决方案。Project为项目及其资源信息提供了一个可集中管理的资源库，以便企业能够对其进行统一的管理与呈报。 企业项目管理解决方案由 Microsoft Office Project Professional 2007、Microsoft Office Project Web Access、Microsoft Office Project Server 2007、Microsoft Office Project Portfolio Server 2007 和 Microsoft Office Project Portfolio Web Access 等多个微软产品构建而成。

69 微软EPM解决方案架构图 微软EMP解决方案架构 企业项目管理解决方案由 Microsoft Office Project Professional 2007、Microsoft Office Project Web Access、Microsoft Office Project Server 2007、Microsoft Office Project Portfolio Server 2007 和 Microsoft Office Project Portfolio Web Access 等多个微软产品构建而成。

70 微软EPM解决方案功能模块

71 微软EPM解决方案项目管理模块

72 微软EPM解决方案生命周期管理模块

73 微软EPM解决方案功能演示 高管人员和项目监理通过项目中心管理项目

74 微软EPM解决方案功能演示 项目经理协调和管理项目

75 微软EPM解决方案功能演示 资源经理对资源分配情况进行评估

76 微软EPM解决方案功能演示 项目成员查看项目进展情况

77 微软EMP解决方案优势 借助微软企业项目管理解决方案，组织能够从战略性项目组合决策到战术性实施的整个项目生命周期中，更有效地管理和 协调从特殊项目到复杂程序的各种工作。具备以下几点主要优势： 提高企业项目管理的可见性与洞察力 提高企业在项目管理中的敏捷性 便于企业更加轻松地开展工作 新的微软企业项目管理解决方案具有可延展性与可编程性

78 Microsoft Office Project 2007实验设计
实验设计目的： 学会使用Microsoft Office Project 2007来实现项目的快速创建与执行管理。 通过熟悉Microsoft Office Project 2007这一项目管理工具，达到进一步理解项目管理领域的相关知识。

79 Microsoft Office Project 2007实验设计
实验内容： 单项目计划创建 创建项目的准备工作 运用模板向导创建项目 创建组织自定义任务 设置项目开始日期，设置期限，链接任务，创建关系，设置条件 项目日历, 任务日历 资源与成本 建立资源库 查看资源信息(资源图表、资源使用状况视图) 资源分配冲突状态分析 用Microsoft Project Professional的智能调度引擎优化资源分配 查看项目成本 项目S曲线的绘制与分析－运用Excel分析项目成本数据

80 Microsoft Office Project 2007实验设计
项目的跟踪 项目跟踪的基本知识 理解任务类型对项目更新的影响 理解更新项目的不同方法 比较基准，进度线和相关视图查看 项目进度跟踪-关键路径技术 项目成本跟踪-盈余结算表分析 项目资源跟踪-资源分配状态分析 创建基线，输入数据 视图和报表 各种视图详解（甘特图、网络图、资源分配状况等） 项目信息的提取与分类 常用报表的应用

81 Microsoft Office Project 2007实验设计
筛选器和分组技术的应用 管理器的使用 表、报告、自定义数据域 多项目文件配合使用 项目的优化 项目的风险控制 缩短项目工期 解决资源冲突 减少项目费用

82 Microsoft Office Project 2007实验设计
7. MS Project 2007与微软其他产品的结合使用 在Project 2007中如何插入Microsoft 其他软件 如何在其他软件中体现Project 资源规划、项目进度等 在Word或其他办公软件中如何向上级报告整体项目进度，如何了解下属项目变化 评价Microsoft Office Project 2007 写一篇文章，论述Microsoft Office Project 2007在实际IT项目管理中的优势和短处

83 微软项目管理案例分析 2010年1月份，微软（中国）有限公司与北京高远华信科技有限公司正式签订了为期5年的战略合作协议，本部分中的EPM案例均取自高远华信公司。

84 案例一 问题与挑战 施耐德中国总部所有IT项目希望通过一个强大的项目管理软件平台，将所有的IT项目信息进行共享，广大的项目成员能够清晰了解项目的各种知识资料，项目的各种指标信息也能 自动化的进行计算，而不是项目经理还需要手工定期的进行汇总。 解决方案： 搭建以Microsoft Office Project Server 2007为核心的EPM平台，管理所有的IT项目，制定规范的操作指南，约束大家的使用习惯和方式，定期更新EPM信息，培养正确的项目管理文化和行为。 实施效果： 在10个工作日内，完成了平台的搭建定制、培训工作，将用户原有的excel表格项目信息通报形式转化为了自动化的准确的WEB共享方式统计汇报。

85 案例二 问题与挑战 中国航天科工集团第四研究院某研究所 项目计划的执行缺乏透明； 项目的进展延误情况多见；
中国航天科工集团第四研究院某研究所  项目计划的执行缺乏透明； 项目的进展延误情况多见； 项目管理人员缺乏必要的项目管理 工具辅助项目管理效率提升 项目的各种例会无法科学预知项目 的问题 解决方案： 基于该单位已经成功运用多年的 AD环境、SharePoint环境，搭建以Microsoft Office Project Server 2007产品为核心的EPM（企业项目管理）平台；按照客户的项目管理业务流程对此平台进行个性化定制；开发分类的项目计划模版，以简化项目计划编制的速 度和质量；开发大量的项目报表，以自动化项目的各项信息汇报；进行系统改造开发以适应军工信息化分级保护的要求。 实施效果： 通过实施EPM的过程，高远华信咨询专家充分与客户项目管理人员进行交流，循序渐进的利用各种机会导入项目管理文化，普及项目管理知识，使得EPM平台的试运行以及正式运行非常顺利。

86 案例三 问题与挑战 ABB是电力和自动化技术领域的全球领导厂商，世界五百强。由于管理ABB中国所有的IT项目，所以项目数量非常大，对于各个项目进展信息的了解成为了瓶颈；每个人同时在从事多个项目，经常发生人力资源冲突的情况，对项目的执行带来非常大的影响；项目的各种文档信息得不到充分的共享。 解决方案： 搭建以Microsoft Office Project Server 2007为核心的EPM平台，将进度管理、资源管理、成本管理、问题管理、文档管理、变更管理纳入管理范畴，让广大项目经理能够快速编制项目计划，每个部 门的部门经理能够清晰的了解到目前及未来本部门人员的工作负荷情况，让广大的管理层人员通过WEB页面可以了解到项目的各种健康状况。 实施效果： 高远华信派出的专业EPM实施团队在不到2个月的时间内，帮助ABB的信息化部门实现了所有IT项目的全生命周期的可视化管理，项目的进度、成 本、评价等信息通过红绿灯的方式在项目中心区域一览无余，让各级管理层第一时间了解到项目的健康状况。 。

87 案例四 问题与挑战 上海西门子线路保护系统有限公司成立于1996年，系德国西门子公司与上海电器股份有限公司共同投资的中外合资企业。
项目计划的编制不规范，不统一，导致项目考核没有统一依据。 项目周报、月报需要项目经理花费大量时间手工编制，数据也不准确。 项目成员对于自己的工作缺乏清晰的了解。 项目经理以及项目管理办公室（PMO）对每个人在每个时期的工作得不到量化的了解和估算。 高级管理层对项目信息的了解得不到一手的准确的资料。 解决方案： 搭建以Microsoft Office Project Server 2007产品为核心的EPM平台；按照西门子线路保护公司的项目管理业务流程对此平台进行定制；开发分类的项目计划模版，以简化项目计划 编制的速度和质量；开发大量的项目报表，以自动化项目的各项信息汇报。 实施效果： 实施周期短，实施内容丰富，从根本上帮助西门子线路保护公司实现了项目管理的可视化、知识化，协作化。

88 Q & A

89 Thank you！