流程债务的隐患

我们大多数从事软件开发的人员都熟悉“技术债务”一词。

快速提醒一下，Ward Cunningham引入了它来描述当我们使用短期内易于实现的代码而不是应用我们确定的最佳整体解决方案时发生的现象。

顾名思义，这是一个明智的决定，它会采取短期的捷径来满足您的要求（例如为假期购买一张新的信用卡），从长远来看，这将使我们在改进系统时花费更多的时间进行开发（例如支付利息）信用卡债务）。

在偿还全部资本之前，我们将在向系统添加功能时始终支付利息，因为债务为有效添加新代码造成了障碍。

沃德建议，当我们处于紧急状态时，我们需要意识到，将来我们将不得不偿还资本，否则利益将会削弱我们。

沃德建议将重构作为解决技术债务的一种解决方案。

我非常喜欢沃德的愿景，并且想将隐喻向上扩展一个层次。

现在，如果我们在上面对技术债务的描述中将“软件”一词​​改为“过程”，则可以定义过程债务。

替换我们得到：

当我们使用易于在短期内实现的流程而不是应用我们已经确定的最佳整体解决方案时， 流程债务就是一种现象。

让我们看一个例子

您注意到最近该系统似乎比平时更加​​不稳定。 您知道这一点是因为有更多来自客户服务的电话和更多的缺陷被提出。

选项1：您想深入了解情况，并相信有5个原因的根本原因分析可以帮助您实现目标。 如果使用这种方法，则可能会发现流程中的变化，以帮助您防止将来出现某些缺陷。

选项2：为开发人员实施更好的策略，以选择缺陷以减少缺陷在未解决队列中的时间，同时保持新功能的创建吞吐量相对稳定。

您知道从长远来看，选项1更好，因为它会在过程中产生变化，以减少返工量。 这将意味着花费更少的时间进行修复，而将更多的时间花费在新功能上，从而意味着更高的吞吐量和新功能的交货时间缩短。

选项1需要一些投资。 您需要举行一个或多个根本原因分析会议，确定具有解决方案的问题实验，直到找到可以减轻问题的解决方案。

如果您承受压力，因为新产品需要运输，旧缺陷需要修复，则您可能会选择选项2。

通过这样做，您引入了流程债务

如果使用选项1，此债务的资本是您可以确定的流程中缺乏更改 。

哦，是的，我忘记了，改变很困难。

最糟糕的部分是您将永远支付的债务利息 ，直到您支付资本为止。 这种兴趣将以的形式出现。
1.错误不断出现，我们似乎一直在修复错误
2.新功能被延迟，因为现在队列在要交付的新功能中 3.任何新功能的交付时间都会增加X倍 4.客户由于您的生产缺陷而继续抱怨 5.您的产品所有者开始对开发团队在缺陷方面的工作量感到恼火 6.开发人员厌倦了总是修复缺陷 7.… 。 需要我多说？

如果您不解决问题，则将在您余生中支付此利息。

覆盖缺陷后的数月内，客户会感到压力，并需要调换工作。

这样健康吗 当然不是。

有治疗方法吗？ 哦，是的，的确如此。

持续改进对流程的影响与重构对软件的影响相同。 它偿还了您的过程债务资本。

通过对实验形式进行小的更改，您就可以清楚地讨论团队所遇到的问题，并不断进行小调整。

我尊敬的同事和热情的创新者克劳迪奥· 佩罗纳（ Claudio Perrone）提出了他的持续改进模型，称为PopcornFlow

如果很难改变，就必须持续不断

我十分同意。

通过使流程更改成为一项连续的活动，我们可以使行为永远存在于团队中，并释放人们创造力，以改善他们自己的工作方式。

翻译自: https://www.javacodegeeks.com/2017/11/hidden-dangers-process-debt.html