微软解决方案框架 - MSF的团队模型

 八、MSF的团队模型

 

   

 

从上图可以看出,MSF中每个子团队在项目中的作用和关注的问题分别对应着项目中不同的六个方面。它们每个子团队的角色都代表了对项目的一种视角,没有哪一个人或角色能完全代表所有的不同质量目标。在此,MSF把角色与责任结合起来了。

    由于在软件项目中每一个方面的失败均会导致整个软件项目的失败。因而,MSF团队模型中,在工作层面上也没有上下级的关系。每个子团队都对最终的软件质量的一部分负责。子团队成员内部,对子团队本身负责,实现该角色的质量目标。角色之间相互依赖,相互合作。它们之间通过“沟通”机制相互共享项目信息。需要说明的是,这种“没有上下级的关系”是在“工作层面”的,不是组织架构的组织。

    在此,我们也可以根据我们自身的情况,对MSF团队模型中进行改造,使之应用于我们的团队中。例如,将“产品管理”和“用户体验”两种角色进行合并。“发布管理”和“测试”角色进行合并等等。MSF是给出一个团队组织的指导方针,没有必要也不应该完全照搬。

(一)MSF团队模型的优点是什么?

MSF团队中,各子团队的工作和职责相互依赖,这种相互的依赖性会鼓励子团队成员对由其他子团队工作做出评论和贡献,以确保该子团队成员所有的知识、能力、经验能够被应用到解决方案里。项目的成功,属于所有的子团队成员。他们共同分享一个成功的项目所带来的荣誉和回报。即使是一个不太成功的项目,也能做到全心投入并从中吸取教训,以完善他们的专长。

(二)MSF团队模型中各个角色的职责分工

    要说明的是,以下给出的MSF团队中各角色的职责分工,不表示任何组织机构或工作职位的固定设置。因为MSF是一个可伸缩的框架,它仅给出一个团队组织的指导。这些角色应该随着组织的变化,而有所变化。使用MSF团队模型,关键在于为了更好地实现项目的目标,清晰地理清角色和它们的职责的分布关系。(这一点,对我们很有帮助,这不仅仅是适用于团队模型,也适用于MSF其他的方面和原则。)

 

 

u    产品管理

目标:满足客户

项目必须满足客户的需求并以此作为成功的标准。如果一个项目其他方面均达到了原来制定的质量标准,但却没有满足客户的需要,那么这种项目一定是不成功的。

职能领域:

A.        市场开发

B.        业务价值

C.        客户拥护

D.       产品计划

职责:

A. 作为客户的拥护者

B. 驱动共同的项目和方案设想

C. 管理客户需求说明

D.       开发和维护业务案例

E. 管理客户期望

F.  驱动产品特征、日程表、资源权衡决策

G.       管理市场开发、产品宣传和公共关系

H.       开发、维护和执行交流计划

描述:

从“产品管理”角色的职责中可以看到,这个角色在团队项目中是代表了客户一方的。“产品管理”这一角色靠近于客户一侧。这个角色的关键目标就是保证最终的软件满足客户。这一角色负责首先要做的就是确定和了解客户,然后在在此基础上清晰界定出用户的需求范围和需求分析。

u    程序经理

目标:交付满足项目约束的解决方案

在MSF团队模型中所有子团队的一个关键目标是实现满足项目约束的解决方案。大多数项目使用“按时、按预算”作为评价成功的标准。

职能领域:

A. 项目管理

B. 解决方案体系结构

C. 过程保证

D.       管理服务

职责:

A. 驱动开发过程以期按时的交付产品

B. 管理产品规格说明书首席项目构架师

C. 促进小组内部的交流和商议

D.       维护项目日程表和报告项目状态

E. 驱使关键的权衡决策的实现

F.  开发、维护和执行项目总规划和日程表

G.       驱使和管理风险评估和风险管理

描述:

