基于 Visual Studio 2010 进行敏捷 /Scrum 模式开发

根据 Forrester Research 今年第二季度的一份研究报告，在超过 1000 名专业开发人员中，采用敏捷模式进行软件开发的已经有 10.9% 采用了 Scrum 模式，在所有的敏捷开发模式中名列首位，而在所有的软件项目管理模式中，敏捷模式更是被 35% 的开发人员所采用。当然，研究报告为我们呈现的仅仅是一个统计学的观点，到底你的开发团队应该采用什么样的开发模式，这还是要根据各自不同的开发环境，人员构成，公司架构以及文化背景来决定。

图 1：Forrester 关于敏捷模式的调查报告

Visual Studio 2010 是微软在 2010 年 4 月发布的全新一代的集成开发环境，配合同时发布的 Team Foundation Server 2010（TFS——团队服务器） ，为开发团队提供了全面的应用程序生命周期管理（ALM）工具和平台。在 2010 这个版本中，对于敏捷，或者说 Scrum 模式的支持是前所未有的。虽然微软的 Visual Studio Team System 从 2005 年开始发布的时候就提供了敏捷流程模板（也就是 MSF Agile）模板，但是 2008 版之前的这个敏捷流程模板都是基于 MSF（微软解决方案框架）的；这个框架是微软针对自己的研发团队的最佳实践进行抽取总结出来的，与广大敏捷开发社区里面所流行的很多敏捷方法并不是很契合，造成了开发团队在实施的时候有很多不适用的地方。因此，微软在开发 2010 版本的过程中，大量的听取了敏捷开发社区中的声音，在自己的 MSF Agile 5.0 的模板中进行很多针对敏捷，更确切的说是 Scrum 开发模式的改进，使得 2010 版本中所集成的 MSF Agile 5.0 的模板非常适合我们来进行 Scrum 模式的开发组织。当然，微软的产品为了追求通用性，在 MSF Agile 5.0 的模板中并没有完全采用 Scrum 模式通行的名称和流程；同时，微软在两周前又发布了一个纯粹的 Scrum 流程模板以供那些希望完全使用 Scrum 模式的开发团队使用，当然这个模板现在仍然是 Beta 版。

我个人认为，开发团队采用哪一个模板并不是最重要的，重要的是我们需要在开发过程中不断地改进过程，并对这个模板进行定制，以便适合我们自己的开发流程。这也是为什么 TFS 所提供的是一个模板，因为它的目的就是希望我们在这个模板的基础上不断的改进，最终找到适合

自己开发团队的流程。其实这也很符合 Scrum 模式的理念；简单一点来说，Scrum**** 模式是一种针对复杂项目的流程组织方式的框架，其目标是为了让我们开发出更高质量的软件产品。围绕的这个目标，Scrum 模式为我们提供一个团队模型，一系列工具和一个简单的流程。在这样一个框架之下，Scrum 模式要求我们不断地改进流程以达到适合团队的最佳状态，这种对改进的要求也是 Scrum 模式区别于其他开发流程的重要特点之一。

为什么 Scrum 模式适合软件开发？

软件行业至今已经有超过 40 年的历史，很多在软件工程中的管理方法都是在不断摸索中改进而来的。早期的软件行业由于规模有限，绝大多数属于作坊型，几个人在一起靠着自己的聪明才智创造出软件产品；但是当团队规模不断扩大的时候，开发人员开始需要一种模型来组织越来越庞大的团队，满足越来越复杂的需求。因为没有经验可循，软件开发团队将很多传统工业工程的方法借鉴到软件行业，因而出现像“瀑布式”的模型。“瀑布式”模型要求我们在实际的开发工作开始之前进行很多非常细致的设计和计划，力图将不可控的开发过程细化成可以控制的颗粒，以达到对复杂项目的总体控制目的。但是“瀑布式”模型忽视了软件项目的一个本质特点，那就是需求的不确定性；我们不可能像造汽车一样在上生产线之前把所有的零件都设计好，所有的流程都规定好，再进行装配；因为任何软件在实际进行编码之前都没有人知道这些代码应该如何实现，而且每一个开发人员的水平不同，习惯不同，写出的代码也是不同的；再加上客户对于软件的需求也是在不断变化的，一年之前的业务流程很可能在一年之后就产生的变化，如果还按照之前的需求进行开发，那么交付的时候肯定是无法满足要求的；更重要的事，在客户没有看到或者实际操作软件产品之前，他们永远也不能明确地告诉你他们要的到底是什么。因为这种种原因，造成了软件开发不可能采用传统的工程方法进行组织，因为其本身是一种需要依赖于开发人员智慧的探索性行为，也造成了我们的软件项目中有很大一部分是失败的。

