走进msf

1．概述 

什么是MSF?

MSF是一套大型系统开发指南,它描述了如何用组队模型、过程模型和应用模型来开发

Client/Server结构的应用程序,是在微软的工具和技术的基础上建立并开发分布式企业系统

应用的参考。

MSF的最大特性是商业化,并自始至终地体现在项目的实施过程中。所谓商

业化意味着客户的商业利益。客户投入多少,得到多少回报,客户要用到哪些最新的技术,最后

如何把项目计划(Project)变成产品(Product)直至产生效益,等等,这些都是MSF要考虑的问

题。

MSF将一个项目中不同阶段的工作人员分为六个角色,通过这六个角色,项目可以得以迅速、

完善地实施。这也体现了项目开发的六个重要质量指标,它们在全球是一致的。这六个角色

分别是:

·产品经理。他了解用户特征,尤其是商业特征,明确用户的需求以及需求的期望值。之所以

强调用户需求的期望值,是因为用户的商业化特征比较强,需求无尽,无法界定到底如何才算

需求得到了满足。而确定了需求期望值后,用户的商业目的就非常明确,实施起来也比较顺

畅。

·程序管理员。他负责制定计划,每天找出完成该计划的风险所在,排除风险,每天交付应该完

成的内容,确保计划按质、按量实施。

·用户教育。设计友好的用户界面,对用户进行培训,确保用户能够并且愿意和喜欢使用开发

出的产品。

·开发。开发者在开发前期就参与用户需求分析和项目计划制定,他最清楚具体的开发过程。

在开发期开始后,他负责进行代码开发,在每一个阶段,交付每一项内容的代码。

·测试。负责开发出的代码的测试。测试者并不是要找到每一个开发者的每一段代码的每

一个错误(bug),而是要找到代码错误之间的关系,解决最根本的错误,掌握错误的状态,从而迅

速排除错误。

·后勤。后勤人员负责将实验室的产品商品化,变成实际可以运行的产品,达到最初制定的商

业目的,取得商业效益。这项工作在以往的项目中可能比较简单,因为实验室的环境可能和实

际环境几乎一致或差别不大。而现在却不同了,实验室环境可能十分简单,而实际环境可能非

常复杂,比如分布式环境、Internet/Intranet环境等,尤其是大企业,实际环境比实验室环境复

杂得多,因而将实验室产品运用到实际环境中是一项非常重要的工作。这项工作没有完成好,

往往使整个项目前功尽弃,功亏一篑。

实施MSF

在项目实施的过程中运用MSF,其效果将是显著的,它能够将技术变成产品,由产品变成效益;

它能够帮助用户少走或不走弯路,从而更快地达到自己的商业目标。

张彤川先生告诉记者,MSF在微软的许多大客户中得以大显身手,比如:瀛海威、中国投资银

行、香港跑马场、香港汇丰银行等。目前,在全国几个大城市举办的MSF巡回讲座,其目的

在于帮助更多的国内公司的领导,尤其是大公司的领导,认识MSF这一思想和原理,并能够在

实际中运用这一思想。微软正计划或已经开始和一些大客户共同实施MSF架构,如方正、用

友等。张彤川先生笑着对记者说,尽管每一位实施MSF项目的微软顾问的收费比较高,但MSF

带来效益足可以使这笔费用微不足道。

由于我国旧的体制往往并不以商业化为主要目标或商业化目的不明确,致使现在仍抱有旧体

制思想的企业在进行项目实施时常常陷入死循环。比如,当一个开发项目即将结束时,由于技

术的发展或业务的发展,客户的需求有所变化(往往是提高了),和最初签定项目实施协议时不

同。抱有旧体制思想的客户通常是拒绝在项目结束协议上签字,而是要求开发商按照变化了

的需求继续进行开发。但是,当按照变化了需求所进行的开发结束时,需求可能又发生了变

化。于是又继续进行开发,如此死循环。而MSF却可以解开这一死循环。当开发项目结束时,

即使需求发生了变化,但仍然可以将已开发出的部分变成产品,把该产品投入商业应用,使它

产生商业效益。至于变化了的需求,则可以开发出下一个版本来满足,甚至不断地开发新版本,

以满足不断变化的需求。

MSF思想正是要解开这一旧体制造成的死循环,从而更好地利用投资,帮助客户实现自己的

商业利益。这也是微软进行MSF巡回讲座、和大公司共同实施MSF思想的主要原因之一。

张彤川先生告诉记者,微软是一个产品提供商和技术提供商,提供平台、产品和技术。而真正

的满足用户实际需求的成千上万的应用要靠合作伙伴来完成。微软提供解决方案架构

(Solution Framework),而不提供具体的解决方案(Solution)。解决方案架构是一种准则或规则,

各个领域内的合作伙伴按照这一准则,以工业化模式制定出具体的解决方案。所谓工业化模

式,是指产品几乎只需要装配一下即可。就像盖房子一样,建筑者只需要把满足一定标准的各

式各样的预制板组装起来,即可建出符合标准的房子。这种模式可以大大提高代码的利用率,

使开发商不必一切从头做起,从而提高开发效率。而MSF是这一切的协调准则。

可喜的是,现在在国内已经有很多MSF应用或MSF思想得到认可的实例。比如,用友公司是

