用敏捷方式偿还技术债务

Question

如果您使用的是敏捷，那么您的想法就是总是在进行增量重构，而不是积累大量的技术债务。话虽如此，如果您有一个敏捷团队正在接管拥有大量技术债务的软件，那么您必须将其融入到某个地方。

你会去创建开发者的用户故事吗？.for例子。

• 作为一个开发人员，我对业务逻辑模块有50%的测试覆盖率，所以我对交付有信心。
• 作为一名开发人员，应用程序支持依赖注入，这样我们就可以交换具体内容，并在将来变得更加敏捷。

或者还有另一种清理代码技术债务的最佳做法？

Answer 1

您的应用程序是内部的还是有外部客户的？如果客户正在支付您的工作和支持申请，这可能是很难让他们在卡片上签字，如你的建议。

另外，用你的第二张卡片，它可能很难说什么是“做”。

解决问题的一种具体方法可能是缺陷驱动的测试--这种方法的思想是，当您得到一个bug报告并估计出修复它的卡片时，看看您可以同时添加哪些测试，这些测试是相似的，但可以增加覆盖率。

而且您也不需要具体的技术细节来了解如何让您的项目接受测试，但是这本书在您开始实际操作时是非常有用的：有效地使用遗产代码

Answer 2

工程实践和技术债务之间应该有区别。我将测试驱动开发和自动化测试视为实践。

由于采用了瀑布团队构建的代码资产，这些资产没有自动化的单元、功能或性能测试。当我们承担起软件资产的责任时，我们用敏捷对产品负责人进行了培训，并告诉他们我们将要使用的实践。

一旦我们开始使用这些实践，我们就开始识别技术债务。随着技术债务的确定，技术故事卡由产品所有者编写并放在产品的待办事项清单上。开发人员和测试人员使用XP工程实践(TDD、自动化测试、对编程等)估计所有工作。这些实践通过TDD、自动功能和性能测试确定了代码中的脆弱性。特别是，通过自动性能测试和分析确定了一个重要的性能问题。债务是如此之大，以至于我们估计修复需要进行6次迭代。我们告诉产品负责人，如果开发了新功能，由于应用程序的性能较差，用户将无法使用它们。考虑到我们不得不将应用程序的规模从几百个用户扩展到成千上万个用户的10s，产品所有者将性能技术债务放在了很高的优先级上，我们在迭代估计中完成了技术卡片。

注:技术债务，可以通过重构内的故事卡的估计，不需要一个技术故事卡。更大的技术债务将会。对于需要技术卡的技术债务，请确定业务影响，并要求产品所有者对技术卡进行优先排序。那就用这张卡。不要为工程实践创造技术债。做所有的评估，知道工程实践将是评估的一部分。不要创建一个卡片来改造应用程序的自动化单元，功能和性能测试。相反，只将工作包含在您正在估计的卡片中，并通过正在工作的卡片将自动测试添加到您所接触的代码中。这将使应用程序能够随着时间的推移而改进，而不会使进展停滞。停止添加所有名片只能在应用程序无法执行或缩放等最严重的情况下保存。

在没有自动单元、功能和性能测试的情况下继承代码库时，请将不幸的情况通知业务伙伴。让他们知道你将如何评估这项工作。创造技术债务，因为它是通过工程实践发现。最后，通知产品负责人，随着越来越多的代码库被自动化单元、功能和性能测试所触及，团队的速度将会提高。

Answer 3

我在敏捷环境中工作，但是在敏捷技术被采用之前，当前的代码库已经存在了好几年。这导致必须尝试以敏捷的方式工作，而不是在编写时考虑到自动回归测试。

因为技术债务会影响我们交付新特性的速度，所以我们记录了由于使用遗留代码而增加的时间。这些数据使我们有理由花时间来偿还技术债务。因此，当客户(无论是经理、CTO还是其他人)认为估计值太高时，你就会有数据来巩固你的地位。

当然，有时，您会发现您的估计值会因为遗留代码的意外怪癖而被忽略，在遗留代码中，让来偿还技术债务。我们发现，只要额外的时间能够被解释和解释，并且可以证明额外的时间所花费的好处，它就被普遍接受了。

当然，YMMV取决于客户或其他因素，但是拥有代表未来技术债务影响的统计数据是非常有用的。