Scrum 模式的出现正是基于对于软件开发行为本质的认识，提供了一种松散的框架，让我们使用一种探索性的流程方法来组织本来就是探索性的开发过程；从根本上满足了软件开发本身对于流程的需求。这种方法论实际上是基于爱德华? 戴明所提出的戴明环的管理方法；戴明环理论提出：人类在进行任何复杂活动时，获得成功的最有效过程要经过：Plan 计划– Do 执行 – Check 检查– Act 改进，四个子过程，并不停的迭代以便找到最佳的方法来解决问题。这个理论不是针对软件开发提出的，但是软件开发本身其实就是最典型的复杂活动。

图 2：Scrum 的流程

这里我们再回头看看 Scrum 的流程，Scrum 的流程主要包含以下内容：

• § Release/Sprint Planning：发布 / 迭代计划
• (C&P) Daily Scrum：每日回顾
• (C&A) Sprint Review：迭代产品检查
• (A) Sprint Retrospective ：迭代流程检查

我们可以看到，Scrum 模式的流程与戴明环仅仅相扣。有很多认为敏捷模式会弱化计划的作用，其实不然，敏捷模式更加强调计划，而且强调更加频繁的计划，比如：每日回顾这个流程就要求我们的团队每个成员每天早上用 15 分钟的时间来回答 3 个问题：

1. 你昨天做了什么？
2. 你今天计划做什么？
3. 有什么问题阻碍你的开发进程？

其实这正是对于之前开发内容的检查，同时也是对后续开发内容的计划过程。

Scrum 模式需要怎样的工具来实现？

对于使用什么样的工具来实现 Scrum 模式，现在也有很多不同的观点。其实有很多人认为白板和即时贴就是最好的工具，其实对于小型团队来说这的确是最有效而且最经济的方法。但是如果考虑到软件公司的管理需求（工作量统计等），远程团队，开发工具集成，代码质量控制，发布后期支持等等；我们还是需要一个高度集成的平台和一整套工具来支持我们的开发团队。

图 3：白板和即时贴

Visual Studio 2010 所提供的集成开发环境可以满足我们以上的一系列需求，帮助我们的开发团队更好组织开发，帮助我们的管理层更好地掌控开发过程，帮助软件公司开发出更高质量的产品。

Scrum 模式对于工具的要求，主要集中在以下一个方面：

1. 团队组织：满足 PO （产品经理），Scrum Master （流程经理）和开发团队管理，以不同的权限访问团队项目并对不同角色提供个性化的信息支持的能力。
2. 产品需求记录和跟踪：对于 Product Backlog Item （PBI 产品需求列表）的添加，编辑，优先级排序以及交付开发团队以后进行跟踪的能力。
3. 流程管理：满足 Sprint Planning, Daily Scrum, Sprint Review 和 Sprint Retrospective 这些流程中对于信息共享，信息转移和跟踪的能力。
4. 产品质量：在整个开发过程中，配合 Scrum 模式达到产出高质量代码和产品的能力。

下面我们就看看 Visual Studio 2010 系统在这 4 个方面如何满足 Scrum 模式的需求，并协助我们开发出高质量的产品。

Visual Studio 2010 上的 Scrum 团队组织

一个完整的 Scrum 开发团队主要由以下角色组成：

