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

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

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

注：在Task中也有前置关系，没有试过是否有MS Project一样的强制效果（你可以试一下）。
以保守的态度估算每项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进行评审，看时间是否与计划相符，进行裁减或增加。

但要注意，填写TFS的Backlog、Task、Sprint先后顺序，以及要“一气呵成”，否则各种报表会很难看（不真实）。

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

• 使用与交付品一致的数据库脚本重新创建和初始化数据库。
• 使用上一个Sprint最新的正确版本部署开发环境。
• 验证各项功能是否正确。

开发开始后马上要做的事

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

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

开发过程中要做的事

Scrum Master/Project Manager

项目经理检查表

Impediment填写界面

Developer

开发人员检查表

注：关于生成定义和代码覆盖率方面，可以看这份资料：http://msdn.microsoft.com/zh-cn/library/bb558973(v=VS.90).aspx

Tester

测试人员检查表

Bug填写界面

燃尽图

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

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