技术债务剖析：实现无债务开发周期的敏捷开发策略

传统的软件程序采用基于阶段的开发方法：功能开发、alpha、beta 和黄金大师 (GM)。

每个版本都从构建新功能的阶段开始，（理想情况下）解决了上次发布遗留的残留事务（但说实话：这种情况很少发生）。每项功能都实施并准备进行测试时，开发周期将达到“alpha”。修复了足够多的错误后，就会发布 beta 版以获得客户反馈。不幸的是，当团队忙于修复足够多的错误以进入 beta 版时，出现了新的错误。就像打地鼠一样：修复一个错误，然后再弹出两个错误。最后，版本达到了黄金大师级，存在零个未解决的错误。“零个未解决的错误”通常通过修复一些已知问题并推迟其余（大多数？）问题，从而实现下一个版本。

不断推迟需要修复的错误对于软件制作来说相当危险。随着错误不断增多，解决问题变得越来越困难，最终导致技术债务的恶性死亡旋涡。更糟糕的是，由于围绕错误进行编码会减慢开发速度，因此还会影响既定的日程安排。同时，由于未修复的错误造成的问题，客户的体验也很糟糕。事实上，一些客户最终会选择终止与您的业务关系。

肯定有更好的方法。

敏捷开发将质量融入迭代开发方法中，这样团队就可以在发布后保持一致的质量版本。如果某项功能无法正常运行，那这项功能就不会交付。是不是很难相信？好吧，有一个窍门：定义或重新定义“已完成”的定义。

对于传统团队来说，“已完成”意味着可以开始 QA。这个定义的问题在于，错误会在发布周期的早期蔓延，并继续蔓延。因此，直到 QA 发现错误，产品各层都已经充满了缺陷。但是，敏捷团队将“已完成”定义为准备发布，这意味着直到客户实际掌握当前项目后，开发人员才会转到下一个故事或功能。为了加快步伐，他们使用功能分支工作流、自动化测试和在整个开发周期中持续集成等技术。

代码库的主分支应随时准备交付。这是第一要务。因此，新功能的开发始于一个任务分支，其中包含功能本身的代码以及相应的自动化测试。功能开发完成并通过自动化测试后，该分支就可以合并到主分支中。由于质量标准始终是固定的（并且固定在较高水平），因此技术债务总是处于控制之中。

对于许多组织来说，这是一次巨大的文化变革。借助敏捷，将注意力从日程安排转移到高质量、可演示的软件上。产品负责人有权首先将团队的注意力集中在最有价值的工作上，从而缩小发布范围，而不是在质量方面妥协。

我们必须要记住：错误持续的时间越长，修复的难度就越大。

如果您使用的是遗留代码，那您很可能继承了一些技术债务。下方主题将帮助您控制现有债务，并使您的团队能够专注于新功能开发等有趣的事情。

某些情况下，开发人员和产品经理对什么构成技术债务存在分歧。我们可以在这里结束争议：

这包括为满足交付截止时间而制作的任何技术捷径！

开发方面可能会将架构工作描述为技术债务。它可能是，也可能不是，具体取决于变化的性质（例如，用“真正的”解决方案替换快捷方式，而不是将整体代码库拆分为微服务）。另一方面，在构建新功能方面，产品管理通常比修复错误或性能缓慢更为紧迫。为了避免任何一方对另一方的观点感到厌倦，每个人都需要了解技术债务、代码库中期望的架构更改和新功能之间的区别。开发和产品管理之间的清晰沟通对于确定待办事项的优先级和改进代码库至关重要。

通过在原始用户故事中添加单独的测试任务，抵制损害“已完成”定义的冲动。推迟非常简单，并且只会引发技术债务。如果测试不是作为原始故事或错误修复的一部分完成，则不会完成原始故事或错误修复。在程序中严格定义“已完成”，并确保它包括完整的自动化测试。没有什么比手动测试和错误的代码库更能削弱团队的敏捷性了。

如果有人发现软件中的错误，请花点时间添加一个演示该错误的自动测试。修复错误后，重新运行测试，确保通过。这是测试驱动开发的核心，测试驱动开发是一种历史悠久的方法，用于保持敏捷开发的质量。

改变团队（以及团队利益相关者）如何管理技术债务的理念并不容易。业务需求有时会缩短开发时间，以便更快地上市。考虑到这一点，我们来回顾一下控制技术债务的一些行动项目：

• 让产品负责人了解技术债务的真实成本。确保需要解决现有技术债务的未来故事的故事点值准确无误。
• 模块化您的架构，并对应用中新组件或库中的技术债务采取坚定的立场。当团队和企业看到这些新组件的敏捷性时，他们自然会希望将这些实践扩展到代码的其他部分。
• 编写自动化测试！没有什么比自动化测试和持续集成更能防止错误了。发现新错误时，编写一个新的测试来重现错误，然后修复问题。如果该错误再次出现，则在客户发现之前，自动测试就能发现它。

请记住，技术债务是所有软件团队都要面对的现实。没有人能完全避开它，最主要的是防止它螺旋式失控。