Microsoft Solutions Framework (MSF) 概述

Microsoft Solutions Framework (MSF) 是一个可以更快地成功交付技术解决方案的适应性强的方法,此方法需要的人员更少,风险更低,同时可以获得更高的质量结果。 MSF 帮助团队直接发现技术项目失败的最常见原因 - 提高成功率和解决方案的质量并减少对业务的影响。

MSF 关注于:

  • 使业务和技术目标相匹配

  • 建立明确的项目目标、角色和责任

  • 实现迭代、里程碑/检查点驱动过程

  • 主动管理风险

  • 有效地响应变化

本文中讨论的 MSF 的关键元素是:

  • MSF 基础原则和观念为团队和团队成员设定方向并引导其一起协作以交付解决方案

  • MSF 团队模型使项目能够扩展、确保团队满足各种利益相关者的需求,并定义目标驱动的角色和责任

  • 通过标识关键项目活动的已证明的项目生命周期,MSF 监管模型(以前称为 MSF 进程模型)可推动快速、高质量的结果

MSF 基础原则和观念

Microsoft Solution Framework (MSF) 的核心是代表多年经验的原则和观念。 通过提炼出在各种 MSF 模型、过程和学科中适用的概念,这些原则和观念成为 MSF 的基础。 尽管它们是常识概念,但正确了解和实现它们可能具有挑战性。 但是,了解它们后,团队可以一起制作优质产品。

基础原则

以下 MSF 原则和概念引导项目团队交付优质的解决方案。 每个团队成员都应该了解并在他们与其团队的其他成员、其组织和利益关相关者之间的交互中应用这些原则。 MSF 的核心是 9 项基本原则:

  1. 打造开放的通信。 为了使你的团队有效和高效,你和你的团队需要在团队成员和整个企业中共享适当级别的信息。 团队需要了解需要执行的操作的性质,以及团队成员和外部联系人如何沟通。 较难的部分是确定每种关系的适当级别,以及需要共享的信息。

  2. 为了实现共同的愿景努力工作。 团队成员可以具有共同的愿景并支持灵活性,以便团队成员能够以实现愿景为前提快速做出明智的决策。 在发现需求空白后,共同的愿景还有助于团队成员填补这些空白。

  3. 授权团队成员。 团队成员不仅可以使用多种方法之一在不断变化的环境中生存下来,而且团队成员还可以学会创造性地寻找成功的方式,同时相互帮助。 如果团队成员不允许实现他们最好的结果,那么不仅会降低他们的创造力,而且还可能使他们士气低落,并且不能帮助创建表现良好的团队。

  4. 建立明确的责任和共同分担的责任。 授权的团队成员经常觉得对他们的决定更负责任,并愿意联合负责一个项目。 更多的团队成员责任可带来更高的质量。 例如,如果团队成员声明已经完成了任务,但发现它没有达到适当级别的质量,则该团队成员负责修复完成的任务以达到规定的质量级别。 通过鼓励正增长和责任而不是惩罚此类失误,团队成员将共同承担总体解决方案及其可交付结果的责任。 这可使更强的团队成员受到激励,以便相互帮助来尽可能达到最佳状态。

  5. 交付增量价值。 通过两个方面交付增量价值:

    1. 确保交付的内容对利益相关者具有最佳价值。

    2. 确定其中最佳的增量以交付价值,或“交付的频率”。

  6. 保持灵活、期望并适应变化。 由于变化可能经常发生,并可能在最坏时发生,因此以灵活的方式来处理变化可帮助你尽量减少由于变化而导致的常见中断。 保持 Agile 意味着组织已准备好进行变化,并且能够平稳地适应和调整。

  7. 进行投入来提高质量。 很多组织信奉质量至上(通常是一个松散定义的术语),但缺少对如何量化质量的了解。 质量必须主动地合并到解决方案交付生命周期中,而不只是发生即可。

  8. 从所有经验中学习。 如果组织的所有级别不从以前有效和无效的工作中学习,那么如何期望他们下次可以改进? 团队成员必须理解并珍惜在所有级别中发生的学习:

    • 例如,在项目级别学习优化整个项目范围的过程

    • 在个人级别,学习如何更好地与其他团队成员交互

    • 在组织级别,学习对每个项目调整收集哪些质量指标

  9. 与内部和外部客户合作。 当客户与项目团队协作时,就会增加项目成功的可能性。 这并不表示客户在做团队的工作。 但是,当客户与交付团队紧密并且增强合作时,实现的解决方案能够更好地满足他们的期望。 与客户合作是相互受益的,因为它有助于降低不确定性、缩短解决需求问题的时间,并通过定期的接触增加团队对解决方案价值主张的了解。

