跳到主要内容

技术债务优先级排序框架模板

TL; TR: 优先级排序标准​

技术债务优先级排序：代码熟悉度。严重程度。依赖性和规模。修复成本

  • 代码熟悉度。你对代码有多熟悉？

  • 严重程度。它如何影响软件的功能或性能？

  • 依赖性和规模。有多少组件依赖于这部分代码？受影响的软件架构规模。

  • 修复成本。修复技术债务问题需要多少故事点？

总分 = (熟悉度 + 严重程度 + 依赖性) – 3 * 成本

另请阅读技术债务优先级排序的 5 个技巧。

什么是技术债务？​

技术债务是软件开发中使用的一个比喻术语，用于描述当选择短期内易于实现的代码而非可能需要更长时间但更稳健或可扩展的选项时所产生的额外开发工作。它指的是走捷径或编写未针对长期可维护性、可扩展性或可靠性进行优化的代码所产生的成本。

技术债务的例子包括编写难以阅读和理解的意大利面条式代码、使用不再受支持的过时库或框架、未能记录代码或测试，以及忽略定期维护或更新。

技术债务示例​

典型的技术债务工单：

  1. 使用过时或弃用的技术：使用旧的或不受支持的技术可能导致兼容性问题和安全漏洞。

  2. 代码质量差：难以阅读、理解和维护的代码可能导致 bug、生产力下降和开发时间增加。

  3. 缺乏文档：未能记录代码、流程和需求可能使未来的开发人员难以理解软件，导致开发时间增加和成本上升。

  4. 测试不足：跳过或延迟测试可能导致未检测到的 bug、安全漏洞和用户不满。

  5. 架构设计缺陷：使用次优架构设计软件或未能规划可扩展性可能随着软件变得更加复杂和难以维护而导致技术债务。

不被视为技术债务的例子：

  1. 有意推迟对项目不重要或可以稍后完成的工作。

  2. 我们做出明智的决定走捷径以满足截止日期或快速交付原型。

  3. 有意选择实施不太理想但对项目目标仍可接受的解决方案。

  4. 我们决定使用特定技术或工具，尽管其潜在限制是基于时间、成本和业务需求等其他因素的权衡。

  5. 我们正在执行不会显著改进软件的日常维护任务。

技术债务问题​

技术债务的主要问题是它会随着时间的推移而累积，使添加新功能、修复 bug 或维护代码库变得更加困难。

  • 功能开发耗时更长

  • 更多 bug

这总是在改进代码和添加新功能之间进行权衡。

技术债务优先级排序标准​

考虑这些标准，你可以创建一个优先级排序系统，帮助你在任务管理工具的工单中识别和解决技术债务，以最大化业务价值并最小化风险。

可以随意添加、修改或重写标准名称和描述，以便你的团队更好地理解。

对于每个标准，我们使用斐波那契数列评估量表，因为它最适合故事点估算。

.app 项目中的技术债务优先级排序标准

hi.ducalis.io 项目中的技术债务优先级排序标准

代码熟悉度​

这是开发团队对正在处理的代码库的理解和熟悉程度。它包括理解和浏览代码的能力，以及对代码结构、设计模式和项目中使用的最佳实践的理解。

代码熟悉度对开发团队至关重要，因为它直接影响他们高效编写和维护高质量代码的能力。拥有更多代码熟悉度的团队可以更快、更准确地工作。

简而言之，代码熟悉度是开发团队技能集的关键组成部分，直接影响他们工作的质量和效率。

  • 1：作者。我编写了那段代码——可以维护和解释它。

  • 2：维护者。我使用过那段代码——对它的工作原理没有疑问。

  • 3：可获取。我可以询问我的队友并阅读相关文档。

  • 5：有文档。我没有使用过它。我们有一些相关文档。

  • 8：可理解。我没有使用过它，但我无需花费太多精力就了解了它的工作原理。

  • 13：有挑战。需要大量时间才能弄清楚它的工作原理。我没有使用过那段代码，但我可以联系使用过它的人或找到文档。

  • 21：从未听说过。你的团队中没有人了解那段代码，或者他们很快就会离开。

严重程度​

