基于Team Foundation Server 2010 Scrum 1.0与持续集成的最佳实践

每个Sprint正式开始之前的准备

在Scrum 1.0中正式创建一个Sprint之前，要将所有的Backlog填写完成，与团队成员一起分解Task，将Task以“相关”的关系与对应的Backlog进行关联以方便开发人员在浏览Task时查看相关Backlog的描述（Task不能拥有两个不同的父级Backlog，故将关系设置为相关）。

你可以为Task/Backlog创建子级Task/Backlog，但注意父级Task/Backlog的状态、迭代范围的变动无法影响子级，我认为层次关系已失去意义，可以不建。


以保守的态度估算每项Backlog的Effort（花费，可代表有效产出），Task的Remaining Work（剩余工作量）。对第一次估算的Task，剩余工作量即总计工作量。

Backlog填写界面



Task填写界面



Backlog的Effort将在Velocity报表计算在对应的Sprint之中，要注意，这份报表只会计算第一次填写的Effort，之后的更新不作计算，所以，对每个Backlog，最好先用Excel等工具记录好Effort，与各干系人确定好后再填入TFS.

Velocity报表



我们采用Visual Studio 2010旗舰版的测试管理工具进行测试计划、测试用例、自动化测试的管理，测试计划的编写是在Backlog评审完成之后进行。在测试计划中需与测试人员约定可测试版本的生成质量，我们的约定是“初次测试已通过”，测试人员可以直接使用这个生成定义来筛选待测试版本，每次的自动化测试都可以生成Bug快照和报表，这里就不详述了。

Sprint计划会议要做的事

准备投影仪，将TFS Product Backlog投放到屏幕上，与团队、产品负责人一起评审每项Backlog和Task：

将评审通过的Backlog/Task状态更新为Approved，不通过项置为Removed。这个操作只有Scrum 1.0项目中Project Administrator、Contributor两个角色中的成员可以完成。

与团队确定交付目标、期限。在TFS上创建Sprint，指定迭代路径、起始时间。

将与团队确定的交付目标相关的Backlog、Task的迭代路径指定为刚刚创建的Sprint。

为每个Task指派开发人员。为每个Backlog指派负责人。

Sprint填写界面



这个事情如果一次会议不能完成，也可以开两次。第一次确定交付目标、计划，第二次对目标细化出来的Backlog、Task进行评审，看时间是否与计划相符，进行裁减或增加。


如果是第N个Sprint并且是在有交付品之后，在新的一个Sprint开始之前，需对开发环境进行整理，保持干净，这包括：

使用与交付品一致的数据库脚本重新创建和初始化数据库。

使用上一个Sprint最新的正确版本部署开发环境。

验证各项功能是否正确。

开发开始后马上要做的事

建立持续集成的生成定义。在这里，我们采用的是TFS 2010的生成服务，具体如何配置可见：http://www.justinablog.com/?p=417

给团队成员一个简单的培训，识别持续集成结果列表、报表中各种图例代表的含义（有编译通过、编译通过测试不通过、编译通过代码覆盖率低等几种状态）。

开发过程中要做的事

Scrum Master/Project Manager

时间点	应做事项
每日早会前	检查被标记为In the progress的Task，将关联的Backlog标记为Committed
每日早会中	与团队查看燃尽图，确认每个被标记为In the progress的Task是否需要协助，确认未关闭的Impediment是否需要协助
每日早会后	检查标记为Done的Task，选择前一个工作日最后一个成功的持续集成版本，将生成质量标记为“初次测试已准备就绪”，发布到开发环境上进行功能的验证；如验证通过，将关联的Backlog由Committed更新为Done，如不通过，提交一个Impediment，指派给开发人员 将状态为New的Bug进行审核，通过标记为Approved，指派开发人员
每日下班前	检查当日的持续集成生成列表与报表，如有红色部分，与团队一起排除错误，直到最后一次生成变为绿色
每周二、四、五下班前	将最新的一个生成质量为“初次测试已准备就绪”的持续集成版本标记为“初次测试已通过”
测试通过	将持续集成该版本的生成质量由“初次测试已通过”变更为“实验室测试已通过”
交付品β版本发布	将持续集成该版本的生成质量由“实验室测试已通过”变更为“部署准备工作就绪”
用户验收结束	将生成质量由“部署准备工作就绪”变更为“用户验收测试已通过”
上线	将生成质量由“用户验证测试已通过”变更为“已发布”

项目经理检查表

Impediment填写界面



Developer

时间点	应做事项
每日早会前	将计划当天待做Task标记为In the progress，将计划当天暂停的Task标记为To do，两项操作均需再次评估剩余工时，即还需要多少工时来完成这项Task 检查分配给自己的Impediment和Bug，在开始修复之前，将对应的Task状态由Done改为In the progress，填写所需剩余工时
每次签入之后	检查持续集成发起者为自己的生成项，如有错误，进行修复；检查代码覆盖率（我们的要求是关键功能的方法达到100%）
下班前	将已完成的Task状态设置为Done，更新所有状态依然为In the progress的Task的剩余工时

开发人员检查表


Tester

时间点	应做事项
每周一、周三、周五早会后 （功能持续集成测试）	获取生成质量为“初次测试已通过”的最新版本，发布到测试环境，检查状态为Done的Backlog/Bug，验证是否通过；如不通过，将Bug状态重置为Committed，将新发现的Bug提交到TFS
发布任何版本之前 （集成测试）	获取最新的生成质量为“初次测试已通过”的版本，发布到测试环境，验证所有的Backlog、Bug是否通过

测试人员检查表

Bug填写界面



燃尽图

燃尽图上展示的是这个Sprint所有Task的剩余工时，黄色部分是正在进行中的工作，蓝色部分是未开始的工作。

Scrum 1.0的燃尽图是每日更新一次，在每个早会，须与团队成员一起查看燃尽图的状态，基本原理就是，面积图在黑色斜线之下，意味着整个团队的进度是安全的，否则意味着延期的风险。