Felomeng翻译：《Microsoft 入门指导：适用于每个人的Scrum》（visual studio 2010）收藏 function change

本文介绍如何使用Visual Studio Scrum 1.0过程模板与Team Foundation Server 2010来实践Scrum敏捷开发方法。涵盖从创建产品订单到设计与追踪Sprint的全过程。

译者前言：Scrum是一种很好的敏捷开发管理方法，而Visual Studio Team Foundation Server 2010中提供了这个模板（需要单独安装），可以大大提高使用Visuals Stuido （专业版以上版本可以连接到TFS）开发的效率。TFS2010不仅可以安装到服务器上，还可以安装到个人PC（windows 7就支持），并且，Share Point和SQL Server也不是必须组件（如果只用基本功能）。

Microsoft 入门指导：适用于每个人的 Scrum（visual studio 2010）
使用微软Visual Studio Scrum 1.0过程模板
<a href="http://visualstudiogallery.msdn.microsoft.com/zh-CN/59ac03e3-df99-4776-be39-1917cbfc5d8e?persist=True" target="_blank">下载地址</a>（内含安装指导）
<ul style="margin-top: 0cm;" type="disc">
<li class="MsoNormal" style="margin: 0cm 0cm 0pt;">原作者 Aaron Bjork</li>
<li class="MsoNormal" style="margin: 0cm 0cm 0pt;">译者：Felomeng</li>
<li class="MsoNormal" style="margin: 0cm 0cm 0pt;">发布日期2010年10月1日</li>
<li class="MsoNormal" style="margin: 0cm 0cm 0pt;">翻译日期2010年12月3日</li>
</ul>
微软Visual Studio Scrum 1.0是一个新的用以实践Scrum团队开发的Team Foundation Server (TFS)过程模板。Scrum近些年已经成为软件产业的主导方法，而软件开发团队则都在寻找可以辅助他们开发过程和实践的工具。本文将概要地描述怎样在TFS2010上使用微软Visual Studio Scrum 1.0过程模板进行工程开发。
开始
团队进行Scrum实践的第一步，就是决定每个Sprint的长度。Sprint是一个固定时间周期的迭代过程，在每一个周期中，团队在上一个周期的基础上为最终产品添加一些可发布的增量。团队可以决定一个合适长度的周期，但是绝大多数团队使用的周期都在一周和30天之间。周期的长短相对来讲并不是很重要（每个团队需要自己去寻觅适合自己的周期长度），重要的是在产品订单（Product Backlog。译者注：其实就是待完成的事项列表）上，每一阶段的产品都是可以按时发布的。
一旦开发周期确定下来，就可以开始向工程的Sprint工作项（work item）中添加相应的日期。用微软Visual Studio Scrum 1.0模板创建新的工程后，工程被默认划分为24个Sprint（四次最终发布版本，每个版本6个Sprint）。这个过程很容易修改——比如，你可以将第一个版本的Sprint数改为10 个——但是本文意不在此，所以我们就把默认的Sprint作为样例吧。
在Visual Studio里面，打开Team Explorer并打开里面的所有Sprint请求（All Sprints query），请求中返回的每个Sprint工作项直接被指定到TFS中的某个迭代周期。打开最开始的几个Sprint工作项，并输入他们的起止日期。关键不在于指定所有Sprint的日期，而是将已有的计划展现给团队，并使产品负责人体会到大体的产品开发计划。
创建产品订单
当前工程的需求清单很可能已经有了。下一步的工作就是将这个清单转化为产品订单中产品订单项（PBI：Product Backlog Item）的工作项。产品订单是一个描述工程的有优先级的需求清单。产品订单上的每个项都被表示为一个被称为产品订单项的工作项。
要创建一个新的产品订单项，在工具栏中单击新建工作项（New work item）下拉菜单，并选中产品订单项。产品负责人负责填写工作项详细内容，包括标题，订单优先级，描述和业务价值（Business Value）。因为这些字段描述了该工作项本身，工作项与订单上其他工作的优先关系，完成后所能带来的业务价值，所以这些字段是工作项的核心。保存新建工作项之后，就可以在产品订单请求结果中看到该工作项了。产品订单请求就是所有产品订单项和Bug的总和，它将被分配在尚未完成工程的根目录。
每个产品订单项都会经历一系列的状态变化，这些状态记录了需求的生命周期：新建、已确认、已分派和完成。
新建：这个状态是产品订单中所有工作项的开始状态。新建产品订单项由产品负责人输入，开始都是新建状态，并具有默认的订单优先级（1000）。这样做是为了确保新增加的产品订单项在产品订单中优先级最低。
已确认：当产品订单项已经足够详细，并且可以评估时，产品负责人会将它的状态改为确认。一般地，在产品订单中，确认状态的项优先级较高，而优先级居中和较低的都是新建状态。
已分派：当团队开始开发一个产品订单项时，产品订单项的状态就会变成已分派。这个状态表示此产品订单项将在一个Sprint内完成。
完成：最终，团队完成了与产品订单项相关的所有工作，并且产品负责人认为产品订单项的实施符合验收标准。这个状态就是完成。
产品负责人向产品订单添加新的订单项时，给订单项指定适当的优先级至关重要。因为团队在一个接一个的Sprint中，他们就是根据产品订单上的优先级一个一个地处理订单项的。那么在订单中优先级的决定因素是什么呢？答案是具体情况具体分析。但是有一些普遍适用的原则和指导方针可以帮助产品负责人对优先级做出良好的划分。
每个Sprint的目标是为用户提供价值。这个观点的根基在于：经常和尽早地发布产品有助于在后面的工程周期中做出更好的决定。正因如此，产品负责人考虑产品订单项中哪些项在用户价值/工程量比上最高是很重要的。产品订单项和Bug工作项表单都具有业务价值字段来记录这个值。产品负责人应该利用这个值和工程量（effort）字段的值对产品订单中的项的相对优先级做出良好的划分。
验收标准
作为产品负责人，最重要的一项职责就是，给每个产品订单项制定详细的验收标准。什么是验收标准？简单地说，就是确定每个订单项“完成”的规范。因为验收标准是产品负责人与团队达成一致的标尺，所以它是Scrum团队成功的关键（验收标准确定了团队应该做什么）。
<img src="http://hi.youkuaiyun.com/attachment/201012/3/0_12913793399T9E.gif" alt="" width="600" height="468">
图1.产品订单请求概览
一些最佳迭代过程正是源于产品负责人和团队对每个订单项验收标准的评审。结果就是产品负责人和团队都明白每个订单项怎样才叫“完成”。“完成”在敏捷软件开发世界中的意思是可以向用户发布，并且没有尚未完成的工作，包括测试、文档撰写、安装等等。请记住，每个Sprint的目标，是生产一个“可发布的产品增量”。为了可发布，所有的工作就必须“完成”。虽然有很多编写验收标准的好格式，但是最重要的还是标准相对所有涉众的易读性和易理解性。
设计第一个Sprint
当产品负责人建立好了产品订单，并且划分好了优先级之后，团队就可以开始第一个Sprint了。团队要召开Sprint计划会议，在会议中团队要在Sprint目标上达成一致。Sprint的目标填写在Sprint工作项的目标（Goal）字段中。产品负责人通过给团队宣读每个订单项及其验收标准，向团队描述产品订单中最高优先级的产品订单项和Bug项。在会议的这个阶段，团队主要是搞清楚产品订单中的每个项以及到底要编写一个怎样的产品。
当团队对所有的订单项已经有了充足的讨论之后，就该开始对每个订单项进行评估了。当前比较通用的方法是使用一项如计划扑克（Planning Poker）的技术。在计划扑克中，团队的每个成员都有一手牌，牌面的值表示了完成一个订单项所需要的工程量。多数计划扑克使用Fibonacci数列（1, 2, 3, 5, 8, 13…），因为团队并不打算做出精确的估计。例如，在讨论订单时，11和12这两个预估值有什么区别？事实上，并没有太大区别。因为在这么细微的预估上面，误差是不可避免的。但是，对于8和13这对预估值，甚至是5和13这对预估计，就容易判断多了。
<img src="http://hi.youkuaiyun.com/attachment/201012/3/0_1291379740825M.gif" alt="" width="600" height="455">
图2.良好的验收标准是成功的关键
通过减少选项，团队关于相关工作的讨论会更有成效。在每个团队成员完成预估后——在预估时，如果团队成员有较低或较高预估，都有机会阐明他们为什么预估这样的值。这个过程的目标，仍然不是达到精确的预估，而是引发讨论，从而使所有成员都明白每个订单项怎样才叫“完成”。团队可以在讨论结束后进行投票，从而达到一个一致的预估。这个值将被输入到被评估的订单工作项或Bug工作项的工程量（Effort）字段中。
对产品负责人所提出的所有工作项不断重复这个过程，直到团队认为已经可以达到本期Sprint的目标为止。下一步，就是团队将每个工作项划分为任务工作项。任务代表了团队将要做的实际的工作，它应该包含所有的相关工作，包括测试、文档撰写、接口设计等等。
记住，一个项只有在所有工作都完成以后才能“完成”。因此，团队在会议的这个阶段共同记录所须要做的所有工作是非常重要的。每个任务工作项都经过团队的评估。随着团队对每个项的任务进行细化，可能会发现某个项比预想的要大。在这种情况下，团队需要和产品负责人沟通，要求将这个项移回产品订单。
向产品订单项或Bug项添加一个任务，在工作项上面切换到任务页，单击新建关联工作项（New Linked Work Item）图标。任务作为产品订单项或Bug项的子项被添加，并且是待办（TO DO）状态。他们可以在产品订单项或Bug项任务页面被追踪。
当创建好所有的任务之后，最后一步工作就是指派工作。指派工作就是把每个产品订单项或Bug工作项置为已分派状态，其中包括团队将在马上开始的Sprint中完成这个项。
Sprint计划会议的结果是：
<ol style="margin-top: 0cm;" type="1">
<li class="MsoNormal" style="margin: 0cm 0cm 0pt;">产品负责人与团队就当前Sprint中要完成产品订单中哪些项达成共识。</li>
<li class="MsoNormal" style="margin: 0cm 0cm 0pt;">要完成产品负责人和团队共同选择的这些项，须要进行的任务列表。</li>
</ol>
在Sprint结束时的Sprint评审会议上，才能确定Sprint最终的成功与否。
追踪第一个Sprint
现在，Sprint计划已经完成，团队已经可以开始工作了。团队开始工作时，分派的订单项不能太多，这很重要。理想状态是，团队成员共同执行一个订单项的任务，直到所有的任务完成，然后再开始处理下一个订单项。这样有助于避免在Sprint结束的时候，所有的项都进行了90%而却没有一个“完成”。
团队成员的第一项工作就是选择他们要进行的第一批任务。通过改变任务工作项的分派给（Assigned To）字段的值，并将状态字段的值置为进行中（In Progress）。
团队成员通过更新剩余工作（Remaining Work）字段，每天更新他们正在进行任务还剩余的小时数。最佳状态是，每个成员在同一时间段只有一个进行中的任务，从而避免工作没有完成或只完成了一部分的风险。当团队成员完成任务后，把任务的状态由进行中改为完成。而工作进程也在每日立会（daily standup。译者注：每天的例会一般长度只有十到十五分钟，并且所有成员站立进行，故得名“每日立会”）中汇报。
<div>
<table class="MsoNormalTable" style="width: 335px;" border="0" cellspacing="0" cellpadding="0"><tbody>
<tr style="height: 141.2pt;">
<td style="background-color: transparent; width: 251.5pt; height: 141.2pt; border: #f0f0f0; padding: 1.5pt;" width="335">
<a href="http://visualstudiomagazine.com/Articles/2010/10/01/~/media/ECG/visualstudiomagazine/Images/2010/10/1010vsm_F2Scrum3_hires.ashx" target="_blank"><img src="http://hi.youkuaiyun.com/attachment/201012/3/0_1291379744E3ar.gif" alt="" width="600" height="532"></a>
</td>
</tr>
<tr style="height: 23.4pt;">
<td style="background-color: transparent; height: 23.4pt; border: #f0f0f0; padding: 1.5pt;" valign="top">
图3.燃烧曲线（Burndown chart）展示了一个Sprint过程 
</td>
</tr>
</tbody></table>
</div>
在Sprint中，团队通过Sprint燃烧曲线追踪所有的过程，一步一步地完成所有的工作。这个曲线清晰地展示了团队将分派给这个Sprint的时间“燃烧”掉的过程，并且很好地追踪了团队进行中的工作量。如图所示，可以看到，在这个Sprint结束前，团队还有20小时的工作需要完成。Sprint燃烧曲线可以在每日立会中展示，以便让每个团队成员明白团队正在怎样完成分派的任务。