国内最著名的财务软件公司,以往大多是最终使用客户购买用友软件,而现在有很多系统集

成商来购买用友财务软件。这些集成商在用友软件的基础上开发出更能满足不同客户的千

差万别的需求的产品,帮助它们达到自己的商业目的。而用友只需提供财务软件核心,让其它

集成商在此基础上进行再开发。这对用友、集成商和客户都是有利的。此外,其它领域的公

司也有类似情形。MSF将结出越来越多的灿烂的果实。

Admin

2．组队模型

开发大型复杂的软件项目是一项充满风险的工作。统计结果表明大型IT项目的失败比例相当高，失败有很多原因：不断变更的需求，不稳定的或不完善的需求说明书，低质量的编码，过大的应用范围，不合适的组队模式，低效的工作过程，不明确的目标等等。微软解决方案框架结构（MSF）通过其核心模型来解决这些问题。组队模型着重于解决在复杂软件工程项目中如何组建项目组、分配合适的角色、项目组的管理、职责划分和质量控制等问题。虽然组队模型是起源于软件开发过程中的规范和准则，但它也同样被成功的应用于基础信息结构设施的实现过程。

简介

开发大型复杂的软件项目是一项充满风险的工作。统计结果表明大型IT项目的失败比例相当高，失败有很多原因：不断变更的需求，不稳定的或不完善的需求说明书，低质量的编码，过大的应用范围，不合适的组队模式，低效的工作过程，不明确的目标等等。 微软解决方案框架结构（MSF）通过其核心模型来解决这些问题。组队模型着重于解决在复杂软件工程项目中如何组建项目组、分配合适的角色、项目组的管理、职责划分和质量控制等问题。虽然组队模型是起源于软件开发过程中的规范和准则，但它也同样被成功的应用于基础信息结构设施的实现过程。

2．1 MSF 组队模型

高效项目组的质量目标 高效项目组的质量目标：

满足客户的期望

在项目的限定条件下交付产品

在交付产品之前，确定并解决所有对客户和最终用户来说都很重要的问题

保证使用者知道如何使用这个产品

确保产品的平滑移交与发布

 2．2 MSF 组队模型由六个明确定义的角色组成：

开发

测试

系统实施

用户教育

产品管理

程序管理

项目组成员之间无限制的交流是一个潜在的成功因素。

除了系统实施角色外，其他角色在众多的微软产品开发组中都可以见到。对大型企业的IT机构来说，可能还有其它的用于补充项目组的被称为“支持角色”的人员，如：数据库管理员、产品质量监督员等。

 

企业基础信息设施结构实现的项目 类似与软件开发，MSF组队模型同样也可以应用于企业基础信息设施结构实现的过程。在这种情况下，“开发”这种角色的工作将包含技术评估、产品或服务的安装和配置等。

2．3同等关系的组队角色

--------------------------------------------------------------------------------

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

基于项目的大小，每个角色被分配给一个人或有人领导的一个小组。同样，一个人也可以承担多种角色。

每个小组成员都要估算他自己的工作量，估算的结果用于作为他们各自角色的项目计划参考，各个角色的项目计划又是项目总体计划的一部分。

在一个成功的项目组中，每个成员都要感觉到对产品的质量负有责任。不能出现由一个小组成员代表另一小组成员对质量负责的情况。类似地，每个小组成员都是客户利益的维护者。

--------------------------------------------------------------------------------

同等关系组队角色的特点 成功的应用同等关系的组队角色模型将有以下特点：

各个角色之间相互依赖、相互协同的工作

每个成员都有明确定义的角色和特定的任务

组长负责管理、指导和协调

每个人都关注于自己任务的执行

交流不受限制

每个人都对交付产品的质量负责

每个工作组成员都在维护客户的利益。

--------------------------------------------------------------------------------

组队模型不是组织结构图 有一个关于MSF组队模型的问题：谁是主管？

MSF组队模型定义了角色和责任，但没有定义项目组的管理模式和结构。项目组可以由一个部门经理负责管理，或根据项目的需要由几个不同的部门成员组成。组织结构图确定出谁是主管，MSF组队模型定义了工作划分和由谁负责完成该项工作。

--------------------------------------------------------------------------------

采用MSF组队模型的优点 项目组的每个成员都为产品的成功作出贡献。

建立了一种鼓励“明确、高效、参与”的企业文化。

增强所有角色的责任感。

鼓励一种面向客户的开发过程。

MSF组队模型的这些优点已经被使用这种模式的组织机构所证实，其中包括微软公司。

--------------------------------------------------------------------------------

实现MSF组队模型的条件 为在企业机构内实现“同等关系的组队模型”，企业机构必须理解以下原则：

应用“同等关系的组队模型”并不需要重新定义企业的组织机构。

每个项目组中的成员，都要感到他们的工作是同样重要和有价值的。

所有项目组中的成员（或至少要求项目组的负责人）要为项目开发的全过程作出贡献。

每个组中的成员都要对产品或服务的质量负责。

产品的质量是由客户的需求或期望确定的。

注: MSF组队模型可能由于文化背景的不同，不能被所有的组织机构或地区采用。成功的关键在于每个MSF组队角色的目标在项目组中都有人负责实现。

2．4 MSF 组队角色

产品管理

--------------------------------------------------------------------------------

