没投过票？千万别说你来过 OSC
近日，有敏捷开发社区发布《工程师技术债务完整指南》。
根据其定义，技术债务也称为代码债务，指开发团队为了加快项目或功能的交付速度，而之后会在某一时间需要重构的情况。技术债务也是一个隐喻框架，用于考虑开发团队加快软件生产后需要重构的关键部分。此时的优先项是更快的开发速度，而不是高质量的代码。
技术债务和金融债务类似，可能损害或者帮助组织工作。统计数据显示，到 2024 年，尚未解决的全球科技债务将使公司损失 4 万亿美元，而进行技术债务补救的公司向客户交付的时间缩短了 50％。
因此，为了使技术债务发挥正面作用，工程师和技术负责人必须监视团队有多少技术债务，并对其进行良好的管理。
Scrum 团队的 6 种技术债务处理方式
Scrum 敏捷开发是一种更加高效和开放的开发框架，这也意味着使用这种框架可能会发生技术债务。
一名 Scrum 培训师 Stefan Wolpers 建议 Scrum 团队通过 6 种方式更好地处理代码债务：
优先考虑技术债务的透明度。要呈现技术债务可视化效果，并在每次 Sprint 会议期间审查技术债务需求。
跟踪技术债务。建议对 bug 进行计数，并在可能的情况下使用更深层的代码度量，如圈复杂度、代码覆盖率、序列评级和规则违规。
快速、定期偿还债务。 Scrum 团队应该考虑在每个 Sprint 周期中，将其 15-20％ 的资源分配给重构代码和修复错误。
调整产品积压。产品积压订单应该包括与偿还技术债务有关的任务。将债务当做是想要解决的 Sprint 问题，这样将避免技术债务被遗漏。
调整对“完成”的定义。在达到可管理的技术债务的设定标准之前，不要将某件事视为已完成。
规范流程。为团队如何处理添加实验，包括引入技术债务的新特性，制定一个可重复的公式。
一些技术债务指标
Bugs。软件开发者应该技术并跟踪 bug，包括已修复和未修复的。
Code Quality。Bugs 会对软件的最终用户有直接影响，但是代码复杂性会损害开发团队和整个组织。因此要密切关注代码的复杂度指标，如圈复杂度、类耦合等等。
Code Cohesion。较高的代码内聚性通常意味着代码具有更高的可维护性、可重用性等。
Code Ownership。更多的工作量通常导致更多的技术债务问题，项目管理人员需要管理从事不同代码工作的人员数量。
Churn。当代码被重写/替换时，它会“Churn”，意指对一段给定代码的可见的活动度量。度量变动可以帮助团队认识到哪些代码需要重构，并进行优先排序。如果工程师必须不断解决同一部分的 bug，这就意味着出现了问题。观察此类变动有助于企业更快发现问题，从而降低技术债务。
猜你喜欢: