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

　　怎样从bug中分析问题所在?

　　Bug的出现往往是系统中产生了更常见问题的一种症状，而对于精益团队来说，将这些症状与真正的问题相关联起来是至关重要的。可以这么说，正如米开朗基罗从大理石碎片中发现它的美丽，并最终打造成迷人的雕像一样，精益团队的任务(例如某些团队会将持续改进作为他们每日工作内容的一部分)就是发挥他们的洞察力，从大量的bug中发现问题，并将其抽取出来。实现这一点需要进行细致地分析，并将这些原始的问题转化为学习的机会。

　　我发现了一种着手进行这种分析的良好方式，就是将所有bug分门别类，并且理解每个bug类别的权重。大多数情况下，某个bug类别就体现了造成某个现有问题的原因，或者它本身就是一个问题。这种关联性可以帮助你以正确的顺序处理这些问题，并首先从对整个操作绩效影响最大的问题开始解决。如果你仍然不确定应该从何处着手，那么优先解决质量问题是比较保险的做法。

　　示例1：敏捷开发中的情景

　　当时我在这个使用敏捷开发的团队中担任经理一职。和许多团队一样，我们团队也不是一个跨职能的团队(典型的Scrum-but)，而是一个负责后台的团队。它在某个迭代内负责构建基础服务端软件，以便让应用团队在之后的迭代中使用这部分功能。

　　我们按照Paretos原则(即80-20原则)对产生的bug进行了一些分析，并且找出了一个占总数约20%的bug类别：这些bug都是由应用团队所提出的，与我们团队所建立的后台软件所暴露的API对“隐式”这一概念的定义有关。当应用团队在使用我们提供的功能时，经常会发生遗漏了某些输入参数，或者是缺少了某些输出数据等问题……因此他们就会为我们创建一些bug，而我们的团队则会说：嘿!这个API已经隐式地表明了它不会返回这些数据。

　　我们同时注意到了这些bug的持续时间，通常从创建直到关闭为止一共持续了大约4个星期。(在最好的情况下)在以一个月为周期的迭代的最后阶段会进行代码发布，客户端团队则可以在下一个迭代时使用这些代码。因此当客户端团队创建了bug，并指派给原来的开发者时，往往距离她开发那些代码时已经过去了两三个星期，开发者不得不再度拾起这段代码……

　　为了处理这种情况，我们决定改变一下工作的方式，将相关人员组织在一起，而产生一个相关联、跨职能并且跨技能的团队。

　　采用了新的方式之后，我们注意到这些“隐式API”相关的bug数量大幅下降了(约50%)。最令人欣慰的是，这种类型的bug的持续时间下降到了几个工作日以内。当然，这个数字有一定的水分，有些bug虽然被发现了，但是并没有记录下来，因为开发者们现在进行结对编程，于是许多bug直接在座位上就解决了。

　　虽然成果是显著的，但我总感觉到还有些不适之处，却说不出究竟是哪里出了问题。之后不久我才发觉，从精益的角度来说，我们目前还有两个不足之处：

　　首先，我们的系统中依然存在bug，因此我们不得不重复劳动，这使得整个开发系统出现了生产力的浪费。但是由于缺乏内建的质量标准，我们无法保证服务端开发者所开发的API不存在问题。此外，对于错误的处理也没有真正的标准，我们的解决手段就是：遇到问题就坐下来一起解决。

　　尽管结果非常显著且令人振奋，但它与团队的每日绩效没并有什么直接的关联，团队也无法立即采取行动并在第二天直接看到结果。我们只是从宏观上在6个月结束后的发布中才能够看到这一效果：即在bug总数中与API相关的bug只占少数。因此我们看到：建立一个跨技能的团队确实能够在某种程度上改进质量，但我们还未能提供一种有效的方法，让我们能够每天监控它的情况，并采取相应的行动。

　　示例2：精益开发中的情景

　　时间转眼间过去了几年，我还是任职于同一家公司中，但目前的职位是项目主管及教练，负责一个大型的多团队、多种技术的敏捷项目的实施。某一个团队遇到了一个很有挑战的技术难题，他们要与某个大家都没有什么经验的技术进行整合。整个团队在过去的两个Sprint中没有交付任何用户故事，他们深陷于质量问题(例如bug)中难以自拨。当第二个Sprint结束后，依然没有任何完成的用户故事(比方说，按照我们对完成的定义来看，该用户故事在功能性需求上需要做到没有任何bug)可以交付。因此在回顾会议中，整个团队一致决定，将每周进行bug评审(在精益中称为红箱分析)。

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