Visual Studio 2010 是微软在2010年4月发布的全新一代的集成开发环境配合同时发布的Team Foundation Server 2010TFS——团队服务器 为开发团队提供了全面的应用程序生命周期管理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发布/迭代计划(CP) Daily Scrum每日回顾(CA) 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 OwnerPO产品经理我喜欢把PO翻译为产品经理因为PO的工作职责就是向客户和干系人收集产品需求进行排序并保证开发团队按照干系人对需求优先级的要求进行交付。Scrum MasterSM流程经理对于Scrum Master我一直没有更好的翻译将其译成为流程经理是因为这一角色要保证团队按照Scrum的方式来组织开发并协助团队和PO进行有效的沟通解决团队所遇到的问题。Scrum Master和项目经理的区别在于他更加倾向于保证开发流程的完整性而不是倾向于满足客户/干系人的需求。开发团队开发团队在Scrum模式中是作为一个整体出现的一般来说团队的大小控制在3-7个人的规模团队作为一个整体向PO负责而不是每个人对于自己的任务负责。在Visual Studio 2010 系统中使用TFS服务器基于角色的权限控制我们可以很方便地定义出不同的权限范围。当然最简单的方法是把Scrum团队的角色和TFS的默认角色之间进行映射。图4TFS团队项目的默认角色Scrum团队角色TFS团队角色Product OwnerContributorScrum MasterProject Administrator开发团队ContributorBuildersProject Administrator根据团队不同人员的职责具体分配项目干系人Readers如果客户愿意更直接的参与项目可以允许他们直接访问TFS。表1Scrum团队和TFS团队角色映射Visual Studio 2010系统中对需求记录和跟踪的支持Scrum模式中的需求主要是采用Product Backlog ItemPBI产品需求列表和Sprint Backlog Item SBI 迭代需求列表来进行管理的在Visual Studio 2010系统中直接提供了针对这两个列表的工作项查询并且还提供了Agile Workbook 敏捷工作簿帮助我们更好对工作量和任务分配进行调控。图5使用MSF Agile 5.0模板创建的TFS团队项目集成了对PBI和SBI的管理功能图6Product Backlog 查询结果上图中就是使用TFS内置的Product Backlog查询获取的产品需求列表这个列表是PO使用的主要工具我们可以注意到这个列表已经根据Stack Rank列进行了排序这也反映了产品需求列表的特性需要根据客户/干系人对需求项的优先级向团队交付任务而PO的除了需要不断完善这个列表还需要不断和客户干系人进行沟通一边确定这个优先级。在Scrum模式中对于优先级的定义决定于两个因素需求的商业价值和紧迫程度另外一个重要的指标就是Story Point这个指标标志着当前需求项的相对大小注意这里说的相对大小很多人将这个值理解为人天或者人时其实是不准确的因为在PO准备产品需求列表的过程中仅凭PO的经验是很难准确的判断出以时间为度量的工作量的但是相对的大小是比较容易判断的。另外从State和Iteration Path两个列的值我们可以看到已经有一些需求在迭代1-2中已经解决。根据这些信息PO可以很容易的对工作进度和剩余需求进行管理。另外一个重要的查询就是Iteration Backlog查询图7Iteration 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也就是以完成工作量的值但是对于使用人天/人时等信息来衡量团队工作量甚至依赖这些数据想客户收取开发费用的咨询类公司来说这些信息是非常重要的。