我们应该停止使用故事点和速率吗?

标签: 故事 速率 | 发表时间:2012-12-19 23:05 | 作者:
出处:http://pipes.yahoo.com/pipes/pipe.info?_id=10560380f804c7341f042a2b8a03e117

敏捷社区的专家正在热议如何使用故事点和速率(Velocity),不少人对使用它们估算和度量总体进度产生了怀疑,打上了问号。大家普遍认为,产生问题的根本原因就是这些度量项往往不是挂羊头卖狗肉,就是浮于表面被误用,很少能用在刀刃上。

Joshua Kerievsky详细记录了他使用故事点的经验,以及他们是如何粉饰太平的。在下面的这个例子中,他讲述了故事点走向恶性通货膨胀的过程。

2004年的一天,Jim想要团队加快开发速率。团队原本的平均开发速率约为每个迭代完成52个故事点。他们的开发速率可能有几个点的浮动,但总体保持着平稳。然而Jim要求团队“全速前进”。仅仅几周后,团队开发速率一跃攀升至80点!

我问一个同事这是怎么回事?

她用讽刺的神情看着我:“这几天在这儿打个喷嚏都算故事点。”我摇了摇头,吃惊地看着这个成熟的敏捷团队居然为了让自己看起来速率加快了,以迅雷不及掩耳盗铃之势膨胀他们的故事点估算。这可是我和两个优秀的Industrial Logic公司教练一起亲自培训、辅导并审核过的团队啊!

此次经历之后,我对故事点和开发速率计算的信心开始动摇了。

Joshua还指出,用故事点来横向比较团队是非常拙劣的方式:

这些年来,我听过多个来自不同公司的经理这样问:“为什么X团队每个Sprint可以完成24个故事点,而Y团队只能完成12个呢?这两个团队规模差不多啊,究竟差别在哪儿呢?”

这些经理并没有把开发速率当成是团队独有的能力指标,而是掉入了一个常见的思维陷阱,把开发速率当成了绩效度量指标。

在Joshua的博客评论中,Bob Martin大叔进一步确认了这一点:

许多团队确实在使用故事点时很挣扎。我遇到过有些团队的项目经理莫名其妙就要求团队加快速率,企图不劳而获,那么团队只能让故事点贬值。我也遇到过有的团队为了讨老板欢心捏造开发速率报表,因为老板更热衷于形式而非内容。对于这样的团队,其他的方法可能更靠得住些。

Scrum Alliance邮件组的讨论中,Ron Jeffries就批判了将开发速率作为度量项这一行为。

  • 开发速率可能并常常被误用。
  • 开发速率可能并常常被用于攀比。

尤其是这跟主流敏捷思想背道而驰。敏捷实施中,很重要的一点就是要通过优先级来决定先做哪些后做哪些,从而掌控项目,而非紧紧盯住数学公式并致力于让数字好看。

团队关注开发速率那么就并不再关注实际价值。我希望我没发明过开发速率,但我却这么做了。

沿着这个思路,他进一步做了详细说明:

我们发现这里的多数问题是关于如何改进估算,让它们更加精确的。当我们进一步分析,我们注意到团队会计划一个完成时间,然而他们会被催促着按时完成所有工作。看得出他们在度量团队预估的准确性。

我们发现产品负责人只会”遵循计划“,几乎不管不顾地分配任务。

只有当产品负责人能够创造性地使用待办事项列表,交付尽可能好的产品时,Scrum才算物尽其用。我发现紧盯着估算对此毫无帮助。

Mike Cohn最近发表了一篇博文,介绍了一个非常看重估算的客户的 案例。援引这个客户的话:

首先,对我而言,至少为了做预算,我需要知道我们的估算可以和实际情况有多接近。当我问投资人要求追加投入时,如果我们只完成了承诺的二分之一,他们会觉得这是个无底洞。我会处理这些情况,但我需要知道我们有个合理的途径来获得一个初步的估算。第二,为了筹集后续资金,我需要了解大概的数目(这是一项需要不少前置时间的活儿)。如果估算和实际情况相差甚远,我们就不得不改进,随后我会去开辟获得资金的渠道。也就是说,没有免费的午餐,钱不可能无缘无故从天而降。我必须有某种水平的度量来反映损益情况并贯穿项目始终。换句话说,我得在项目过程中盯住燃尽图,关注项目成本。

Vasco Duarte提出了一个故事点的 代替方案通过统计故事数量来做来估算 。 

如果是估算以及监控那些长期项目(提示:这只适用于长期项目,例如在未来至少有三个以上Sprint),你可以假设所有的故事大小都一样,因此就可以通过度量每个Sprint完成的故事数量来跟踪进度了。

Mike Cohn也提出来类似的观点:

我承认用看板的团队相对较少做很具体的估算。这往往是由于他们已经默认了所有的工作的规模都相当的缘故。

Neil Killick提供了 另一种不需要估算的定价方式。他以自己做网站的例子做比照。他的供应商会根据公布的可用预算给出最可能实现的方案,而Neil如果在任何一点上感到不满意,随时都可以选择终止合作。

他认为,这个选择

不需要估算。随着项目推进,不断改进设计、慢慢成形。它拥抱变化,因为我看得到网站的进展。并且这种模式也体现出我的供应商公司很期待和我密切合作,达成我想要的结果。这种方法也正是为面对特殊风险(按合同规定会亏钱)而准备的,因为他们对自己完成工作的质量信心满满,对他们和客户建立的良好关系坚信不疑。

你有没有发现类似开发速率和故事点估算在团队中助长了不良作风的事情呢?对于社区专家提出的代替方案,读者,你怎么看?

查看英文原文: Should we stop using Story Points and Velocity ?

