大型软件开发项目中的功能小组模型

── Visual Studio 开发团队的敏捷实践经验分享（一）

编者按：出乎我们意料，前一段时间 InfoQ 中文站、雅各布森和微软共同举办的“敏捷 Scrum 实战营”活动，得到了上海和北京两地技术人员的热捧，原计划 300 人的参会规模，实际报名近 800 人，活动也根据需要从两场增加到三场。在活动中，我们也收到许多来自参会者的反馈，他们希望能够了解类似微软这样大规模、分布式的团队是如何实施敏捷的。据此，InfoQ 中文站联系了微软上海研发中心，并很荣幸得到他们的积极反馈。本文即是 InfoQ 中文站特邀编辑滕振宇采访了微软亚太研发集团服务器与开发工具事业部的部门经理 Ramesh Rajagopal 的作品。在采访中，Ramesh 从项目管理、需求管理以及技术架构控制等方面分享了他所带领 Visual Studio 软件生命周期管理工具团队使用敏捷方式组织管理大规模软件团队方面的经验。

注：本文是依据邮件采访整理而成，为保持现场感，文中使用第一人称指代微软亚太研发集团服务器与开发工具事业部。

微软 Office 产品组最早引入了功能小组模型，并采用这个模式开发、发布了几个 Office 版本。之后，微软其它部门也开始采用，包括 Windows 部门和开发工具事业部门（后者负责开发 Visual Studio 系列产品）。这些部门都拥有数千名工程师，我们需要在具有数百万行代码的代码库上工作，并且多次成功发布了这些产品，可以说，功能小组模型在项目管理、需求管理、以及技术及构架控制等方面有着很好的扩展性。

首先简单介绍一下我们是如何进行产品计划。进入产品开发前，高层管理团队要确定新版本将带来的商机（Business Opportunity）。（注意：为了能够确定这些商机，高层管理团队会从在整个部门收集数据和征询反馈意见。）然后，起草对应这些商机的高层目标。这些目标会被分解为多个用户价值主张（User Value Propositions, 可以将它们看作是 Agile 术语中的“epic“故事）。接下来它们又会被细分为用户体验（User Experience, 可以将他们理解为 Agile 术语中的“主题”，Themes）。功能小组于是会定义实现这些用户体验的用户故事。实现这一整套用户体验也就是实现了用户价值主张，从而达到商业目标（Business Objectives）。

我们会为每个产品的发布设计一个计划里程碑（通常情况下一个里程碑需要 12 个星期）。在这个阶段，产品负责人会为这个产品发布制定一组要达到的商业目标和目的。接下来每个下属团队（它们是整个产品，如 Visual Studio，开发的一部分）要创建出符合一个或多个商业目标的产品待开发事项（Product Backlog）。

下面让我们来看一个具体的例子。对于微软开发工具部门而言，我们的使命是：“让每一个使用微软工具和平台的软件项目获得成功”。我们每个产品以及其中所包含的功能都是围绕这个使命来开发的。例如，早期的 Visual Studio 主要是集中在核心的开发活动上，如：编码、编译和调试。后来我们意识到软件项目要成功，需要提供对整个开发周期的支持。这直接导致了 Team Foundation Server 和 Visual Studio ALM（Application Lifecycle Management，软件应用生命周期管理）工具的产生，以支持项目管理、构架、设计和测试等开发活动。

Visual Studio 2010 的一个商业目标是 :“使软件开发团队采用正确的方法来编写软件”。从这个高层主题可以创建出几个价值主张。其中一个主张就是：“使软件开发团队通过构架和模型工具来管理软件的复杂性”。它还可以再进一步细分为：“使软件开发团队能够理解和分析已有的代码”、“使软件开发团队能够验证它们的代码是否符合指定的构架设计”、“使软件开发团队能够理解他们所在的领域和需求，并设计出期望的构架”等主题。这些主题分配给各个功能小组。在设计计划里程碑最后阶段，功能小组和产品负责人（负责某一特定的价值主张）相互协作一起定义出产品待开发事项。它包含了一组划分好优先级的用户故事，期间会充分听取团队成员的意见和反馈，并最终与产品负责人进行确认。 这实质上就是产品的发布计划，并用它来进行跟踪和管理产品的开发。产品待开发事项中的用户故事也是以工作项的形式保存在 TFS 上的（TFS 2010 的 MSF Agile Template 定义了用户故事工作项类型）。

每个产品待开发事项可能会覆盖多个价值主张，而关于同一个价值主张的主题也可能存在于多个产品待开发事项列表中。价值主张与产品待开发事项之间是多对多的关系。同时，根据项目的不同，可能是多个功能小组共享一个产品待开发事项列表，也有有一些功能小组独自拥有一个列表。

当然，产品待开发事项本身在 Sprint 过程中发生改变的情况，也并不少见。在整个计划和实现阶段，功能小组通过多种渠道与客户进行接触。在计划的早期阶段，计划初稿会发送给特定客户（一般代表了产品的目标受众）来征求他们对价值主张、优先级等的意见。在接下来的实施阶段，团队会建立一个客户咨询委员会，并与其分享产品的开发进展、向其征询反馈意见。另一个客户沟通渠道就是 MVP（Microsoft Most Valuable Professionals，微软最有价值专家），团队会与这些 MVP 定期交流。我们还通过 TAP（Technology Adoption Program, 技术先行体验计划），让参与客户在他们选定的项目环境下试用产品的测试版本，并提供反馈。相应的，微软团队会为客户提供定制的技术支持（通常会指定一名功能小组工程师负责与客户沟通），根据用户的反馈调整产品。此外，我们还有 CTP（Community Technology Preview，社区技术预览版），它是产品开发的一个中间版本，发布给更多用户并听取他们的意见。当然，作为上述沟通方式的结果，产品团队会对产品待开发事项做相应的调整，包括添加新用户故事，删除或者重新安排已有用户故事的优先级等。在这种情况下，如果某些用户故事的优先级提高了，并且需要进一步的澄清和研究，那么 Sprint 的计划会需要更多的时间。

