微软发布官方TFS 2010 Scrum 模板

最近在看Brian Harry的博客，发现微软刚刚发布了TFS 2010上面使用的Scrum v1.0 beta版的模板，虽然还是beta版本，但是已经是非常scrum化的模板。 

http://blogs.msdn.com/b/bharry/archive/2010/06/07/a-scrum-process-template-for-tfs.aspx

趁晚上的时间吧这个模板安装在我的测试TFS服务器上，简单测试了一下：

#1 – 安装很便捷

按照包里包括了模板文件和SharePoint门户的wsp部属包：

使用模板管理器可以很方面的把模板部署到服务器上：

Stack Rank 

#2 – 流程模板指南现在指向Scrum.org

我使用这个新模版创建了一个项目，发现流程模版指南里显示的scrum.org；我个人觉得如果指向Scrum Guide可能会更好一点 ( http://www.scrum.org/scrumguides/).
 

#3 – 工作项全部针对Scrum进行了优化

工作项已经被更新为完全Scrum化的类型，名称符合Scrum的常用标准:

• Product Backlog Item（PBI产品需求列表项）: 代替了User Story 
• Impediment（障碍工作项）: 代替了 Issues，这个工作项是Scrum Master用来记录阻碍团队正常开发的障碍的工作项，是Scrum Master的工作重点
• Task （任务工作项）
• Test Case （测试用例工作项）
• Shared Steps （共享测试步骤工作项）
• Bug （缺陷工作项）
• Sprint（Scrum中的迭代）: 这是全新的工作项，用来记录和迭代相关的内容，如：迭代开始/结束时间，审核会议记录等内容。

Product Backlog Work ItemPBI产品需求列表项 :

使用新的Scrum模板创建了一个PBI工作项，发现这不仅仅是User Story的工作项的改名那么简单： 

 

具体看一下PBI的内容： 

-       Backlog Priority （优先级）: 代替了User Story中的Stack Rank和Story Points，PO可以使用这个值来对PBI进行优先级的标注，这是PO的主要工作内容之一；
-       Effort（工作量）: 这代表了用来完成当前PBI所需要的工作量；
-       Business Value（商业价值）: 用来衡量PBI对用户的价值的相对值；
-       Tasks（任务列表）: 这里需要链接到所有实现当前PBI的任务工作项；
-      Test Cases（测试用例）: 我们在定义Scrum项目的PBI的同时需要对如何对当前PBI进行测试进行定义，也就是UAT。这也是Scrum模式中的需求所不同之处，一边来说需求仅仅是对用户的要求进行描述，但是Scrum要求我们对用户如何测试这个需求也同时进行定义，以保证需求的有效性；
-       Acceptance Criteria（接受条件）:这里应该对当前PBI的接受条件进行定义，应该等同于done criteria，但是一般来说，我们不会对每一个PBI采用不同的done criteria。 

PBI的状态转换: 

我觉得这里的状态改进很好，因为它更好的体现了scrum模式的工作流程。首先PBI处于New的状态，然后由PO/干系人审核，变为Approved状态；在迭代计划会议上，PO会把PBI的内容交付给团队，团队需要给与PO承诺他们将按要求完成需求，这是转换为Committed；最终当团队完成了这个需求的时候，转变为Done的状态。（我个人一直认为微软的流程模板的精华在于其状态转换，很好的对状态转换进行定义意味着我们可以对团队的工作流程进行更好的控制；以往的MSF Agile模板因为过于追求通用型，对状态转换的定义往往无法满足开发团队要求，这个Scrum模板为我们提供了一个非常的例子）。 
 

状态包括:

-       New
-       Approved/Removed
-       Committed
-       Done    

Sprint 迭代工作项:

这是Scrum流程模板中的全新工作项，也是以往的Agile模板所缺失的重要工作项类型。其内容包括迭代的开始/结束时间，迭代的目标定义和迭代的审核会议（Restrospective）的记录模板。 审核会议（Retrospective Meeting）是Scrum的精华内容：Scrum鼓励团队针对实际情况对工作流程，团队组织，任务分配等等进行不断的优化，以便可以找到适合团队的工作方式；审核会议是Scrum为团队提供的反思开发流程的机会，对这些内容进行定义可以为我们改进流程提供非常好的事实基础。

Task 任务工作项:

Scrum中的任务不关心任务上的实际工作时间，因此我们没有在这个任务工作项上看到Completed Work数据域，而仅仅保留了剩余工作量Remaining Work数据域。这当然是Scrum模式的特点之一，但是对于依赖于工作小时来收取开发费用的咨询类软件公司来说，实际工作时间是非常有意义的数据。

另外值得我们注意的是任务工作项的状态有：To do, In Progress和Done，3个状态。这是一个非常棒的改动，就像我之前说过的，状态的转换代表了开发团队的工作方式。对于我来说，非常关心我的团队每天正在那些内容上工作，所以这个In Progress的状态就非常重要了。

Bug 缺陷工作项:

缺陷工作项同样有比较大的改进，特别需要注意的是Backlog Priority这个数据域；很多人都对如何处理Bug工作项有疑问，Bug到底应该等同于任务还是等同于PBI，这里Scrum模板为我们很好的解答了这个问题：Bug工作项应该是等同于PBI的产品需求。因为实际上Bug也是一种需求，是一种解决缺陷的需求，普通的PBI则是一种添加更多商业价值的需求（注意是商业价值而不是功能，因为scrum中的需求是业务导向的，而不是功能导向的）。

测试用例和共享测试步骤工作项：

这本来就不是scrum的内容，而是MSF Agile中的内容，在这里得到了保留。 

#4 - 工作项查询也作了优化，很方便

Scrum v1.0 Beta 模板包括了一个“当前迭代”的查询目录，里面包括了所有针对当前迭代的查询；非常方便使用并可以很容易的进行复制以便支持后续的迭代。

-       Product backlog: 这里你可以看到PBI和Bug工作项类型被选定，他们都是产品需求列表的内容。

-       Sprint Backlog 迭代需求列表: 除了PBI和Bug之外，还包括了相关的任务   

-       Work in Progress 正在进行的工作: 这个查询太有用了，每天早上都已运行一下，就知道团队今天要干嘛了。  

-       Open Impediments 未解决的障碍: 这会是Scrum Master用的最多的查询，看看团队现在有那些问题阻碍他们正常开发？

#5 - 报表还需要改进

当前的Scrum模板仅仅包含了Scrum中最常用的3个报表，还需要多多改进。根据Brian Harry的说法，他们会把Agile模板中的一些常用报表包含进来，特别是一些软件工程类的保镖，比如：构建报表。 

Release Burndown
Indicates how quickly the team is completing work and delivering Product Backlog Items. Its primary use is for planning when to schedule a release and to track the team's progress towards delivering on its goals.

Sprint Burndown
Indicates the team's progress towards completing its work for a sprint.

Velocity
Indicates the amount of effort the team is completing in each sprint.

As I don’t have any data in the database yet, I just copied above screenshots from Brian’s blog.

#6 - 门户和文档模板方面还需要很多的工作

门户可以说还完全是空的，里面没有找到任何的Excel模板，报表和doc文档模板；看来这毕竟还是beta版。我非常希望微软可以把Agile Workbook包含进来，这是Agile 5.0里面一个非常好用的模板，对于我们进行计划会议非常有用。

总结

当然，就像每一个微软产品的v1一样，对于Scrum v1.0模板我同样也没有太高的期望值。但是通过以上我们可以看到这个模板非常的Scrum化，基本上满足了一个Scrum团队的工具要求。当然，一般的软件公司是不太敢使用beta版的模板的，因为模板的改变在TFS中仍然是一个很困难复杂的过程。

PS：最近很多人都已经试用过这个模板了，有人反应为什么不支持Microsoft Project；关于敏捷项目是否应该使用Project这个问题大家是个有观点，有人认为敏捷项目不应该使用Project来进行管理；有人觉得Project很重要。其实就像Scrum所推行的理念一样，模板/流程/方法论都必须和实际的开发团队，公司文化，技术实现所关联；我个人认为用不用Project不重要，如果Project能够很好的解决问题，那么就用，不用担心用了Project就不敏捷的问题。工具是给人用的，不要被工具所制约就好。