1. Product Owner （PO 产品经理）：我喜欢把 PO 翻译为产品经理，因为 PO 的工作职责就是向客户和干系人收集产品需求，进行排序并保证开发团队按照干系人对需求优先级的要求进行交付。
2. Scrum Master （SM 流程经理）：对于 Scrum Master 我一直没有更好的翻译，将其译成为流程经理是因为这一角色要保证团队按照 Scrum 的方式来组织开发，并协助团队和 PO 进行有效的沟通，解决团队所遇到的问题。Scrum Master 和项目经理的区别在于，他更加倾向于保证开发流程的完整性而不是倾向于满足客户 / 干系人的需求。
3. 开发团队：开发团队在 Scrum 模式中是作为一个整体出现的，一般来说团队的大小控制在 3-7 个人的规模；团队作为一个整体向 PO 负责，而不是每个人对于自己的任务负责。

在 Visual Studio 2010 系统中，使用 TFS 服务器基于角色的权限控制，我们可以很方便地定义出不同的权限范围。当然，最简单的方法是把 Scrum 团队的角色和 TFS 的默认角色之间进行映射。

图 4：TFS 团队项目的默认角色

Scrum**** 团队角色

TFS**** 团队角色

Product Owner

Contributor

Scrum Master

Project Administrator

开发团队

Contributor

Builders

Project Administrator

根据团队不同人员的职责具体分配

项目干系人

Readers

如果客户愿意更直接的参与项目，可以允许他们直接访问 TFS。

表 1：Scrum 团队和 TFS 团队角色映射

Visual Studio 2010**** 系统中对需求记录和跟踪的支持

Scrum 模式中的需求主要是采用 Product Backlog Item（PBI 产品需求列表）和 Sprint Backlog Item （SBI 迭代需求列表）来进行管理的，在 Visual Studio 2010 系统中，直接提供了针对这两个列表的工作项查询，并且还提供了 Agile Workbook （敏捷工作簿）帮助我们更好对工作量和任务分配进行调控。

图 5：使用 MSF Agile 5.0 模板创建的 TFS 团队项目集成了对 PBI 和 SBI 的管理功能

图 6：Product Backlog 查询结果

上图中就是使用 TFS 内置的 Product Backlog 查询获取的产品需求列表，这个列表是 PO 使用的主要工具，我们可以注意到这个列表已经根据 Stack Rank 列进行了排序，这也反映了产品需求列表的特性：需要根据客户 / 干系人对需求项的优先级向团队交付任务；而 PO 的除了需要不断完善这个列表，还需要不断和客户干系人进行沟通，一边确定这个优先级。

在 Scrum 模式中，对于优先级的定义决定于两个因素：需求的商业价值和紧迫程度；另外一个重要的指标就是 Story Point，这个指标标志着当前需求项的相对大小，注意这里说的相对大小，很多人将这个值理解为人天或者人时，其实是不准确的，因为在 PO 准备产品需求列表的过程中，仅凭 PO 的经验是很难准确的判断出以时间为度量的工作量的，但是相对的大小是比较容易判断的。

另外，从 State 和 Iteration Path 两个列的值我们可以看到，已经有一些需求在迭代 1-2 中已经解决。根据这些信息，PO 可以很容易的对工作进度和剩余需求进行管理。

另外一个重要的查询就是 Iteration Backlog 查询：

图 7：Iteration Backlog 查询结果

Iteration Backlog 中包含了团队在某个迭代中需要完成的需求以及针对这些需求细化出来的具体开发/ 架构/ 测试等任务。在Visual Studio 2010 中，微软终于开始支持树形结构的工作项关联，从上图可以看出，每一个User Story 的下面都挂接着相应Tasks，这些任务是在Sprint Planning Meeting 中由团队成员自己根据PO 对需求的阐述进行的细化，同时团队成员还需要根据经验对这些Tasks 进行估算，给出基线估值（Original Estimate）。在开发过程中，团队成员在每天的Daily Scrum 之前需要对前一天的任务更新状态（State），已完成工作量（Completed Work）和剩余工作量（Remaining Work）字段的内容；通过这些信息我们就可以使用TFS 自带的燃尽图报表对进度进行查询和预测了。