产品管理的任务 产品管理负责为产品或服务确定一个方向，获取并量化用户的需求，开发、维护商务关系和商业环境，并管理客户的期望值。

这种角色的目标是确保清晰地表述客户的期望值，并使其为项目组所理解，并使功能规定与客户的业务优先级相吻合。产品管理负责“前景陈述文档”。“前景陈述”表达了要开发产品或要实现服务的关键商业目标，（例如“顾客必须要在60秒或更短的时间内完成退房手续”）。产品管理负责项目的高层次交流和协调，如商务立项、项目费用、合同谈判、演示，以及产品定位。

--------------------------------------------------------------------------------

产品管理所需的技能 产品管理这种角色的成员无须具备开发技能，但是他们应该对技术有深刻地理解并知道技术会给目标客户带来哪些潜在收益。最重要的是，产品管理这种角色应该以用户的语言说话，并具有商业领域应用的经验。目标客户中能够理解自身业务的人将是项目组产品管理角色较合适的人选。

--------------------------------------------------------------------------------

产品管理在软件开发组中所担任的角色 收集项目需求并确定其优先级

将量化后的使用者和客户的需求讲解并提交给项目小组

为产品确定方向

确保功能规定能够体现业务需求

协调项目组与外部的交流，如：

商业立项

给客户群体作演示

将功能特性集成

产品的定位与范围确定

费用和合同的谈判

管理产品中非软件元素的集成与交付（例如，参考卡片、模板等等）

推出一个合格的产品

2．5程序管理

--------------------------------------------------------------------------------

程序管理的任务 程序管理的任务是控制决策的各种因素，以保证在合适的时间推出合适的产品。同时程序管理创建功能规定文档，并将它作为如何实施产品或服务的一种决策工具。最后程序管理将面对，使产品或服务与组织标准和操作目标相一致的日常协调工作。

程序管理是一个关键的交流与协调的角色。基于前景陈述文档，程序管理勾画出并维护功能定义。程序管理负责所有与分析、定义和系统结构相关的活动。在开发人员的配合下，程序管理必须确保功能规定在现有的资源下，技术上是可以实现的。

定义项目如何与外部标准相协调，并使外部群体参与项目的审查过程。

维护与外界的技术合作与交流，这是确保开发小组不受外界干扰，并有效工作的一个关键因素。同样它也会使项目组能够发现并重用其他人的工作。

在特定发布所包含的功能完成后，对功能规定进行修改控制。

合并各个角色小组产生的项目进度，并管理主进度（每一个项目组中的成员都有义务，根据他们的职责在整个项目中安排他们自己的时间进度）。

--------------------------------------------------------------------------------

程序管理所需的技能 程序管理需要具有很强的技术能力，以与开发人员相配合作出关键的决策。他们需要理解项目体系结构的实质，他们常常是项目组中最有经验的成员。程序管理必须跟踪项目的进展。另外，程序管理还需要具有很强的交流和讲解的才能，以便更有效地进行协调和谈判。

--------------------------------------------------------------------------------

程序管理在开发组中所担任的角色 根据其他组的负责人提供的信息创建功能规定：

定义产品如何与外部软件系统及组件互操作。

执行产品规定的技术审核。

对功能规定文档进行修改控制。

在每个项目里程碑处，协调项目组的审核；如有必要对进度和功能进行调整。

跟踪项目进展并管理项目进度。

交付一个合格的产品。

2．6开发

--------------------------------------------------------------------------------

开发的任务 开发的任务是构造或实现一种满足规定和用户期望的产品或服务。

开发这种角色是用于交付一个完全服从讨论过的功能规定的系统。这种角色很重要的一个方面就是积极地参与构建功能规定的过程。与瀑布式过程模型中的开发继承功能规定的方式相反，MSF组队模型中开发组的负责人与程序管理一起工作，共同构建验证结构的演示模型，提供技术解决的方法，探索设计中的各种选择。当功能规定成为基准线后，开发角色开始承担负责开发时间计划的责任。

在软件开发的项目中，开发也负责审查测试计划。开发必须及时改正程序中的错误，对代码的质量负责。

在基础信息设施实现的项目中，软件是购买而不是开发的。开发角色的任务是提供各种选择的技术评估、构造演示环境、配置系统、并集成新的方案到现有的基础信息结构设施中去。

--------------------------------------------------------------------------------

开发所需的技能 客户机—服务器系统的开发，需要熟悉C语言编程、Microsoft Visual Basic编程、网络、通讯、数据库设计和数据库性能调整。尽管一个人不可能在所有这些技术方面都是专家，但是在一个开发组中包含所有这些方面的专长的开发人员非常重要。开发的经理通常是一个有系统结构实现经验的总体设计师，或者是一个在项目的所有技术领域里能够理解和懂得关键问题的开发人员。

--------------------------------------------------------------------------------

开发在开发组中所担任的角色 积极地参与功能规定的创建和复查。

与程序管理一起工作，构建验证概念或结构的演示模型。

创建“自下而上”的开发进度表。

审查测试计划。

开发和构建产品（代码的集成编译可以由测试来执行）。

及时地找出和修改代码错误。

交付一个高质量的产品。

 2．7测试

--------------------------------------------------------------------------------

测试的任务 测试的任务是保证产品或服务交付之前，能够发现所有存在的问题。

