本文是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的计划会需要更多的时间。

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

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

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