Visual Studio ALM Rangers 如何使用 Team Foundation Service 为 Visual Studio 11 做准备

本文是系列文章的一部分，在该系列文章中，Visual Studio ALM Rangers 提供指导，以帮助您解决复杂的实际环境问题。我们的目标是帮助您提高解决方案的内聚性和质量，以及整体的应用程序生命周期管理 (ALM) 过程。

回顾一下，Rangers 是一个专家团队，他们通过解决缺失的功能（功能差距和空白）、消除采用障碍以及根据实际经验发布最佳实践和指导，来促进 Visual Studio 产品组、Microsoft Services 和 Microsoft Most Valuable Professional (MVP) 社区之间的协作。

自 2006 年 Rangers 项目启动以来，我们已经交付了增强功能和最佳实践指导的组合。Rangers 和熟悉我们业务的人都知道，我们总是通过社区投票来选择我们的项目。换句话说，Rangers 决定了现实世界中需要什么，以便您能做得更好。但这有一个副作用。如果您查看一组此类项目——例如 Visual Studio 2010 系列——它们看起来就像是随机的内容集合，存在很多空白。这让我们回到了过去，以及我们有史以来最伟大的 Ranger “项目”，理解我们的 Visual Studio 11 就绪性阴谋。这是我们第一次决定通过设计实现全面覆盖，这催生了 20 个新的 Ranger 项目！随着如此多的并发项目，我们正在打破所有记录，但我们知道这是值得付出的额外努力的。对于 Ranger 来说，还有什么比在技术上为 Visual Studio 11 做好准备更重要呢？

构建软件解决方案的团队一直期望有一个开箱即用、高质量且可预测的应用程序生命周期管理流程和工具。Visual Studio 和 Team Foundation Server 历史上最大的挑战在于，技术通常会超前于 MVP 和 Microsoft Services 在实际领域的实践指导。所有产品都会遇到这种困境，这通常会导致实施的不确定性、挫败感和产品采用的阻碍。

Rangers 努力解决这一挑战；随着 Visual Studio 和 Team Foundation Server 2010 的发布，ALM Ranger 指导在产品发布后不久就随之发布。随着最新一轮的 Rangers 就绪性工作，我们正在同时发布 Visual Studio 和 Team Foundation Server 11 的带外工具和指导。产品团队称之为 SIM shipping 或同步发布。

正如图 1所示，我们与 Developer Product Evangelism (DPE)、MSDN 和 Patterns & Practices 密切合作，提供有关流程和方法、Team Foundation Server 规划和管理、Visual Studio 测试和架构工具、Team Foundation Build 和 Windows Azure 解决方案的指导。我们的目标是消除重叠的指导、重复的交付物和令人困惑的消息。

Rangers 解决方案的独特性在于，我们不关注产品有哪些功能，而是关注如何最好地使用这些功能，这基于该领域专家的经验，例如 Microsoft Services 中的 Rangers、Microsoft Most Valuable Professionals (MVP) 和 ALM 社区。

在我们之前的 MSDN 文章《Visual Studio ALM Rangers - 反思虚拟团队》中，我们详细介绍了我们命名为 Ruck 的流程。对于新读者来说，Ruck 被定义为“松散的 Scrum”。这个名字非常贴切我们的流程，该流程基于 Scrum 和 MSF，但绝不是纯粹的 Scrum。我们选择 Ruck 这个名字，是因为我们不想通过称我们的流程为它明显不是的东西来玷污 Scrum 纯粹主义者的心。Visual Studio ALM Rangers 使用那些在我们的非专注、非协作、通常反 Scrum 的项目中有效的工具和仪式。ALM Rangers 是 MVP 和 Microsoft FTE，他们有全职工作，确保他们有稳定的收入，并且他们参加 ALM Rangers 是出于对 Visual Studio 和 Team Foundation Server 的纯粹热情。这些 ALM Ranger 社区项目是他们的副业，因此他们的全职工作有时会阻碍工作。有时，这会带来重大的挑战。这让我们想起战场上一个队伍毫无区别地失去队员，而你只能处理它，因为任务很少会改变。

