新书：使用 Visual Studio 实现敏捷软件工程

《使用 Visual Studio 实现敏捷软件工程——从概念到持续反馈》是一本深入探讨 Visual Studio TFS 特性的新书，它阐述了怎样帮助敏捷团队更好地管理应用程序生命周期。该书的作者是 Sam Guckenheimer（产品负责人，微软 Visual Studio 产品策划）和 Neno Loje（应用程序生命周期管理 ALM 自由顾问，TFS 专家）。

InfoQ 联系了 Sam 和 Neno，和他们广泛探讨了新书的内容以及 VS TFS 的其它主题。

InfoQ：敏捷方法通常要求我们使用最小工具集（比如电子表格），这样我们才不会在学习如何使用工具软件上花费太多的时间。然而，Visual Studio + TFS 是端到端的应用程序生命周期管理系统，你们为何认为它们同样很适合敏捷团队使用？

Sam Guckenheimer: 我先具体谈论下电子表格的问题，然后再具体回答您提出的问题。Excel 是一种电子表格软件，它同时也是 Team Foundation Server 的主要客户端。因此，敏捷团队不仅能使用最熟悉的工具，还能享用 TFS 以及 Visual Studio 其他组件提供的历史、规模、完全生命周期等方面的功能。

您的问题暗示只是在项目初期团队才会采用敏捷实践，他们不关心历史、规模以及广泛意义上的应用程序生命周期。而我们的经验并不是这样的，这和分析家 Forrester 和 Gartner 等人的报告也不相符，在敏捷会议或其他类似会议的经验报告中你也听不到这种情况。敏捷在于自我管理，在于多学科人员组成的团队不断努力提高他们的价值流。

我们能在 20 分钟内就让用户成功使用上 TFS 2010，而对于 Team Foundation Service（部署在 Windows Azure 上的版本）则只需 1 分钟。所以 TFS 不会成为团队生产效率的障碍。

Neno Loje: 如果你想研究（和管理）产品的整个应用程序生命周期，以找出能着手改进工作流程和减少浪费的潜在环节，你就需要获得尽可能多来自数据存储中心的生命周期数据。你当然希望这样大量的数据采集都可以自动完成，数据量越多越好。
至于客户端工具，你仍可以使用能满足需求的工具。使用非常简单的电子表格或者使用墙壁上的简单任务板也没什么大问题——但把数据存储在“筒仓”中的话，你能获得的成就就非常有限了。数据应当存储在数据中心中——这就是 Team foundation Server 提供的功能。

InfoQ：庞大软件开发项目上的敏捷实践能因为使用更好的工具而受益吗？

Sam Guckenheimer: 当然可以。向客户高效交付价值的主要障碍之一就是，集成了不合适的工具，从而造成浪费。Kent Beck 在他的论文《敏捷开发工具》中阐述了一些这样的问题。面对这样问题，经典反映是以手工处理应付，但结果只会造成更多的浪费，使问题更加恶化。只有当项目之间存在可信赖的透明度、集成以及自动化的时候，协作的各个团队之间存在无缝的工作流程，才能在一定范围内实现敏捷。

InfoQ：你们建议本地协作的微型敏捷团队使用 Visual Studio ALM 工具吗？

Sam Guckenheimer: 我们关注由超过三人组成的团队，这和 Scrum 建议的 6±3 独立团队成员数是一致的。

Neno Loje: 我研究过许多小团队，也在一些小团队中工作过。我发现小团队和大团队一样，要解决同样的问题和挑战，而小团队在人员数量和时间上更有限。特别是在这种情况下，TFS 的自动化功能对小团队很有价值，因为他们没有时间去研究那些不知是否能满足他们需求的工具。

对于您提的是否建议敏捷团队使用 ALM 解决方案的问题，我认为关键点不在于团队大小，而在于团队的需求是什么。事实上曾经在一个两人团队向我说明他们面对的挑战后，我坚信他们需要像 TFS 这样的 ALM 解决方案。因为他们人数很少，所以必须谨慎地考虑怎样记录代码库的修改，怎样才能和外包公司一起维护一条清晰明了的协作流程。