一旦创建好用户故事并把它们按照优先级排序，功能小组就可以开始设计构架框架。这通常会包括开发软件原型，与用户体验设计师、架构师等进行相关的讨论。在这些工作完成后，产品开发就正式开始了。

产品开发由一系列 3 至 4 周的 Sprint 组成。每个 Sprint 计划是在上一 Sprint 结尾开始，并在这个 Sprint 开始的 1 到 2 天内完成。每个 Sprint 采用的都是相同的流程：功能小组长们先挑选出一组他们认为在下个 Sprint 内能够完成的候选用户故事，然后根据团队成员的反馈意见、生产力进行调整，并与产品负责人进行确认。用户故事会被分解成多个任务，并由团队成员在迭代中领取这些任务。（Visual Studio 2010 的 Agile Process Template 定义了用户故事和任务这两个工作项类型）。在 Sprint 计划结束时，功能小组要完成的一组用户故事，并在 TFS 上把这些用户故事设置为这个 Sprint 的迭代路径（Iteration Path）。

在每日 Scrum 站立例会中，每个功能小组的成员都会向小组报告各自任务的完成小时数和剩余小时数，并同时要更新 TFS 上相应的工作项。这些时间更新会被综合起来，以反映出当前 Sprint 所要实现的用户故事的进展状况。此外，产品利益相关者和负责某个用户价值主张的功能小组组长也会每周开会。除了这些 cadence 会议，所有的团队人员还可以通过 TFS 数据仓库生成的每周进度报告，随时跟踪、了解总体进展情况。

Visual Studio 2010 为这一切提供了良好的支持。在我们团队的项目中，项目管理团队定制了一个过程模板（Process Template），分别为商业目标、价值主张和主题（我们在内部使用“功能”这个词）定义了相应的工作项类型。这个过程模板部署在 Team Foundation Server 上。在这些工作项类型之间定义了嵌套的父 / 子连接关系，例如：一个商业目标是通过一组价值主张来实现的。不同的商业目标、价值主张和主题都是以工作项的形式保存在 TFS 上的。

你可能知道，Visual Studio 主要优势之一是与 Office 工具的集成，如：Excel 和 Project。Visual Studio 2010 Ultimate 版本带有几个 Excel 工作薄，可以帮助用户在 Excel 中创建、修改和浏览工作项（如果你已习惯于使用 Excel）。例如：Product Backlog 工作薄和 Sprint Backlog 工作薄可以帮助你快速创建工作项，同时修改多个工作项的优先级、状态、指派完成人员等。 另外，用户故事和任务之间的嵌套关系使多个用户故事的进展可以被自动累计起来，以反映出整个主题、价值主张以及最终商业目标的进展状况（这些故事都符合既定商业目标）。

当然，功能小组模型所面临的重要挑战之一就是管理小组之间依赖关系。各个功能小组在自己的“功能分支（Feature Branch）”上工作，“功能分支”上的代码只有在功能实现之后才能够被集成到“主干分支（Main Branch）”上（主干分支上的代码最终生成交付给用户的产品）。因此，在产品开发初期确定功能小组之间的依赖关系，并达成服务级别协议 （Service Level Agreement）非常重要。绝大多数的依赖关系是在早期计划和原型设计阶段就被发现了。例如，为实现“理解并分析现有代码”的主题，相关功能小组必须依赖于负责程序语言编译器的功能小组。

功能小组会和它所依赖的团队进行协商，促使其尽早完成它们需要的功能。在极少数特殊的情况下，如果某个团队依赖于特定 API，那么这些 API 会被事先提供给团队，从而保证可以生成基于那些 API 的功能。功能小组会通过多种途径来跟踪所依赖功能的进展情况。例如：使用 TFS 来查询依赖功能的工作项、每周的协调会议等。频繁集成已完成功能的代码也是保证功能小组模型成功的一个重要因素。它使得依赖于其它功能的团队能够持续不断地得到它们所需要的功能。

微软多个产品线多次成功发布的实践表明敏捷开发以及功能小组模型能够很好地保证复杂软件产品的开发。

受访人简介：Ramesh Rajagopal 是微软亚太研发集团服务器与开发工具事业部的部门经理，在上海带领 Visual Studio 软件生命周期管理工具团队，帮助 C/C++ 开发人员在 Windows 平台上创建世界级的应用程序。Ramesh 多次受邀与独立软件开发商分享微软敏捷开发的经验。他的大部分职业生涯致力于包括 Visual Studio 在内的软件开发工具研发。Ramesh 拥有北卡罗来纳州立大学的计算机科学硕士学位。此前 Ramesh 曾在其部门博客上发表过主题为“Visual Studio Team Architect 团队的敏捷开发”的系列文章：第一、二、三部分。

采访人简介：滕振宇（Daniel Teng），Irdeto BSS 高级软件经理，CSP，敏捷教练，InfoQ 中文站特邀编辑。创建并领导Irdeto BSS 上海研发团队，负责大型付费媒体计费以及客户管理系统软件产品的开发。

感谢微软周京生、林俊彦对本文的翻译以及钱量、朱永泰、郑洁对本文的校译。

给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家加入到 InfoQ 中文站用户讨论组中与我们的编辑和其他读者朋友交流。