写这篇文章主要有两个原因：
- 首先，我对软件开发行业的总体状况不甚满意。
- 其次，我想写下我认为 "现代 "敏捷的失败之处（也就是说，它甚至不是宣言中所描述的敏捷），特别是对估算的痴迷，在现实世界中很少有效果。
我相信NoEstimate（无估算）是一条前进的道路，特别是在看了Allen Holub的演讲之后。他雄辩地描述了一直在我脑海中形成的相同想法。
故事点的误用
下面是故事点的反模式：
1、没有意识到故事点是一种估计：尽管有 "故事点估算 "的说法，但在很多情况下，利益相关者似乎完全没有意识到 "估算 "的部分。在其他情况下，分配的故事点价值往往被认为是实现积压项目所需的确切工作量。
2、迫使或胁迫开发人员选择一个较低的数字。对开发人员施加压力，以使他们感到除了 "估计 "一个较低的工作量外别无选择，以便不受影响，避免被挑出的压力。更糟糕的是，在冲刺结束时，当工作 "耗时 "超过估计时，就会指责开发人员。
3、立即对高或低的数字打折扣。与上一点类似。立即不考虑任何与其他团队成员相比属于异常的估计。一个与平均水平大相径庭的分数通常意味着两件事中的一件--要么他们没有理解工作的范围，要么他们对任务有独特的见解和关注。一些利益相关者忽略了这些见解和关注，因为它们不方便。
4、根据总分来比较和评判开发者的工作量。这是一种可怕的做法，只会导致怨恨和对工作量的不公平表述。有时，一个开发者完成了许多估算值较小的任务，却被认为比一个完成了估算值较高、需要较长时间才能实现的任务的开发者做了更多工作。这两个开发者都有贡献，但其中一个几乎没有得到承认。
5、把故事点的估计当作不可改变的事实。一旦就一个故事有多少分达成了协议，就没有办法在没有不必要的戏剧性和争论的情况下，随着更多的发现更新它的价值。当然，情况不应该是这样的，因为改变应该是宣言的一部分。这不可避免地导致每个人都估计出更高的价值，以便获得喘息的机会。
"应对变化胜过遵循计划" - 敏捷软件开发的宣言
6、当开发人员意识到一个故事被高估或低估时，他们会责备他们。与上一点类似。劝阻和诋毁开发人员的估计，往往是定期进行的。这需要停止。
7、为了决定一个故事应该是1分还是2分而进行30分钟以上的辩论。漫长而持久的讨论有时是需要的，这就是生活和开发的本质。也许需要考虑更大的系统架构，或者担心某种方法会导致技术债务和高度耦合的代码。另一方面，一些围绕一个 "简单 "的任务是否应该被分配1分或2分等的争论是很荒谬的，是在浪费时间和耐心。
8、期望每个冲刺阶段都有相同的 "速度"。这个问题比较微妙，似乎是在不知不觉中悄悄出现的--至少在几个冲刺完成之后。它可能是微妙的，但它是一种使人衰弱的做法，随着时间的推移，只会使团队和其成员精疲力竭。这可以通过多种方式表现出来，通常是同时进行的。将每个冲刺阶段的故事点的具体数量作为强制目标。调整故事点来 "适应 "这个目标。从积压项目中引入额外的项目来 "适应 "目标，从而增加开发人员的工作负担。
9、故意估计不准确的故事点，以帮助创建一个 "完美 "的燃烧图。与上一点类似，但需要特别指出的是。这里有几个角度在起作用。
- 1) 开发人员只是想工作，并且厌倦了被责骂，所以 "估计 "了一个故事点，这将使scrum master满意。
- 2）ticket管理员被问及为什么他们的团队没有一个完美的燃烧图，于是将故事点揉成高管们想听到和看到的东西。即使烧毁图是完全不准确的，只要它是一条完美的直线，对于 "做敏捷 "的组织来说，这似乎就是最重要的。