观念

上述讨论的基本原则是对如何为团队定向以获得最大限度地成功进行指导,而将团队成员作为个人进行定向以获得最大限度地成功则称为观念。 每种观念都可帮助团队成员接近实现其特定的解决方案交付。 理想情况下,团队成员变得如此适应这些观念,以至于他们不管是否在工作都会使用它们。 以下是每个团队成员应该内在化的一些观念:

  • 培养对等方的团队。 如果你的组织能够体现 MSF 基本原则,尤其是权力和责任,那么运行具有分层项目结构的项目真正有意义吗? 如果每个人都了解使命及其目标,以便他们在交付解决方案时具有共同的愿景以及角色和责任,那么每个人都可作为对等方并可以被同等对待。 这不是建议无政府状态或由委员会管理,而是让每个人共同承担成功交付解决方案的责任。 虽然对整个项目共同负责,而每个角色又单独对项目相应的方面负责。 你将会看到,仍有计划管理员角色,但此角色侧重于在项目约束内交付项目,而不在于管理团队成员。

  • 侧重于业务价值。 在交付业务价值方面度量成功。 这意味着不仅交付客户所需要的内容,而且还交付客户想要的内容以及价值。 若要交付价值,团队中的每个人都需要了解客户认为什么有价值。 无法向客户提供业务价值使项目面临风险:偏离方向的风险;花费很多误导的时间、工作量和金钱的风险;甚至被取消的风险。

  • 保持解决方案的视角。 由于大多数项目的大小和复杂性,因此当通过查看其可操作部分来查看解决方案时,团队成员有时过于仔细查看小的细节,而忘记记住最终解决方案。 这就是为什么如此强调具有共同愿景的原则的原因。 在团队成员交付他们负责的部分时,他们需要回顾解决方案的总体使命、目标和愿景。 通常,子团队会优化他们的领域,相信他们为共同利益而行动,但发现他们需要返工主要的方面以便符合解决方案;他们陷入细节之中而无法看到整体解决方案。

  • 工艺出色。 团队不仅应该为提高质量而投入,而且成员们还应该看到质量既是他们的责任也是其他团队成员的责任,并且不应将它委托或传递给其他人。 相反,质量是整个解决方案交付生命周期中每个人的责任。 这种观念不仅包括能够在团队成员自己的可交付结果中提高质量,而且包括推动提高过程制定和项目监管的质量。 这种观念还鼓励每个团队成员扩大他们对需要完成总体使命的技能的了解。 通过监视自己的质量并交付他们可以做的最好结果,团队成员可以帮助最终产品的持续改进。

  • 持续学习。 有时对你和你的团队具有的技能感到自豪已经不足以实现最终目标。 团队成员需要学习新的技能以成为团队中更好的同事。 假设大多数项目、团队和环境是唯一的,每个项目都提供机会来学习、实验及细化技能、过程和步骤。 若要充分利用这些机会,持续学习和适应必须存在于组织的所有级别 - 不只限于团队成员。

  • 将服务质量内在化。 服务质量 (QoS) 定义解决方案的预期操作特征,如预期解决方案可用性的级别。 不仅仅是架构师,利益相关者和团队成员也必须了解 QoS 以及满足他们将如何影响可交付结果。 否则,利益相关者和团队成员可能会对有关解决方案的行为做出隐式假设。 由于这些假设很少是一致的,因此每个团队成员需要从头开始就做出明确的设计决定以确保满足 QoS。 这样,可将隐式假设转换为明确的 QoS 要求。 而且从一开始就将 QoS 明确设计为解决方案,并且不将它视作事后的考虑事项。

  • 做个好公民。 从软件开发的角度来看,好公民意味着在你工作的所有方面都值得信赖、自豪,并且负责任和受到尊重。 这包括但不限于你如何:

    • 与你的资深团队成员、组织和利益相关者交互

    • 参与项目并帮助交付解决方案,包括成为企业、项目和计算资源的受信任的守护者。 这包括开放地和自愿地共享资源、信息和知识。 好公民会奉行和关注更大的利益。

  • 履行你的承诺。 尽管嵌入了许多检查和平衡,但在某种程度上,通过团队成员履行其承诺,MSF 可以基于所获得的信任和权力而运行。 MSF 建立了一个环境,其中团队成员和利益相关者能够信任他们的资深团队成员会履行其承诺。 由于项目是相互依赖的活动的集合,因此当一个团队成员不履行其承诺时,它会使整个项目不平衡并受到危害。

