领导力大挑战
在实施Scrum项目的过程中，Scrum Master的角色是相当关键的，因为他是团队的推动者。本文围绕什么是仆人式领导、仆人式领导的起源、如何将领导力传达给团队、Scrum Master作为仆人式领导者的角色展开叙述，同时重点阐述仆人式领导者应有的基本内外特征。
新闻
该内容已经被标记书签！
标记书签错误，请重试！
计算速度是否要把bug修复考虑在内？视情况而定
作者 Vikas Hazrati 译者 郑柯 发布于 2011年9月18日
计算速度是否要把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中文站总编。做过开发，当过PM，干过销售，搞过市场，最终还是回到媒体。实用的理想主义者，相信：每天改变一点点，这个世界会更好。
相关厂商内容
多名敏捷社区最有影响力人物将出席Scrum Gathering上海站大会
大众点评网诚聘：Java、架构/性能优化、Hadoop等职位
毋庸置疑，计算速度必须计入Bug修复时间！
发表人
高 翌翔
发表于
Re: 毋庸置疑，计算速度必须计入Bug修复时间！
发表人
mahone mahone
发表于
Re: 毋庸置疑，计算速度必须计入Bug修复时间！
发表人
高 翌翔
发表于
Re: 毋庸置疑，计算速度必须计入Bug修复时间！
发表人
熊 小
发表于
Re: 《持续交付模式》从另一个角度讲述了相关问题
发表人
高 翌翔
发表于
Re: 《持续交付模式》从另一个角度讲述了相关问题
发表人
熊 小
发表于
Re: 温伯格的那些经典书籍的重要性
发表人
高 翌翔
发表于
-
看过4x100接力赛都知道，中途掉棒、捡棒（Bug、Debug）没人为你单独计算失误时间，平均速度是400/总时间得出的！
因此，如果在计算速度时不计算Bug修复时间的话，那么这种做法就是自欺欺人的，
计算出来的速度只是理想速度罢了，根本没有任何参考价值！
正确的做法是，计算速度是严格计入Bug修复时间，然后通过不断改进过程、方法、工具，
缩短Bug修复时间，从而真正达到提高速度之目的！ -
比较赞同。。。
如果对于客户来说。。。有bug也没关系？那就不要计算fix bug的时间。。。
如果客户觉得不能有bug（一些比较明显的bug，或者是业务逻辑的bug），那肯定要计算在内。。。不然，就是程序员不停的加班。。。 -
比较赞同。。。
如果对于客户来说。。。有bug也没关系？那就不要计算fix bug的时间。。。
如果客户觉得不能有bug（一些比较明显的bug，或者是业务逻辑的bug），那肯定要计算在内。。。不然，就是程序员不停的加班。。。
与客户交流时只提速度，不提Bug，否则客户都被吓跑了。
而告知客户的速度就是计入Bug修复时间后得出的实际速度，
而排除Bug修复时间算出的理论速度是我们追求的终极目标！ -
《持续交付模式》从另一个角度讲述了相关问题：
修正补丁（hot fix）如何处理？
所有这些场景中，我们都没有提到修正补丁的概念。这是有意为之，如果遵循持续交付的思想和理念，是没有所谓的修正补丁的。一旦变更进入集成环境，它们就会很快进入生产环境。在这个理论下，不需要修正补丁，只有正常的bug修复，其优先级偶尔会超过功能特性的开发。
然而，现实世界不是完全由理论指导的。功能常常会停滞在QA阶段，其时间超过预期，要么是质量问题，或者仅仅是因为它们的规模。与之类似，生产部署也可能延迟，因为业务需要，比如合同强制要求，或是早已公之于众的特定日期升级计划。类似事件发生时，修正补丁就有必要了。此时，最佳方案是抛开流程，完成工作优先。不要让形式成为公司和客户不必要的负担。一旦尘埃落定，危机解决，就可以开始研究问题发生的根本原因了。
持续交付的目标，不是要让修正补丁更易于处理，而是要制定出编码和测试的标准，消除对修正补丁的需要。每次流程失败的时候，就是你学习如何改进代码标准和测试实践的机会，避免重大bug再次发生。同样地，这也能为你提供理由，检查日程表制定方针中的缺陷，看看是什么导致流程的停滞和问题。如果无法同时在这两方面聚焦，你就永远不能保证所有的bug修复都可以通过严格控制的流程。
简而言之，持续改进是任何形式的持续交付的根本组件。 -
恩，受教了。
就我本人而言，努力提高测试技能是当务之急！
最后的总结很精彩持续改进是任何形式的持续交付的根本组件。
我来班门弄斧一回，敏捷就是以变应变。 -
温伯格的那些经典书籍的重要性，现在在国内仍然没有得到足够的认识。他有一本里面提到的反馈循环，是非常适合用于敏捷的（当然，本质上任何管理都适用），而且可以拿来做深入分析，而不是仅仅下一个简单的定性结论。
可惜现在这些书已经很难找到了。 -
恩，之前在微博有高人提过温伯格的名字，当时简单查了一下，是位世外高人！
确实，高度抽象的结论虽然便于传播和记忆，但是不利于执行。
可真做起来，问题很多！
多谢指点，以前孤真是陋寡闻，开始关注温伯格老前辈，可惜他不在微博玩儿里，嘿嘿
7 条回复
关注此讨论 回复