修复bug与解决问题——从敏捷到精益

　　关于精益的定义有许多，但其中最令我感到鼓舞的是精益企业研究所主席John Shooke在它的著作《管理精益》中所描述的一段话：精益通过提高员工的水平来保证产品开发。在这个定义的基础上，这篇论文接下来解释了精益是怎样提高人员的水平的：方法就是解决问题。这一定义揭示了以下管理实践的美妙之处：仔细设计你的工作，让你能够清晰地看见所发生的问题(以及同时出现的学习机会)，并在问题出现后以科学的方式解决。

　　在与使用敏捷方法进行软件开发的团队共同工作时，我曾经有过一些误解：起初时，我混淆了bug和问题的概念，并且确信敏捷过程就是精益，因为它能够使bug变得可见。在最后的几个月里，在我头脑中的概念开始渐渐清晰起来，回想起当初的情景，我开始相信，我所在的敏捷团队产生的bug，与精益系统产生的学习机会并不是一回事：后者表明在我的团队中确实存在着质量问题，而在其它许多团队身上我也看到了同样的问题。

　　写这篇文章的目的，是为了描述我对bug与质量问题这一点上的思考方式是怎样逐渐变化的。这对于读者更好地理解造成bug产生的质量问题，并相应地提高绩效能够起到一些启示作用。并通过一些真实的故事描述来看清楚真正的问题所在。(先声明一点：我们并不假设所有的敏捷团队都对此问题抱有类似的误解)

　　　什么是bug?

　　在软件工业中，一个bug可以代表任何形式的系统错误(NullPointerException、Http 404错误代码或是蓝屏……)、功能性错误(在我单击B的时候，系统本应执行Z，却最终执行了Y)、性能问题以及配置错误等等。

　　在精益的术语中，一个bug必须能够按照下一节提到的定义进行清晰的表达，才能说它是一个问题。请相信我，我所见过的(和自己产生的)bug中，95%以上都不像是某种问题——性能问题或许是个常见的例外情况，但有趣的是，它们也是绩效的一部分，不是吗?

　　什么是问题?

　　让我们在这里做一个标准的定义吧。在《丰田模式：精益模式的实践》(Toyota Way Field book)这本书中，Jeffrey Liker定义了一个问题所需的四个方面的信息：

　　当前的实际绩效

　　预期的绩效(标准绩效或目标绩效)

　　以当前绩效和目标绩效之差所体现的问题严重程度

　　问题的范围和特点

　　正如Brenée Brown在TED所做的一次关于漏洞的演讲中所说的一样，如果你不能评估某个漏洞，那么它就不存在。从更实用的角度来说，如果你不能解释在绩效差距上的问题所在，那么很可能是由于你并没有花足够的时间去思考它。

　　在开始着手解决一个问题之前，重要的一点是要清晰地表达它，花一定时间去理解它(按照精益专家Michael Ballé的说法：要善待它)，并且克制住直奔解决方案的冲动。我们都听说过爱因斯坦的名言：“如果我只有一小时的时间去解决一个问题，我会首先用55分钟去思考问题，最后用5分钟去思考解决方案。”没有人说这是件容易的事。

　　在软件开发敏捷团队的情境中，绩效指标或许是一张燃尽图(表示工作量与延迟)、bug数量、系统响应时间(质量)、客户对已提交的用户故事的评价(以总分10分来表示客户满意度)，以及每个Sprint提交的用户故事(或用户故事总点数)数量(生产力)。

　　按照这些指标，可以有以下这些问题存在：

　　质量：这个页面的响应时间目标是在500ms以内，而在5000个并发用户的情况下，我们测量到的结果是1500ms。

　　质量：在Sprint结束时仍未解决的bug数量(2个，而不是0个)

　　工作量/延迟：我们预计这个用户故事需要3天时间完成，而实际上用了8天才完成

　　生产力：在Sprint结束时，整个团队共提交了5个完成的用户故事，而之前的计划是完成7个。

　　客户满意度：我们希望每个用户故事都能够得到8分以上(满分10分)，而在上个Sprint结束后，有两个用户故事的客户满意度低于这个分数(6.5分和7分)。

原文转自：http://www.infoq.com/cn/articles/bug-fixing-problem-solving