测试要准备测试计划、测试规定和测试的案例，这些文档用于拓宽测试范围和进行足够的可使用性测试。在软件开发的项目中，测试必须针对所有的接口，包括用户界面和API的每个方面。将新软件集成到现行系统时也必须进行测试。测试人员通常开发自动测试程序，这样开发人员在把代码提交给测试人员以前，就可以使用它们对自己的代码进行测试。

测试要管理错误跟踪数据库，并对错误报告的质量负责。错误数据库对于产生针对进度跟踪项目状态的统计报告来说，是一种重要资源。错误报告也用于确定项目进度中的、关键部分的风险。

测试这种角色必须独立于开发才是真正有效的。联系时间进度，测试需要提供产品质量稳定性的独立验证。

注 重要的是要认识到测试不仅是包含代码上的，测试还应用在功能规定、系统的性能、用户界面和实施计划上。

--------------------------------------------------------------------------------

测试所需的技能 测试组必须由一个熟悉测试过程、统计学和软件开发的人来领导。由于大多数测试组要编写自动测试程序，所以一个好的测试经理必须也是一个有经验的开发者，他必须胜任领导同样大小的一个开发项目。对于客户机—服务器系统来说，测试计划和过程可能很复杂。他们必须考虑到桌面系统的用户配置特性、网络问题、桌面系统连接问题。对于事件驱动的编程、多网络传输协议、不同的服务器、主机或者后台系统互操作问题、数据和数据库管理问题等，测试工作可能会变得更为复杂。测试组必须认识到应用配置之间复杂的相互作用。 

--------------------------------------------------------------------------------

测试在开发组中所担任的角色 开发软件测试计划、规定和测试的案例。

测试用户界面、应用程序接口。

开发和维护自动测试程序。

跟踪所有的错误和问题，保证它们在产品提交以前被解决。

构建并管理产品的集成和控制（同样也可以由开发来完成）。

提供给开发组与产品质量、进度和风险相关的测试衡量数据。

交付一个高质量的产品。

--------------------------------------------------------------------------------

测试对比质量保证 测试与质量保证有着重要的区别：测试针对一个项目，包含详细的技术工作，它是项目组的一个核心角色。质量保证通常是公司的一个职能部门，它在一个负责企业质量和标准实施和监督的人领导下工作。质量保证也负责在不同的项目组之间共享最好的实践经验。

2．8用户教育

--------------------------------------------------------------------------------

用户教育的任务 用户教育的任务是通过方案演示和系统培训，最大可能性地使系统的使用者得到相关产品和服务的价值。用户教育的第二个任务是通过使产品更容易理解和使用，降低系统技术支持的费用。

作为使用者利益的倡导者, 用户教育参与系统和用户界面原型的设计和构造，也包括程序的安装过程。用户教育也开发伴随系统的打印文档或电子联机文档。如果需要的话，用户教育还要准备并交付系统的培训材料。

通过推动和参予产品的可使用性测试，用户教育与程序管理在设计用户界面的过程中有着紧密的联系。用户教育也同程序管理和开发一起工作，确保产品的范围、设计的任何改动，反映在文档的内容中，并相应的调整培训内容。

--------------------------------------------------------------------------------

用户教育所需的技能 用户教育必须熟悉用于编写产品打印文档和联机帮助的工具。他们必须能够理解并实现项目要求的系统方案演示。这包括对现有系统和未来系统的分析，帮助有效地做演示系统的设计。

因为培训是最终产品或服务的一个组成部分，用户教育也必须胜任教学和教学设计的工作。

--------------------------------------------------------------------------------

用户教育在开发组中所担任的角色 设计和开发系统的展示手段，如联机帮助、工作指南、智能帮手等。

进行使用者分析。

编写用户手册。

设计和开发展示、宣传和评估的方法。

参与产品使用性测试。

创建培训计划和相关材料、环境。

培训用户。

交付一个高质量的产品。

注 演示方案在任何产品中都是非常重要的因素。因此在项目初期阶段，用户教育这个角色就必须紧密地加入到项目组工作中去。

2．9系统实施

--------------------------------------------------------------------------------

系统实施的任务 系统实施的任务是确保产品平稳地过渡、安装和移交到产品操作和技术支持组手中。

--------------------------------------------------------------------------------

系统实施在软件开发组中所担任的角色 确保产品从开发到使用操作的平稳移交。

开发系统操作相关的过渡、安装和技术支持计划。

与开发经理一起工作，把系统初始化需要装载的数据打包，便于系统的安装和管理。

与日常操作人员协调工作，考虑：

系统的日常管理，包括局域网和服务器的管理。

灾难恢复计划。

热线技术支持。

用户注册和帐户管理。

系统安装和故障检修。

跟踪系统特性增强的要求和系统故障记录的情况。

适合的软件和文档版本控制策略

交付一个高质量的产品。

--------------------------------------------------------------------------------

项目管理 MSF组队模型不是一张组织机构图，但是大多数业务都要设立一个对开发的产品或服务负有组织责任的“项目经理”。这个经理和MSF组队角色中每组的组长一起工作，共同构成一个项目管理组。通常根据企业的组织结构，项目经理可能是使用系统的商务部门主管或信息电脑主管。项目经理与组队模型中各角色的负责人一起共同承担项目中应用MSF组队模型和过程模型的责任，完成时间进度和资源的安排、风险估计和计划跟踪、监控等等。项目经理是项目的维护者，他将帮助开发小组得到获得成功所需要的资源。但是项目的日常管理工作是各个角色组组长们的责任：

