示例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评审（在精益中称为红箱分析）。
在第一次会议中，团队为所遇到的问题建立了一个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》中所写的一样，这是你的组织中的系统在向你发出的一种声音：“在我身上还有一些你所不了解的东西，但如果你愿意倾听，我就会告诉你。”团队正是这样才能够从工作与流程中快速地培养自己的专业技能，并真正地成为一支梦想中的团队。
从敏捷到精益
我从2004年开始成为一名敏捷实践者，而在过去的几年中，我的思维方式渐渐转为精益。正是它帮助我跨越了一些单纯依靠敏捷无法跨过的障碍。
按我的经验来看，精益已经被证明是一种有效的手段，它能够帮助你超越敏捷，建立起一种持续改进的实践，并为团队带来直接的绩效提高和激励作用。而明确地区分bug与问题这一方式已经被证实是对持续改进的一大助力。
如果你也开始了这一相同的过程，你是否能指出bug与问题之间有哪些关键的区别因素吗？