如何解决技术债务：问题的敏捷根源（2018）

当人们谈论技术债务时，他们实际上是在指按期限进行“快速而肮脏的”程序更改的长期后果，而不是像软件开发作者兼演讲者Martin Fowler所说的那样编写“更好的设计”。

Fowler说，IT组织如何累积技术债务就像人们如何累积金融债务一样。它“需要支付利息，这是由于快速而肮脏的设计选择，我们在未来的开发中必须付出额外的努力。”

对于进行敏捷开发的团队而言尤其如此。敏捷时，步伐更快，并且可以尽快交付客户需要的功能。事情只需要工作就可以继续前进，尽管它们需要很好地工作，但“快速而肮脏的”工作仍然会发生，并且技术债务会不断累积。

随着越来越多的团队从Waterfall转移到Agile，我们看到大型机开发中会发生这种情况。但是，不管您的大型机团队遵循哪种开发理念，我都认为有一些常见的缺陷会导致技术负担增加：

缺乏代码逻辑的文档，削弱了开发人员对程序的了解，以查找要更改的代码

用于源代码管理，调试，编码标准和实施，代码覆盖率和测试的开发工具不足

零或无效的自动测试，为由于手工处理而导致的错误或忽略的测试留有余地

很高兴知道什么活动或缺乏造成技术债务。但是，当您的目标是支付时，您​​也必须考虑您的技术债务的存在。

根据您的大型机店铺的文化，工艺和工具，您认为最大的技术债务最大化会有所不同，特别是对于那些从瀑布到敏捷的人。至少有五个公共领域，在该旅程中为大型机团队产生了技术债务。

瀑布开发使您有时间在部署新功能之前彻底预订，研究，设计，代码和测试和修复错误。缺点是您没有足够快，以满足客户，商业和营销需求。

与瀑布不同，敏捷开发可用于创建较少的目标功能，以更快地满足新功能的商业压力。这对公司及其客户在数字时代有益。但是，如果您从瀑布向敏捷的成熟应用程序移动到敏捷，技术债务通常是从旧系统和旧代码继承的。

任何已经存在的系统很可能都有其技术债务份额。旧的系统，开发人员越多 - 一些更好的编码器，而不是其他人 - 很可能已经致力于它。代码不断更新和更改，旧的代码基础随着时间的推移而增长，使其变得更加困难。

添加到现有应用程序的代码越多，引入新复杂性或打破现有逻辑的可能性就越有更多的机会，从而产生更多缺陷和增加的开发时间。较旧的错误通常更难以找到和修复。

即使产品在发布前审查了高性能的审查，当您快速移动时，技术债务是不可避免的。由于重构代码缺乏时间，它会迅速构建，构建测试自动化环境甚至写入好文件。

基于文档的技术债务确实是它自己的野兽。这很容易产生，甚至使工作变得很糟糕，但是却经常被忽略。

使用敏捷，系统更改的频率比瀑布式更改的频率高得多。这意味着文档也需要快速发展。

开发人员倾向于记录更改，而不考虑面向客户的产品文档的整体流程。如果未适当注意如何将文档添加到指南中，您将很快得到一组with肿且无法使用的说明。

当您开始将成熟的Waterfall应用程序转换为敏捷流程时，现有文档中的技术债务通常很明显-遗漏或遗忘了说明，错过了步骤，没有清楚地传达信息，新的更新加剧了问题。

但是，对于在敏捷流程中开发的新应用程序来说，构建出色的文档很容易，因为您是从头开始的，也就是说，如果您严格遵守完成的定义。

如果严格遵守完成的定义，那么新开发项目就很难产生技术债务。这意味着：

在敏捷中，产品负责人负责宣告完成的故事，但是整个团队负责执行完成的定义。如果不遵守“完成”的定义，则技术债务可能导致：

如果您的大型机团队承担过多的工作，也可能导致技术债务。对于在sprint中工作的敏捷团队尤其如此。在某些情况下可能会发生这种情况。

在sprint计划中，团队应该确信他们可以完成为该sprint计划的所有故事，否则，他们可能会急于采取捷径来完成工作，这将导致效率低下的代码，缺陷和质量下降。在团队承诺将其包含在计划的冲刺中之前，应使用特定的接受标准编写故事，并对其进行调整和调整大小。

许多团队很难说“不”，并且在冲刺阶段承担的工作比完成还多。在敏捷时间框内尤其如此，团队会“冲刺”以在项目的目标完成日期之前交付最低可行的产品（MVP）。借助敏捷时光箱，应该始终在定义，调整大小和达成共识之前就制定MVP，这样团队就不会被追逐不断扩大的项目范围所困扰。

每个团队成员应一次处理一个故事，以最大程度地减少进行中的工作（WIP）。在制品过多可能会导致技术债务，因为人们从一项任务转移到另一项任务，而不是在承担更多任务之前专注于完成最高优先级的工作。

团队不应感到压力太大，无法完成冲刺阶段所能完成的工作。范围爬行，在不增加资源的情况下向固定长度的sprint或有时间限制的项目中添加工作通常会导致技术负担。团队需要大声疾呼，向后推，了解自己的能力。

在敏捷中，Scrum团队应专门负责冲刺工作。客户问题和应用程序停机之类的中断会产生负面影响，并经常导致冲刺工作不完整或开发人员加班。

开发人员应该专注于他们致力于的冲刺工作，而不用担心被解雇来处理客户和生产问题，这就是客户解决方案团队的目的：确保客户在开发人员提供客户所需的功能时得到应有的关注。

当然，始终关注新的发展可能会导致技术债务。应分配时间和资源以适当重构和维护代码，改进自动化测试和更新现有文档。这不会添加新功能，但将使团队能够减慢并使它们在长期运行中更高效。

技术已先进，提供更高效且有效的硬件，软件和网络功能，可能需要编码变化以利用。更容易阅读和理解代码，更改和修改更容易。

技术债务显然不仅限于做敏捷的团队，并且这些积分可能适用于大量的瀑布，尽管有不同程度。无论如何，所有大型机团队都被要求今天更快地移动，是否努力变得敏捷或战斗，以保持他们的瀑布状态 - 当你移动更快，技术债务累积时。

既然你了解为什么技术债务正在增长，在哪里，让我们谈谈你如何支付。在我的下一篇文章中，我会讨论这一点以及技术债务的一些后果以及如何预防和管理它向前发展。