在敏捷中偿还技术债务

Question

如果您使用敏捷，那么我们的想法是始终进行渐进式重构，而不是建立大量的技术债务。话虽这么说，如果你有一个敏捷团队正在接管拥有大量技术债务的软件，你必须在某个地方适应它。

你去创建开发者用户故事吗？ 。例如 。

• 作为开发人员，我对业务逻辑模块的测试覆盖率为50％，因此我对交付有信心
• 作为一名开发人员，该应用程序支持依赖注入，因此我们可以在未来更换具体结构并使其更加灵活。

还是有另一种清理此代码技术债务的最佳做法

Answer 1

您的申请是内部的，还是您有外部客户？如果客户为您的工作和支持申请付费，可能很难让他们像您建议的那样在卡上签字。

另外，根据你的第二张卡片创意，可能很难说“完成”是什么。

您的问题的一个具体方法可能是缺陷驱动测试 - 这个想法是，当您收到错误报告并估计要修复它的卡时，请查看您可以同时添加哪些测试相似但增加了覆盖率。

并且您没有具体询问有关如何让您的项目受到测试的技术细节，但是一旦您开始实际执行此书，这本书非常有用：Working Effectively with Legacy Code

Answer 2

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

采用由瀑布团队构建的代码资产后，资产没有自动化的单元，功能或性能测试。当我们承担软件资产的责任时，我们对Agile的产品所有者进行了培训，并告诉他们我们将使用的做法。

一旦我们开始使用这些做法，我们就会开始识别技术债务。随着技术债务的确定，技术故事卡被产品所有者编写并放置在产品待办事项上。开发人员和测试人员使用XP工程实践（TDD，自动化测试，结对编程等）估算了所有工作。这些实践通过TDD，自动化功能和性能测试确定了代码中的脆弱性。特别是，通过自动化性能测试和分析确定了一个重要的性能问题。债务是如此之大，我们估计修复需要6次迭代。我们告知产品所有者，如果开发了新功能，由于应用程序性能不佳，用户群将无法使用它们。鉴于我们必须将应用程序从几百个用户扩展到成千上万的用户，产品所有者将性能技术债务优先考虑在内，我们在估算的迭代中完成了技术卡。

注意：技术债务可通过重构在故事卡的估算范围内修复，不需要技术故事卡。更大的技术债务将会。对于需要技术卡的技术债务，确定业务影响并要求产品所有者优先考虑技术卡。然后工作卡。不要为工程实践创造技术债务。所有人都在估计工程实践将成为估算的一部分。不要使用自动化单元，功能和性能测试来创建卡来改进应用程序。相反，只将工作包含在您估计的卡片中，并将自动化测试添加到您通过正在工作的卡片触摸的代码中。这将使应用程序能够随着时间的推移而改进，而不会使进度停止。停止添加所有名片只应保存在最激烈的情况下，例如应用程序无法执行或扩展。

如果您继承了没有自动化单元，功能和性能测试的代码库，请告知业务合作伙伴悲惨的事态。让他们知道你将如何评估工作。通过工程实践发现技术债务。最后，告知产品所有者，随着越来越多的代码库被自动化的单元，功能和性能测试所触及，团队的速度将会提高。

Answer 3

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

由于技术债务会影响我们提供新功能的速度，因此我们会记录由于使用旧代码而添加了多少时间。这些数据使我们能够专门用于偿还技术债务的时间。因此，当客户（无论是经理，CTO还是其他人）认为估算过高时，您就拥有可以巩固您职位的数据。

当然，您偶然会发现您的估算值已经过去，因为遗留代码的意外怪癖会让您 偿还技术债务。我们发现，只要可以解释和解释额外的时间，并且可以为所花费的额外时间带来好处，那么它通常被很好地接受。

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

Answer 4

每次提交代码时，每个人都应该做的事情是减少技术债务。

当您编辑代码时，在离开露营地之前，您会像侦察员一样整理一下。

这样，经常变化的代码会更好，这对业务有利。

永不改变的代码不会改善，但如果有效的话，为什么还要改进呢？

不要为此安排任务，尽管长期计划很有帮助，讨论问题的论坛也是如此。

非常大的项目将受益于某种锁定方案，因此两个编码器不会在不同步的情况下同时重构同一段代码。

/罗杰

Answer 5

我认为询问客户希望使用该应用程序的时间长短是一个好主意。如果应用程序的生命周期有限（例如，三年或更短），那么在重构方面付出很多努力可能没有意义。如果预期（或希望）寿命更长，则重构的回报变得更具吸引力。

您可能还想尝试为重构投资创建业务案例。显示您想要进行的各种改进的具体示例。对成本，风险和预期回报进行诚实评估。尝试找到一个可以独立于其他重构的特定重构，并游说批准将该更改作为重构过程的测试运行。

请注意，当您谈到投资回报时，您可能需要提供具体的数字。仅仅说“修复bug会更容易”是不够的。相反，你应该准备好说“我们会看到错误修复的周转时间至少提高30％”，或“我们将减少40％的回归。”您还应准备与管理层和/或客户进行协商，以便您都同意您拥有对他们有意义的测量结果，并在重构之前和之后提供测量结果。