关于精益的定义有许多，但其中最令我感到鼓舞的是精益企业研究所主席John Shooke在它的著作《管理精益》中所描述的一段话：精益通过提高员工的水平来保证产品开发。在这个定义的基础上，这篇论文接下来解释了精益是怎样提高人员的水平的：方法就是解决问题。这一定义揭示了以下管理实践的美妙之处：仔细设计你的工作，让你能够清晰地看见所发生的问题（以及同时出现的学习机会），并在问题出现后以科学的方式解决。
在与使用敏捷方法进行软件开发的团队共同工作时，我曾经有过一些误解：起初时，我混淆了bug和问题的概念，并且确信敏捷过程就是精益，因为它能够使bug变得可见。在最后的几个月里，在我头脑中的概念开始渐渐清晰起来，回想起当初的情景，我开始相信，我所在的敏捷团队产生的bug，与精益系统产生的学习机会并不是一回事：后者表明在我的团队中确实存在着质量问题，而在其它许多团队身上我也看到了同样的问题。
写这篇文章的目的，是为了描述我对bug与质量问题这一点上的思考方式是怎样逐渐变化的。这对于读者更好地理解造成bug产生的质量问题，并相应地提高绩效能够起到一些启示作用。并通过一些真实的故事描述来看清楚真正的问题所在。（先声明一点：我们并不假设所有的敏捷团队都对此问题抱有类似的误解）
什么是bug？
在软件工业中，一个bug可以代表任何形式的系统错误（NullPointerException、Http 404错误代码或是蓝屏……）、功能性错误（在我单击B的时候，系统本应执行Z，却最终执行了Y）、性能问题以及配置错误等等。
在精益的术语中，一个bug必须能够按照下一节提到的定义进行清晰的表达，才能说它是一个问题。请相信我，我所见过的（和自己产生的）bug中，95%以上都不像是某种问题。性能问题或许是个常见的例外情况，但有趣的是，它们都
而在精益团队中，一个bug并不代表一个问题，xXXX。我所见过的95%以上的bug表面上并不像真正的问题——性能问题或许是个常见的例外情况，但有趣的是，它们也是绩效的一部分，不是吗？
什么是问题？
让我们在这里做一个标准的定义吧。在《丰田模式：精益模式的实践》（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分）。
怎样从bug中分析问题所在？
Bug的出现往往是系统中产生了更常见问题的一种症状，而对于精益团队来说，将这些症状与真正的问题相关联起来是至关重要的。可以这么说，正如米开朗基罗从大理石碎片中发现它的美丽，并最终打造成迷人的雕像一样，精益团队的任务（例如某些团队会将持续改进作为他们每日工作内容的一部分）就是发挥他们的洞察力，从大量的bug中发现问题，并将其抽取出来。实现这一点需要进行细致地分析，并将这些原始的问题转化为学习的机会。
我发现了一种着手进行这种分析的良好方式，就是将所有bug分门别类，并且理解每个bug类别的权重。大多数情况下，某个bug类别就体现了造成某个现有问题的原因，或者它本身就是一个问题。这种关联性可以帮助你以正确的顺序处理这些问题，并首先从对整个操作绩效影响最大的问题开始解决。如果你仍然不确定应该从何处着手，那么优先解决质量问题是比较保险的做法。
为了处理这种情况，我们决定改变一下工作的方式，将相关人员组织在一起，而产生一个相关联、跨职能并且跨技能的团队。
虽然成果是显著的，但我总感觉到还有些不适之处，却说不出究竟是哪里出了问题。之后不久我才发觉，从精益的角度来说，我们目前还有两个不足之处：
在第一次会议中，团队为所遇到的问题建立了一个Pareto模型。我们创建了一张表格，将bug类别放在一列里，bug的数量和bug ID则分别用余下的几列来表示。
这种方式相比之前的方法显得更为精益。因为它对每日绩效（质量）和生产力（提交的用户故事数量）产生了直接的影响，并且为团队带来了新的操作标准。
图2：敏捷团队的性能指标示例
将一个敏捷团队转变为学习团队
经历过了以上两个示例之后，加上我从这次经历中所学到的经验，我将为你推荐一种将敏捷团队转变为精益和学习团队的路线图：
对绩效进行评估，让它可为众人所见，并且每天都要对它展开讨论。
我能够理解这一点对于某些非主流的敏捷教练来说是难以忍受的，但事实可能会令你感到沮丧：如果我们需要进行改进，那么首先要做的第一件事就是评估。此外，最重要的一点是，只有面对现实，才能进行深刻的学习。网络巨擎（谷歌、亚马逊、Twitter及Facebook）或者实践领导者（Etsy）都是这样做的：他们对每件事情都进行评估，如果他们仅仅关注于计算用户故事的点数，就不可能达到如今的绩效。在敏捷团队方面有个实际的例子可供参考：除了Sprint燃尽图之外，还要展示质量绩效（没有关闭的bug数量、每次发布的bug数量、每种类别的bug数量，等等）、客户满意度（例如对交付的用户故事按照总分10分进行评分），并且每一天都对燃尽图没有达到预期目标的原因进行分析。
确保使用精益的方式表达问题
对于某个问题的表达必须包含两个方面：所观察到的绩效和目标绩效。Pareto是一种将原始的bug进行分类处理的优秀工具，但还要专门进行分析，以理解每个类别是如何影响到绩效的。
这种方式可以保证你已经清晰地为划分了问题的类型，并且从商业绩效的角度以正确的次序分别进行处理。
当问题出现时逐一分析解决
精益式解决问题方法的关键之一，就在于不要试图同时解决多个问题。你只需要专注于一个问题，理解它如何影响你的绩效指标，并确保你理解造成该问题的原因所在。
进行校验
很遗憾，根据我的经验来看，我们通常会倾向于忽略这一步骤。如果你的预估与现实不符、你的软件不能正常工作，那很好！你是否可以从中学到些什么？如果你所想象中会发生的事与实际发生的事产生了偏差，那这一段偏差就是可以从中进行学习的地方。这正是在第二个示例中的团队所做的事。正如Stephen J. Spear在他的著作《Chasing the Rabbit》中所写的一样，这是你的组织中的系统在向你发出的一种声音：“在我身上还有一些你所不了解的东西，但如果你愿意倾听，我就会告诉你。”团队正是这样才能够从工作与流程中快速地培养自己的专业技能，并真正地成为一支梦想中的团队。
从敏捷到精益
我从2004年开始成为一名敏捷实践者，而在过去的几年中，我的思维方式渐渐转为精益。正是它帮助我跨越了一些单纯依靠敏捷无法跨过的障碍。
按我的经验来看，精益已经被证明是一种有效的手段，它能够帮助你超越敏捷，建立起一种持续改进的实践，并为团队带来直接的绩效提高和激励作用。而明确地区分bug与问题这一方式已经被证实是对持续改进的一大助力。
如果你也开始了这一相同的过程，你是否能指出bug与问题之间有哪些关键的区别因素吗？
最新内容请见作者的GitHub页：http://qaseven.github.io/