搜索任何问题跟踪器，不久你肯定会找到许多关于"Bug vs Feature"争论的例子。有时这场辩论会变得相当滑稽，就像XKCD模仿的那样通常情况下，Bug与特性的争论被视为不做某事的借口。实际上这不是一个bug而是一个特性，以WONTFIX结尾。这种类型的东西可以-非常正确-让用户非常不安。在这一点上，我们可以开始拖出迈尔斯-布里格斯的个性类型，并尝试识别出哪些个性会吸引到软件工程中。。。也许更具诱惑力的是使用拉康的精神分析理论来将这种行为归入拉康式的结构中，把软件工程师称为变态的痛苦形式。我想提出一个不同的观点。这种行为是接受标准游戏的一部分。问题是你没有意识到你在玩这个游戏。你可能连规则都不知道。这不是一个传统意义上的游戏，也不是一个你可以选择只是观察的游戏-就像一些蜜蜂在观看其他蜜蜂玩蜜蜂科里的Mao变体时学到的，其中包括对"观察"的惩罚。相反，这是博弈论意义上的博弈。在接受标准游戏中，我们都有自己的角色。如果我们都能正确地扮演这些角色，那么我们最终会得到很棒的产品，每个人都会很开心。如果有人没有正确地玩游戏，或者选择不玩游戏，那么最终你将面临Bug与特性的争论和挫折。我将试着解释这个游戏。游戏的目的是发展一个产品。为了改进产品，我们必须改变它。每个变更都有相关的验收标准。在满足验收标准之前，超算云，变更不适用于产品。游戏的中心是定义验收标准。当接受标准明确并以某种形式记录下来时，游戏效果最好，但对于相互信任的小团队来说，口头接受标准和共享领域知识可以让游戏玩得很好。当接受标准模糊时，游戏不起作用。游戏中有两个角色：变更驱动者的角色是定义与变更要求一样精确的验收标准。变更实施者的角色是按照验收标准的要求，将验收标准实现得最少。当实现者做的事情超出了验收标准的要求时，他们在游戏中就失败了，就像驱动程序没有充分规定验收标准一样。我们玩游戏吧。该产品是美国军舰企业号NCC-1701-D。管理层已经注意到护盾需要经常使用。进行了一项时间和运动研究，结果非常清楚地表明，在以下时间段内，损失了几秒钟：舰长说"攻击盾牌"；安全员打开屏蔽控制台；选择"Shields"屏幕；最后单击"Engage"（接合）按钮。结果是请求更改UI。在舰桥指挥官的屏幕上添加一个"接护盾"按钮。这一变化还可以包括一个restapi，以便在驾驶台指挥官的三线制录音机离开他们的工作站时调用该功能。变更驱动程序没有正确地扮演他们的角色，所以让我们看看当变更实施者玩验收标准游戏时会发生什么：比赛开始了！首先，整个"改变可能"。。。你用了"可以"，所以我们不必在那里做任何事。那么，就不需要restapi了。下一步，你说在屏幕上添加一个按钮，但你从来没有说过按钮应该做任何事情。从中我们可以得出结论，我们只需添加按钮，而不必执行任何操作。结果是，改变得到实施，大数据培训，飞船在下一次遭遇时就爆炸了。换言之，大数据能做什么，由于变更驱动因素没有正确地发挥他们的作用，我们最终得到了一个糟糕的次优产品，而每个人都是一个失败者。在这之后应该发生的变化是驾驶员应该认识到船舶的破坏是他们的过错，是由于他们未能正确发挥自己的作用。应该有学习，下一次的改变请求应该有更好的接受标准。在舰桥指挥官的屏幕上添加一个"接护盾"按钮。该按钮不需要任何确认，将接合护罩。按下按钮应在不超过50毫秒的时间内接合护罩。让我们看看如果变更实现者不能正确地扮演他们的角色，会发生什么。好的，我们加上了"接护盾"按钮。。。当防护罩已经启动时，保持按钮不动是没有意义的。为了完整起见，当防护罩接合时，我们将用"防护罩向下"按钮替换按钮。结果是改变得到了实施，而且更多。这一次飞船爆炸是因为护盾在快速循环，物联网智能水表，因为舰桥指挥官把手指放在控制台上超过50毫秒，并启动了原先更改时没有要求的"护盾放下"按钮。换言之，由于变更实现者没有正确地扮演他们的角色，我们最终得到了一个糟糕的次优产品，而每个人都是一个失败者。那么，我们如何才能玩这个游戏，软件企业的认定，让每个人都赢，我们最终得到一个极好的产品？我的回答是，我们应该认识到这是一个游戏，并奖励正确地玩它。。。但在你开始改变之前，先奖励它。在开始进行更改之前，请确保对更改的接受标准达成一致。变更驱动程序应该要求在他们的验收标准中有漏洞。不要等到实现更改后才发现您在标准中留下了漏洞！ 变更实施者应该寻求确认交付变更的最小努力。不要超过要求执行。如果我们在开始之前做上述工作，最好是作为验收标准评审的一部分，那么每个变更将提供什么就很清楚了。当然，在产品发生变化时，保持对产品总体功能的准确描述还有另一个问题，但是我们可以将更新后的描述添加到验收标准中，我们就完成了！