crum模式中的几个重要的会议包括Sprint Planning MeetingDaily Scrum MeetingSprint Review MeetingSprint 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 构建的触发方式可以保证所有嵌入源代码库的代码都是经过验证的。图11Gated Check-in 构建触发器Gated Check-in 触发方式和以往的触发方式所不同之处在于开发人员执行迁入操作的时候代码并不会直接进入源代码库而必须先经过构建的验证保证编译成功和定义好的迁入验证测试可以成功运行然后TFS才会把代码真正嵌入服务器。之前的持续集成Continuous Integration 方式也会在迁入的时候进行构建但是这种构建是将代码先迁入然后再运行构建如果代码中已经存在了缺陷那么在服务器上就会留下缺陷代码Gated Check-in 借助TFS源代码管理中的“搁置”功能先把代码搁置到服务器上临时存储中在构建成功后才会正式迁入所以缺陷代码不会进入服务器。图12构建参数配置TFS的自动化构建可以集成测试列表图中的上方的红色区域中就是要求构建从项目文件中的测试列表文件中提取单元测试并自动运行另外一个在Visual Studio 2010种的重要改进就是下方红色区域中的架构验证参数。如果我们的项目文件中包含了架构层次图Layer Diagram的话那么我们就是添加这个参数让构建自动的验证项目的代码是否符合架构设计的要求。图13Visual Studio 2010的层次架构图 Layer DiagramScrum模式开发中的架构设计给我们提出了非常大的挑战由于我们采取业务导向的需求定义开发人员必须从数据层一直实现到表现层在这个过程中如何保证项目的架构仍然符合需求非常困难而Visual Studio 2010的架构验证功能则可以帮助我们在每次迁入代码的时候都进行验证保证违反架构规范的代码不会进入最终的交付产品。消除无法重现的Bug无法重现的Bug一直都是困扰开发人员的问题开发环境测试环境生产环境的不同开发人员测试人员和最终用户的不同都是造成Bug无法被重现的客观因素。在Visual Studio 2010中提供了很多强大的调试和测试工具来帮助我们解决这个问题。IntelliTrace历史数据调试协作调试测试管理器和手工测试Test Manager实验室管理Lab ManagerIntelliTrace——历史数据调试器IntelliTrace在开发过程中的名称就叫Historical Debugger 历史数据调试器后来这个用来进行市场宣传的名称反而不能反映它的实质。IntelliTrace可以把程序运行过程中的所有历史数据都记录下来使得程序员可以回滚到任何的历史点来查看程序状态这对于开发人员调试复杂逻辑非常有用之前我们在做同样工作的时候必须反复运行程序以便找到问题而现在则可以让程序反向运行。图14IntelliTrace调试器重所记录的程序历史数据另外IntelliTrace还可以把这些调试数据另存为tdlog文件当开发人员A发现了B的一个问题的时候他可以把自己调试环境中的tdlog发送给B开发人员B就可以使用这个文件让Visual Studio恢复到开发人员A的调试状态从而保证B可以有效的重现A所看到的问题。协作调试协作调试实际上解决多个开发人员在调试过程中的另外一些信息共享问题的方法上面的IntelliTrace可以共享调试历史数据但是用过Visual Studio 的开发人员都知道像“断点”是不能保存到调试数据中也不会被保存到项目文件中所以协作调试就提供了开发人员共享断点信息并且还可以让开发人员在断点信息上添加一些说明以便帮助其他的开发人员理解问题。