在单个敏捷工作项中处理“相关”工作

我是一个由4个开发人员组成的项目团队，其中包括我自己。我们一直在讨论如何处理单个工作项中出现的额外工作。

这些额外的工作通常是与任务稍有相关的事情，但并非总是必须达到项目目标（可能是一种观点）。示例包括但不限于：

• 重构工作项更改的代码
• 与项目更改的代码相邻的重构代码
• 重新设计票证周围较大的代码区域。例如，如果某个项目要更改单个功能，那么您意识到现在可以重做整个类以更好地适应此更改。
• 改进刚修改过的表单上的用户界面

当这笔额外的工作很少时，我们不在乎。问题是，当这项额外的工作导致项目的实质扩展超出了原始特征点估计时。有时，一个5分的物品实际上需要13个时间。在一种情况下，我们得到了13分，回想起来可能是80分或更高。

在我们的讨论中，有两种解决方案。

1. 我们可以在同一个工作项中接受额外的工作，并将其记为错误估计。对此的论点包括：

   • 我们计划在sprint末尾进行“填充”以解决此类问题。
   • 始终使代码保持比发现的状态更好的形状。不要签入半途而废的工作。
   • 如果我们将重构留给以后使用，则很难安排时间，并且可能永远无法完成。
   • 您现在处于最佳的心理“环境”中来处理此工作，因为您已经在代码中深陷其中。最好是现在就解决它，并且比以后再丢失该上下文时更有效。

2. 我们为当前工作项目划了一条线，并说额外的工作进入单独的工单。参数包括：

   • 拥有单独的票证可以进行新的估算，因此我们不必对自己的真实情况撒谎，也不必承认我们所有的估算都是可怕的。
   • 冲刺“填充”用于应对意想不到的技术挑战，这些挑战是完成票证要求的直接障碍。它不适用于仅“精打细算”的附带物品。
   • 如果要安排重构，只需将其放在待办事项列表的顶部即可。
   • 我们没有办法在估算中正确考虑这些内容，因为出现时似乎有些武断。代码检查者可能会说“那些UI控件（您实际上未在此工作项中对其进行修改）有些令人困惑，您也可以解决吗？” 这就像一个小时，但他们可能会说：“好吧，如果此控件现在与其他控件继承自相同的基类，为什么不将所有这些（几百行）代码都移到基类中并重新连接所有这些内容，级联的变化等？” 那需要一个星期。
   • 它通过在票证中添加无关的工作来“污染犯罪现场”，从而使我们的原始特征点估计毫无意义。
   • 在某些情况下，额外的工作会推迟检入，从而导致开发人员之间的阻塞。

我们中有些人现在说，我们应该决定一些截止日期，例如，如果其他物料少于2 FP，则将其放入同一票证中；如果更多，则将其设为新票证。

既然我们只需要几个月就可以使用敏捷，那么这里周围所有经验丰富的敏捷退伍军人对此有何看法？

敏捷计划和用户故事的重点是为项目利益相关者和软件用户提供价值和透明度。这是一件好事，但没有，也不应取代，包括或降级良好的体系结构指南，设计管理，良好的开发实践和维护技术债务的重要性。

敏捷不能很好地解决后者，因为它并非旨在解决这些主要是技术问题的问题。

知道我非常不同意重构任务，技术债务处理和设计工作应该考虑给定sprint中不同的用户故事。这些仅仅是开发人员可能会执行的任务，以帮助满足该Sprint的用户需求。

请记住，任务是可分配工作的任何单元，可以帮助将给定的用户故事移至体系结构准则之内，并维护整个软件的良好设计和开发实践。

这就是工时估算应该放在任务而不是用户故事上的原因。这也是为什么某些任务对于完成多个用户故事至关重要的原因。