实际上，纯粹的Scrum 模式并不关心已完成工作量（Completed Work）也就是以完成工作量的值，但是对于使用人天/ 人时等信息来衡量团队工作量，甚至依赖这些数据想客户收取开发费用的咨询类公司来说，这些信息是非常重要的。

Visual Studio 2010 对 Scrum 流程中重要事件的支持

Scrum 模式中的几个重要的会议包括：

1. Sprint Planning Meeting
2. Daily Scrum Meeting
3. Sprint Review Meeting
4. Sprint Retrospective Meeting

这一系列的会议是真正体现 Scrum 模式对于开发流程控制的核心内容，在 Scrum 模式中另外一个非常重要的概念是：时间箱（Time Box），它要求我们对于流程中的事件进行非常严格的时间控制。很多人在开始进行 Scrum 模式开发的时候的一个普遍问题是：一个迭代（Sprint）的长度应该是多少？对于这个问题其实也没有标准答案，而必须根据团队的大小来进行判断。对于之前我所建议的 3-7 人大小的团队，我会建议采用 2 周的迭代长度。原因在于 1 周太短，团队还无法完成真正有商业价值并可以进行交付的需求；而 3 周的时间则太长，需求的变化所造成的风险会变得比较大。

采用迭代式开发的时候其实长度是越短越好，我们总是尽可能的缩短迭代以便可以通过给客户的交付获得更有价值的反馈以便对后续的开发进行调整，因此这个长度应该是团队刚刚可以完成可交付需求的最短时间。我们需要严格控制的是，迭代的长度应该是一个时间概念儿不是工作量的概念，也就是说如果 2 周的时间已经耗尽但是团队还没有完成当前迭代中的所有需求，那么也必须结束迭代进行交付，而不能选择延长迭代来完成未尽需求。这样做的结果有两个：1）当前的迭代会以失败告终；2）通过对已经完成需求的交付，我们可以获取客户的反馈。很明显，失败的迭代是我们不愿意看到的，但是客户对于已经完成需求的反馈比保持常胜将军的名誉更加重要，因为后者是保证我们软件质量（符合需求）的重要手段。

当然，这里隐藏着另外一个很重要的问题，在团队无法完全完成需求的情况下如何还能提供可交付的成果，这就要依靠我们对于需求定义方式的变化和 Visual Studio 2010 中对持续集成和更加高效的测试支持来实现了。在需求定义上，我们需要采用业务导向的需求定义，保证每一个需求的完成都可以交付一定的商业价值。以往的需求往往是功能导向的，但是功能导向的需求对于用户来说不一定具备商业价值，但是业务导向的需求则可以保证这一点，比如：我们可以这样定义一个 User Story，作为市场经理，我希望对客户数据进行查询以便可以找到本市的客户并和他们进行联系。使用这样的需求定义意味着只要我们完成这一需求对客户就是有价值的，因为它不是一个功能碎片，而是一个用户交互用例。如果在一个迭代中我们无法完成所有的需求，只要完成其中一个，那么都是可以向客户交付的。另外，借助 Visual Studio 2010 对持续集成和测试的支持，我们可以采用每日构建的方式保证所有完成的代码都符合质量要求，也就避免了在迭代后期进行集中测试而拖延交付的可能性。

Sprint Planning Meeting 的支持

在 Visual Studio 2010 中提供了一个叫 Agile Workbook 的 Excel 模板，可以帮助我们很好地完成 Sprint Planning Meeting。在这个会议中，最重要的任务就是将 PBI 转化成 SBI，并且由团队给出完成这些 SBI 的承诺；团队要做出这样的承诺最重要的依据就是这些需求所涉及的工作量是否可以承受。Agile Workbook 正是帮助我们回答这一问题的强大工具。从下图我们可以看到，当我们制定了迭代上的人员配备并将 Task 分配给每个开发人员以后，模板会给出非常直观的柱状图，帮助团队判断工作量是否可行。