InfoQ：在书中你们提及如何让“完成”标准更有效，以及技术债务（technical debt）的相应风险。能否请你们进一步阐述这些主题？

Sam Guckenheimer: 技术债务是妨碍团队交付价值的罪魁祸首。它导致低质量、不可预测、无法正常运作的组织、低落的士气、延后的日程安排等等问题。

在这里我们再次运用了 Scrum 以及其他敏捷实践的精华。Visual Studio 产品线（具体讲是 Team Foundation Server）的关键扩展是我们使完成标准（Definitions of Done，DoD）自动化。在过去，DoD 通常通过检查列表处理，这在以前很合适。但是随着实践的深入，持续集成等概念出现，使得某些 DoD 自动化达到了一定层次，特别是和构建相关的单元测试。

我们认为这是更宽泛模式的一个实例，DoD 可应用于许多周期中，只要可能，这些步骤就应该自动化。这样，它们就能够透明化、可信赖以及低开销。在我们的新书中，我们尽量围绕生命周期以及每个周期的 DoD 来组织章节。

InfoQ：关于源代码控制，TFS 没有其他很多 DVCS（分布式版本控制系统）提供的特性，其中之一就是离线工作特性。将来你们在这些方面会有所改进吗？

Sam Guckenheimer: 我们已经在 TFS 2010 中采用了轻量级分支，这极大提高了离线工作的用户体验。但确实如你所说，它还不是完全的 DVCS。我们一直在不断改进产品，但目前还远不是要做什么重要声明的时候。

InfoQ：VS TFS 工具链是高度可定制的，面对这么多选项，也许用户会困惑使用默认好呢，还是自定义功能好？你们建议在什么时候团队应该开始自定义功能（比如处理模板功能）？

Sam Guckenheimer: 用户需要自定义功能一般有以下两个原因：

1. 需要和其他系统交互，可能是历史遗留系统或 TFS 范围之外的系统。比如，许多用户想要将 TFS 连接到桌面帮助系统以跟踪客户信息；而 SI 拥有客户账单系统等等。
2. 需要使用 TFS 实现内部流程以作为我们标准流程模板的扩展。

一般来说，我们建议在自定义功能前三思而后行。我们允许并鼓励流程改进，但不鼓励不加思索地随意修改。我们相信过程模板代表很好的实践，同时我们也正和 Scrum.org 紧密合作，其中之一是我们正在合作实现优秀的 Scrum 模板。

Neno Loje: 考虑到用户可能没完没了地思考如何有效地自定义功能，从这个角度可以说每个可自定义功能的复杂系统都是个危险品。很多公司倾向于遵循常规的工作方式，并觉得这是很不错的方式。作为敏捷团队，可以先直接在 TFS 中使用微软提供的三个预定义流程模板（Scrum，Agile 和 CMMI）中的一个，之后在回顾阶段（retrospective）思考流程是否有可以改进的地方，并决定是否要做改动（增加或删除字段和规则）。启用流程改进的 backlog 是个不错的主意，这样的话你可以跟踪改动。如果你头脑中有改进流程的具体而清晰的目标，那么自定义流程常常是很容易的事情。如果一开始你就试图自定义最合适的流程，则会很困难和很花时间，最终的结果可能是造成的浪费比创造的价值多。正如 Scrum 所建议的，一开始就应该采用 sprint，之后可以不断做调整。

InfoQ：自动化的场景 / 负载测试通常需要高成本的预投资，并且一旦有哪怕极其微小的行为上的改动，就要花费很大的维护成本。根据你们的经验，有什么衡量标准能够帮助我们确定什么时候采用自动化测试才是合理的吗？

Sam Guckenheimer: 这两个问题很好。维护自动化测试的开销不应该成为改进被测试软件的障碍，所以你必须将软件设计成有利于测试的（比如可以采用 MVVM 模式），而将测试设计成有利于重构的。因此我们建议：

1. 前期采用低投入的负载测试以试探系统架构
2. 编写代码进行单元测试
3. 前期探索式测试
4. 只当配置以及回归测试高度可复用时才有选择地采用 UI 自动化测试

