过渡到敏捷，大技术债务，小项目

几个月前， 丽贝卡（Rebecca）问了一个有关项目中技术债务的有趣问题。 她问，

发生大混乱时如何开始？ 在那种情况下，很小，仅仅是专业的清理行为甚至可能不会造成任何损害。

当然，与任何好问题一样，答案是“取决于情况”。 最大的依赖点在于项目是大型还是小型项目，以及该项目是并置还是分布式。 为了便于讨论，我们假设它很小且并置。

当您过渡到敏捷并且拥有适当大小的代码库时，您从事该产品一段时间的机会就很大。 您有旧版代码。 您可能有旧式测试。 您肯定有考虑代码和测试的旧方法。 您如何摆脱长期积累的技术债务而工作？ 您是否可以按照我在《基础结构，技术债务和自动化测试框架的思想》中概述的方式来开展工作？

是和否。让我们假设，对于一些小的功能，您可以承担一些小的债务。 而且，您的债务如此之多，以至于某些技术债务领域您只是不想触及那些代码领域，或者如果您触及这些领域，就知道您将陷入流沙之中。 您知道必须创建的测试要比创建“时间”要多。 就是说，即使是蜂拥而至，故事的规模也大大小于债务的规模。

现在，你怎么办？

你告诉别人。 您告诉产品负责人。 你告诉你的同事。 我，无论如何，我可能仍会为该代码编写一些测试，因为我想知道下一次进入流沙时的情况。 但是现在我比年轻时拥有更多的白发经验，因此我对该产品做出了不同的选择。

如果我是该项目的项目经理，我想知道，因为我想管理风险。 以我的经验，太多的技术债务会影响团队生产要素的能力。 而且，如果我是产品负责人，我想知道，因为技术债务会影响我们对产品做任何事情的能力。

而且，在这种情况下，您可能要考虑将三个积压的积木作为一个漏斗存入一个积压的迭代中。 阅读可能三份积压的积压比一张积压的好吗？ 并且，请确保阅读所有评论。 他们很有见识。

这个想法是您仍然只有一个积压的迭代。 但是您可以对要对产品进行排名的所有工作具有可见性。

事后看来很容易地说：“不要陷入那种情况。” 好吧，嗯 但是组织处于这种情况。 而且，他们需要帮助。 我仍然认为，最好的答案是偿还技术债务是在小部件上工作，并在发现债务时偿还债务。 这样一来，您将永远不会获得超出所需的回报，也不会进行过多的架构工作，并且永远不会遇到这个奇怪的积压问题。

另一方面，有些人没有意识到他们有多少债务。 任何有助于他们了解自己所拥有东西的东西都是有用的。 但是也许有更好的方法。 也许您有更好的方法？

让我总结一下：

1. 如果可以，在实施故事时还清技术债务。
2. 蜂拥而至，开始并完成一个故事。 这将帮助您避免债务并还清债务。
3. 编写更多测试以暴露债务，因此将来没有人会感到惊讶。
4. 通过创建债务积压来暴露债务，以便可以对债务进行排名以准备进行迭代计划。
5. 在计划迭代时，请从债务积压中删除顶层项目。 将该项目与功能积压中的顶部项目进行成对比较。 哪个项目更具价值？ 将该项目放在迭代积压中。 继续直到团队说：“停止，我们不能在此迭代中做更多的事情。”
6. 您最后的解决方案是重新架构。 为什么？ 因为它阻止您在项目中取得进展。 阅读Startup Suicide –重写代码 。 对于初创企业而言，这不仅仅是自杀。

始终确保技术债务可见。 这是对其进行管理的关键。 无论您是否喜欢我的解决方案，都应使债务可见。 而且，如果您不喜欢我的任何想法，请发表评论。 哎呀，如果您喜欢他们，请发表评论。 我很想知道你的想法。

参考： JCG合作伙伴 Johanna Rothman在管理产品开发博客上向敏捷，大型技术债务，小型项目的过渡 。

翻译自: https://www.javacodegeeks.com/2012/10/transition-to-agile-large-technical-debt-small-project.html