BT

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

构建产品需要多久?

| 作者 Vikas Hazrati 关注 0 他的粉丝 ,译者 郑柯 关注 3 他的粉丝 发布于 2011年9月27日. 估计阅读时间: 4 分钟 | CNUTCon 了解国内外一线大厂50+智能运维最新实践案例。

交付产品大概需要多少时间,这是客户常常提出的问题,也是让敏捷团队感到不爽的问题。一方面,在没有开始动手前就估算整个产品功能的工作量,等于无头苍蝇到处乱撞。然而,很多情况下,这是一个很现实的问题,团队不能将其抛在脑后。

Jarrod Roberson提到:不应该估算一整个项目,因为这与敏捷哲学完全是背道而驰。团队最多能够做到的,是根据成本和其他约束条件设定一个日期,产品负责人应该判断到这个日期截止要完成哪些功能。Pascal Thivent补充道:任何前期的估算都会导致固定的产品范围,这正是敏捷反对的。更极端的建议是:敏捷团队永远不要介入需要前期估算的项目中。

但是,这么做在现实世界中可行吗?

敏捷团队常常遇到这样的情况,客户需要一个大概的估算,以辅助多方面的决策。Hugo Palma认为

我认为,对于实现给定的功能,所有的客户都想了解大致估算,想知道要花多少钱。有人说:如果用敏捷,就不能这么做;我不同意。现实世界中的客户希望知道在一个项目上大概要花多少钱,至少有个粗略的概念,敏捷是可以调整、适应的。

Mike Cohn提到:他常常被问及,交付一个产品大概要多少个小时。他推荐的第一种方式,是推迟分析,直到有足够的历史数据,或者在sprint规划会议上能够得到一些承诺,再做分析。不过,有时候是需要粗略估算。对于这样的情况,Mike建议使用backlog取样技术,找出不同规模用户故事的平均小时数。

如果我们把1个点的故事平均一下,也许可以发现大概每个点数需要3.2个小时,2个点的故事要拆分成任务,每个点数大概4.3个小时,3个点的故事平均每个点4.1个小时,如此类推。

然后就可以把平均小时数与产品backlog中对应规模的故事数乘起来,再加总。

Mike提醒大家注意:这种技术会把任务识别和估算步骤中引入的不足全部包括进去。Rob Bowley的评论是:backlog取样技术没有效果,因为软件开发无法预测,而且像这样的技术估算出来的工作量会低于实际要完成的工作量。

尝试这么做,是没有道理可言的。它必将大大低估所需的工作量。考虑到软件开发需要投入的资金,结果就是对组织造成财务上的伤害,或是毁掉某些人的事业。

Matteo Vaccari提到:尽管使用backlog采样估算也许有助于得到一些数字,但还是会不断出现新的未知数,比如团队成熟度、一起工作的历史数据、完成的定义,等等;这些都将使得估算失去作用。

这种情形下的另一种选择,是采取Martin Fowler提议的“柔软范围(Scope Limbering)”方法,其用意是:从固定范围合同开始,然后逐步教育客户敏捷的优点,帮助他们克服“固定范围的海市蜃楼(FixedScopeMirage)”。Rob Thomsett提议的“翻番再加一点(double and add some)”游戏,也与Martin的方法类似。

因此,在真正意义上,看起来没有哪个方法是完备的。它们都有某种程度的主观性,因此有自己的问题。不过,如果在需要粗略估算的场景中使用这些技术,也许能帮助利益相关者做出更成熟的决策。

查看英文原文:InfoQ: How Long Would it Take to Build the Product?

评价本文

专业度
风格

您好,朋友!

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

获得来自InfoQ的更多体验。

告诉我们您的想法

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

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

翻番游戏那篇很有趣 by 朱 敏

Martin 的故事是很好的经验;翻番游戏那篇值得一看,很有趣:)

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

1 讨论

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


找回密码....

Follow

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

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

Like

内容自由定制

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

Notifications

获取更新

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

BT