所有的组长都要参与功能规定文档的讨论，对功能规定基准线的任何改变建议都必须为全体组长所接收。

不再是自顶向下强制性地估计出时间表，而是每个主要成员贡献出自己的时间进度估计，共同组成总体的时间表。

作为项目的推进者，每种角色的组长都有责任评估风险，并参与项目决策、权衡的决定。

--------------------------------------------------------------------------------

支持的角色 有些项目或业务可能需要其它的专业人员来扩展组队中的角色。这些辅助支持的角色可能包括：

系统结构设计人员

系统使用性专家

用户接口设计者

科学研究人员

数据库管理员

2．10小组模式

--------------------------------------------------------------------------------

小组模式 MSF组队模型不同于其它的组队方法，非常重要的一点是MSF提倡使用小的工作组。在开发复杂的技术产品时, 大规模的项目组需要非常多的“过程开销”来满足交流的需要。同样项目组应该在同一个地理位置上，智力产品的开发极大地依赖于组内成员之间的高效交流。如果测试组在一个地方，而开发组在另一个地方就很难取得成功。如果用户教育不接近程序管理和开发，那么系统用户教育工作的质量也将得到反向的影响。

MSF组队模型是一个同等关系的组队模型，项目组中的每个人都对产品质量负相同的责任。同样当项目组负责人没有获得作出影响他们成功或失败的关键决定的权力时，项目组也会失败。在软件开发项目中，同等关系的概念也被应用到开发人员/测试人员的比例上。

微软公司中多数开发组在项目开始时，开发人员与测试人员的比例就是1:1。而其他外部的许多项目也许只需要2:1或者3:1的比例（开发人员：测试人员），在开发包含多种复杂接口的复杂的客户机/服务器系统时，开始前的全职测试队伍也要考虑在内。

最后MSF的组队模型假设项目组有权作出获得成功的相应决策。当一个小组人数多于六人的时候，将会有多个人被赋与某些角色。他们可以被组织成共享一个角色的功能小组。

--------------------------------------------------------------------------------

在大型项目中的小组工作模式 大多数情况下每个功能小组（如开发，测试或用户教育）的人数应该在三至七人之间。如果因为问题的复杂性，任意一个角色需要更大的组时，程序管理和开发应该将把问题分解成较小的、容易管理的部分。在微软公司强调模块化、结构化和规定的接口，不仅仅因为它们是好的实践经验，而且也因为它们能使项目更有效地进行管理，从而降低风险。

跨功能的工作小组可以为整个项目的一个子集工作，就象是为独立的产品工作一样，这些小组成为组件小组。

在基础信息结构设施实现的项目中，组件小组可以体现为在不同的地理位置上进行系统实现和产品装配的工作小组。

--------------------------------------------------------------------------------

组件工作组 组件小组通常包含一个程序经理、多个开发人员、测试人员和用户教育人员，他们对开发一个特定产品的功能集负责。每个组件小组都有自己的功能定义和时间进度表，并且严格地执行这个时间进度表，以交付一个完整的产品。如果可能整个组件小组应该在相同的办公地点工作，这样能便于交流和解决与他们工作相关的问题。

大型项目可以从这种模式中受益。当一个项目组被划分成许多组件小组时，组件小组中的成员也是大的职能组的一部分--如开发和测试，这些大的职能组可以共享开发技能和知识、通用的工具和资源。

 

在小项目中的小组工作模式 每个项目中决定如何构造一个项目开发组，是规划项目过程的一个组成部分。上面描述的六种角色反映出在一个项目组中必须具备的六种职责。然而软件开发准则并不是说，在项目组中必须要有六个成员。在有些情况下，一个小组成员可以承担两个或更多的角色，而这种情况一旦出现，就要认真考虑这些角色安排在这个人身上是否必要。

 

组队成功的因素 任何组队方式的成功，都可以由以下的因素体现出来：

有经验的负责人

自我激励的组队成员

组队成员在同一个地理位置

每个组队成员都有权作出决定

制定明确的目标

所有组队成员都胜任自己的工作

--------------------------------------------------------------------------------

小组模式的优点 组织、分配项目的人力资源为多个小组，具有以下几个确保项目成功的主要优点：

降低交流阻塞

降低过程开销

降低管理的费用

更快地进行实现

高质量的产品

2．11外部的协调

--------------------------------------------------------------------------------

项目组外的工作组 产品管理、程序管理、测试、用户教育和系统实施角色都具有重要的外部协调责任，这些责任包括与下列人员的协调：

商务或项目管理

使用者

系统操作和支持

系统标准制定

前台帮助支持

企业总体信息结构策略

质量保证标准制订

3过程模型

在微软解决方案框架结构的词汇定义中，框架（framework）指根据实际问题的映射模型，开发出的应用程序组合。根据当前问题的实际情况和队中成员的技能水平等，在项目进展过程中作适当的调整非常必要。MSF过程模型包含四个主要的里程碑，它们是前景/范围认可（Vision/Scope Approved）里程碑、项目设计认可（Project Plan Approved）里程碑、范围完成/第一次应用（Scope Complete/First Use）里程碑和系统发布（Release）里程碑。这四个里程碑是客户与项目组之间重要的设计、评估和协调的同步点。

