我不认为我的 故事点故事 会获得如此关注。反应分为两组：“大帖子”类型，简短且支持。和“你做错了”类型，冗长且争论不休。
在我在那篇文章中使用它之后，我不能责怪人们告诉我“你做错了”。它确实让我想到了那个短语。
以下是现实生活中的例子，反映了我们如何看待是非。
首先是技术方面。单元测试、重构、设计。当我审查测试和代码并发现问题时，反应要么是“是”，要么是“是但是”。通常“是但”与代码本身无关。它与“我们没有时间”或“我们必须在 10 年的遗留代码上构建它”有关。文化解释而不是糟糕的编码实践。很少，回答是“不”。当人们有足够的经验（和进取心）与全能的顾问争论时，就会发生这种情况。之后的讨论就有趣多了，尽管“不”最终获胜。
在这种对与错的讨论中，显然偏向于更顽固的一方。但是，它以编码和设计“最佳实践”为中心。
现在，让我们谈谈流程。在这里，我们看到更多“是但”的讨论。但“不”是大多数。 “在 Scrum 中不是这样”。或者“你不应该那样使用故事点”。流程教条一旦植入组织成员的心中，似乎比任何“最佳实践”都更强大。
似乎技术实践比程序实践更受尊重，至少作为正确性的衡量标准。
无论我们如何衡量正确性，这都无关紧要。
不管我是错还是对
你看，我的建议是否对你有用。根据我的经验，我可能是对的，但我的建议仍然不适合你。反之亦然。讨论无关紧要。
归结为有效性。
重要的是该工具或流程是否适合您。如果它加快发展。如果它提高了质量。如果人们可以自由地安全地进行实验。如果他们快乐。
告诉我这不仅对您或团队有帮助，而且对底线有何影响。这是让我闭嘴最有效的方法。
你可以随心所欲地犯错，但我不反对成功。