Visual Studio 2010对Scrum流程中重要事件的支持
crum模式中的几个重要的会议包括：
- Sprint Planning Meeting
- Daily Scrum Meeting
- Sprint Review Meeting
- 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 的开发人员都知道，像“断点”是不能保存到调试数据中，也不会被保存到项目文件中；所以协作调试就提供了开发人员共享断点信息，并且还可以让开发人员在断点信息上添加一些说明，以便帮助其他的开发人员理解问题。