3．1MSF过程模型

--------------------------------------------------------------------------------

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

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

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

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

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

 

这四个里程碑是客户与项目组之间重要的设计、评估及协调的时间点。这些里程碑上交付的内容在里程碑代表的阶段结束后，被置于一种可变控制的状态下。可变控制是一种从需要改变到最终稳定的文档或代码，并获得一致同意的过程。这些交付的内容必须被置于可变控制状态下，保证整个项目组在共同的假设、指南和目标基准线情况下工作。

--------------------------------------------------------------------------------

过程模型的定义 过程模型描述的是系统开发的生命周期内各种顺序进行的活动。

3．2MSF过程模型的特点

--------------------------------------------------------------------------------

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

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

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

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

--------------------------------------------------------------------------------

内部的里程碑 除非交付的整体时间进度少于三个月，否则仅有四个里程碑的项目计划并不能够提供对一个重要项目的控制。在MSF过程模型中，每个组队角色的负责人要在一起讨论和承诺内部的里程碑。通过这种方法达到整个项目组定期了解项目进展中存在问题的目标。

这些内部的里程碑帮助逐渐的构建主要的外部里程碑，它是MSF过程模型的一个关键特色。许多软件开发项目失败的原因是它们没有足够的项目范围的定义。当项目范围太大时，这些项目就象被“黑洞”吸引住了一样，项目开发工作进展的过程中永远没有可见的进展。在一个大的或复杂的项目开始的时候，确实没有办法精确了解真正的项目范围，通过规划和设计的过程逐渐减少了初始范围中不能完成的内容，所以很难有保证使项目完全按计划进行。就象艾森豪威尔说过的话“没有根据计划打赢的战役，但没有战役是在没有计划的情况下打赢的。”

为解决这种局面的方法就是设置经常的检查点，使项目的范围根据用于构建和测试产品的新信息不断地进行重新评估。这样会发现新的或正在发展中的风险，在这些风险失去控制前就能够进行处理。尽早地了解项目存在的重要问题，能够提供给项目组更好的控制项目范围中存在的问题和影响发布日期的风险的能力。

在软件开发项目的开发过程中，内部里程碑是一系列定义明确的功能集代码发布的时间点。每一个这样的发布都将以一个完整产品的发布来看待，每个发布都要经过测试、排错的完整过程。这种过程能够稳定代码，并提供给项目组了解项目进展过程和预定时间进度规划之间关系的可靠信息。在这些内部里程碑上所有的错误被修复非常重要，不能修复的错误代表着对于不明确的范围而做的不完整的工作，这将会造成对任何时间进度估计可靠性的影响。

3．3过程模型

--------------------------------------------------------------------------------

框架对比方法论 在MSF的解释中，框架是由根据反映实际存在问题的模型构建的应用组成的。根据目前手上的问题，项目组成员的技能等做作适当的改变通常是必要的。

方法存在于过程之中，它是针对完成某项任务的详细描述。方法论是一种包含一整套预先规定好的方法的过程。方法论可能会适合或不适合眼前的项目，它们往往具备多于必需的过程。

应用MSF参考模型较传统的方法论比较，提供了更多的弹性。

--------------------------------------------------------------------------------

瀑布式过程模型 在传统的阶段模型中，如软件开发生命周期方法--Software Development Life Cycle (SDLC)，阶段的定义暗示着每种工作的集合必须完成后，下一个阶段才能开始。任务驱动的开发生命周期通常导致具有以下特点的瀑布式的过程模型：

在项目或产品的生命周期内，不同的工作组处理不同阶段的任务。

每个阶段的工作必须详细记录下来，以保证新的工作组能够接管旧工作组离开后的全部工作。

关键的决定必须尽早地确定。

测试仅仅发生在项目快要结束的时候。

在软件开发过程中，组队有效工作的一个关键因素是组队成员间是否能够有效的交流。当不同的工作组管理工作过程的不同部分时，交流的手段被严格地限制在记录文档上，写作和阅读这样文档所花费的时间非常昂贵。在整个过程中重要的信息可能已经丢失或省略，决策的许多内容不能很好地交流。随着项目的一个个连续的过程，项目组距离在项目最初阶段获得的客户需求越来越远。

使用了瀑布式过程模型的大型复杂项目，在时间进度和质量上隐含着许多不确定的因素。开发组可能很长时间内在黑暗中摸索前进，没有任何真正对进展的评估，问题隐藏在代码中。结果导致重要的错误往往在项目即将结束时，才呈现在大家的面前，而这时的修复错误的费用将会最高，这些错误对产品发布的时间影响最大。

最后，瀑布式的过程模型侧重于将精力集中在客户的初始需求上，而不是集中在技术发展能够为使用者提供更佳能力的前景上。这似乎没有什么，但认识到任何方案的最终质量可能依靠最终用户的想象不到的内容，这一点非常重要。一个高质量的解决方案是在明确了解企业商业需要的前提下，选择合适的技术加以匹配的、一系列确定的前景定义的结果。良好的过程模型能够管理超出客户明确定义的使用者需求集合。

