缺陷是否估点

最近在客户这里又遇到这样的讨论：缺陷是否需要估点？

要回答这个问题我们先看三个场景：

1. 团队在项目开发中发现缺陷：我们先假设缺陷的来源来自客户验收，再假设这次项目的预估总点数是100点。这样我们来看缺陷是否应该估点

    根据大小，我们为发现的缺陷估点为5个点（因为根据一致性估算原则，它确实有这么大），根据以往的velocity，团队就能比较准确的估算出什么时候这个缺陷可以被修复。从这个层面上来看，为控制进度，为项目的可视化，给缺陷估点是没有什么错误的。

    然后我们看一个相对极端的情况：发现很多缺陷，这些缺陷估点总共超过100点，那么团队继续修复＋新功能开发。。。。。。最后该团队完成了200点。这是不是意味这该团队作了更多的事情，换句话说，是不是bug越多，团队干的活越多？真实情况是该团队没有多作事情，并且不仅没多做还把该作的事情作的比较烂。那么bug是不是不应该估点？我还是推荐大家估点（缺陷点，不同于故事点）这些点告诉团队我们有过多大的浪费！

2. 团队工作在一个遗留系统上：假设该遗留系统的实施公司已经倒闭，上哪也找不到人了

    团队在开发新功能的时候发现遗留系统缺陷了，团队应该怎么对待这些缺陷？改还是不改？如果改，估点还是不估点？我的个人原则是客户的东西我们要照顾好，要改。但是，从商业上／从项目进度控制上来讲是不估点就不改，不然我不是赔大了？另一个原则是点不算钱也不改。那么在一个真实的项目里应该怎么作呢？如果该项目是time material，那么我们视这些缺陷等同与新特性，也就是一个故事，纳入一般功能，按优先级开发。如果该项目是fixed price的，那么要将这些缺陷估点（缺陷点，依然不同于故事点管理），这些缺陷点是否修改要在更高商务层面上去讨论

3. a团队修改b团队的缺陷

很多人认为这种情况不会发生，但这种场景在很多大型开发企业里是存在的，并且普遍存在。很显然这种情况下，a团队要对b团队的缺陷估点，并且纳入a团队的velocity里，说白了就是这些缺陷的修复属于a团队的performance。但对于b团队呢？他们把尾巴甩给了a团队，自己就高枕无忧了吗？和第一种情况类似，b团队应该要把这些bug算为自己的缺陷点，并且缺陷点／故事点应该成为一项performance指标

很多人说缺陷不要估点，因为那是本来就应该作的事情，属于原有故事的一个部分，既然那个故事点已确定，缺陷就不该估点。整体上来说，我认为缺陷是要估点的，但将这些点与一般的故事点区别对待是很重要的，因为缺陷点是浪费，故事点是价值（但在第二种场景下缺陷点也是价值）