红色，绿色，重构。那是单个工作项的范围。编写一个涵盖变更范围的失败测试套件，对通过测试所需的最低数量进行编码，然后在仍通过测试的同时重构达到编码标准。这三个步骤都是必需的；在定义问题之前，您无法编写解决方案的代码，如果在编写代码行时进行重构，则始终会违反YAGNI，但是如果您不参与测试并在通过测试后进行重构，则按照定义，您将承担技术责任最终您将不得不还款。

给定这个定义并遵循它，一个5指针竟然变成13指针是一个错误的估计。您认为重构工作可能更像是重组。您必须重新组织代码库的相当大的区域，以便以易于理解和可维护的方式包含新功能。这通常表示团队无法理解未来的总体发展路径，从而导致某些事情在最终迭代中非常简单地被实现，而最终需要非常坚实。广管局与项目经理之间（他们知道待办事项的详细内容）与通常专注于当前冲刺的开发团队之间的更好沟通可以减轻这种情况。另外，这个故事还暴露了过去开发过程中产生的大量技术债务，赶上了团队。除了对设计模式和项目的总体未来路径有更好的概念了解之外，更好的代码审查过程还可以帮助减少此类情况的发生。

要记住的一件事是，重构是“非理想的”工作。在敏捷SCRUM中，任务以“理想时间”估算；就是说，花费大量的时间来编写全新的代码，这些代码从未存在过，并扩展了该项目的功能基础。实际上，一个8小时的开发人员日实际上可能只有5个理想小时；有时您可以指望6，尤其是在团队真正投入的项目“延展”中。重构或回退并进行更改（这些更改不会影响项目的功能，但会以其他方式改善代码库）是不理想的工作，如计划，设计，沟通，检查，中断或技术停机。除了技术停机之外，非理想的工作很重要，但在产品所有者的眼中并没有取得进展。

因此，假设重构不会使实际花费的时间增加一倍，那么当您估算理想时间时，可以预期会有一定数量的重构工作。可以说，因为我不知道您团队的点数刻度是如何校准的，所以5点数相当于一个理想的开发人员周，或大约25个理想的小时。那个5变成了13（以相同的比例超过了两个开发者周），这引起了对导致复杂性膨胀的原因的一些回顾。也许代码库不需要实际完成的那么多重构，也许大量的技术债务堆积在团队中，这是团队不为人知的，必须解决这些问题才能使新功能生效，

在另一个世界中，让我们想象一下，理想小时的5估计值将根据实际小时数变为7（约35个小时），因为您需要额外的10个小时的重构才能将新代码和一些先前的比特放入经过正确设置的格式中设计架构。在这种情况下，额外费用就在故事应该花费的开发人员工作日数的理想时间与总工时之间。因此，作为项目经理，我将5变成7是一个合理的估算，然后继续。

故事点是对给​​定用户故事的相对复杂性的估计。听起来您是在使用故事点说这将花费X个人日/小时。相反，争取两个目标

1. 分解故事，直到它们处于一致的范围内（3、5或8分）
2. 假设故事包含任何必要的重构

随着时间的推移，这将为您提供速度的基准。每5点的故事不会花费与其他故事相同的时间，但是每个冲刺的平均速度（团队可以完成多少个故事点）将保持一致。

担心某个特定故事将花费多少时间会适得其反。估计值仅对大小一致的故事进行平均（例如，由于重构，IE 1 5指针可能会花费更长的时间，但是您会从相关的故事中受益）。

应该相对截断原始工作项中的内容以及其他内容。用户故事是讨论的起点，因此在处理故事时的冲刺期间，可能会有各种作用域元素要确定下来。

有时，在冲刺计划中，故事可能会添加其他标准，以免发生“范围蠕动”，这种情况可能发生在用户想要新表格，然后将其更改为101时，这对于用户来说是不现实的。有时需要2周的冲刺。

需要牢记的另一面是，这项额外工作能带来多少价值。可能会有成千上万种可能的重构，但是任何人对所有这些工作有什么好处？在这里必须有一些指导方针，以帮助团队保持良好运转，但又不会迷失于使代码完美的尝试。