MSF 团队模型

MSF 团队模型将典型的解决方案交付活动和责任划分为七个支持组。 这些组相互依赖并处于多领域。 如下表所示,若要有助于采用平衡的方法,则每一个角色都应对以下方面具有独特的视角:什么是需要的、什么是必须支持的,以及与交付解决方案相关联的目标应该是什么。 这些角色可以在小团队的情况下进行合并,并在大团队的情况下进行扩展。

因为组织和团队差别很大,所以这些角色不暗示或建议任何类型的组织图或职务组。 最常见的情形是,这些角色分布在 IT 组织内不同的组中,而且有时与业务用户社区及外部顾问和合作伙伴分布在一起。

角色

目标

职能领域

产品管理

  • 确保解决方案交付业务价值

  • 定义项目约束内的解决方案

  • 确保满足客户的需求和期望

  • 市场/企业通信

  • 业务分析

  • 产品计划

计划管理

  • 交付项目约束内的解决方案

  • 设置满足支持方的需求和期望的方式

  • 项目管理

  • 计划管理

  • 资源管理

  • 过程保证

  • 项目质量管理

  • 项目操作

体系结构

  • 设计解决方案以满足项目约束内的业务目标

  • 解决方案体系结构

  • 技术体系结构

开发

  • 生成规范的解决方案

  • 解决方案开发

  • 技术咨询

用户体验

  • 最大程度地提高解决方案可用性

  • 增强用户准备情况和有效性

  • 确保满足用户的需求和期望

  • 可访问性

  • 国际化

  • 技术支持通信

  • 培训

  • 可用性

  • 用户界面设计

测试

  • 只有在确保该解决方案的所有方面满足或超过它们各自定义的质量级别之后,批准发布解决方案

  • 回归测试

  • 功能测试

  • 可用性测试

  • 系统测试

版本/操作

  • 平滑部署及转换到运营

  • 确保满足 IT/业务运营需求和期望

  • 版本管理

  • 交付基础结构

  • 操作

  • 生成管理

  • 工具管理

MSF 监管模型

将监管模型(以前称为过程模型)设计为在正确的时间提供正确的指导给正确的人。 如果他们首先关注优先级最高的功能并将次要功能移到后续版本,则它旨在允许团队能够比其他方式更快地交付解决方案的关键部分。 此模型旨在帮助快速推动团队对如何履行解决方案的各个方面达成共识。 监管模型是已成功用于改进项目控件、最小化风险、改进解决方案的质量以及加快开发速度的灵活 MSF 组件。 由于 MSF 是完全自定义的,因此预计组织采用监管模型,以适用于其业务流程和现有的解决方案交付方法。

MSF 监管模型将项目监管与过程制定相关联。 项目监管侧重于优化解决方案交付过程,并有效和高效地使用项目资源。 过程制定侧重于定义、生成和部署满足利益相关者的需要和期望的解决方案。

MSF 监管模型的关键方面包括活动的重叠轨迹、同步检查点以及递增的方法,以便为客户交付价值。

轨迹

通过使用活动的重叠轨迹,MSF 监管模型可促进项目监管和过程制定。 在一个级别上,轨迹是某些活动的重叠且协调的组,这些活动针对生成每次跟踪的相关可交付结果。 但是,MSF 轨迹比这更多;每一条都有独特的使命,并表示项目节奏和焦点中的变化。 轨迹在每次跟踪中使用评审和称为检查点的同步点(详见下文),以帮助确定是否实现跟踪的目标。 此外,主要检查点还用来结束每次跟踪,这可实现对指导许多活动的责任的转移,并鼓励团队为下个跟踪的目标更适当地采取新的视角。

MSF 监管模型由五个重叠的制定轨迹和贯穿整个制定轨迹的持久监管跟踪组成。