由于该项目的规模巨大，这次 Visual Studio 11 就绪性工作对使用 Ruck 的 Visual Studio ALM Rangers 产生了重大影响。通常，只有几个项目并行运行。现在我们有大约 21 个项目并行运行，并且有多个项目间依赖项。以前，使用 Ruck 的 ALM Ranger 项目是独立运行的，与其他项目没有或只有很少的依赖项。现在已经不是这样了。现在，许多项目依赖于其他项目的工作，而同步发布本身就依赖于所有项目。因此，我们每周安排一次 Ruck of Ruck 会议。此外，我们在 SharePoint Wiki 站点上显示一个 Ruck 状态页面。项目负责人，他们要么是经验丰富的 Ruck Masters，要么是正在接受培训的 Ruck Masters，每周更新状态表，提供简要的状态报告并列出任何障碍。如果没有障碍，我们不需要他们参加 Ruck of Rucks 会议。

任何人都可以访问 SharePoint 页面，查看另一个项目的状态。我们通过将所有人在 Team Foundation Service Preview 中作为 Reader 访问所有项目来实现透明度。我们的目标是实现完全透明，并减少 ALM Rangers 的带宽消耗。因此，我们不需要他们参加 Ruck of Ruck 会议来告诉我们他们做了什么、接下来要做什么以及他们的障碍是什么。我们可以轻松地从 Team Foundation Service Preview 和 SharePoint Wiki 中获取这些信息。会议的重点是处理我们无法通过电子邮件解决的障碍。

新版本 Visual Studio 的发布需要我们有熟悉新功能的 Developer Division 的项目经理。事实上，他们可能已经为 Visual Studio 11 定义了这些新功能，这使他们成为担任产品所有者的绝佳人选。值得注意的是，Microsoft Developer Division 如何通过为每个 Ranger 项目提供一名项目经理来扮演产品所有者的角色来支持 Visual Studio ALM Rangers。过去，我们经常有项目经理担任 ALM Ranger 项目的产品所有者或主题专家，但从未有如此多的项目经理同时担任。

产品所有者的职责是帮助定义和批准我们的 Epics 和用户故事。由于他们忙于发布下一个版本的 Visual Studio 11，我们也尽量减少他们的带宽消耗。然而，许多产品所有者非常认真地对待他们的职责，并出席所有会议，即使这些会议在深夜进行（取决于他们的时区）。Visual Studio ALM Rangers 认识到他们的贡献和奉献精神，并非常感激有他们在团队中。

Visual Studio ALM Rangers 必须以前所未有的方式扩展其工作，新成员以前没有这样做过。鉴于此，我们进行了 Ruck Master 培训，并正在确定潜在的候选人。其中一些候选人发现，成为 Ruck Master 并不容易，这个角色不适合他们。除了 Ruck Master 角色外，项目负责人还在团队中有其他职责。当 Ranger 第一次担任负责人和 Ruck Master 时，会为项目分配经验丰富的 Rangers 作为导师。随着我们推进这次就绪性工作，我们正在了解我们需要适应的地方和需要改进的地方。通过回顾、Ruck 改进社区和虚拟 Ranger Talks 来获得见解和改进。与 Scrum 一样，Scrum Master 应该只有一项职责，我们也了解到这同样适用于 Ruck Master。然而，ALM Rangers 没有能力为每个项目配备专门的 Ruck Master。随着我们涌现出新的 Ruck Masters，这种情况将来会改变。

Team Foundation Service Preview 对我们的流程产生了重大影响。预览版突显了我们都知道的一点；在追求敏捷性时，工具不是问题，而是人与文化。通过 TFS Preview 的工具，我们可以快速发现需要关注的问题。几个小的行为促使我们改变了将 Product Backlog Work Items 添加到 sprint 的方式，但这本身并不是流程的改变。预览版中的功能，例如出现在工作项列表上方的燃尽图，影响了我们站会团队进度的可视化。燃尽图显而易见；当你的 sprint 面临迫在眉睫的危险时，你无法否认，正如你可以在图 2 中看到的。