“程序管理”角色的中心是实现在各类项目约束内交付解决方案的目标。这就类似于项目中控制的作用。程序管理确保了在适合的时间(用时间表)交付出适合的解决方案。

    作为项目日程的控制者,“项目管理”角色收集或整理项目的总日程表中。总日程表被跟踪记录。

    作为项目预算的控制者,“项目管理”角色控制项目预算,跟踪实际开支。此外,项目管理还协调各种资源,促进小组交流。

u    开发角色群

目标:根据规格说明创建解决方案

精确的按照规格说明书交付产品对子团队来说是很重要的,因为规格说明书代表着子团队与客户之间的一项协议。

职能领域:

A. 技术咨询

B. 实现的构架和设计

C. 应用程序开发

D.       基础结构开发

职责:

A. 指定物理设计的特征

B. 估算完成每个特征所需的时间和精力

C. 构建每个特征并监督其实现

D.       准备部署时使用的产品

E. 为小组提供技术主题的专门知识

描述:

MSF 提出了三级设计过程:概念设计、逻辑设计、和物理设计。“程序管理”和“产品管理”共同拥有概念设计。“开发”角色拥有设计中的逻辑和物理方面。逻辑和物理设计要求了解相关技术带来的影响。

“开发”角色主要责任是按规格说明书构建功能,其中涉及到的内容包括:编码规范和设计、管理单元测试、处理在测试过程中查出的质量问题、解决方案组件的整合。

u    测试

目标:在所有产品质量事宜被识别并处理后进行发布

所有的软件都存在缺点。“测试”角色的一个关键目标是确保那些缺点在发布产品之前被确定和处理。

职能领域:

A. 测试规划

B. 测试工程

C. 测试报告

职责:

A. 确保了解所有问题

B. 决定测试策略和制定计划

C. 执行测试

描述:

“测试”角色群的目标是只有当所有的产品质量问题被识别出来并被处理后,才可以批准发布。所有被交付的产品都是有缺点的。关键是在发布产品之前,确保那些缺陷被识别出来并被处理。

u    用户体验

目标:提高用户效率

为了项目的成功,用户操作软件的方式必须尽量完善。一个拥有丰富功能与特性的软件,但它的这些功能与特性却很难被目标用户所操作,这被认为是失败的。

职能领域:

A. 技术交流

B. 培训

C. 可用性

D.       用户界面设计

E. 国际化

F.  易用性

职责:

A. 为项目小组充当用户拥护的角色

B. 管理用户需求说明

C. 设计和开发性能支持系统

D.       驱动可用性和用户性能增效的权衡决策

E. 为用户提供帮助特点和帮助文档的规格说明书

F.  开展和提供用户培训

描述:

“用户体验”角色群的目标是提高用户效率。用户体验由六个方面组成:易用性、国际化、技术交流、培训、可用性和图形设计。

u    发布管理

目标:进行平滑的部署及日常运行

有时进行平滑部署的需要会被忽视。子团队必须争取实现一个平滑的部署并为产品的支持和管理做好准备。这些内容可以包括在部署前的培训、基础结构和支持的准备工作等。

职能领域:

A. 基础结构

B. 支持

C. 操作

D.       业务发布管理

职责:

A. 作为各种操作、支持与交付渠道的拥护者

B. 管理所得

C. 管理产品部署

D.       驱使可用性和可支持性权衡决策

E. 管理各种操作、支持和交付渠道之间的关系

F.  为项目小组提供后勤支持

描述:

发布管理角色群的目标是使部署流畅和持续操作。

 

(三)MSF团队模型的最佳实践

1. 组建小型专业化团队(一般不超过10人)

2. 在同一地点共同工作(团队内部沟通、与客户的沟通都很方便)

3. 要求客户加入项目团队(制定特定接口人)

4. 全体参与项目重要活动(项目不神秘原则)

5. 在复杂的项目中,“程序管理”角色分成“项目经理”和“架构师”两种职责。

 

 

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值