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

http://www.infoq.com/cn/articles/visual-studio-2010-agile-scrum-development

根据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的流程主要包含如下内容：

• (P) 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的强大。目前咱们已经在澳大利亚墨尔本和意大利米兰成功运做了这个课程。做为在亚洲去惟一贯中国提供这一课程的提供商，我也但愿可以和更多的开发 人员分享这些内容。