大规模视频网站的计费与流量管理
本次分享将会就大规模视频网站的计费与流量管理这个话题，从操作层面细细进行讲解和分析，为系统工程师们揭示平日里我们没有关心的另一些内容。同时也希望本次分享能揭示行业中的一些“潜规则”，让互联网行业的流量与带宽管理更为开放与简洁。
本次演讲视频录制于QCon杭州2011。
新闻
该内容已经被标记书签！
标记书签错误，请重试！
在Agile/Scrum项目中处理Bug
作者 Mark Levison 译者 曹云飞 发布于 2009年7月23日
人们常问这样一个问题：Scrum建议一个团队如何处理 bug？Bug是应当放在产品backlog中还是在一个单独的bug清单中？如果bug在产品backlog中，那么是由产品所 有者来确定bug优先级还是bug自动成为最重要的项目？是否应该有一个单独的bug修复sprint？
在Pascal Maugeri的团队 ，即使在改善了对“完成”和正在做“正确的测试/单元测试”的定义之后 ，他们还是能发现从sprint中逃逸的bug 。他问如何解决这个问题。
George Dinwiddie， 敏捷教练， 建议团队在回顾时提出这个问题——他曾与只有微乎其微的bug率的团队共事。Mark Levison （本文记 者）建议： “我会问为什么没有在发现bug的sprint中修复它们？我的重点是减少发现（然后修正）问题所花费的 时间。毕竟，如果我们在一个sprint的故事中发现了一个bug，那么产品负责人不应该同意该故事已经完成。此外， 早期发现bug将使人们更容易修复，因为开发团队的脑海中对相关代码依然有清晰的印象。
Jim Schiel ，Artisan咨询 公司的认证Scrum训练师，认为只需把bug放在产品 backlog中，由产品负责人确定优先级， “除非修复起来很简单，在这种情况下，你可以在sprint的规划会议中确定 解决方案并且在sprint中实施该方案。”
Bruce Kantelis说，这一 切都与发展一种文化有关：“我们会把缺陷分类。让用户工作陷于停滞的bug会被设定为头等优先级，并且马上得 到注意，开发团队会中断当前工作来修复程序并打补丁。其他的缺陷都成为故事，放在下一个sprint的任务列表顶部 。随着时间的推移，团队认识到与质量相关的度量和行为真的会影响他们的日常工作，他们就会尽量减少缺陷及其 带来的干扰。”
Mike Cohn提醒我们， 对于在sprint中发现的bug，最好的处理方法是在整个团队房间里面大声喊出这个bug。如果做不到这一点，可以用 一张卡片来描述该bug并添加到任务板上。然而对于在sprint中漏掉的bug，他宁愿将它们添加到产品backlog中，由 产品负责人考虑它们的优先级。许多现有的团队仍然有bug数据库，他们还得继续使用该数据库。在这种情况下， 他建议保持一个独立的bug backlog，产品负责人安排各个队列中任务的优先级：例如，头两个条目来自产品 backlog，接下来的条目是bug，最终两个条目来自backlog。
Kev lin Henney不太认同这种做法，他认为这近乎等同于将bug看作会产生负面价值的特性：
如果缺陷被视为具有负面价值的特性，它们就会像特性一样 被管理。开发团队会把划分了优先级的bug存储起来，像对待用户故事一样对待bug，把修复bug的工作外包，等等 做法都会冒出来。虽然这些做法对于处于过渡期或者危机的项目来说有些作用，但并不是一个应予以鼓励的长期观 点。毕竟，正如“敏捷软件开发宣言”所说： “可工作的软件是工作进展的首要度量方式。”一个功能特性中已经 存在已知的缺陷，还要把它看做是已完成和可工作的，这样的做法可有点不太诚实。——“是的，这个功能已经完 成了……但还有一些bug。”
Ron Jeffries 认为：在功能特性开发结束后再修复其中的缺陷，这样做的代价总是比在刚发现的时候就去修复要昂贵。
所以，如果我们错误地编写软件然后修复它，客户会花费更多金钱：除了给付应有的，她还得为bug的修复 付出额外代价。
她真的应该责备我们。我愿意鼓励客户把所有的缺陷区分优先次序，这能让客户体验到团队不恰当的软件过 程所带来的痛苦。我确信客户会表达那种痛苦，从而使得团队明白把事情做好是更好的方式。
你总是避免bug么？将bug放在产品backlog中？你发现Kevlin 指出的问题了么？
查看英文原文：Coping with Bugs on an Agile/Scrum Project
译者 曹云飞 从事软件开发多年，包括Web应用、桌面应用、前后端开发，热衷于计算机理论与应用技术的钻研，软件架构与敏捷开发。
孰优孰劣？没有定论
发表人
张 凯峰
发表于
1 条回复
关注此讨论 回复