监管跟踪图

显示模型的 6 个跟踪的关系图

监管跟踪

遵循一组可能不断变化的项目约束,监管跟踪侧重于平衡项目资源和解决方案交付的有效和高效使用。 此外,监管跟踪还支持持续过程改进。

好的项目监管提供了正好足够的监督、过程、指导和严密性,以高效和有效地使用项目资源、交付解决方案并处理权衡决定,同时平衡遵循一组可能不断变化的项目约束。 MSF 监管跟踪致力于提供并持续改进良好的项目监管。 它包括整个项目的离散和持久的活动。

监管跟踪的目标如下:

  • 指导制定活动以交付带有可重复和可靠结果的解决方案

  • 优化并持续改进团队的表现和吞吐量、解决方案的质量以及过程改进

  • 安全审批来自:

    • 解决方案满足他们的需要并充分可用的用户

    • 准备好解决方案进行部署的运营部门

    • 完成项目的客户

制定轨迹

过程制定是详细的步骤顺序,通过这些步骤定义、生成和部署解决方案。 实质上,制定轨迹可帮助团队达成预想的高级别协议,并创建方法选项以实现该愿景(预想跟踪);评估这些选项并计划选定选项(计划跟踪);生成解决方案(生成跟踪);确保按预期交付解决方案(稳定化跟踪);以及最终部署该解决方案(部署跟踪)。

每个制定跟踪的目标如下:

预想

  • 清楚地了解项目约束的上下文中所需的内容。

  • 借助最好地满足这些需要的选项和方法,组建必需的团队以设想解决方案,同时最好地满足这些约束。

计划

  • 将概念解决方案发展为有形的设计和计划,这样它可以在生成跟踪中进行生成。

生成

  • 依照计划跟踪可交付结果(如设计、计划、时间表和要求)生成解决方案的各个方面。

稳定化

  • 提高解决方案的质量,以满足部署到生产的版本标准。

  • 验证解决方案满足利益相关者的需要和期望。

  • 从用户的角度验证解决方案的可用性。

  • 将成功最大化,并尽量减少解决方案的目标环境中与解决方案部署和操作相关联的风险。

部署

  • 将解决方案成功地集成到指定环境内的生产。

  • 将剩余解决方案交付的责任尽可能平稳并尽快地从项目团队传输到运营和支持团队。

检查点

检查点(MSF 的中心主题)用于计划和监视项目进度并促进可交付结果和活动的完成。 检查点用来为团队和客户再次确认项目范围提供明确的机会,或调整项目范围以反映不断变化的客户或业务要求,或在项目的过程期间适应可能会具体化的风险和问题。 检查点用于许多原因,例如:

  • 帮助同步工作元素。

  • 提供进度和质量的外部可见性。

  • 支持中途更正。

  • 将评审的重点放在目标和可交付结果上。

  • 继续进行下一步之前,先提供工作的审批点。

MSF 区分两种类型的检查点:主要检查站和临时检查点。 主要检查点标记主要活动和主要可交付结果的完成,包括给定跟踪的计划活动的结束。 由团队定义临时检查点以指示跟踪内的进度并将较大的工作分为可处理的片段。

迭代方法

解决方案不提供业务价值,直到将它部署到生产并有效地使用。 因此,MSF 监管模型的生命周期包括解决方案生产阶段的增量开发和部署,从而确保业务价值以及团队总体战略愿景和目标的实现。 对于将明确的重点放在对过程中业务影响的团队,强大的多维业务表示形式组合是 MSF 确保项目履行技术的承诺的方式。

迭代开发的实践是 MSF 中重复的主题。 以迭代方式开发文档、设计、计划和其他可交付结果。 如你所料,MSF 监管模型是一种迭代方法。

摘要

对于希望快速开发高质量、业务相关的技术解决方案的组织,Microsoft Solutions Framework 将是一款有效的工具。 它的灵活性使用户很容易适应大多数技术项目,从而帮助团队有效地交流和协调关键活动。

书目

请注意,本部分内容来自 Microsoft Solutions Framework Essentials (ISBN 9780735623538)。 Microsoft Press。 保留所有权利。

请参见

概念

使用 Visual Studio ALM 和 TFS 跟踪工作

使用团队项目内容,选择过程指南