图 8：对迭代 1-3 上的工作量进行横向比较，根据历史数据判断后续迭代是否可行

图 9：在当前迭代上对每个开发人员的工作量分配进行比较

Daily Scrum Meeting 支持

这个会议非常简短，所以我们更加需要非常直观的图表以帮助团队对进度进行审核，在 TFS 中提供了燃尽图为团队提供这些信息。

图 10：迭代燃尽图

根据每个开发人员对于工作量的更新，从上图我们可以很容易对完成时间进行预测，图中黑色实线和横轴的焦点就是当前迭代的可能完成时间。

Sprint Review & Retrospective Meeting 的支持

Sprint Review 的支持更多地体现于 Visual Studio 2010 的持续集成能力，因为这个会议是对于需求完成情况的审核，如果我们能够保证需求是业务导向的并充分利用 Visual Studio 2010 的自动化构建和测试集成能力。那么我们就可以保证在这个会议上交付一定的商业价值。具体如何使用 Visual Studio 2010 来实现在后面做详细介绍。

Retrospective 会议其实非常简单，需要我们团队成员对当前迭代的运作进行总结，但为了使这些信息可以完整的保存以便后续使用，我们可以利用 TFS 提供的门户站点，定制一个 SharePoint 的列表分类的记录这些反馈以便团队查询。

Visual Studio 2010**** 对于产品质量的保证

提高产品质量是 Visual Studio 2010 在设计阶段就确定的重要目标，在 2010 版本所添加的新特性中，已经想着这个目标形成了一套完整的解决方案。对于 Scrum 模式来说，交付高质量的产品也同样是其终极目标，而且我们需要在迭代时间很短的情况下仍然保证质量，这就更加需要依赖工具的支持。

自动化构建

之所以把自动化构建列在首位，是因为软件工程发展到今天，自动化构建已经是任何一个想要实现高质量的软件开发团队都必须采用的工程方法；另外，对于 Visual Studio 2010 系统来说，自动化构建也起着承上启下，贯穿全局的重要地位。当开发软件进入第一个迭代的开发时，所要进行的第一项工作并不是开始实际的编码，而是创建出符合团队需求的构建模板。这样做的目的在于团队在后期的实际开发中可以更加专注于需求的开发，而不必花费额外的时间和精力来集成开发人员的代码；开始阶段的代码量很少，团队可以有更加清晰的思路将迁入策略，架构验证，自动化测试列表设置好并保证构建可以正常运行；如果把这个工作放到迭代后期进行，往往会因为代码中的缺陷和不同开发习惯造成构建模板不能正常运行。

在 Visual Studio 2010 中，提供了更加便捷的模板创建工具，特别是添加了 Gated Check-in 构建的触发方式，可以保证所有嵌入源代码库的代码都是经过验证的。

图 11：Gated Check-in 构建触发器

Gated Check-in 触发方式和以往的触发方式所不同之处在于，开发人员执行迁入操作的时候代码并不会直接进入源代码库，而必须先经过构建的验证：保证编译成功和定义好的迁入验证测试可以成功运行，然后 TFS 才会把代码真正嵌入服务器。之前的持续集成（Continuous Integration） 方式也会在迁入的时候进行构建，但是这种构建是将代码先迁入，然后再运行构建，如果代码中已经存在了缺陷，那么在服务器上就会留下缺陷代码；Gated Check-in 借助 TFS 源代码管理中的“搁置”功能，先把代码搁置到服务器上临时存储中，在构建成功后才会正式迁入，所以缺陷代码不会进入服务器。

图 12：构建参数配置

TFS 的自动化构建可以集成测试列表，图中的上方的红色区域中就是要求构建从项目文件中的测试列表文件中提取单元测试并自动运行；另外一个在 Visual Studio 2010 种的重要改进就是下方红色区域中的架构验证参数。如果我们的项目文件中包含了架构层次图（Layer Diagram）的话，那么我们就是添加这个参数让构建自动的验证项目的代码是否符合架构设计的要求。

