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的流程主要包含以下内容：
- (P) Release/Sprint Planning：发布/迭代计划
- (C&P) Daily Scrum：每日回顾
- (C&A) Sprint Review：迭代产品检查
- (A) Sprint Retrospective ：迭代流程检查
我们可以看到，Scrum模式的流程与戴明环仅仅相扣。有很多认为敏捷模式会弱化计划的作用，其实不然，敏捷模式更加强调计划，而且强调更加频繁的计划，比如：每日回顾这个流程就要求我们的团队每个成员每天早上用15分钟的时间来回答3个问题：
- 你昨天做了什么？
- 你今天计划做什么？
- 有什么问题阻碍你的开发进程？
其实这正是对于之前开发内容的检查，同时也是对后续开发内容的计划过程。
Scrum模式需要怎样的工具来实现？
对于使用什么样的工具来实现Scrum模式，现在也有很多不同的观点。其实有很多人认为白板和即时贴就是最好的工具，其实对于小型团队来说这的确是最有效而且最经济的方法。但是如果考虑到软件公司的管理需求（工作量统计等），远程团队，开发工具集成，代码质量控制，发布后期支持等等；我们还是需要一个高度集成的平台和一整套工具来支持我们的开发团队。
图3：白板和即时贴
Visual Studio 2010所提供的集成开发环境可以满足我们以上的一系列需求，帮助我们的开发团队更好组织开发，帮助我们的管理层更好地掌控开发过程，帮助软件公司开发出更高质量的产品。
Scrum模式对于工具的要求，主要集中在以下一个方面：
- 团队组织：满足PO （产品经理），Scrum Master （流程经理）和开发团队管理，以不同的权限访问团队项目并对不同角色提供个性化的信息支持的能力。
- 产品需求记录和跟踪：对于Product Backlog Item （PBI 产品需求列表）的添加，编辑，优先级排序以及交付开发团队以后进行跟踪的能力。
- 流程管理：满足Sprint Planning, Daily Scrum, Sprint Review和Sprint Retrospective这些流程中对于信息共享，信息转移和跟踪的能力。
- 产品质量：在整个开发过程中，配合Scrum模式达到产出高质量代码和产品的能力。
下面我们就看看Visual Studio 2010系统在这4个方面如何满足Scrum模式的需求，并协助我们开发出高质量的产品。
Visual Studio 2010上的Scrum团队组织
一个完整的Scrum开发团队主要由以下角色组成：
- Product Owner（PO产品经理）：我喜欢把PO翻译为产品经理，因为PO的工作职责就是向客户和干系人收集产品需求，进行排序并保证开发团队按照干系人对需求优先级的要求进行交付。
- Scrum Master（SM流程经理）：对于Scrum Master我一直没有更好的翻译，将其译成为流程经理是因为这一角色要保证团队按照Scrum的方式来组织开发，并协助团队和PO进行有效的沟通，解决团队所遇到的问题。Scrum Master和项目经理的区别在于，他更加倾向于保证开发流程的完整性而不是倾向于满足客户/干系人的需求。
- 开发团队：开发团队在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）也就是以完成工作量的值，但是对于使用人天/人时等信息来衡量团队工作量，甚至依赖这些数据想客户收取开发费用的咨询类公司来说，这些信息是非常重要的。
