在单个敏捷工作项中处理“相关”工作
我是一个由4个开发人员组成的项目团队，其中包括我自己。我们一直在讨论如何处理单个工作项中出现的额外工作。 这些额外的工作通常是与任务稍有相关的事情，但并非总是必须达到项目目标（可能是一种观点）。示例包括但不限于： 重构工作项更改的代码 与项目更改的代码相邻的重构代码 重新设计票证周围较大的代码区域。例如，如果某个项目要更改单个功能，那么您意识到现在可以重做整个类以更好地适应此更改。 改进刚修改过的表单上的用户界面 当这笔额外的工作很少时，我们不在乎。问题是，当这项额外的工作导致项目的实质扩展超出了原始特征点估计时。有时，一个5分的物品实际上需要13个时间。在一种情况下，我们得到了13分，回想起来可能是80分或更高。 在我们的讨论中，有两种解决方案。 我们可以在同一个工作项中接受额外的工作，并将其记为错误估计。对此的论点包括： 我们计划在sprint末尾进行“填充”以解决此类问题。 始终使代码保持比发现的状态更好的形状。不要签入半途而废的工作。 如果我们将重构留给以后使用，则很难安排时间，并且可能永远无法完成。 您现在处于最佳的心理“环境”中来处理此工作，因为您已经在代码中深陷其中。最好是现在就解决它，并且比以后再丢失该上下文时更有效。 我们为当前工作项目划了一条线，并说额外的工作进入单独的工单。参数包括： 拥有单独的票证可以进行新的估算，因此我们不必对自己的真实情况撒谎，也不必承认我们所有的估算都是可怕的。 冲刺“填充”用于应对意想不到的技术挑战，这些挑战是完成票证要求的直接障碍。它不适用于仅“精打细算”的附带物品。 如果要安排重构，只需将其放在待办事项列表的顶部即可。 我们没有办法在估算中正确考虑这些内容，因为出现时似乎有些武断。代码检查者可能会说“那些UI控件（您实际上未在此工作项中对其进行修改）有些令人困惑，您也可以解决吗？” 这就像一个小时，但他们可能会说：“好吧，如果此控件现在与其他控件继承自相同的基类，为什么不将所有这些（几百行）代码都移到基类中并重新连接所有这些内容，级联的变化等？” 那需要一个星期。 它通过在票证中添加无关的工作来“污染犯罪现场”，从而使我们的原始特征点估计毫无意义。 在某些情况下，额外的工作会推迟检入，从而导致开发人员之间的阻塞。 我们中有些人现在说，我们应该决定一些截止日期，例如，如果其他物料少于2 FP，则将其放入同一票证中；如果更多，则将其设为新票证。 既然我们只需要几个月就可以使用敏捷，那么这里周围所有经验丰富的敏捷退伍军人对此有何看法？