图 13：Visual Studio 2010 的层次架构图 Layer Diagram

Scrum 模式开发中的架构设计给我们提出了非常大的挑战，由于我们采取业务导向的需求定义，开发人员必须从数据层一直实现到表现层；在这个过程中如何保证项目的架构仍然符合需求非常困难；而 Visual Studio 2010 的架构验证功能则可以帮助我们在每次迁入代码的时候都进行验证，保证违反架构规范的代码不会进入最终的交付产品。

消除无法重现的 Bug

无法重现的 Bug 一直都是困扰开发人员的问题，开发环境，测试环境，生产环境的不同；开发人员，测试人员和最终用户的不同都是造成 Bug 无法被重现的客观因素。在 Visual Studio 2010 中，提供了很多强大的调试和测试工具来帮助我们解决这个问题。

• IntelliTrace（历史数据调试）
• 协作调试
• 测试管理器和手工测试（Test Manager）
• 实验室管理（Lab Manager）

IntelliTrace——历史数据调试器

IntelliTrace 在开发过程中的名称就叫 Historical Debugger （历史数据调试器），后来这个用来进行市场宣传的名称反而不能反映它的实质。IntelliTrace 可以把程序运行过程中的所有历史数据都记录下来，使得程序员可以回滚到任何的历史点来查看程序状态，这对于开发人员调试复杂逻辑非常有用；之前我们在做同样工作的时候必须反复运行程序，以便找到问题，而现在则可以让程序反向运行。

图 14：IntelliTrace 调试器重所记录的程序历史数据

另外，IntelliTrace 还可以把这些调试数据另存为 tdlog 文件；当开发人员 A 发现了 B 的一个问题的时候，他可以把自己调试环境中的 tdlog 发送给 B，开发人员 B 就可以使用这个文件让 Visual Studio 恢复到开发人员 A 的调试状态，从而保证 B 可以有效的重现 A 所看到的问题。

协作调试

协作调试实际上解决多个开发人员在调试过程中的另外一些信息共享问题的方法，上面的 IntelliTrace 可以共享调试历史数据；但是用过 Visual Studio 的开发人员都知道，像“断点”是不能保存到调试数据中，也不会被保存到项目文件中；所以协作调试就提供了开发人员共享断点信息，并且还可以让开发人员在断点信息上添加一些说明，以便帮助其他的开发人员理解问题。

测试管理器和手工测试（Test Manager）

测试管理器是 Visual Studio 2010 系统中为测试人员特意开发的可以独立运行的测试环境，它完全独立，不依赖于 Visual Studio IDE，提供非常强大的测试录制等功能。在前面介绍构建的时候我曾经将单元测试集成到构建中去自动运行，但是单元测试只能针对后台逻辑进行，不能解决 UI 测试，或者叫黑盒测试问题。微软的测试管理器的出现，就是为解决 UI 测试的问题。

TFS 2010 中专门提供测试用例（Test Case）工作项类型，这个工作项允许测试人员对具体的测试步骤进行设计，并且给出预测的结果；同时，借助测试管理器的录制功能，还可以把测试人员换的操作全部都录制下来，一边后来自动播放；或者生成 Coded UI 测试，一旦有了 Coded UI 测试，我们就可以把这些针对 UI 的测试也集成到自动化构建中去。

图 15：测试用例（Test Case）工作项

实际上，真正可以使用单元测试覆盖的测试仅占所有的测试的 30% 都不到，另外这 70% 的测试以往都是依赖于测试人员手工的进行；现在借助微软测试管理器的功能，我们可以将这些测试集成到高度自动化的开发流程中。可以帮助我们更加快捷的完成测试，为开发人员提供反馈。