InfoQ：Scrum 另外强调在每个 sprint 末尾“潜在可交付”软件的重要性。但在巨大开发工作量以及存在几个项目 / 产品间的依赖的情况下，这样做实际上可行吗？

Sam Guckenheimer: 我想您的意思是，应该怎样处理团队间的依赖关系，以及会对 sprint 目标产生什么样的影响？显然，你必须调整 sprint 目标和日程安排以使各个团队间能协同工作，而 TFS 确实能跟踪 PBI（产品需求列表）间依赖关系。当团队 B 依赖于团队 A 时，团队 B 可能需要创建一个 mock 或者 fake 以模拟团队 A 尚未提供的服务 / 组件，这样才有可能在 Sprint N 阶段达到潜在可交付，之后在 Sprint N+1 阶段将 mock 替换为真实的服务 / 组件。这种情况在整个软件过程中都会发生，这也是使用 TFS 跟踪组合 backlog 的另一个原因。

InfoQ：在书中你们提到在 Pex 的帮助下 VS 怎样能够创建高覆盖率的单元测试初始集，现在能说一说具体是怎样的吗？

Sam Guckenheimer: T 简单地回答就是：Pex 采用代码分析技术找出未覆盖的代码路径，然后产生覆盖这些路径的单元测试。这样做并不是意图替代 TDD（测试驱动开发），而是作为某些情况下的测试方案选项，比如没有测试代码的历史遗留系统。您可以访问这里以查看更多信息和亲手试一试。

InfoQ：VS 2008 针对不同的角色（测试人员、架构师等）附带了多个 SKU。而这些在 VS 2010 中发生了变化，VS 2010 只有 3 个 SKU——专业版、高级版旗舰版。这和 Scrum 提出的每种工作每个人都要通晓和参与一些的建议有关系么？

Sam Guckenheimer: 是的，差不多是这样。完全公开地讲，我们还有一个版本叫 VS 测试专业版，这个版本的功能被包含到 VS 最终版中。我们的确合并了架构师 SKU 和开发者 SKU 两个概念——坦白讲这种区分在很多情况下都是糟糕的，我个人反对这样区分，因为现今团队由多学科专业人员组成，离散角色的概念已经显得很过时。至于测试用例，我们知道领域测试人员不编写代码，也不用这个 IDE 作为他们的工具，我们为他们独立创建了独特的用户体验。

InfoQ：智能 / 历史跟踪调试在各种大小的项目中都是对开发者很有用的特性，然而它只包括在以大型项目为目标的 Visual Studio 旗舰版中。这样做有什么特别原因吗？

Sam Guckenheimer: 确实这样，这是因为商业上的原因。我们将功能区分到不同级别的 Visual Studio 版本中，客户选择购买他们需要的版本。值得注意的是，体验版所有功能在 BizSpark 计划下可以免费使用三年，在学术协议下学生 / 学校可以永久免费使用。

InfoQ：VS 下个版本的一个有趣特性是管理利益相关者的反馈。你们能做进一步阐述吗？

Sam Guckenheimer: 基本的想法是 PBI 可以将反馈工作项（Feedback Work Item）作为子项。我们将建立通过邮件方式从利益相关者请求反馈（对故事板和新发布的工作软件）的工作流程。之后将按照和 PBI 的相互关系捕获反馈。因为所有这些都是在 TFS 中管理的，你清楚是哪个 PBI，也清楚是哪次软件构建，两方面都有完全的历史信息。

Neno Loje: 我们都希望最终发布的软件就是客户正真想要的，而不希望发布后才发现客户其实想要别的东西。过程中不断发布产品让客户试用，这是我们通常所说的持续发布，这是正确方向上的第一步（TFS 帮助你将这一步自动化，所以这事很容易办到）。下一步是在不同阶段建立客户紧密反馈环路，以保证团队在做正确的事情并始终关注已发布的产品是否对客户产生价值。这个阶段被称作持续反馈。

InfoQ：我们看到 TFS Cloud 的早期预览版已经发布，你们在书中也简单提到了。你们认为在云趋势下会有什么重大改变呢？

