原文出自：
http://www.satisfice.com/articles/release_criteria.pdfhttp://www.satisfice.com/articles/release_criteria.pdf
“上线标准”和疯狂的数字
James Bach和我多年以来一直都在进行一个讨论，它是关于我对“上线标准”的定义。他认为我有时会基于一些看上去并不一目了然的根据而进行一些有些疯狂的度量。他是对的，我有时就是这么做的。当一个项目有一个可能可以上线的产品的时候，我会用一个“上线标准”去决定它是否真的可以。我之所以这么做是希望“一个产品是否能上线”这个决定是一个基于数据的、经过思考的团队的决定，而不是某个最有权利的个人的大致感觉。
有时一个上线的决定是在人们很疲惫和承受压力之下做出的。有时上线的决定是基于一个公司对收入的需要。我比较倾向于在做出决定前，通过解决引起压力的问题而减少最后一刻做上线决定时的压力。定量的上线标准是方法之一，而且我也真的这样实践着。只是这些上线标准可能对任何一个不了解某个具体项目的细节的人而言，看起来比较武断，甚至疯狂。
一个神奇数字的价值
我最近担任一个小型中间件应用组的项目经理。这个组包含6个开发人员，3个测试人员和一个兼职的文案。当我上任的时候，这个组正在准备发布一个ß版本。经过短暂的评估，我意识到这个软件不可能在大家希望它发布的时候发布一个足够稳定的ß版本。缺少稳定性是因为在当前这个版本里有太多的缺陷，并且需要太多时间来修复从上一个版本里带过来的缺陷。
但是这个团队并没有跟踪缺陷。所以我提出了围绕缺陷的ß版本和上线版本的标准。ß版本要求所有已知的缺陷都在缺陷跟踪系统中进行记录，并且未修复的高优先级的缺陷应该少于36个。而上线版本要求没有一个未修复的高优先级的缺陷。当然，还有一些其他的标准，但是这些就是围绕缺陷的标准。
当我向James描述这个情况的时候，他睁大了眼睛问我“为什么是36？36到底有什么意义？”
我解释说当我们不可能以软件当前的稳定性去发布一个成功的ß版本的时候，我希望我的团队意识到到底我们要处理的是多少个缺陷。一个实实在在的缺陷的数字可以做到这一点，因为大家都只看到自己手头上处理的那些缺陷，而没有从其它的缺陷的角度来考虑问题。
我的团队对于缺陷有一个很有意思的视角。任何时候开发人员都基于一个假设在工作，即他们正在处理的问题就是产品的最后一个问题。从事后诸葛亮的角度，这看起来有些傻。但是设想你也处在这样一个情况下。在过去的5年中，你一直被夹在两种状态中：一是认为你已经接近可以上线了，二是意识到你已经完成的工作并不算成功。你的高层在上季度就希望能发布这个产品。你的客户希望你能发布一个ß版本。有些开发人员并不理解整个产品，而你们都已经筋疲力尽了。测试人员并不完整地理解怎么测试这个产品，而且他们也疲惫了。
这时你会怎么做？你可能也吊死在同一棵树上，认为每个缺陷都只是你的产品尚不能发布的一个例外。你也会埋头苦干，并希望现在这个缺陷就是最后一个。
我希望消除这个错觉。与其希望我们正在处理的问题就是最后一个，我希望能够给问题一些空间，同意项目带着某些已知的被认同的问题上线。如果我们可以认同一个非零的缺陷标准，项目组就可以走出他们现在身陷的泥沼。他们可以停止认为他们已经达到完美，也停止因为不够完美而感到失落。我们也就能够将项目推向ß版本，以至最终的上线。
达到神奇数字
说真的，我最初的建议是“所有已知的缺陷都在缺陷跟踪系统中进行记录，并且未修复的高优先级的缺陷应该少于40个。”当我这样建议时，我被叫到区域经理的办公室。我们进行了一次颇有意思的谈话：
区域经理：“Johanna,你冒犯了整个项目组。你怎么做的项目经理？你凭什么认为系统有那么多高优先级的缺陷？我认为我们的缺陷总数甚至不到80个，并且我敢打赌其中只有少量是高优先级的。”
JR:“好吧，机遇我们的测试，我认为我们有至少100个缺陷，其中大部分都是高优先级的。我认为当我们修复一些高优先级的缺陷后我们又会发现一些低优先级的缺陷。”
区域经理：“不可能。我打赌我们的缺陷总数少于70个。也许只有6个是高优先级的。”
JR：“好吧，我们的重新修复缺陷率达到40%，而且测试人员现在每天都会发现多于5个缺陷。我们修复缺陷的速度赶不上我们发现缺陷的速度。我认为总共100个缺陷已经是一个很乐观的估计了。”40%的重新修复缺陷率意味着每修复10个缺陷就会引入4个新的缺陷。（参见G.M. Weinberg的Quality Software management, Vol 2, Dorset House, 1993）
区域经理：“不，你错了。我们不可能有超过60个缺陷。如果我输了我请你喝咖啡。”
你可以看出如果我让这次对话继续这样发展下去，区域经理可能会说他们根本就没有缺陷。这是一个聪明的上级，只是他不理解软件项目。他不理解缺陷是会聚集的，而且有时当你修复了一些缺陷后，又有10个新的缺陷跳出来了，因为现在有些代码才被运行到。我决定将对话换个方向。
JR:“好的。让我们达成一个一致意见：为了避免争执，我们说你认为大概有70个还未修复的缺陷，而我则极端悲观地认为其中一半都是高优先级的。那我们就把35作为高优先级缺陷的数字，然后加上1作为给大家的 可允许的误差,然后把ß版本的标准定义为“不多于36个高优先级的缺陷。”好么？”
容忍缺陷
区域经理答应了我的提议，条件是我要为少于36个的每个缺陷请他喝一杯咖啡。我们开始使用缺陷跟踪系统。第一周结束的时候，我们有100多个尚未修复的缺陷，其中70多个是高优先级的。为了将这个数字减少到36个以便我们可以发布ß版本，我们很挣扎，但我们努力做到了，而且我们对自己是诚实的。
这并不是说只是我希望项目组意识到缺陷。我希望他们能愉快地认同缺陷。他们必须意识到他们生产了缺陷而且他们也不一定可以在某个特定版本中修复所有的缺陷。这样的认识反过来使得意识到缺陷并没有那么可怕。缺陷也是可以容忍的。
这个项目的客户对他们拿到的ß版本欣喜若狂。他们从来没有从这家公司得到过这么好的一个版本。当我们发布最终版本的时候，他们打来电话祝贺项目组。
我并不是说少于36个缺陷就是质量好而37个缺陷就是不可接受的。我使用这个缺陷指标，帮助项目组迈出质量意识的第一步。如果这个项目组的人说“我不认为36是一个正确的数字。”那我们就会谈一谈对于这个产品质量到底意味着什么。
在这个案例中，ß版本和发布版本的标准帮助项目组看到他们正在做的事情。而且，每个标准都给了公司一个统一的目标和标尺，也允许他们可以不用完美只要良好。
在这个案例中，缺陷数目是一个集中的团队的衡量标准。团队只有在团队里的每个人都发挥团队精神通力合作时才能成功。我把项目组推向一个具体的目标，并让我自己帮助他们改进他们的开发流程（如使用缺陷跟踪系统，计划工作，使用配置管理系统，等等）。
在项目结束的时候，项目组意识到36只是一个非零的数字，一个不要求完美的数字。这个数字是宝贵的因为它让人们思考数据—它从哪里来又做什么用。这个目标给了项目组一个动机去使用一个可以帮助他们成功的流程。项目组发现了怎么做到这一点。
我并不关心是否在项目中发布标准看起来有些疯狂，尤其是对项目组外的人而言。作为一个咨询项目经理，我需要确保人们在项目结束的时候了解数字背后的推理过程。在这个案例中，数字帮助人们意识到他们需要跟踪和量化一些项目中的数据。当他们可以跟踪数据的时候，他们会选择如何利用这些数据。
我不在乎这些数字与常人用正常思维考虑出来的想法有没有什么关系。我只关心发布标准帮助项目组按时发布合适的版本，不会引发客户的尖叫。而为了做到这一点，人们无须发疯或筋疲力尽，也不会把彼此都逼疯。
