另一个用于解决技术债务的工具集

让我们准备努力与不可言喻的本身，看看我们是否可能毕竟可能无法实现它。

“呃，codebase就是如此混乱，”我的新技术领先表示。 “它只是在Cruft上面的Cruft，永远不会清理，总是'下一个释放后'。难怪我们一直在将错误报告速度快，我们可以修复它们。“

不是您希望在关键团队中作为新近地指定的工程经理听到的。领导预计该团队能够提供关键的新功能，而且还有更好的不自愿潮流。

我去了与产品经理交谈。 “技术债务？”他说，“当然，我们可以解决一些技术债务 - 但让我们一定要首先通过点击我们的OKR来获得一些可信度。这并不容易。“

削减到三年。我是那个团队的新雇用。我的奴役伙伴 - 让我们打电话给他伙计 - 我碰到了代码库的一个奇怪的角落。

“我有一个你可以使用的策略，”哥们说。 “当您遇到似乎的代码时，这感觉值得修复，您将在单独的文本文件中写下问题。然后你去做有用的工作。“

“哦，我懂了。最终，您返回文本文件并解决问题？“

维基百科描述了学习的无助作为“受试者在持久的受试者展出的行为超越控制之后。”没有支持，这就是工程师如何感受到技术债务。

当我作为经理回到这支球队时，我伸出了八年前的哥们。 “代码也是Airbnb的废话，”当我们陷入困境时，他告诉我，“但至少他们付出良好，我不必非常努力地工作。”

这不是真的。我们解决了技术债务。我们发布了领导力的关键功能，击中了我们的OKR，并清理了一些可怕的，长期的删除不良代码。在3个月内，团队对技术债务的态度已经开始转身。

技术债务最大的原因是因为工程师内心化，这不是他们的工作来解决它。初创咒语像“焦点”和“让小火焰烧伤”导致那样 - 无处不在的小火。

“完成狗屎”是一个伟大的咒语，但你仍然必须在自己之后清理。

这里的修复是文化。明确表示识别债务的工程师，花时间达到解决它。庆祝他们的工作到同行。一位朋友曾经创建了一个删除了任何删除大量代码的PR的Slack Bot。整个公司的工程师都开始努力获得特色。

现在当然，团队确实有需要做的实际工作。 Empower并不意味着“忽略我们的实际工作” - 它意味着，“如果你星期五修复困扰你的东西，我就有你的背。”

如果你在一个没有严格解决技术债务的团队中，那么可能很多，甚至不清楚甚至可以做些什么。这是可固定的。

这将为您设置您的技术债务积压的稳固初始列表。有关更多想法，请通过诸如CodeClimate的工具来运行Codebase，以算出粗糙的斑点。

我们第一次像这样跑一个头脑风暴，每个人都同意我们有一部少数思想，这是如此简单，有价值，以至于我们应该立即完成它们。就像那天一样。它感觉就像一口气的新鲜空气。事情是可疑的。

鼓励人们随时添加到积压时，他们遇到烦恼并且没有时间在那里修复它。在未来的团队回溯或头脑风暴中，确定出现并将其添加到积压的任何技术债务。

时间播放产品经理并使用ICE优先考虑您的技术债务对修复所需的努力，影响解决方案对速度的影响，以及修复实际工作的信心。

现在他们只需要完成。这将需要从产品经理中购买。

何时有时间与你的下午有“谈话”，我发现了“你应该多久清洁你的房间”是有用的类比。

从不清理你的房间是一个坏主意，显然是如此。随着时间的推移，它变得不可爱。这就是我们的工程师的感受。与此同时，如果你每天都清理你的房间，那就不是一个干净的房间，这是过度的，不再有用。适度，混乱是健康的 - 这意味着你是在优先考虑。我们不需要闪闪发光的房间，但我们确实需要做得不多。在一天结束时，洁净室是一间富有成效的房间。

与您的产品经理一起，同意小额债务项目可以添加到团队的票队列中的费率。与上面这样的Spiel，您可以有希望获得〜10％的工作，以专注于债务，具体取决于团队和公司的成熟度。

对于〜周长的项目，尽量利用像黑客周的特定时间，并将高价值项目投入寻找有趣项目的工程师。

这是良好的领导能帮助的地方。在这个特殊的公司，工程领导层推出了“质量OKRS”。每季度，每个团队都必须注册有意义的“质量”OKR目标。

什么是“质量”目标？这是团队的，但它的主旨是，只是解决你的商业指标中尚未翻译的最痛苦的事情。

在季度规划期间，我们将前三大“重型技术债务”项目融为一体，从领导力获取买入，然后将这些想法带回了集团。

由于质量项目从自上而下和无可争议的祝福，PM有空气盖，以支持工作而无需推动。

还有技术债务吗？ 是的。 它是否继续积累？ 当然。 但它感到不可避免吗？ 不再。