BT

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

计算速度是否要把bug修复考虑在内?视情况而定

| 作者 Vikas Hazrati 关注 0 他的粉丝 ,译者 郑柯 关注 3 他的粉丝 发布于 2011年9月19日. 估计阅读时间: 3 分钟 | 如何结合区块链技术,帮助企业降本增效?让我们深度了解几个成功的案例。

计算速度是否要把bug修复考虑在内?近来,在这个问题上有大量争论。看起来似乎没有一个绝对正确的答案。不过,敏捷人士提出一些建议,说明什么时候应该考虑,如何放进去,以及什么时候可以避免。

Syed认为:是否要放进去, 要看你怎么定义速度。如果速度是从“价值”角度出发,那么bug修复就不应该放进去,因为这些工作没有为客户加入任何新的价值。然而,如果速度是从“成本”角度考虑,那么bug修复应该放进去,因为它们占用了时间和精力。

Mike Cohn推荐 为bug赋予故事点数。他认为:

这样做对两个阵营来说是最好的。我们可以看到团队真正能够完成多少工作,还能看到历史数据,知道每个sprint中有多少工作放在修复bug的故事点数上。

Jason Yip提出一个有趣的比喻,他把速度看作我们向目标终点奔跑的一个指示。 Jason强调:重要之处是跑向目标。

现在,如果有人施加反向推力,往后推动5米,速度就降低了。因此,速度更像是向量,而不是标量。

Robert认为:可以采取财务中的 复式记账法来判断速度。他说:

我会把bug修复算在速度内——但是,在传统的复式记账方法中,我还会把产生bug的那个迭代的速度拿过来,作为负值记录在当前迭代的速度上。

Greg推荐的做法是:只用简单一句话说明不把bug修复工作放在速度里面,这样很危险。是否应该计算在内,要看很多具体情况,还有目标的真实定义:

也许目标是开发多个新功能,也许目标是开发一个能让很多客户兴奋的特性。也许目标是修复遗留产品中的bug。不把bug修复放在速度中,也许对某个团队有意义,但是还有很多上下文这么做有问题。

Jack Milunsky提到:是不是把bug修复工作放到速度里面并不重要,重要的是要认真对待它,因为修复bug需要耗费时间。

在Sprint或迭代计划会议时,应该把bug和用户故事放进去。如此,完成任务和修复bug的总时间不应超过团队的能力范围。我知道很多教练会争辩,说bug应该单独跟踪,而且应该在发现bug的sprint里面解决掉。但是在实践中,这不是总能做到的。尝试一下,你就会大大改进团队的可预测性。

因此,应该认真对待bug,这是大家的强烈共识。是否应该把修复bug的工作放到速度里面去,还是个问题,大家意见不一致,也许,正确的做法是:根据具体情况。

查看英文原文: InfoQ:Count Bug Fixes Towards Velocity? Depends…

评价本文

专业度
风格

您好,朋友!

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

获得来自InfoQ的更多体验。

告诉我们您的想法

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

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

毋庸置疑,计算速度必须计入Bug修复时间! by 高 翌翔

看过4x100接力赛都知道,中途掉棒、捡棒(Bug、Debug)没人为你单独计算失误时间,平均速度是400/总时间得出的!

因此,如果在计算速度时不计算Bug修复时间的话,那么这种做法就是自欺欺人的,
计算出来的速度只是理想速度罢了,根本没有任何参考价值!

正确的做法是,计算速度是严格计入Bug修复时间,然后通过不断改进过程、方法、工具,
缩短Bug修复时间,从而真正达到提高速度之目的!

Re: 毋庸置疑,计算速度必须计入Bug修复时间! by mahone mahone

比较赞同。。。
如果对于客户来说。。。有bug也没关系?那就不要计算fix bug的时间。。。
如果客户觉得不能有bug(一些比较明显的bug,或者是业务逻辑的bug),那肯定要计算在内。。。不然,就是程序员不停的加班。。。

Re: 毋庸置疑,计算速度必须计入Bug修复时间! by 高 翌翔

比较赞同。。。
如果对于客户来说。。。有bug也没关系?那就不要计算fix bug的时间。。。
如果客户觉得不能有bug(一些比较明显的bug,或者是业务逻辑的bug),那肯定要计算在内。。。不然,就是程序员不停的加班。。。

与客户交流时只提速度,不提Bug,否则客户都被吓跑了。

而告知客户的速度就是计入Bug修复时间后得出的实际速度
而排除Bug修复时间算出的理论速度是我们追求的终极目标!

Re: 毋庸置疑,计算速度必须计入Bug修复时间! by 熊 小

《持续交付模式》从另一个角度讲述了相关问题:

修正补丁(hot fix)如何处理?
所有这些场景中,我们都没有提到修正补丁的概念。这是有意为之,如果遵循持续交付的思想和理念,是没有所谓的修正补丁的。一旦变更进入集成环境,它们就会很快进入生产环境。在这个理论下,不需要修正补丁,只有正常的bug修复,其优先级偶尔会超过功能特性的开发。
然而,现实世界不是完全由理论指导的。功能常常会停滞在QA阶段,其时间超过预期,要么是质量问题,或者仅仅是因为它们的规模。与之类似,生产部署也可能延迟,因为业务需要,比如合同强制要求,或是早已公之于众的特定日期升级计划。类似事件发生时,修正补丁就有必要了。此时,最佳方案是抛开流程,完成工作优先。不要让形式成为公司和客户不必要的负担。一旦尘埃落定,危机解决,就可以开始研究问题发生的根本原因了。
持续交付的目标,不是要让修正补丁更易于处理,而是要制定出编码和测试的标准,消除对修正补丁的需要。每次流程失败的时候,就是你学习如何改进代码标准和测试实践的机会,避免重大bug再次发生。同样地,这也能为你提供理由,检查日程表制定方针中的缺陷,看看是什么导致流程的停滞和问题。如果无法同时在这两方面聚焦,你就永远不能保证所有的bug修复都可以通过严格控制的流程。
简而言之,持续改进是任何形式的持续交付的根本组件。

Re: 《持续交付模式》从另一个角度讲述了相关问题 by 高 翌翔

恩,受教了。
就我本人而言,努力提高测试技能是当务之急!

最后的总结很精彩持续改进是任何形式的持续交付的根本组件

我来班门弄斧一回,敏捷就是以变应变

Re: 《持续交付模式》从另一个角度讲述了相关问题 by 熊 小

温伯格的那些经典书籍的重要性,现在在国内仍然没有得到足够的认识。他有一本里面提到的反馈循环,是非常适合用于敏捷的(当然,本质上任何管理都适用),而且可以拿来做深入分析,而不是仅仅下一个简单的定性结论。

可惜现在这些书已经很难找到了。

Re: 温伯格的那些经典书籍的重要性 by 高 翌翔

恩,之前在微博有高人提过温伯格的名字,当时简单查了一下,是位世外高人!

确实,高度抽象的结论虽然便于传播和记忆,但是不利于执行。
可真做起来,问题很多!

多谢指点,以前孤真是陋寡闻,开始关注温伯格老前辈,可惜他不在微博玩儿里,嘿嘿

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

7 讨论

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


找回密码....

Follow

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

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

Like

内容自由定制

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

Notifications

获取更新

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

BT