MSF(Microsoft Solution Framwork) 培训后感
今天上课讲了MSF (微软项目工作流) 培训.虽然是短短的一个上午的互动讲解,但是还是学习到很多的东西.至少站在了一个管理者的角度而不是一个开发人员的角度去看待一个要开发的项目过程了.(呵呵,以后有机会做开发管理不错)
微软对这个开发的模式大概定义了一个框架.按项目中人员的角色不同,划分了6种不同的角色.为了使一个项目取得成功，必须实现六个关键的质量目标，这种理念是 MSF 的基础。这些质量目标驱动小组并定义了组队模型。虽然整个小组都对项目成功与否负责，组队模型还是将六个质量目标和分离的角色群联系起来以确保义务分明和中心明确。
组队模型的六个角色群 － 产品管理、程序管理、开发、测试、用户体验以及发布管理 － 定义了确定职能领域以及和他们相关联的职责的通用方式。角色群常常仅仅被看作多个角色。无论那一种解释，这个概念是相同的：解决方案框架和组队模型是可伸缩的，以满足构建一个特别的解决方案的需要。一个角色或是一个角色群，可能包含一个人员或许多人员，这依赖于一个项目的大小和复杂程度，依赖于为完成功能区内的职责而需要具备的各项技能。
| 角色群 | 目标 | 职能领域 | 职责 |
|
产品管理 |
满足客户 |
市场开发 业务价值 客户拥护 产品计划 |
作为客户的拥护者 驱动共同的项目和方案设想 管理客户需求说明 开发和维护业务案例 管理客户期望 驱动产品特征、日程表、资源权衡决策 管理市场开发、产品宣传和公共关系 开发、维护和执行交流计划 |
|
程序经理 |
交付满足项目约束的解决方案 |
项目管理 解决方案体系结构 过程保证 管理服务 |
驱动开发过程以期按时的交付产品 管理产品规格说明书 － 首席项目构架师 促进小组内部的交流和商议 维护项目日程表和报告项目状态 驱使关键的权衡决策的实现 开发、维护和执行项目总规划和日程表 驱使和管理风险评估和风险管理 |
|
开发 |
根据规格说明创建解决方案 |
技术咨询 实现的构架和设计 应用程序开发 基础结构开发 |
指定物理设计的特征 估算完成每个特征所需的时间和精力 构建每个特征并监督其实现 准备部署时使用的产品 为小组提供技术主题的专门知识 |
|
测试 |
在所有产品质量事宜被识别并处理后进行发布 |
测试规划 测试工程 测试报告 |
确保了解所有问题 决定测试策略和制定计划 执行测试 |
|
用户体验 |
提高用户效率 |
技术交流 培训 可用性 用户界面设计 国际化 易用性 |
为项目小组充当用户拥护的角色 管理用户需求说明 设计和开发性能支持系统 驱动可用性和用户性能增效的权衡决策 为用户提供帮助特点和帮助文档的规格说明书 开展和提供用户培训 |
|
发布经理 |
进行平滑的部署及日常运行 |
基础结构 支持 操作 业务发布管理 |
作为各种操作、支持与交付渠道的拥护者 管理所得 管理产品部署 驱使可用性和可支持性权衡决策 管理各种操作、支持和交付渠道之间的关系 为项目小组提供后勤支持 |
产品管理角色群的关键目标是满足客户。小组必须让项目满足客户的各种需求，以实现成功。然而，首先要做的是清楚的确定和了解客户！在某些案例中，客户要求的解决方案和特性集将与项目支持和投资商的要求不同。因此小组必须进行清晰区别和需求分析，提出使双方都获益的因素。只有这样，定制和满足期望的职责才能够被指派到恰当的职能领域内。有可能项目只实现了预算和时间的目标而没有满足客户的需要，那么这个项目仍是不成功的。
MSF 组队模型为每个角色群规定了不同的职能领域以便更为精细的定义一套职责，角色通过各项职责的履行形成一套常用技能集。
为了实现满足客户的目标，产品管理角色群要求有多个职能领域：产品规划、业务价值、客户拥护和市场开发。
职能领域
市场开发
| • |
驱动销售和影响目标客户的公共关系讯息 |
| • |
高度区别化，使解决方案在竞争获得优势 |
| • |
通过零售商配销使目标客户能够容易获得产品 |
| • |
提供支持，使客户在购买和使用解决方案时有肯定的体验 |
业务价值
| • |
为项目定义和维护业务解释 |
| • |
定义和评价业务价值实现 |
客户拥护
| • |
驱动共同的项目和解决方案设想 |
| • |
管理客户期望和沟通 |
产品规划
| • |
收集、分析客户和业务需求并按优先级排序 |
| • |
执行市场研究、市场调查和竞争情报与分析 |
| • |
确定业务效绩评价与成功标准 |
| • |
确定多版本发布计划 |
市场开发
市场开发是筹划宣传、销售和配销一个产品、解决方案或服务的过程或技术。市场开发包括几个方面：启动市场、维持市场与公共关系。在一个解决方案生命周期的进程中，市场开发的中心将发生转移。了解您的解决方案在生命周期中的市场定位对执行适当的行动是至关重要的。
业务价值
在业务价值职能领域内，产品管理为客户、业务决策制定者 (BDM) 提供 他们所要求的简明的预测方法 以判断花费在一项 IT 解决方案上的投资对业务活动所带来的财务上和操作上的回报。
为有效的提供一个可用的解决方案，产品管理必须了解客户的业务活动、各种成功因素和关键工作指标。可以将获得这些知识的过程定义为业务价值评定或关键性成功因素辨识。很明显，了解使客户获得成功的方式有助于确定和提出恰当的解决方案。随着规律性的渐增，进行 IT 投资需要进行深入细致的调查，许多 IT 相关的解决方案都需要在项目停止前进行财务评议。通过进行客观的支出回报分析，满足客户的可能性将增加。财务结果的计算完善了进行 IT 投资的业务解决方案的开发。
客户拥护
这一职能领域包括了高级别交流和客户期望管理的职责。高级别交流包括了公共关系、高级管理／客户简报、市场推广、演示和产品启动。一旦项目设想被确定，期望管理将成为产品管理的关键角色。期望管理被认为是首要的角色，因为它可能决定成败。
有效进行期望管理的重要性可以用例子来描述，假如小组预期交付给用户 10 个产品特性（数据是随便给出的）。如果小组实际只交付了 2 个产品特性而不是客户所期望的所有 10 个，那么这个项目无论对客户还是对小组来说都是失败的。
然而，如果产品管理在特性开发和产品研发期间与客户维持好持续的双向交流，客户期望将得以实现而保证最后的成功。产品管理可以包括让客户参与权衡决策制定过程以及告知客户不断变化的风险和其他难题。与之前的情形不同，客户能够评估开发状态并且同意小组在指定时间能交付所有的 10 个产品特性是不现实的，而只交付了 2 个却是可以接受的。在这种情形下，交付 2 个产品特性现在符合了客户的期望并且双方都会认为这个项目是成功的。
产品规划
产品规划确定了为解决方案的多个版本所设定的要求和特性。产品规划的目标是使程序经理或开发人员尽可能以最少的时间更容易地理解一个解决方案的要求。首先，它要求完全理解解决方案的当前要求 － 业务需求是什么，客户如何使用该解决方案，支持的要点有什么以及有哪些可用的供选择的方案。其次，检查那些为使用该解决方案的客户实现增值的特性，例如实现新业务内容的入口、与其他系统的集成、更优良的工作效率、从其他解决方案上升级、减少支持费用等等。以这些知识为基础，产品规划员能够推荐出指派给每个解决方案版本的特别的特性并且为这些特性按优先级进行排序。
产品规划的核心是研究和分析。了解客户和业务的需求以及竞争状况，并给予研究和分析恰当的关注。这将防止在解决方案中加入不必要的特性。
程序管理角色群
程序管理角色的中心是实现在各类项目约束内交付解决方案的目标。可以将其看做确保项目出资人满意项目成果的过程。为实现这一目标，程序管理控制和驱动工作日程表、特征定制和项目预算。程序管理确保了在适合的时间交付出适合的解决方案，确保了在整个项目进程中理解和管理项目出资人的期望。以下是被选定的职能领域的描述：
程序管理
| • |
跟踪和管理预算。 |
| • |
管理总的项目工作日程表。 |
| • |
驱动风险管理进程。 |
| • |
促进小组内部交流和商议。 |
| • |
跟踪项目进度和管理项目状态报告。 |
| • |
管理资源配置。 |
解决方案体系结构
| • |
驱动全面的解决方案设计。 |
| • |
管理功能规范说明。 |
| • |
管理方案功能范围和各类关键权衡决策。 |
过程保证
| • |
驱动进程质量保证。 |
| • |
定义和推荐改进。 |
行政服务
| • |
实现项目管理进程，支持小组领导使用它们 |
| • |
提供一套行政服务，支持有效的小组工作 |
项目管理
作为项目日程的控制者，项目管理收集所有小组日程，确认这些日程，并将他们整合到总日程表中。总日程表被跟踪记录并报告给小组和项目出资者。
作为项目预算的控制者，项目管理通过从小组中所有角色收集资源需求促进项目预算的建立。项目管理必须理解和赞同所有的资源决策（硬件、软件以及人员）并且跟踪实际开支。小组和项目出资人都应收到该状态报告
此外，项目管理还协调各种资源，促进小组交流，帮助驱动关键性决策
解决方案体系结构
解决方案体系结构是程序管理角色群的职能领域，它对解决方案的逻辑设计和功能规范负责。解决方案体系结构专注于确保一个解决方案能够被指定的用户使用，以达到指定的有效性、效率、满意度目标。
解决方案架构师的责任包括：
| • |
促进解决方案的总体设计。 |
| • |
管理功能规范。 |
| • |
管理解决方案范围和关键性取舍决策。 |
拥有着逻辑设计的解决方案体系结构提供了解决方案的业务部分（像概念设计中产品管理的描述）和解决方案的技术部分（像物理设计中开发的描述）之间的至关重要的连接。解决方案体系结构扮演了功能规范管理人的角色。它促使小组与它们的其它角色的需求一起就解决方案的内容和设计达成一致，并证明已经被项目风险投资者同意的方法是正确的。它还对支持需求的功能的可追踪性负责（并最终完善业务价值），因此所有支持规定需求的功能都是可见的，且改变任一功能小组都可以评定其对解决方案价值的影响。
解决方案体系结构行为包括：
| • |
创建解决方案概念，并以客户的企业体系结构进行编排；设计版本发布策略；审查需求获取规划。 |
| • |
从结构/标准工作组和互操作相关处获取需求；促进逻辑设计程序；提供一个可追踪映象来跟踪支持需求和利益的功能；创建功能规范；定义临时发布。 |
| • |
管理功能规范的变更；维护可追踪映象；为其它小组角色和外部风险承担者阐明规范；就互操作问题同其它项目小组保持联络。 |
| • |
参与筛选过程；管理项目风险投资者期望的解决方案内容。 |
| • |
为企业体系结构小组提供更新；为未来的版本发布更新需求。 |
解决方案体系结构实施者的技术必须是可靠的，它们需要拥有广博的知识和经验，还要有能力使技术问题同潜在的业务需求发生关联。虽然对于被用于解决方案的具体技术解决方案，架构师可能依赖开发小组向他们提供专业知识，不过他们肯定能迅速抓住那些解决方案细节的本质，了解它们的内在联系以及它们对部署解决方案的环境的影响。解决方案架构师肯定还能够同客户的架构师讨论那些影响，使得他们可以迅速的解决被提议的解决方案同企业体系结构之间的任何冲突。
过程保证
程序管理的过程保证职能领域确保项目小组采纳的过程致力于适应项目整体目标、强调排除有缺陷的消息来源。过程保证对两个主要的区域负责：
| • |
定义被小组使用的关键项目过程，为小组的执行提供建议与指导。 |
| • |
承担过程、建议改进、和一致性监控的审查，以验证它们的关联性和有效性。 |
过程保证致力于下列行为：
| • |
定义符合项目设计的项目协议和过程。 |
| • |
为项目过程的有效执行提供建议和指导；验证过程的一致性；承担里程碑的审查；建议过程改进。 |
由于得益于一个独立于项目小组的地位，过程保证能够有一个客观的看法。因为这个原因，它经常从项目小组的外部进行管理，即使项目的大小使它不能成为一个专职的角色。
行政服务
本职能领域属于程序管理角色群，对执行项目管理过程和为项目小组提供行政支持负责。
项目行政职能领域确保项目小组执行过程符合项目管理定义的项目设计规范。它对确保项目小组能在最小的官僚作风下有效的运转负责。
项目行政责任包括：
| • |
利用它们执行项目管理过程和支持小组领导。这包括统一小组输入以维护总体规划与进度，帮助领导程序报告。 |
| • |
提供一套诸如安排日程会议、常规获取、以及合同管理这样的行政服务来有效支持小组工作。 |
项目管理致力于：
| • |
支持诸如有效的从第三方召集小组成员；管理合同安排；组织小组设施（空间、电话、安全访问等等）这样的项目启动过程。 |
| • |
建立统一的规划框架；帮助小组领导规划和日程安排；统一小组输入以维护总体规划与进度；建立财政与进度报告过程。 |
| • |
帮助小组领导进度报告；构建整体进度和财政报告。 |
| • |
确保在项目完成时关闭所有的行政系统。 |
| • |
执行一般的行政支持行为。比如：安排日程会议；执行风险与问题管理过程；维护主要风险表、操作表等各种表单；生成财政和进度报告；管理小组工作场所以提高士气。 |
开发角色群
“规范构建”目标是关注 MSF 项目期间的开发角色群。为了成功达到它的质量目标，开发角色构建了一个解决方案，它符合客户期望和在功能规范中表述出来的规范。开发角色群依附于解决方案体系结构，并与来自全面解决方案规范的功能规范一起设计它。
除了是解决方案的构建者之外，开发还为小组提供了如同技术顾问一样的服务。作为一个技术顾问，它为设计和技术选择决策提供输入，也为确认决策产生和减轻开发风险构建功能模型。
作为构建者，开发提供低级别解决方案和功能设计，评估这个设计交付所需要的工作，然后构建解决方案。开发之所以评估它自己的工作和计划，是因为它每天都和所有进展的可能性因素在一起工作。MSF 把这个概念看成是从底层向上的评估，而且它还是 MSF 方法的一个基本部分。它的目标是取得一个更高质量的计划，增加那些提供评估的角色和他们执行工作时的责任。
技术咨询职能领域
| • |
为小组提供像技术咨询一样的服务。 |
| • |
评估和确认技术。 |
| • |
积极参与到功能规范的创建和评审中。 |
| • |
为组织定义开发标准作出贡献。 |
执行体系结构和设计职能领域
| • |
通过向体系结构的具体的解决方案细节提供应用程序、数据、技术，为解决方案的执行体系结构映射企业体系结构(EA)决方案。 |
| • |
拥有和执行逻辑的与物理的解决方案设计。 |
应用程序开发职能领域
| • |
编码符合设计规范的功能。 |
| • |
在开发期间管理代码审查，以共享知识与经验。 |
| • |
完成由测试角色支持的测试规划定义的单元测试。 |
基础结构开发职能领域
| • |
开发符合设计规范的功能。 |
| • |
在开发期间管理代码审查，以共享知识与经验。 |
| • |
完成由测试角色支持的测试规划定义的单元测试。 |
| • |
开发自动化部署脚本。 |
| • |
开发部署文档。 |
技术咨询职能领域
技术咨询职能领域提供一个如同技术资源的服务，贯穿在项目生命周期中。作为一个技术咨询者，开发必须在高级设计、评估和验证技术中提供输入，并在开发过程的早期引导研究以减轻开发风险。
在预想阶段，这个职能领域致力于从执行的前景来分析用户/客户需求。为了通过项目的初始参数确定实施的可行性，职能领域评估项目技术的本质，促使对设想/范围文档的定义。它为执行方法的正反两面的可能性和有效的技术初始技术的选择提供指导。在这个过程中，职能领域可能会管理研究，与组织内部或别处的相应的人进行协商，并同技术供应商保持对话。对于附加的验证，职能领域可能开发一个被当成验证概念进行服务的有限功能模型。这在项目关联中是独特的，它要求新技术的使用或者应用在项目小组缺乏经验的领域内。
执行体系结构和设计职能领域
执行体系结构和设计职能领域描述在一个 MSF 项目中，与解决方案的执行体系结构定义和解决方案设计的开发相关的一组责任。
从设计的立场看，程序管理对解决方案的整个体系机构负责，它被部署在企业体系结构中。对企业体系结构向解决方案的执行体系结构的映射，开发通过提供具体的解决方案细节向其负责，具体包括解决方案的应用程序、数据、以及技术。
MSF 提出了一个三级设计过程：概念设计、逻辑设计、和物理设计。程序管理和产品管理共同拥有概念设计。概念设计包括了用户情境、高级可用性分析、概念数据建模、以及初始技术选择。开发拥有解决方案设计中的逻辑和物理方面。逻辑和物理设计要求对解决方案中相关技术和技术选择带来的影响的了解。
应用程序开发职能领域
应用程序开发职能领域描述了与一个 MSF 项目中的软件开发相关的一组责任。开发角色在整个职能领域中的主要责任是为被要求的解决方案构建功能，其中涉及到的内容包括：规范和设计、管理单元测试、处理在测试过程中查出的质量问题、为生产最终产品完成解决方案组件整合。
开发角色在解决方案过程中始终坚持促进标准的定义。开发管理代码审查，以评估单元级别的应用程序功能的质量等级。审查允许项目小组成员共享开发知识与经验、支持 MSF 的目标“自发学习”。测试角色主动的同开发角色一起工作，为解决方案特征计划和管理独立的质量评估，就如同一个完整的解决方案一般。
基础结构开发职能领域
基础结构开发职能领域描述了在 MSF 项目期间与系统开发相关的一组责任。系统基础结构包括一个分布式计算环境的网络接触结构、客户端和服务器系统、以及所有支持组件。软件基础结构包括客户端和服务器操作系统、还有提供必须的平台软件服务的软件产品，比如：目录、通信、数据库、企业应用程序集成、系统管理。网络管理等。
在基础结构开发期间，开发角色“开发”设计中规定的基础结构。这包括为解决方案配置基础技术解决方案，比如：网络支持、设计中定义的客户端和服务器系统。基础结构的各个方面可以被其所支持的应用程序的需求所影响，反之亦然。比如：一个关键项目高性能解决方案可能需要分组供应和后端服务器均衡负载。解决方案的操作系统和平台产品需要适当的开发。各式各样的软件平台产品必须被安装、配置、和优化以适应解决方案的需求。在适当的测试与稳定处理之后，基础结构解决方案在发布管理的掌握下在大规模配置，其中发布管理管理着解决方案基础结构需求的获取
测试角色群
测试角色群的目标是只有当所有的产品质量问题被识别出来并被处理后，才可以批准发布。所有被交付的产品都是有缺点的。关键的目的是在发布产品之前，确保那些缺陷被识别出来并被处理。在维修被质询的缺陷的过程中，编制解决解决方案文档的处理几乎涉及到了一切。交付一个缺陷已知且被处理的有解决解决方案的产品，比起交付一个有着未被识别的缺陷的产品要好得多，因为稍后小组和用户就会为之大吃一惊。
要想成功，测试小组角色群必须致力于几个主要的责任。那些责任被分组在三个主要职能领域中。
测试计划
| • |
开发测试方法和规划。 |
| • |
参与设置质量规则。 |
| • |
开发测试规范。 |
测试工程
| • |
开发和维护自动测试案例、工具、和脚本。 |
| • |
管理测试以准确确定产品开发的状态。 |
| • |
管理构建过程。 |
测试报告
| • |
为小组提供产品质量相关的数据。 |
| • |
在产品发布之前跟踪所有的错误和交流问题来确保他们的解决方案。 |
测试规划
测试规划职能领域是测试角色群的一部分，它致力于使小组知道如何确保所有的产品质量问题被识别且处理。
测试角色开发测试方法和规划，并为小组测试解决方案之策略描绘轮廓。这些规划包括具体类型的测试、具体测试区域、测试成功标准、和资源(硬件和人员都是)中需要测试的信息。
测试规划职能领域的一个重要部分就是通过为项目小组的质量控制方法和规则提供输入，参与设置质量规则，以确保解决方案的成功。
测试规划职能领域的最后一个行为是开发测试规范。这是对需要工具和代码符合的测试规划的定义的详细描述。
测试工程
作为测试角色群的一部分，测试工程职能领域致力于完成测试规划中定义的行为，这是确保所有产品质量问题被识别出来且被处理所必须的。本域所定义的责任是：开发和维护测试案例的具体职责；开发工具、脚本、以及文档来执行测试功能；进行日常构建的管理，以确保测试规程能以单个参考标准执行和报告；还有管理测试以准确确定产品开发的状态——同当前的构建一起，通过运行测试案例、工具、和脚本来识别问题。
跟踪和报告
作为测试角色群的一部分，跟踪和报告职能领域致力于清晰的向项目小组表达解决方案中普遍错误的和普遍正确的是什么，从而使开发状态能被精确的描绘出来。
问题跟踪的执行是为了确保所有被识别出来的问题在发行之前已经被解决。问题状态文档包括了分配、优先级、决定、和解决，它们全部都频繁的向小组提供与当前产品质量状态和详细趋势分析有关的数据。
户经验角色群
用户经验角色群的目标是提高用户效率。用户经验由六个职能领域组成：易用性、国际化、技术交流、培训、可用性、和图形设计。为了使解决方案被成功执行，用户经验角色群在每个职能领域中都有一些必须被管理的责任。下面是职能领域和相关责任的列表。
易用性
在设计中促进易用性概念与需求。
国际化
改善解决方案在国际市场中的质量和可用性。
技术交流
| • |
为支持系统设计和开发文档（helpdesk 手册，KB 文章等等）。 |
| • |
帮助/辅助文档。 |
培训
开发和实行学习策略（构建/购买/交付）。
可用性
| • |
收集、分析、区分用户需求。 |
| • |
为解决方案设计提供反馈与输入。 |
| • |
开发使用情境和使用案例。 |
| • |
为项目小组担当用户辩护者。 |
图形设计
| • |
促进用户接口设计。 |
易用性
易用性职能领域致力于通过促进设计中的易用性概念和需求，确保解决方案对那些有缺陷的人来说是易用的。易用性的重要是有很多原因的。最主要的一个方面，易用性很重要是因为不论人们的能力如何，产品和解决方案应该对所有人来说都是易用和可用的。一个产品或者解决方案没有在易用性上得分将缺乏完全的采用率。另外，遵从易用性可以符合政府法规的要求。
易用性观念和需求必须在整个解决方案开发周期中被提出，且必须包括：
| • |
每个功能规范内的易用性部分的结合。 |
| • |
将易用性信息集成进解决方案帮助部分。 |
| • |
确保易用性文档的完善。 |
| • |
确保易用性文档以易用的格式呈现。 |
国际化
国际化职能领域中的责任是提高解决方案在国际市场中的质量与可用性。国际化职能领域由全球化和本地化过程两部分构成。
全球化
全球化是一个定义和开发解决方案的过程，它考虑解决方案本地华化的需要，其内容要么没有改变，要么没有本地用户不需要的工作区。换句话说，一个彻底全球化的发行解决方案即是为了打算进行最小难度的本地化。
本地化
解决方案本地化包括改变解决方案用户界面、帮助文件、印刷品和联机文档、行销内容、还有Web站点。有些时候，这些内容可能需要为某个特定的语言版本改变为图形元素，甚至进行内容的更改。
技术交流
技术交流职能领域致力于解决方案文档支持系统的开发。
技术交流职能领域的一个主要责任是创建诸如帮助工具这样的工具组件。这种帮助工具能够为用户的基本的问题、关键字描述、错误解释、和经常被问到的问题提供答复。像帮助工具这样的工具可以使用户和组织双方得利。用户得利是因为他们的问题和询问通过及时有效的方式得到了回答。组织则得益于降低了支持成本。
技术交流职能领域得一个补充责任就是为解决方案设计和开发文档。这可能包括安装、升级、操作、和疑难解答指南的开发。
培训
培训职能领域致力于通过提供有效使用解决方案需要的技能知识，来提升用户执行能力。这个技能知识转移是通过执行一个学习策略来实现的。学习策略的开发是用户经验小组角色群的责任。
学习策略的开发可能在组织内部进行，或者外包给一个专门进行培训和开发的组织。不管实际上是谁开发这个学习策略，这个方法通常都由以下部分组成：
| • |
对用户和企业的目的与目标进行分析。 |
| • |
设定期望的技能级别集合。 |
| • |
开发和执行一个培训规划。 |
| • |
在执行时，测度培训规划的可行性，对培训规划进行适当的修改，以保证执行的成功。 |
学习策略可能由以下的一个或几个交付机制组成：教师指导培训、技术交付培训、自主学习或使用工作帮助。很多组织选择了混合方法来适应这种单独的自主学习风格。
可用性
可用性职能领域致力于保证解决方案可以被特定的用户使用，并高效且令人满意的完成规定的目标。
可用性职能领域定义的一个主要的责任是可用性研究，它包括收集、分析、区分用户需求。通过在早期以及贯穿解决方案工作中的了解客户工作上花费时间，项目将更有可能性有效的适应客户需要。
可用性职能领域中定义的另一个主要责任是开发使用情境和使用案例。这里的主要打算就是设想和考虑整个解决方案多大程度上可能被使用。这个工作帮助开发小组从一个整体和直观角度了解了用户如何处理解决方案，这通常可以导致设计被改进，从而使有效性增加。
可用性职能领域中定义的最后一个主要责任是为解决方案提供反馈和输入。通过在整个开发周期中花费时间把用户反馈提供给开发人员，解决方案将因此获取一个更高的用户满意率。
图形设计
本图形设计职能领域致力于确保解决方案中的图形原理的设计是恰当的。图形设计职能领域的主要职责是推动用户界面的设计。这包括设计用户打算与之结合的对象（还有应用于那些对象的操作），还包括接口的主要画面。
发布管理角色群
发布管理角色群的目标是使部署流畅和持续操作。发布管理是直接参与 MSF 小组操作的角色。它包含了下列职能领域的责任：
| • |
扮演项目部署和操作工作组的主要支持者。 |
| • |
为发布行为和驱动最优化自动管理工具选择。 |
| • |
为产品发布设置运作标准。 |
| • |
参与设计，致力于易管理性、可支持性、以及可部署性。 |
| • |
推进操作训练。 |
| • |
为首次部署提供促进和建立支持。 |
| • |
规划和管理生产解决方案部署。 |
| • |
确保稳定性测量以达到验收标准。 |
基础结构
| • |
企业基础结构规划 |
| • |
通过地理布局协调物理环境使用与规划（数据中心、实验室、外部办事处）。 |
| • |
为小组的统一的基础结构管理和标准提供规则和规程。 |
| • |
向 MSF 小组提供基础结构服务（构建服务器、标准映像、软件安装）。 |
| • |
为小组管理软硬件采购。 |
| • |
构建准确反映生产环境的测试与分级环境。 |
支持
| • |
为 IT 用户提供第一位的联络与客户服务。 |
| • |
通过同客户管理 SLA 支持业务，保证承诺被实现。 |
| • |
提供事件与问题决议；对用户需求和日志事件作出快速反应。 |
| • |
向开发和设计小组提供反馈。 |
| • |
开发故障转移和恢复规程。 |
操作
| • |
帐户和系统设置控制；管理用户帐户和权限。 |
| • |
通信、数据库、远程通信操作；网络操作。 |
| • |
系统管理、批处理。 |
| • |
防火墙管理；安全管理。 |
| • |
应用服务。 |
| • |
主机集成服务。 |
| • |
目录服务操作。 |
业务发布管理
| • |
产品注册码；注册验证程序。 |
| • |
许可管理。 |
| • |
封装。 |
| • |
管理销售渠道。 |
| • |
出版物与电子出版物。 |
对于每个开发环节的参与人员
第一部分:远景规划部分:
产品管理.程序经理
(产品需求分析,主要功能的要求等,开发的预计周期成本,风险系数的考虑.以及风险规避办法.达成协议后签订远景协议)
第二部分:程序框架设计
程序经理,开发人员,产品管理
(功能的细化,模块的划分,设计文档和技术文档的建立,修改流程的定义等相关的文档材料)
第三部分:开发阶段
开发人员,客户体验人员,程序经理
(开发程序,不定时的团队交流,并让客户代表参与其中,避免后续工作的重复性,并开始做用户说明书.完成时签订设计完成协议,并对程序中暂未处理的问题统计和规划)
第四部分:测试阶段
测试人员,开发人员,项目实施人员,程序经理
(处理产品中剩下的遗留问题,对于未能解决的问题由决策人员作出决策,在功能,时间,资源中间,找出一个合理的解决方案.实施人员开始客户情况的了解,准备项目实施所需要的各种资源(人力,物力,财力)
第五部分:部署阶段
项目实施人员,产品管理,测试人员,开发人员
产品的发布部署.并又实施人员及时反馈意见,对于问题由测试人员,开发人员解决,并由产品管理人员跟进客户,争取二次开发的可能性.
总结下:MSF对于一个项目来说是一个比较完整的解决模式:对于风险的评估规避,前景的展望,设计的进度控制,后期的bug处理,产品的实施这几个阶段来说都能起到很好的控制和掌握.是一个可以借鉴的框架.