--------------------------------------------------------------------------------

存在的问题 开发智力和知识产品会面对特别的挑战。创造性工作从本质上来看更难预料，更难以按时间进度进行。与大多数商业过程不同，高压控制的方法论可能会抑制创造力，产生不良的结果。

相反走另一个极端，拥有太多自由并没有明确责任的过程将会带来其他问题。一个工作组可能失去对重要工作的关注力，而更多地从事他们认为能发挥灵感的项目工作。有时这样做是有益的，但如果这些有创造力的工作总是偏离最重要的目标，项目就会走入歧途。所以一个好的过程应该包含经常的里程碑，来保证项目组集中注意力于正确的任务上。

MSF过程模型与MSF组队模型结合在一起，被设计成为能够最大的提供创造力和项目注意力的模型。

3．4过程模型中的里程碑

前景/范围核准里程碑

--------------------------------------------------------------------------------

定义 前景/范围核准里程碑是客户和项目组就项目的前景和范围达成一致的机会。 

--------------------------------------------------------------------------------

 

前景对比范围 确定前景和范围是两种对立的活动，但却都是一个成功项目需要的两种活动。前景是对方案是什么的一种扩展观点。范围定义了在当前项目的条件限制下，前景中的哪个部分可以被实现。

--------------------------------------------------------------------------------

交付的内容 前景陈述文档是在组队角色其它成员提供信息的前提下，由产品管理角色组共同创建的。

设计目标文档提供了对产品范围的看法，它可以由程序管理或产品管理来创建。这份文档应该确定在功能规定设计过程开始前，需要解决的问题和征求的意见。

风险评估是随着项目的进展过程更新的动态文档。这个文档确定了可能影响项目进展过程的、将要到来的技术和组织机构上的问题。

项目组织结构文档定义了项目组的管理结构，它勾画出向项目设计认可里程碑前进的结构。

3．5项目设计认可里程碑

--------------------------------------------------------------------------------

定义 项目设计认可里程碑是客户和项目组就交付的内容、构建的优先级和期望值达成一致意见的重要机会。它提供了重新评估风险和重新验证早期对时间进度和资源使用估计的机会。

项目组的每一种角色都提供一份计划和时间进度文档，用于描述如何构建功能规定中的产品。项目计划精炼了前景/范围文档中客户和项目组达成一致意见的部分。所以一份好的项目设计和计划是：

从商业整体目标、使用者分类和每类使用者期望执行的活动中得到的。

将客户的期望分类成一系列的逻辑服务：用户服务、业务规则服务和数据服务。这些服务统称系统的逻辑结构。

明确定义界面设计、功能接口、数据需求、帮助系统和培训过渡活动等。

定义外部接口、交互性目标、性能指标和其它应用到解决方案上的假设和限制。

反映组队角色所有成员一致的承诺。

控制内部的时间进度和外部交流。

 

交付的内容 功能规定描述了交付的产品具有什么样的功能，它是这个里程碑上最重要的交付。

风险评估是由项目组的组长们根据已知的问题不断复查和更新的。

项目计划是每种角色计划的集合。根据功能规定中的任务，将其分组成主要的内部里程碑。项目计划的内容中包括方法、依赖条件、假设、预算和费用信息。

项目时间进度由每种组队角色的时间进度合并而成，所有角色的时间进度都基于开发的时间进度。

3．6范围完成/第一次使用里程碑

--------------------------------------------------------------------------------

定义 当进入全部产品的第一个beta版时，就来到了范围完成/第一次使用里程碑。这个版本的发布紧接着代码的完成和软件开发项目中的一系列测试活动。范围完成/第一次使用允许使用者评估产品，确定需要强调的遗留问题。同样它也是产品的第一次过渡和支持操作过程的测试阶段。 

 

 

交付的内容 这个里程碑上交付的主要内容是全功能的代码，这些代码足够稳定可以用于Beta测试。

根据已知的问题，由各种角色的组长复查并更新风险评估。

由用户教育组设计的所有产品演示辅助方案和演示方案原型。

测试规定文档给出了与代码相关的各种测试的各个方面，并定义了特定领域的测试需求。

测试的案例描述出如何测试某一方面的代码，满足测试规定的要求。

在项目设计核准里程碑上给出的可变控制的、基于版本的功能规定，所有的改变都应该反映在功能规定中。

根据风险和已知的变化，复查和更新的时间进度安排。

3．7发布里程碑

　

--------------------------------------------------------------------------------

定义 当产品或服务发布、移交给系统支持和操作组时，就到达了发布里程碑。 

 

交付的内容 可执行代码

发布的注释

不同版本的原代码

培训手册、文档记录和演示辅助工具

问题和错误数据库

安装的平台和工具

软件/数据的安装程序和转换迁移工具 

3．8基于里程碑的方法

--------------------------------------------------------------------------------

为什么是四个里程碑？ MSF过程模型中的四个里程碑对应了项目开发的四个方面，当客户和项目组重新定位关系时，这四个里程碑同样代表了一个项目中四个正式的时间点。每个里程碑上交付的内容都是根据它们具有外部可见性而选择的。

基于里程碑的方法是一种重要的设计、评估和协调客户与项目组之间关系的过程。

--------------------------------------------------------------------------------