在 Scrum 模式中，业务导向的需求也要求我们的测试团队可以更加快捷的给出测试结果，前一天完成的需求最好可以在第二天就将测试结果反馈给团队；依赖于每日构建，我们可以在每天晚上将前一天的代码生成一个新版本，共测试团队使用；测试团队在第二天就可以把测试结果反馈给开发团队，同时将可以自动化运行的测试继承到每日构建中；在第三天的时候我们的团队就可以利用这些已经自动化的测试来验证我们的程序了。

由于每天都进行测试，那么新增的代码量就非常有限，也就使得 Bug 的数量可以得到有效的控制，从这个方面上说，测试管理器所提供的手工测试，自动化测试录制和回放，并且和构建的继承为我们提供了一个非常高效的高质量的开发平台，从流程和工程技术上为质量提供了保证。

实验室管理（Lab Manager）

实验室管理是我在 Visual Studio 2010 系统中见过的最酷的功能，也是微软继承了自己的多项产品为开发团队提供的最完整的测试解决方案。在测试中一个非常难实现的问题，就是对于不同环境的创建，还原和状态的保存。如果同一个用例在不同的环境中运行，结果往往是不同的，而且我们客户的使用环境也往往很复杂，所以就要求我们的测试人员可以搭建很多不同配置的测试环境，以便验证应用程序可以适应他们要求。

微软借助自己的 Hyper-V 虚拟化平台，为测试团队搭建这样的测试环境提供了非常好的支持，比如：我们可以使用 SCVMM 和 TFS 协同工作，当 TFS 需要测试环境的时候，通过 SCVMM 部署一台符合要求的虚拟机，并把需要测试应用自动的部署到这个虚拟机中，最终在这个环境中运行指定的测试。这样的测试环境避免了测试人员自己的机器不干净而导致的结果偏差，而且还可以通过环境快照的方式吧虚拟机的某个状态直接交付给开发人员进行检查。

在上面所介绍的这些功能中我们可以看到，实际上我们解决了 3 个不同测试的不可重现问题：

1. 开发人员本机上的不可重现：IntelliTrace
2. 开发人员和开发人员之间的不可重现：IntelliTrace, tdlog 和协作调试
3. 开发和测试环境之间的不可重现：微软测试和实验室管理器，Hyper-V

这些功能在工程技术上为团队保证了高质量，同时配合 Scrum 模式所推行的时间箱管理，业务导向的需求定义以及流程上的保证，Visual Studio 2010 系统和 Scrum 一起帮助我们创建更好的产品和更好的团队。

结束

我使用 Visual Studio Team System 是从 2005 年开始的，最初的目的只是为了满足远程迁入代码的需要；但随着 2008 和 2010 版本的发布，对于流程定制和整体性的质量解决方案的需求越高。幸运的是，这个时候公司为我提供了到澳大利亚接受 Scrum Master 培训的机会，使我可以体系化的了解了 Scrum 模式的精髓，回来之后就对我们的开发团队进行了一系列的优化。

同时，作为 Scrum Master 我也同时获得了提供 Professional Scrum Developer 培训的机会，PSD 课程是微软和 scrum.org 共同开发的一套基于实践的 scrum 开发人员培训课程，它使用 Visual Studio 2010 系统作为平台，将参训人员分为不同的团队，进行实际的开发工作，在开发的过程中让学员体会 Scrum 的妙处和 Visual studio 2010 的强大。目前我们已经在澳大利亚墨尔本和意大利米兰成功运作了这个课程。作为在亚洲去唯一向中国提供这一课程的提供商，我也希望能够和更多的开发人员分享这些内容。

更多内容请见：

我的博客： www.almnetworks.net

我的公司主页： www.ssw.com.au

个人介绍： http://sharepoint.ssw.com.au/AboutUs/Employees/Pages/Lei.aspx

PSD 课程中文介绍： http://www.ssw.com.au/ssw/Events/Scrum-Training-Course-China.aspx

注：本文已收录在架构师（7 月刊），更多内容请下载架构师。

给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家加入到 InfoQ 中文站用户讨论组中与我们的编辑和其他读者朋友交流。