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

本文适合对Team Foundation Server 2010的部署和管理、模板配置有经验的人员阅读。

在阅读本文之前,需了解Scrum的一些基本知识;其次,需对Visual Studio Scrum 1.0模板有基本的了解。

Scrum的资料:http://msdn.microsoft.com/en-us/library/dd997796.aspx

Scrum 1.0的资料:http://msdn.microsoft.com/en-us/library/ff731587.aspx

每个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填写界面
Screenshot showing a new product backlog item

Task填写界面
Screenshot showing a new task work item

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

Velocity报表
Screenshot showing a velocity chart

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

Sprint计划会议要做的事

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

  1. 将评审通过的Backlog/Task状态更新为Approved,不通过项置为Removed。这个操作只有Scrum 1.0项目中Project Administrator、Contributor两个角色中的成员可以完成。
  2. 与团队确定交付目标、期限。在TFS上创建Sprint,指定迭代路径、起始时间。
  3. 将与团队确定的交付目标相关的Backlog、Task的迭代路径指定为刚刚创建的Sprint。
  4. 为每个Task指派开发人员。为每个Backlog指派负责人。

Sprint填写界面
Screenshot showing a new sprint work item.

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

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

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

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

开发开始后马上要做的事

建立持续集成的生成定义。在这里,我们采用的是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填写界面
Screenshot showing impediment work item

Developer

<

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

开发人员检查表

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

Tester

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

测试人员检查表

Bug填写界面
Screenshot showing a new bug work item

燃尽图

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

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

Screenshot showing a sprint burndown chart

© 2018 Silent River All Rights Reserved. 本站访客数人次 本站总访问量
Theme by hiero