Sam Guckenheimer: 我在上面已经提到，启动只需要使用大约一分钟时间。TFS 的目标是为软件开发团队提供最完整的合作站点。我们每个月都会更新服务。第一个重点是在大用户量尺度上达到 LAS 运维标准（99.9% 正常运行时间），我们已经接近这个目标。我想明年你将会看到一系列新功能的发布通知。

Neno Loje: 云服务的美妙之处在于你不必像自己安装和操作服务器时那样关心基础架构问题。特别是对于小团队，这极大降低了负担。想象一下，你和我现在正决定一起开始一个小项目——我们将怎么开始合作呢？使用云上的 TFS 我可以在几分钟（可能是几秒）内添加所有人到项目中，然后不仅在代码层面一起工作，同时也能共享所有工作项，比如需求列表以及自动化构建结果。

InfoQ：在书中你们向读者介绍了在 VS 2005 发布之前微软自己遇到的问题以及帮助解决这些问题的七种改变。工具在把组织推向更好的实践上有多重要呢？

Sam Guckenheimer: 工具（tooling）与实践的变化并肩行走。两者必须同时进行并创建良好的周期，还要根据具体环境做相应调整。例如，附加在 TFS 2010 中的“Gated-Check-In”特性就是为了实现持续集成 / 持续交付实践所做的工具。经典 CI（持续集成）无法做到这样，因为 Main 经常挂掉。但我们确实需要一种方式能够在每次签入最新代码时运行测试，所以我们构建了一中工具用于在签入代码之前进行编译和测试，它类似于 DVCS，但在代码提交上更加及时。这是一个持续的周期——对我们有用的东西我们也会提供给客户使用，最初通常是以 Power Tool 或 Feature Pack 的形式。大约 95% 的客户都预定了新特性，他们能及时地获得这些特性。

InfoQ：你们还提及在一些成功之后可能会突发一些破坏性的问题。比如，有人在主要里程碑之后变换工作是很常见的事情。你们有采取措施以应付未来可能出现的问题吗？

Sam Guckenheimer: 是的。我们正努力进一步搞清楚使我们获得成功的因素以及还存在的不足，我们正在思考需要什么样的知识和改进来强化某些周期。我们把这称为“为自己投资”。例如，我们在组织中举办 Scrum 和产品负责制培训，并把这视为组建团队的一种方式。在工程实践中，我们已经确保相关人员通晓性能工程，我们也在出台 DevOps 课程以供管理层参考和学习。在朝着持续产品交付不断前进的同时，我们也在努力进一步靠近持续组织优化。目前谈论这些努力是否成功还为时尚早，但目前的表现还不错。这是一个巨大的共享管理挑战。在读了 Kahneman 的著作后，我认为回归平均值是事件的通常过程。我们正努力证明持续改进是做好工作的最佳途径。

关于作者

Sam Guckenheimer 是《使用 Visual Studio 实现敏捷软件工程——从概念到持续反馈》一书的作者。Sam 目前是微软 Visual Studio 产品线的产品负责人。在该职位上他作为首席客户支持，负责这些产品的发布策略。在 2003 年加入微软之前，Sam 是瑞理软件有限公司（Rational Software Corporation，现在成为 IBM 的 Rational 部门）的产品线策略主管。Sam 和他的妻子以及三个孩子目前居住于西雅图，他们建造了一座环保型房屋，在 Metropolitan Home 和 Pacific Northwest magazine 两篇文章中有对这所房子的描述。

Neno Loje 是《使用 Visual Studio 实现敏捷软件工程——从概念到持续反馈》一书的作者。他目前的角色是应用程序生命周期管理（ALM）自由顾问和 Team Foundation Server(TFS) 专家。Neno 利用 Visual Studio(VS)/TFS 帮助许多公司建立了团队环境和软件开发流程。

查看英文原文： New Book: Agile Software Engineering with Visual Studio

感谢侯伯薇对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博（ @InfoQ ）或者腾讯微博（ @InfoQ ）关注我们，并与我们的编辑和其他读者朋友交流。