BT

如何利用碎片时间提升技术认知与能力? 点击获取答案

跟踪速度,而不是任务完成时间

| 作者 Chris Sims 关注 0 他的粉丝 ,译者 郑柯 关注 3 他的粉丝 发布于 2009年1月28日. 估计阅读时间: 2 分钟 | GMTC大前端的下一站,PWA、Web框架、Node等最新最热的大前端话题邀你一起共同探讨。

一个全新敏捷团队的成员在Scrum Development邮件列表提出这样的问题:如何跟踪工程师在每个任务上耗费的时间,以及这与敏捷中速度概念的关系。速度是敏捷的度量方式,用来跟踪团队要用多久才能完成功能开发,以此了解完成一个项目要用多长时间。讨论组的意见是:跟踪任务完成时间毫无必要,没有用处。

最初的帖子中提到:他的团队使用故事点估算故事大小。团队完成了故事之后,他们结算了相关的故事点数。这个结算过程就会用来计算团队的速度:

……团队的速度,也就是团队在每个冲刺中完成的大概工作量。也许是在时长4周的冲刺中完成25个故事点数。这个数字可以用来估量后续冲刺中可以完成的工作量。

目前看来一切正常。帖子接下来描述了团队如何将故事拆分成任务,以及这些任务如何使用小时数进行估算和跟踪。

我们一直在用燃尽图,其中每个团队成员每天都会写下每个任务剩余的时间。这些数据会用来生成燃尽图电子表格。但是,这仅仅为燃尽图获取了数据,对速度毫无帮助。

这种混淆正好从旁例程了某些敏捷专家的观点,包括Ron Jeffries等敏捷专家推荐根本不要估算或是跟踪任务George Dinwiddie补充了他的看法:

如果你让故事尽量小,那就不必在燃尽图中用小时进行跟踪了。我发现团队更善于跟踪故事,他们不会浪费时间去重新估算要用多少个小时完成任务。

在这一系列讨论中,Ron和其他人指出:在“4周冲刺中完成25个故事点”,这其中的信息已经足够用来完成其他估算了。这就是团队的速度,将来这个团队能完成多少故事,用速度就足以预测了。

你的团队除了估算故事之外,还会跟踪任务估算么?请您在评论中留下观点,并说明您的原因。

查看英文原文:Track Velocity, Not Time Spent on Tasks


 

评价本文

专业度
风格

您好,朋友!

您需要 注册一个InfoQ账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我
社区评论

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

讨论

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT