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

《使用Visual Studio实现敏捷软件工程——从概念到持续反馈》是一本深入探讨Visual Studio TFS特性的新书，它阐述了怎样帮助敏捷团队更好地管理应用程序生命周期。该书的作者是Sam Guckenheimer（产品负责人，微软Visual Studio产品策划）和Neno Loje（应用程序生命周期管理ALM自由顾问，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帮助许多公司建立了团队环境和软件开发流程。