基于里程碑方法的特点 外部可见性

MSF过程模型中的主要里程碑是整个项目组同步他们交付的内容，满足客户期望的时间点。项目设计和交付的内容可能会根据项目结果不同而不同。当项目开始时不可能了解所有的事情，是项目开发过程中不可避免的。

里程碑是复查点，而不是冻结点

尽管可以通过选择一个特别晚的产品发布日期，达到完整预测项目的目的，但结果几乎所有这样做项目的费用都很高。MSF过程模型中的四个里程碑允许客户和项目组重新确认，或调整项目的范围和使用者的期望。

目标驱动的方法

里程碑上交付的内容包含了每一个阶段的目标。

明确的交流

组队成员间明确的交流是项目成功的潜在因素。

3．9管理风险

--------------------------------------------------------------------------------

风险评估 因为在项目计划时不可能了解所有发生的事情，所以对于开发组来说确定风险就成为一个关键的成功因素。开发和稳定阶段必须使用风险评估的手段，作为时间进度安排的基本设计规划假设。

--------------------------------------------------------------------------------

风险控制的时间进度 风险控制的时间进度安排是指在项目中风险程度高的部分优先开发的方法。无论是软件开发项目还是基础信息设施实现项目，风险控制的时间进度安排都很重要。

 

风险控制的时间进度安排的好处 鼓励尽早的建立体现概念理解的原型

确定何时完成何种功能特色

根据技术和业务的风险，对工作任务进行优先级划分

在每个里程碑上进行风险复查

风险控制的时间进度安排的一个优势是，在高风险的部分需要比原计划更多的时间时，可以提供更灵活的响应时间。

--------------------------------------------------------------------------------

风险控制的时间进度安排的实现方法 项目组和客户对如下风险的优先级达成一致：

技术风险 - 保证潜在风险的功能尽早完成

商业业务风险 - 保证对商业业务非常重要的那些功能被强调

开发的时间进度将包含一个或多个内部发布

和最终发布一样，每个内部发布中都包含发布的管理和测试。

--------------------------------------------------------------------------------

降低风险 SDD鼓励在到达项目设计认可里程碑前，开发验证概念的模型和原型，这将降低不好的时间进度估计带来的风险，避免项目的失败。

--------------------------------------------------------------------------------

优先级划分的时间进度安排的优点 开发人员积极地工作以满足规定的时间进度，而不是延伸开发工作，以填充考虑风险因素在内工作时间。

错过进度安排中的里程碑，将作为早期的警报提供给项目管理人员，从而作出调整和权衡的准确决定。

客户对项目中出现风险的地方有明确的理解，因此他们的期望能够更贴近实际，更有生产价值。

3．10版本发布

--------------------------------------------------------------------------------

综述 版本发布的概念是过程模型的一个重要部分。它能够帮助项目组响应功能、时间进度和风险等方面的变化，它同样也确立了对版本一这个基准线不断增强的阶段。

MSF过程模型鼓励项目组将正在开发中的项目，想象成为一个产品，将新特色的开发和旧特色的维护作为不同版本的发布。这种概念会影响如何设定期望，以及整个项目如何设计、规划和管理。

--------------------------------------------------------------------------------

定义 第一个版本的发布交付了一系列核心特色。随后的版本发布逐渐增加新的特色，直到完成了产品的全部前景和期望。 

 

不同的版本发布不一定需要前后衔接（也就是版本1发布后，版本2才开始）。当项目组成熟后，他们通常会采用重叠的发布方式（在版本1发布前版本2就开始了）。

--------------------------------------------------------------------------------

需要一个跟踪的系统 管理不同版本发布的过程需要一个跟踪系统。这个系统应该包括记录：

排除在当前版本范围之外的、分析设计过程中提出的想法。

在功能规定中确定各种特色的优先级，能够帮助开发组将注意力集中在高优先级的功能特色上。

在当前版本中存在的问题和一些不重要的错误，可以按优先级划分后在下一次发布中解决。

--------------------------------------------------------------------------------

版本发布的优点 版本发布实现方法的主要优点是：

在项目的范围内管理不确定的因素和变化

为项目组所有成员确定明确的和有激励性的目标

强制结束项目中的问题

鼓励连续的和不断补充的功能特色交付

促使更短的时间内交付

3．11质量优化

--------------------------------------------------------------------------------

确定的发布时间想法 一个确定的发布时间想法的实现需要在范围、时间进度和可靠性三个方面作出权衡。

不是每个项目都可以用时间来控制。

不是每个项目都可以用功能特色来控制。

不是每个项目都需要没有任何错误的解决方案。

--------------------------------------------------------------------------------

作出权衡 当一个产品在开发时，在功能特色（范围）、时间进度和错误修复三个方面作出权衡通常是不可避免的。使用不断补充的系统或产品发布方法，允许根据客户的要求作出权衡，实现这些目标间的权衡。当客户的期望满足或超出后，产品质量目标就达到了。

--------------------------------------------------------------------------------

范围的调整 大多数的项目会从确定的发布时间想法中受益。如果发布的时间不断推迟，项目组将很难具有效率。多数情况下，最好一点一点的调整项目的范围，而不是改变发布的时间。版本发布允许项目组在应用项目范围上更具有弹性，而且具有更强的能力提高产品或服务的质量。