影响严重程度：确定技术债务问题对软件功能或性能的影响程度。影响严重程度可以是高、中或低，这可以用作优先级排序的标准。

  • 1：完全没有影响。

  • 2：外观性：对某些局部组件的浅层影响。可以在资源和时间可用时在未来解决。

  • 3：次要：工作良好，但我们可以改进它。可以在资源和时间可用时在未来解决。

  • 5：构建者：降低生产力、使代码可维护性降低或阻止添加新功能。可以在资源允许时稍后解决。可以稍后解决

  • 8：阻碍者。阻碍对软件某个组件的进一步增强或更新。应尽快解决以防止出现重大问题。

  • 13：主要。阻碍并几乎破坏多个软件组件。给项目带来额外的风险或延迟。

  • 21：破坏者。如果不解决，它会使软件无法使用或产生高风险。

依赖性和系统规模​

有多少组件依赖于那部分代码？受影响的软件架构规模：

  • 1：微不足道。可以忽略，因为它可以在任何时候偿还。

  • 2：次要局部。它包含在单个方法、类或函数中。可能违反 SOLID 原则——对软件的整体质量没有重大影响。

  • 3：中等局部：影响多个方法、类或函数。修改时也可能更难避免意外后果。

  • 5：全局。包含在单个应用程序或服务中，但涉及跨子系统的 SOLID 违规，在更广泛的系统中扩展到看似无关的区域。它还可能包括抽象层之间的不匹配、集成点问题和硬耦合。这种债务不会影响应用程序或服务的使用者，但在修改服务本身时会感受到。

  • 8：主要全局。对软件质量的影响更大、更广泛。它可能涉及多个子系统并影响整个应用程序或服务。修改时也可能更难避免意外后果。

  • 13：系统性。跨多个应用程序、基础设施或团队蔓延。它涉及共享数据存储的众多服务、不同有界上下文之间的高耦合，以及技术实现与业务逻辑之间的明显不匹配。系统性债务从长远来看是不可持续的，需要立即关注。

  • 21：关键。这对软件的整体质量构成重大风险，可能影响系统的稳定性和可靠性。

修复成本​

修复技术债务问题需要多少故事点？

  • 1：无需投入

  • 2：低成本：迭代持续时间的 10%。

  • 3：中等：迭代持续时间的 20%。

  • 5：显著：半个迭代

  • 8：高：一个迭代

  • 13：非常高：超过一个迭代，但少于两个迭代。建议拆分为多个工单。

  • 21：成本过高。目前不知道如何处理。两个迭代及以上。

自定义标准描述​

不要忘记，最好的标准描述是你的队友更容易理解的。你拥有的标准和量表描述越具体——对你的优先级排序过程越有利。指定迭代持续时间、依赖项的解释、阻碍者的定义以及代码熟悉度的含义。详细了解标准描述编辑。

在 hi.ducalis.io 为你的团队轻松自定义标准描述

自定义标准描述

不适用于技术债务评估的标准​

业务价值、发生频率、年龄和对用户体验的影响是评估技术债务不可靠的标准。

不要使用：业务价值或用户体验​

代码质量、文档、测试覆盖率和软件架构等因素很少与收入等业务指标直接相关。这些因素影响开发团队高效进行更改的能力以及软件的整体质量、可靠性和可扩展性。

不维护技术债务的最流行原因之一是从潜在收入的角度对其进行评估。

不要使用：发生频率​

考虑技术债务问题在未来再次发生的可能性。技术债务不是可能再次发生的 bug。不要浪费时间预测未来。

不要使用：问题年龄​

更快地重构旧库可能看起来像一个明显而直接的想法。但是，如果代码运行良好并且不会降低速度或产生漏洞，为什么要花时间在上面呢？年龄不应该是你的优先级排序标准。

技术债务工单的优先级评分计算​

像往常一样，我们需要平衡标准权重，以制定正确的策略来为技术债务设置最高优先级工单。默认情况下，我们的权重为 -2。你团队拥有的开发资源越少——权重必须越负。

.app 上用于技术债务优先级排序的成本标准设置。

"成本"标准的权重设置

最终公式非常简单：

收集技术债务待办事项的工单​

Ken Ruben 的《Essential Scrum: A Practical Guide to the Most Popular Agile Process》

