BT

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

超越短期的Scrum项目估算?

| 作者 Dan Puckett 关注 1 他的粉丝 ,译者 张龙 关注 14 他的粉丝 发布于 2011年1月6日. 估计阅读时间: 2 分钟 | CNUTCon 了解国内外一线大厂50+智能运维最新实践案例。

近日,Michael Sync提出这样一个问题:如何对大项目或是大特性进行估算

我知道我们不应该对一个以上的sprint进行估算,因为后面可能会对其进行修改。但真实情况往往并非如此。我们需要提前对整个项目或是一些特性进行估算,这样才能确定目标日期并对特性进行调整或是改变其优先级。 为了能更加精确地进行估算,我们需要在创建sprint之前将用户故事分解为任务。 那该如何处理或是估算呢?

Peter Bell对估算与承诺进行了严格的区分

是否有人问过你关于估算或是承诺的问题呢?所谓估算,就是根据目前可用的信息做出的合理猜测。估算不是偏高就是偏低,通常在构建复杂软件时估算会偏低。他们不是承诺,也不能当作承诺。

Scrum Development邮件列表上的成员所达成的共识是项目估算并非特别有用,也不值得你花很多时间在这上面。“woynam”写到

进行估算的组织请不要再忧虑某些东西要花费多少代价了,请转到变化上来吧。如果你知道要花费多少代价、要花费多少时间,那么唯一变化的就是你的这些钱会实现多少个高优先级的特性了。关键在于如果你不再进行估算, 那么你仍旧可以确保首先实现最有价值的那些特性。

George Dinwiddie写到

如果利润或是损失取决于对花费的精准预测,那么你可能选错产品了。这种产品的升值潜力太低了。

我经常发现组织中的高层很清楚这一点,但中层经理往往不太理解:

Ron Jeffries则对这个话题 给出了自己的看法

对于大多数组织来说,估算都不是什么好事:他们被当作承诺和威胁,还会导致人们机械化地决定工作量、增加故事点或是小时数,而非仔细洞察团队到底能完成什么,如何完成。

我完全不赞成对故事进行估算,除了这样的描述:“几个人干几天”。当然了,这仍然是估算,但却不易被误用。

我喜欢让团队在几周内对大的故事进行估算,然后不断累加。这么做的结果会让人们对项目大小形成一种共识。不能将这当作承诺,但可以作为一个点,你可以提出重要的问题,比如说:在N美元和M月的前提下, 我们能否交付呢?

查看英文原文:Scrum Project Estimation Beyond the Near-Term?

评价本文

专业度
风格

您好,朋友!

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

获得来自InfoQ的更多体验。

告诉我们您的想法

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

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

当老板问你这个软件能什么时候完成。 by see sai

你如何回答?不估算的话难道无限期拖延?
也不能回答它说不知道吧。

Re: 当老板问你这个软件能什么时候完成。 by yuhong huang

总得给个预估时间。相信老板也不会认为说的时间就估那么准。另外,软件这个版本具有哪些功能特性很大程度还是产品经理或者项目经理在控制,可以有一定的取舍,如果时间卡的很紧,也是有一定余地。

Re: 当老板问你这个软件能什么时候完成。 by Lee Moody

完全不估算不太现实. 估算本身还是需要的, 主要是要清楚估算只是估算, 不可能是准确的.

允许的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通知我

3 讨论

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


找回密码....

Follow

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

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

Like

内容自由定制

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

Notifications

获取更新

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

BT