译者 金毅 金毅,从事离岸开发中心筹建和管理工作。坚信以人为本,力争做一名实干家。关注敏捷实施和项目管理的实践。

您可能也会喜欢

相关 [故事 速率] 推荐:

我们应该停止使用故事点和速率吗?

- - InfoQ cn
敏捷社区的专家正在热议如何使用故事点和速率(Velocity),不少人对使用它们估算和度量总体进度产生了怀疑,打上了问号. 大家普遍认为,产生问题的根本原因就是这些度量项往往不是挂羊头卖狗肉,就是浮于表面被误用,很少能用在刀刃上. Joshua Kerievsky详细记录了他使用故事点的经验,以及他们是如何粉饰太平的.

贪的故事

- Andre - 白板报
跟公务员一起吃饭有三个永恒的话题:房,车,贪. 他们谈起房和车固然兴奋,但只有谈起身边哪个小官又落马时才会眉飞色舞. 我发现,他们喜欢谈的话题不是大贪大腐,那个自有全国媒体去关注,而是“三小”案件. 所谓“三小”是指“小工程、小项目、小干部”. 因为小,往往不会被马上双规,这为小干部赢得了时间,他们会对纪检部门说,“我现在想不起来了,等回家好好梳理梳理.

Scrum的故事

- Philip - 《程序员》杂志官网
2001年2月,17位敏捷先驱齐聚犹他雪鸟度假村,起草《敏捷宣言》的时候,Scrum只是众多方法中不太起眼的一个. 十年之后,Scrum却成为最流行的敏捷方法,几乎成为敏捷的代名词. 本文来介绍下Scrum的两位创始人——Jeff Sutherland与Ken Schwaber. 大家可能不会想到,Jeff Sutherland的第一份工作居然是美国空军战斗机飞行员,还曾于1967年获得了“壮志凌云”称号,完成过100次飞越北部越南的作战任务.

罗勒的故事

- Liao Yun - Day Green
文 by 马姑娘  \  图 来自网络搜集. 认识罗勒是好多年前,我刚刚开始喜欢香草的时候,但是第一次体会到罗勒的神奇是在几个月前的泰国. 和几个同事找到一家泰国菜店,对着菜单乱指一通,点了一盘sea food with basil. 当时没觉得怎么样,没想到几个小时以后同事像喝了酒一样变得异常聒噪,在回国的飞机上一直不停做幼稚的自问自答,几个小时嘴巴没有停过.

屁眼的故事

- 迦叶 - 无聊哦
当人体最初形成的时候,所有的器官都想当头儿. 大脑说:应该我当头儿,因为我掌管着全身的各种神经反应和功能. 手说:我们应该当头儿,因为我们做所有的活儿来挣钱. 脚说:我们应该当头儿,我们载着身体和大脑走遍天涯海角. 心脏、肺、眼睛等器官纷纷发言要求当头儿. 最后,屁眼站出来表示他也想当头儿. 大家对他的要求嘲笑不止,屁眼怎么能当头儿呢?.

别针的故事

- 扬 - 玩意儿
这里的主人公是别针,摄影师以微距拍摄来诠释它的悲欢离合,被人控制着情绪. 本文原始链接:http://www.cngadget.cn/the-story-of-pin.html.

15个小故事

- 慧 - 有意思吧
  甲去买烟,烟29元,但他没火柴,跟店员说:“顺便送一盒火柴吧.   乙去买烟,烟29元,他也没火柴,跟店员说:“便宜一毛吧. 第一种:店主认为自己在一个商品上赚钱了,另外一个没赚钱. 第二种:店主认为两个商品都赚钱了,赚钱指数为2. 同样,这种心理还表现在买一送一的花招上,顾客认为有一样东西不用付钱,就赚了,其实都是心理边际效应在作怪.

HTC品牌故事

- alcon - AnimeTaste
HTC我们都很熟悉咯,这里发现了一个关于他们的动画,讲述了他们的成长之路,在此我们不去评判这个品牌的好坏,单纯来一起欣赏下这个动画宣传片吧. 每周故事汇 | weekly stories 36. 每周故事汇 | weekly stories 40. 每周故事汇 | weekly stories 1.

Socket的速率控制

- - CSDN博客互联网推荐文章
做一个以精确速率向外输出数据的数据源,要完成这个目标,最基础的是:. 1、找到一种精确的计时器,在精确的时间范围内控制数据源以指定的速度向外发送数据. 2、通过对套接字选项和线程优先级的设置减少网络因素对发送速度造成的影响,从而提高发送精度,保证数据的实际发送量尽可能的达到指定的理论发送量.      针对第一个要求,通过寻找到一种时间精度达到微秒级的精确计数器来保证,在硬件支持的情况下可以通过WindowsAPI获取时钟频率以及震荡次数,通过在事件两端分别调用函数得到震荡次数的差值并结合时钟频率可以计算出精确的时间间隔,通过指定的传输速度和精确的延时可以计算出需要发送的数据量.

秋菊男的故事

- 牛三斤 - 皮赛罗可爱多---the peaceful side of luoyonghao
十四年前......这是一个真实的故事. 十四年前,我在东北老家延吉市的一个外语培训机构学过一段时间的许国璋英语. 这是一个韩国人开的私立学校,名字很土,叫三育. 学校的水准很糟糕,国内教师通常是本地的大学或中学教师出来兼职的,外教大都是些口音诡异的菲律宾人和马来西亚人. 经常能看到的场面是,一些学生在“外教口语班”开课后,纷纷赶到前台表示愤怒,工作人员则浓眉大眼地解释说,菲律宾和马来西亚的官方语言确实是英语.