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

　　在第一次会议中，团队为所遇到的问题建立了一个Pareto模型。我们创建了一张表格，将bug类别放在一列里，bug的数量和bug ID则分别用余下的几列来表示。

　　之后的目标是逐个排除每种bug类别背后的根本问题，首先从发生次数最频繁的开始。为了鼓励团队成员就这一话题展开交流，Scrum Master决定将这张Pareto表格贴在Scrum公告板与bug数量的旁边，并且每天对其进行更新。在每天早上的站立会议上，团队都会报告当前的 bug情况，而新产生的bug都会按照其分类添加到该表格中。这种方式能够使团队更明显地意识到每日质量性能的变化情况，同时也是实现PDCA中的C—— Check(检验)的一种良好方式。当问题被根除之后，这方面的bug应该至少在一周之内不复存在了。不过，某些时候还是会发生这些bug，而这也是需要学习的地方。

　　举一个例子，该团队已经认识到了bug类别中有一种属于回归缺陷，即对软件的改动破坏了原本能够正常工作的特性。这种bug多数情况下发生在图形用户界面端，因为对这一部分进行自动化测试是非常困难的事。我们所找出的一个根本问题在于，初级程序员并不总是完全理解他们对代码的改动可能会造成的影响。对此问题的解决措施是在流程中加入一个新的步骤，在提交代码之前先让某个更资深的开发者进行代码复审。这一步骤大概只需要15分钟，但能够大幅降低回归缺陷出现的次数。此外还将对每次发布的bug数量进行每日评估(每天发布两次)。这种方式还能够提高初级开发者的技能水平。

　　最终，所有的问题都得到了解决，结果是令人惊叹的：所有的问题都通过标准流程(在提交代码之前进行代码复审)得以一一根除。每日的bug数量直线下降，每个迭代周末能够提交的包括完整功能并且无bug的用户故事数量也在上升。3个月之后，该团队就从之前产生bug数量最多的困境中摇身一变，成为了整个项目中高质量、高效率团队的代名词。

　　这种方式相比之前的方法显得更为精益。因为它对每日绩效(质量)和生产力(提交的用户故事数量)产生了直接的影响，并且为团队带来了新的操作标准。

　　图2：敏捷团队的性能指标示例

　　将一个敏捷团队转变为学习团队

　　经历过了以上两个示例之后，加上我从这次经历中所学到的经验，我将为你推荐一种将敏捷团队转变为精益和学习团队的路线图：

　　对绩效进行评估，让它可为众人所见，并且每天都要对它展开讨论。

　　我能够理解这一点对于某些非主流的敏捷教练来说是难以忍受的，但事实可能会令你感到沮丧：如果我们需要进行改进，那么首先要做的第一件事就是评估。此外，最重要的一点是，只有面对现实，才能进行深刻的学习。网络巨擎(谷歌、亚马逊、Twitter及Facebook)或者实践领导者(Etsy)都是这样做的：他们对每件事情都进行评估，如果他们仅仅关注于计算用户故事的点数，就不可能达到如今的绩效。在敏捷团队方面有个实际的例子可供参考：除了Sprint燃尽图之外，还要展示质量绩效(没有关闭的bug数量、每次发布的bug数量、每种类别的bug数量，等等)、客户满意度(例如对交付的用户故事按照总分10分进行评分)，并且每一天都对燃尽图没有达到预期目标的原因进行分析。

　　确保使用精益的方式表达问题

　　对于某个问题的表达必须包含两个方面：所观察到的绩效和目标绩效。Pareto是一种将原始的bug进行分类处理的优秀工具，但还要专门进行分析，以理解每个类别是如何影响到绩效的。

　　这种方式可以保证你已经清晰地为划分了问题的类型，并且从商业绩效的角度以正确的次序分别进行处理。

　　当问题出现时逐一分析解决

　　精益式解决问题方法的关键之一，就在于不要试图同时解决多个问题。你只需要专注于一个问题，理解它如何影响你的绩效指标，并确保你理解造成该问题的原因所在。

　　进行校验

　　很遗憾，根据我的经验来看，我们通常会倾向于忽略这一步骤。如果你的预估与现实不符、你的软件不能正常工作，那很好!你是否可以从中学到些什么?如果你所想象中会发生的事与实际发生的事产生了偏差，那这一段偏差就是可以从中进行学习的地方。这正是在第二个示例中的团队所做的事。正如 Stephen J. Spear在他的著作《Chasing the Rabbit》中所写的一样，这是你的组织中的系统在向你发出的一种声音：“在我身上还有一些你所不了解的东西，但如果你愿意倾听，我就会告诉你。”团队正是这样才能够从工作与流程中快速地培养自己的专业技能，并真正地成为一支梦想中的团队。

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