这只是一个例子。随着我们进行项目设置并向您展示 Rangers 如何使用工具，将出现更多示例。所以，让我们为我们的团队创建一个Team Foundation Service 中的环境，作为“Rucking”的内部测试游乐场。

注意：该环境基于 Team Foundation Service Preview，外观和感觉在未来可能会发生变化。有关预览的更多信息，请联系作者。

但是，在我们开始之前，您可能想花时间观看这些 Channel9 视频，这些视频涵盖了 Team Foundation Service Preview 的详细信息，并为您提供了有关本文中介绍的设置和配置步骤的更多信息。

1. 引言
2. 入门
3. 管理安全性
4. 敏捷项目管理
5. 使用 Visual Studio、Microsoft Test Manager 和 Eclipse
6. 团队生成

步骤 1 – 注册 Visual Studio Team Foundation Service 帐户

我们首先访问 Team Foundation Service Preview (https://tfspreview.com)，定义一个帐户名，提供一个有效的邀请码并接受许可协议，如图3 所示。请仔细考虑您的 URI 名称，因为它不可更改，并且将成为您与团队共享的 URL。

步骤 2 – 创建团队项目

创建帐户和关联的默认 Team Project Collection 后，我们为团队创建一个 Team Project。有关指导，您可以查看 Team Foundation Server Planning Guide，网址为 http://go.microsoft.com/fwlink/?LinkID=230947。该指南涵盖了服务器、Team Project、Team Project 和 Team 设计的许多场景。接下来我们纠结的问题是，是为每个 Ranger 项目创建一个 Team Project，如图 4 所示，还是创建一个 Team Project，其中包含多个 Team，如图 5 所示。

图 4 – 多 Team Project 场景

图 5 – 单 Team Project 场景

我们选择创建多个 Team Project，为 Ranger 项目提供了清晰的边界，并为将来将 Team Project拆分到单独的 Team Project Collections 提供了可能性。同样，花些时间考虑 Team Project 名称，因为它也是不可更改的。

注意：另请参阅 Ranger 项目的需求管理 – 我希望我们对 Team Project 做得更不同，其中讨论了我们未来希望对 Team Project 拓扑进行的更改。

创建 Team Project 时，如图6 所示，请注意所花费的时间，与我们习惯的本地服务器的创建时间相比，这将是一个惊喜。或者，您可以关闭“创建新 Team Project”弹出窗口，同时继续工作，项目将在后台创建。或者，您可以专注于此窗口并监视进度条，如图 7 所示。

步骤 3 – 创建一个 Team

接下来，我们切换到管理模式，创建一个名为ACV_TFSTeamProjectGuidanceTeam 的 Team，如图8 所示。这启用了新的功能，例如敏捷规划工具（backlog、board 等）。

我们通过添加团队成员来完成团队创建。我们使用他们的 LiveID 凭据，但在未来，可能会支持其他身份验证凭据。最终结果是一个特定于项目的 Team Project，其中有一个 Team 和七名成员，如图9 所示。

步骤 4 – 定义迭代和 Team 焦点

首先，我们为迭代分配开始和结束日期，如图10 所示，并为 backlog 选择一个迭代路径，如图11 所示。请注意，能够为迭代分配开始和结束日期是 Team Foundation Server 11 中的一项新功能。开始和结束日期允许弃用我们在以前的 Visual Studio Scrum 流程模板中使用的 Sprint 工作项类型。

图 10 – 定义迭代日期

图 11 – 为 backlog 定义迭代路径

步骤 5 – 定义 Product Backlog

接下来，我们定义 Product Backlog，如图 12 所示，以及相关的任务。要确定 backlog 的优先级，您可以将项目拖放到列表中。Backlog 优先级是此最新版本中的隐藏字段，您可以但应避免手动编辑优先级。与以前的 Team Foundation Server 版本一样，您可以选择 Web 应用程序、Visual Studio Team Explorer 或 Excel 作为操作 backlog 的工具。

步骤 6 – 定义 Sprint Backlog

为了完成设置管理任务，我们选择一个 sprint——在此例中是 sprint 7 —并以每工作日小时为单位定义团队成员的能力（1），如图13 所示。查看已定义的容量，兼职带宽对 Ranger 的一项挑战变得显而易见，其中 sprint 的（2）总容量和（3）每资源容量都清晰显示。

单击“内容”，我们将看到所选 sprint 的 Product Backlog 项目和相关任务，如图14 所示。

Ruck 的一个关键原则，与 Kanban 和 Scrum 一样，是工作可视化。我们都明白可视化为何有效，因为对我们许多人来说，这是沟通的关键；我看得比听得更清楚。我们在预览版中利用可视化进行站会，以确认对“你做了什么”、“你接下来要做什么”以及“是否有障碍”的回答。图 15 显示了我们用作站会关键视觉元素的任务板。任务板不仅为沟通提供了出色的可视化效果，它还确认了所说的话，并且是对那些可能交付不足的人的激励。但它也是一种快速便捷的拖放任务从一列到另一列以匹配会议中所说内容的方式。图15 中的面板适用于整个团队。如果您单击“团队成员”，面板将更改为显示按团队成员而非按 Product Backlog 项目划分的任务。会议开始后，我们切换到“团队成员”视图，以便您可以看到正在说话的人的任务。

要近距离查看燃尽图，请单击燃尽图图像。您将看到燃尽详情的全面视图，如图16 所示。这在站会开始时非常有用，以便大家可以快速了解当前 sprint 的状况。

如前所述，工具不是问题——人才是。让人们花两分钟更新他们的工作项似乎就像让他们纳税一样，我们常常感觉自己像 Ruck 警察。这并不是什么新鲜事，只是引起变革和培养习惯的一部分。但是 Team Foundation Service Preview 允许在会议期间快速调整工作项，并立即反映更改。Ruck 要求使用工具，因为我们不是同地办公；我们没有每日站会；而且我们不是全职的，因为这是我们都在做的副业。有人可能会争辩说，MSF、敏捷宣言和 Ranger 宣言意味着当我们说我们会做一些工作时，我们是认真的，并且也意味着我们可以依靠每个人更新他们的工作。

Team Foundation Service 环境在 Visual Studio 11 就绪性内容的开发中起着至关重要的作用，既作为所有 Ranger 团队的支持性运营基础设施，也作为 Team Foundation Server 11 和 Visual Studio 11 的内部测试环境。

我们使用此软件即服务解决方案的独特体验、我们的成功案例和最具挑战性的困难，以及我们的Team Foundation Servce 指南将是我们未来文章的重点。

Bijan Javidi 是 Visual Studio 的首席架构师，也是 Visual Studio ALM Rangers 的领导者。他在加入 Microsoft Consulting Services 之前，从事了二十年的应用程序开发咨询工作，那时正值 Y2K 恐慌，客户正在经历 Y2K 恐慌。2006 年 1 月，他从德国来到位于雷德蒙德的总部，加入了 Visual Studio 团队。

Brian Blackman 是 Microsoft Services Partner ISV 团队的首席顾问，专注于影响我们 ISV 合作伙伴在工程和市场上的成功。他拥有 MBA 学位，是 CSM、CSP、MCSD (C++)、MCTS 和 Visual Studio ALM Core Ranger。他花费时间编写代码、创建和交付研讨会以及在各种领域和所有 ALM 相关事物上进行咨询。

Jeff Beehler 是 Visual Studio 的参谋长，负责协调 Visual Studio 工作从规划到执行再到发布的许多方面。因此，他参与了所有发布 Visual Studio 的团队，并且为了完成他的工作，他“内部测试”了系统的许多部分。他曾是原始 Visual C++ 1.0 团队的一员，并乐于参与将 Visual Studio 扩展到“仅仅”编写代码之外的工作。

Willy-Peter Schaub 是 Microsoft 加拿大开发中心的 Visual Studio ALM Rangers 的高级项目经理。自 20 世纪 80 年代中期以来，他一直致力于软件工程的简洁性和可维护性。他的博客地址是 blogs.msdn.com/b/willy-peter_schaub，Twitter 是 www.twitter.com\wpschaub。

感谢以下技术专家审阅本文：Bill Heys、Patricia Wagner、Gregg Boer