是否应该将技术债务/技术升级安排为一项功能(给定的分数)或一项琐事(不给出分数)？

Question

在关键跟踪器中，我们应该为技术债务的用户故事做些什么？我们应该把这些看作是特征(给点)还是杂务(不给点，从而降低速度)？

我感到困惑的是，什么应该被认为是一项杂务：

1. 代码复制--很明显，如果我们在多个地方放置了相同的代码，这是非常糟糕的代码实践，并表明团队中的开发人员应该更多地考虑软件的可维护性，进行重构，团队应该花时间在代码评审上。由于所有这些都需要成熟、时间和代码级别的经验，所以最好少交付点，这样代码质量就不会受到影响。因此，这些错误应该受到惩罚，速度应该降低，不给点杂务。
2. 技术升级--类似于模块化JS、HTTP2、React、MVC或任何其他新的/更好的技术。这些步骤将使代码的性能和维护更好。但这应该是杂务还是特写呢？我相信这就是技术世界的样子，新技术不时出现，你必须迁移到它。所以，我认为没有必要因为这样的工作而惩罚球队的速度。有什么建议吗？
3. 复制/子标准代码--在遗留代码中，很少有代码是长期未被修改的，或者当一个新团队成立时，但是代码库有点老了，我们将面临这个挑战。研究小组说，他们没有对这部分进行编码，所以为什么他们的速度应该受到惩罚，因为他们从来没有创造过这样的技术债务。
4. 由于业务的迫切性，不符合标准的代码--有时，由于竞争对手/目标/业务/用户的压力，开发人员被迫尽快推出功能。清理这样糟糕的代码是否也被认为是一项繁重的工作(w/o评分)？这一次，开发团队并没有错，那么为什么要降低他们的速度呢?事实上，在这种情况下，他们多加了几个小时。

我相信以上提到的所有类型的杂务，如果做得很好，将会在未来提高球队的速度。但是，我们应该如何保持平衡，保持车队的速度，以及惩罚的技术错误，团队所做的错误作出错误的决定？

问题类似于：应将技术债务安排为一项功能还是一项任务(或)？，但我没有找到令人信服的答案，涵盖了所有4点，所以我重新发布了一种不同的方式。

Answer 1

简短的回答:偿还技术债务是一项繁重的工作。您没有为最终用户提供新的功能，所以它不会被指向。

官方答覆：

错误和杂务在默认情况下是无法估计的，因为它们有助于提高业务价值。Bug和杂务被认为是正常软件产品开销的一部分--它们是随着时间的推移而出现的，并且是持续的开销，是进行业务的持续成本。Tracker的自动速度计算作为内置成本来计算，并估计每一次迭代可以完成多少业务价值的工作。这使您可以将计划的重点放在业务价值、风险和优先级上。因此，跟踪器中的bug和杂务通常是不被估计的。您可以在项目设置中启用对bug和杂务的估计；但是，我们强烈反对打开bug和繁重的评估。如果你改变主意，你以后就不能关掉它。https://www.pivotaltracker.com/help/articles/planning_使用_速度/#臭虫_和_家务活

这就是为什么被归类为bug和杂务的故事不能用PT的默认设置分配给它们，但我认为这也解释了为什么不应该将这些任务作为仅仅为了获得分数而将其作为功能来计算的原因。

首先，我认为你不应该把速度的下降当作惩罚:这只是信息。也许这是很自然的事情，就像一个新加入的人，你必须花额外的时间训练。也许是一些意想不到的事情降低了你的能力(比如疾病)或者消耗了额外的能量(比如“停止这个世界”的错误)。也许您只是没有很好地估计功能，无论出于什么原因；这是您可以从中学习的东西。或者是因为作为一个团队，你决定优先偿还一些技术债务，而不是交付新特性(也许还会招致更多的债务)。

第二，承担技术债务并不一定是一个错误。无意中发生这样的事情并不理想，但如果你决定现在就把“快速而肮脏”的事情做好，比如你需要稍后整理一下，这样你就能得到更多的用户反馈，或者在一个艰难的截止日期之前，这是你作为一个团队做出的一个深思熟虑的选择，而且是可以接受的。

至于某物是否应该是一种特性，一个简单的经验法则是:终端用户关心吗？你提到改善搜索引擎优化:这是他们感兴趣的东西吗？他们很可能关心性能，但另一方面，他们可能更愿意拥有一些新的特性，而不是相同的东西，因为它们比加载时间少了几百毫秒。做一些调查:去问问他们想要什么。让他们帮助你把团队的时间花在哪些事情上是最好的。

您可能会发现，当前的技术选择阻碍了您尽可能高效地交付某些特性，在这种情况下，将全部或部分应用程序迁移到新的应用程序上是完全合理的(同样，也是故意的)。

我相信以上提到的所有类型的杂务，如果做得很好，将会在未来提高球队的速度。

在这里，我完全同意你的观点，但这些杂务不是要分两倍计算吗？如果您正在做这项工作，以便以后可以交付更多的功能，那么您应该在完成之后看到更高的速度，而不是在执行时。

此外，代码评审和交付过程中的基本重构(例如，TDD周期的“重构”部分)应该已经是您正在进行的工作的一部分，因此已经包括在团队的总体速度中。

披露:我是一个Pivot，在伦敦的关键实验室工作，但不是在跟踪小组。

Answer 2

相反，我们处理错误和技术债务就像处理任何其他PBI一样。事实上，我们甚至没有"bug“类型。所有的东西都是一台PBI。我们的待办事项是根据分配给PBI的业务价值排序的。因此，一个突出的面向用户的错误会导致问题，它将有很高的商业价值分配给它，因为你冒着这样的风险亏钱，而且它很可能是最先做的事情之一。另一方面，一个没有太大影响并且没有影响到底线的bug会有一个相对较低的业务价值，并且可能会在一段时间内无法修复。这是一个重要的精神墙，应该被拆除:不是每一个错误都应该被修复。听起来像是亵渎，我知道，但是如果修复bug所涉及的努力超过了修复它所带来的业务价值，那么ROI是负的。把每件事当作一个PBI，让您可以自由地做出这些类型的经验性决定，而不会因为它是一个"bug“而分心。

同样，在技术债务方面，仍有很大的商业价值在发挥作用。一些技术债务可能会以很低的成本发生，而且可能会持续很长时间，但有些技术债务会随着时间的推移而扼杀你的业务，因此具有很高的商业价值。关键是再次认识到，一切都只是一个PBI。所有的东西都进入到待办事项中，根据它们给业务增加的价值来处理该待办事项。无论它是一个特性，一个bug，还是技术债务，都是无关紧要的。

这也有利于完全回避你的问题。因为一切都是PBI，所以一切都有助于速度。对我来说，做那些不按你的速度来计算的实际大小的工作的想法有点疯狂。你基本上在你的经验数据中创造了一个巨大的黑洞。速度已经是一个相当粗糙的度量，它是一个基于更多估计的估计。添加一堆未被跟踪的可变工作量，现在这个数字几乎毫无意义。你的团队在冲刺中所做的一切都是你速度的一部分。