在"Essential Scrum: A Practical Guide to the Most Popular Agile Process"中，作者 Ken Ruben 使用三个类别来定义技术债务：偶遇的、已知的和目标技术债务。

  • 偶遇的技术债务是开发团队在日常产品使用或维护期间暴露之前不知道存在的技术债务。例如，在向软件添加新功能时，团队可能会发现多年前添加到代码中并保持不变的变通方法，导致意外行为。偶遇的技术债务也可能由"位腐烂"引起，当代码随着时间的推移而恶化，改变其功能和可用性时就会发生这种情况。

  • 另一方面，已知技术债务是开发团队已经知道并且可以在软件中看到的技术债务。已知技术债务的例子包括代码质量差、缺乏文档或测试不足。

  • 最后，目标技术债务是开发团队选择在特定迭代或发布中解决的已知技术债务。这可能涉及改进代码、改进文档或增加测试覆盖率，以减少技术债务并提高软件质量。

通过了解不同类型的技术债务，开发团队可以确定其工作的优先级，并努力解决技术债务，以最小化其对软件长期可维护性和可靠性的影响。

技巧 1. 在任务管理工具上创建专用部分​

必须有一个属性将技术债务工单与 bug 或功能等其他工单分开。使用特殊标签/标记、工单类型或组件。你应该始终可以选择查看包含所有工单的完整待办事项，并按类型对其进行筛选。

技巧 2. 使用一致的格式​

使用一致的格式记录技术债务工单，例如待办事项工具中的用户故事或任务。这将帮助你轻松识别和确定技术债务工单的优先级。

技巧 3. 提供清晰的描述​

提供技术债务问题的清晰描述，包括其对代码库的影响、修复它所需的估计投入以及任何潜在的风险或后果。

技巧 4：使用代码变更频率收集偶遇的技术债务​

代码变更频率是对软件系统代码库进行更改的频率。

它可用于评估软件项目的健康状况和质量，并识别潜在问题和风险。它允许评估影响、识别高风险区域并就更改代码库做出明智的决策。

  • 高频率可能表明频繁更新、改进、不稳定或错误。

  • 低频率可能表明缺乏维护或演进，导致技术债务和其他问题。

强烈建议观看 Adam Tornhill 关于这个想法的演讲，"

。"

技巧 5：自动扫描代码以发现性能问题和漏洞​

有许多用于代码分析的工具。尝试它并将发现的问题推送到任务管理工具的待办事项。

  1. Code Scene — 一个可视化、理解和改进软件的工具，涉及代码、知识以及背后的人员。根据自动化、优先级排序和可操作的建议进行改进。

  2. SonarQube：一个流行的工具，可以检测代码中的安全漏洞、代码异味和其他问题。它支持各种编程语言并与各种 CI/CD 工具集成。

  3. OWASP ZAP：一个开源 Web 应用程序安全扫描器，可以检测 SQL 注入、跨站点脚本和其他安全问题等漏洞。

  4. CodeClimate：一个基于云的平台，可分析你的代码并提供有关其质量、可维护性和安全性的见解。它支持各种编程语言并与 GitHub、Bitbucket 和其他工具集成。

  5. Snyk：一个基于云的工具，可扫描你的代码和依赖项以发现安全漏洞并提供修复建议。它支持各种编程语言并与各种 CI/CD 工具集成。

  6. AppDynamics：一个提供对应用程序性能的实时洞察的工具，包括响应时间、错误率和其他指标。它可帮助你识别性能瓶颈并优化代码。

  7. Qodana。评估你拥有、合同或购买的代码的完整性。用你喜爱的 JetBrains IDE 中的所有智能功能丰富你的 CI/CD 管道

结论​

技术债务在软件开发中是不可避免的，但它也可能成为进步和创新的重大障碍。通过开发适合你团队的技术债务优先级排序系统，你可以最小化其影响并随着时间的推移保持软件的质量和可靠性。

请记住，技术债务不仅仅是开发人员的问题；它影响整个组织。通过将技术债务管理纳入项目管理流程，你可以确保每个人都了解其影响并共同努力解决它。

最后，重要的是要记住，解决技术债务不是一次性事件；它需要持续的关注和投入。通过定期审查和更新你的技术债务待办事项，你可以掌握潜在问题并确保你的软件从长远来看保持健康和可靠。

下一步阅读：技术债务优先级排序的 5 个技巧

最后更新： 今天