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

    年初，应InfoQ中文站邀请，Ramesh Rajagopal （的作者）和他的团队在“敏捷Scrum实战营”活动期间接受了InfoQ中文站的邮件采访。本文由滕振宇先生根据Ramesh的回答和团队的翻译编辑而成。如需转载，请先与联系。

     原文地址：

    在采访中，Ramesh从项目管理、需求管理以及技术架构控制等方面分享了他所带领Visual Studio软件生命周期管理工具团队使用敏捷方式组织管理大规模软件团队方面的经验。本文是依据邮件采访整理而成，为保持现场感，文中使用{dy}人称指代微软亚太研发集团服务器与开发工具事业部。

    微软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的一个商业目标是 :“使软件开发团队采用正确的方法来编写软件”。从这个高层主题可以创建出几个价值主张。其中一个主张就是：“使软件开发团队通过构架和模型工具来管理软件的复杂性”。它还可以再进一步细分为：“使软件开发团队能够理解和分析已有的代码”、“使软件开发团队能够验证它们的代码是否符合指定的构架设计”、“使软件开发团队能够理解他们所在的领域和需求，并设计出期望的构架”等主题。这些主题分配给各个功能小组。在设计计划里程碑{zh1}阶段，功能小组和产品负责人（负责某一特定的价值主张）相互协作一起定义出产品待开发事项。它包含了一组划分好优先级的用户故事，期间会充分听取团队成员的意见和反馈，并最终与产品负责人进行确认。 这实质上就是产品的发布计划，并用它来进行跟踪和管理产品的开发。产品待开发事项中的用户故事也是以工作项的形式保存在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来查询依赖功能的工作项、每周的协调会议等。频繁集成已完成功能的代码也是保证功能小组模型成功的一个重要因素。它使得依赖于其它功能的团队能够持续不断地得到它们所需要的功能。

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