当前位置:CIO技术探讨 → 正文

衡量和管理技术债务的5个最佳实践

责任编辑:cres 作者:Isaac Sacolick |来源:企业网D1Net  2018-10-12 10:25:08 原创文章 企业网D1Net

维护应用程序和避免或至少延迟遗留状态的秘密在于组织和团队如何管理技术债务。
 
对于所有需要进行技术债务管理的开发组织来说,这都是一个巨大的挑战,技术债务指的是过去在软件开发工作中做出的决策所产生的大量工作。
 
解决技术债务的工作常常受到冷遇,因为这些工作无法解决急迫的业务需求,加上投资回报率的不明确,因此通常会被认为是可延期的。对于任何涉及维护的问题,无论是代码还是房屋,这都是一个经典问题。但是也有一些方法可以用来衡量和管理技术债务,这将有助于你保持对技术债务的控制。
 
您今天开发的应用程序是如何演变为明天的遗留应用程序的?您和开发团队正在按照常规的发布计划快速发布应用程序的改进,因此可能很难想象这些应用程序将来会变成遗留状态。您可能还想知道,在开发应用程序以降低成为遗留应用程序的风险时,您可以在今天做些什么。
 
应用程序不会在一夜之间成为遗留项目,之所以会变成这样,有两个主要原因:
 
•随着应用程序的发展,组织可能会分配更少的人员来维护它,而将人员转移到更具战略性的项目。
 
•随着时间的推移,团队致力于对应用程序进行技术改进的时间可能会越来越少,因为他们会关注新的活动。
 
技术债务的定义
 
通常,那些因技术改进而带来的积压工作被称为技术债务。技术债务是开发团队为维护应用程序的体系结构、底层平台和代码而必须要做的事情。技术债务的例子包括:
 
•在需要更多时间来实施更强大的解决方案时,那些应该重构小段代码的工作。
 
•在实现了一个复杂的特性之后,留下来的维护工作。团队可能已经用大量的设想预估了这个特性,但是产品负责人仍然优先考虑它的开发。它是在最好的意图下开发出来的,但事后看来,可能还有更高效、更强大的实现。这造成了另一个技术债务来源。
 
•一个为简单用例开发的代码模块,但随着时间的推移,它需要重构来适应用于更广泛的用例。
 
•有时,代码在没有适当的辅助工具的情况下被发布。这些辅助工具应该包括应用程序日志记录、错误检查、异常处理、文档和其他工件。
 
•有时,代码模块可以作为独立的微服务以实现进行更好的管理。这种类型的转变可能被一些人认为是架构升级,但我仍然将其称为技术债务,因为这是技术驱动的改进。
 
•有时,团队开始使用库或服务的新版本来部署新代码,并将旧代码的升级保留到以后来完成。这种拖延造成了技术性债务。
 
•升级和补丁平台、第三方服务、开发工具和新API版本的连接也是技术债务的一种形式。
 
衡量这种债务表明了开发团队认为的还需要做多少工作才能最好地支持应用程序。具有大量且不断增长的技术债务的应用程序是它们正走向遗留状态的有力指标。
 
维护应用程序以及避免或至少延迟遗留状态的秘诀在于组织和团队如何管理技术债务。
 
弄清楚了这些技术债务的来源之后,不同规模的技术组织应该如何处理这些问题呢?首席信息官面临的最棘手的问题之一就是如何管理遗留系统和实现技术的现代化,因此我们在管理技术债务方面需要面对既得利益者。
 
每周四的下午2点,我都会在#CIOChat标签下参与Twitter聊天。我询问了他们的技术债务战略,并在接下来的5个最佳实践中包括了他们关于如何最好地度量和管理技术债务的一些想法。
 
1.管理技术债务从衡量技术债务开始
 
如果没有某种方法可以捕捉细节并加以管理,你就无法管理日益严重的问题。正如云技术合作伙伴公司副总裁兼首席架构师Ed Featherston所说的:
 
一切都是一种权衡。技术债务也是这种权衡下的结果。为了权宜之计做出的决定,留下了必须偿还的债务。我所见过的处理这一问题的最好方法之一是将特定的技术债务积压与产品积压分离开来。这为累积的债务带来了可见性和透明度,并且每个迭代周期都应该包括产品和技术债务的故事。
 
对敏捷团队来说,在待办事项列表中标记技术债务是一个重要规则。这可以在一个迭代周期中完成,因为技术债务得到了确认,所以可以在迭代周期回顾会议中进行捕获。Featherston和我在这里有所不同:我更喜欢在相同的待办列表中捕获产品的增强和技术债务,但是技术债务用户故事和任务被标记为一个或多个不同的标签。但是,只要团队和产品负责人能够看到在每个迭代周期中添加和处理的技术债务是什么,任何一种方法都是有效的。
 
2.使用发布计划策略来管理技术债务
 
大多数开发组织都有一种管理应用程序发行版的方法,来对这些发行版的目标范围和时间做出决策。但即使是执行持续发布周期的团队也会召开会议来审核短期和长期的优先事项。在这些会议中,架构师和开发人员可以表达哪些功能的优先级是复杂的,并可能导致新的技术债务形式。
 
用Affinitas Life的首席技术官Wayne Sadin的话来说:
 
通过确保项目预算和计划能够明确处理正在进行的维护成本,包括被替换系统的退役(日期/成本/过程),来停止增加技术债务。填补深坑的第一步:停止挖掘!
 
Sadin在规划会议上提到了几个强有力的管理原则:
 
•在规划时讨论复杂的功能,寻找更易于实施的更简化的解决方案,以减少技术债务。
 
•确保将团队的百分之一的优先事项用于解决技术债务。我的经验是,发布速度的30%应该应用于处理债务,而发布计划会议是讨论和辩论优先级的好地方。
 
•当我们都喜欢构建新的应用程序并致力于创新时,开发组织也需要关注旧的平台、应用程序、库和代码模块。这也可以纳入发布计划。
 
•最后,可能也是最重要的,是技术组织如何管理新技术的选择和采用,包括开发平台和库。如果您选择一项技术是因为它是“下一个最好的东西”,而“下一个最好的东西”与已经使用的技术重叠,那么你就是在制造新的技术债务!
 
3.Devops CI/CD使解决技术债务变得更加容易
 
Devops的关键实践之一是实现持续集成、持续测试和持续交付管道或CI/CD管道。这种自动化可以将代码嵌入版本控制系统,打包应用程序,将代码交付给开发或测试环境,并通过一系列的回归测试。
 
通过这种自动化,让团队对代码库进行小的、增量的更改有了更多的信心,因为部署是脚本化的,而回归测试可以最快地识别应用程序的问题。
 
与此形成鲜明对比的是没有这种自动化或测试系统的遗留应用程序。开发团队在对这些应用程序进行更改时将变得越来越担心,因为他们不知道什么时候会中断,也不知道部署是否能够可靠地执行。这种担心减缓了团队解决技术债务的速度,并加快了应用程序到到达遗留状态的速度。
 
4.规划发布周期以解决补丁和升级问题
 
较小的技术债务项目,如修复和重构代码,可以在发布范围内完成。但是当涉及到更大的升级时,则通常需要一个专门的“系统升级”版本来执行和测试升级。系统升级最好是在不引入新功能的情况下执行,这样团队就可以根据已建立的测试和已知行为来验证升级。
 
有纪律的组织通常会执行周期性的计划,以在对业务和用户需求影响最小的时候安排这些升级周期。正如奥克兰大学的CIO Theresa Rowe所说:
 
我们通过对现有技术投资进行谨慎地周期性规划来管理技术债务;任何投资都需要进行规划来与战略举措相匹配。
 
例如,如果您的应用程序在Java和MySQL后端上运行,开发团队可能会考虑每年进行一次重大升级,来跟上这些平台的主要发布周期。然后,它应该寻找使用率相对较低的时段来安排这些升级。
 
5.传达遗留应用程序和技术债务的状态
 
重要的是要认识到应用程序的维护状态对大多数业务领导者来说是不可见的。只有当遗留应用程序的可靠性较差或需要的功能升级时间太长或实现成本太高时,它们才会感觉到遗留应用程序的存在。换句话说,他们可以感知应用程序何时达到遗留状态,但是他们对导致遗留状态的技术债务的测量和管理缺乏很好的理解和可见性。
 
解决这一差距是技术组织的共同责任。首先,你需要测量它。然后,通过提前确定优先级并解决它。最后,通过创建报告或合适的沟通工具来提供这些遗留问题的可见性。

关键字:CIO首席信息官

原创文章 企业网D1Net

x 衡量和管理技术债务的5个最佳实践 扫一扫
分享本文到朋友圈
当前位置:CIO技术探讨 → 正文

衡量和管理技术债务的5个最佳实践

责任编辑:cres 作者:Isaac Sacolick |来源:企业网D1Net  2018-10-12 10:25:08 原创文章 企业网D1Net

维护应用程序和避免或至少延迟遗留状态的秘密在于组织和团队如何管理技术债务。
 
对于所有需要进行技术债务管理的开发组织来说,这都是一个巨大的挑战,技术债务指的是过去在软件开发工作中做出的决策所产生的大量工作。
 
解决技术债务的工作常常受到冷遇,因为这些工作无法解决急迫的业务需求,加上投资回报率的不明确,因此通常会被认为是可延期的。对于任何涉及维护的问题,无论是代码还是房屋,这都是一个经典问题。但是也有一些方法可以用来衡量和管理技术债务,这将有助于你保持对技术债务的控制。
 
您今天开发的应用程序是如何演变为明天的遗留应用程序的?您和开发团队正在按照常规的发布计划快速发布应用程序的改进,因此可能很难想象这些应用程序将来会变成遗留状态。您可能还想知道,在开发应用程序以降低成为遗留应用程序的风险时,您可以在今天做些什么。
 
应用程序不会在一夜之间成为遗留项目,之所以会变成这样,有两个主要原因:
 
•随着应用程序的发展,组织可能会分配更少的人员来维护它,而将人员转移到更具战略性的项目。
 
•随着时间的推移,团队致力于对应用程序进行技术改进的时间可能会越来越少,因为他们会关注新的活动。
 
技术债务的定义
 
通常,那些因技术改进而带来的积压工作被称为技术债务。技术债务是开发团队为维护应用程序的体系结构、底层平台和代码而必须要做的事情。技术债务的例子包括:
 
•在需要更多时间来实施更强大的解决方案时,那些应该重构小段代码的工作。
 
•在实现了一个复杂的特性之后,留下来的维护工作。团队可能已经用大量的设想预估了这个特性,但是产品负责人仍然优先考虑它的开发。它是在最好的意图下开发出来的,但事后看来,可能还有更高效、更强大的实现。这造成了另一个技术债务来源。
 
•一个为简单用例开发的代码模块,但随着时间的推移,它需要重构来适应用于更广泛的用例。
 
•有时,代码在没有适当的辅助工具的情况下被发布。这些辅助工具应该包括应用程序日志记录、错误检查、异常处理、文档和其他工件。
 
•有时,代码模块可以作为独立的微服务以实现进行更好的管理。这种类型的转变可能被一些人认为是架构升级,但我仍然将其称为技术债务,因为这是技术驱动的改进。
 
•有时,团队开始使用库或服务的新版本来部署新代码,并将旧代码的升级保留到以后来完成。这种拖延造成了技术性债务。
 
•升级和补丁平台、第三方服务、开发工具和新API版本的连接也是技术债务的一种形式。
 
衡量这种债务表明了开发团队认为的还需要做多少工作才能最好地支持应用程序。具有大量且不断增长的技术债务的应用程序是它们正走向遗留状态的有力指标。
 
维护应用程序以及避免或至少延迟遗留状态的秘诀在于组织和团队如何管理技术债务。
 
弄清楚了这些技术债务的来源之后,不同规模的技术组织应该如何处理这些问题呢?首席信息官面临的最棘手的问题之一就是如何管理遗留系统和实现技术的现代化,因此我们在管理技术债务方面需要面对既得利益者。
 
每周四的下午2点,我都会在#CIOChat标签下参与Twitter聊天。我询问了他们的技术债务战略,并在接下来的5个最佳实践中包括了他们关于如何最好地度量和管理技术债务的一些想法。
 
1.管理技术债务从衡量技术债务开始
 
如果没有某种方法可以捕捉细节并加以管理,你就无法管理日益严重的问题。正如云技术合作伙伴公司副总裁兼首席架构师Ed Featherston所说的:
 
一切都是一种权衡。技术债务也是这种权衡下的结果。为了权宜之计做出的决定,留下了必须偿还的债务。我所见过的处理这一问题的最好方法之一是将特定的技术债务积压与产品积压分离开来。这为累积的债务带来了可见性和透明度,并且每个迭代周期都应该包括产品和技术债务的故事。
 
对敏捷团队来说,在待办事项列表中标记技术债务是一个重要规则。这可以在一个迭代周期中完成,因为技术债务得到了确认,所以可以在迭代周期回顾会议中进行捕获。Featherston和我在这里有所不同:我更喜欢在相同的待办列表中捕获产品的增强和技术债务,但是技术债务用户故事和任务被标记为一个或多个不同的标签。但是,只要团队和产品负责人能够看到在每个迭代周期中添加和处理的技术债务是什么,任何一种方法都是有效的。
 
2.使用发布计划策略来管理技术债务
 
大多数开发组织都有一种管理应用程序发行版的方法,来对这些发行版的目标范围和时间做出决策。但即使是执行持续发布周期的团队也会召开会议来审核短期和长期的优先事项。在这些会议中,架构师和开发人员可以表达哪些功能的优先级是复杂的,并可能导致新的技术债务形式。
 
用Affinitas Life的首席技术官Wayne Sadin的话来说:
 
通过确保项目预算和计划能够明确处理正在进行的维护成本,包括被替换系统的退役(日期/成本/过程),来停止增加技术债务。填补深坑的第一步:停止挖掘!
 
Sadin在规划会议上提到了几个强有力的管理原则:
 
•在规划时讨论复杂的功能,寻找更易于实施的更简化的解决方案,以减少技术债务。
 
•确保将团队的百分之一的优先事项用于解决技术债务。我的经验是,发布速度的30%应该应用于处理债务,而发布计划会议是讨论和辩论优先级的好地方。
 
•当我们都喜欢构建新的应用程序并致力于创新时,开发组织也需要关注旧的平台、应用程序、库和代码模块。这也可以纳入发布计划。
 
•最后,可能也是最重要的,是技术组织如何管理新技术的选择和采用,包括开发平台和库。如果您选择一项技术是因为它是“下一个最好的东西”,而“下一个最好的东西”与已经使用的技术重叠,那么你就是在制造新的技术债务!
 
3.Devops CI/CD使解决技术债务变得更加容易
 
Devops的关键实践之一是实现持续集成、持续测试和持续交付管道或CI/CD管道。这种自动化可以将代码嵌入版本控制系统,打包应用程序,将代码交付给开发或测试环境,并通过一系列的回归测试。
 
通过这种自动化,让团队对代码库进行小的、增量的更改有了更多的信心,因为部署是脚本化的,而回归测试可以最快地识别应用程序的问题。
 
与此形成鲜明对比的是没有这种自动化或测试系统的遗留应用程序。开发团队在对这些应用程序进行更改时将变得越来越担心,因为他们不知道什么时候会中断,也不知道部署是否能够可靠地执行。这种担心减缓了团队解决技术债务的速度,并加快了应用程序到到达遗留状态的速度。
 
4.规划发布周期以解决补丁和升级问题
 
较小的技术债务项目,如修复和重构代码,可以在发布范围内完成。但是当涉及到更大的升级时,则通常需要一个专门的“系统升级”版本来执行和测试升级。系统升级最好是在不引入新功能的情况下执行,这样团队就可以根据已建立的测试和已知行为来验证升级。
 
有纪律的组织通常会执行周期性的计划,以在对业务和用户需求影响最小的时候安排这些升级周期。正如奥克兰大学的CIO Theresa Rowe所说:
 
我们通过对现有技术投资进行谨慎地周期性规划来管理技术债务;任何投资都需要进行规划来与战略举措相匹配。
 
例如,如果您的应用程序在Java和MySQL后端上运行,开发团队可能会考虑每年进行一次重大升级,来跟上这些平台的主要发布周期。然后,它应该寻找使用率相对较低的时段来安排这些升级。
 
5.传达遗留应用程序和技术债务的状态
 
重要的是要认识到应用程序的维护状态对大多数业务领导者来说是不可见的。只有当遗留应用程序的可靠性较差或需要的功能升级时间太长或实现成本太高时,它们才会感觉到遗留应用程序的存在。换句话说,他们可以感知应用程序何时达到遗留状态,但是他们对导致遗留状态的技术债务的测量和管理缺乏很好的理解和可见性。
 
解决这一差距是技术组织的共同责任。首先,你需要测量它。然后,通过提前确定优先级并解决它。最后,通过创建报告或合适的沟通工具来提供这些遗留问题的可见性。

关键字:CIO首席信息官

原创文章 企业网D1Net

电子周刊
回到顶部

关于我们联系我们版权声明隐私条款广告服务友情链接投稿中心招贤纳士

企业网版权所有 ©2010-2024 京ICP备09108050号-6 京公网安备 11010502049343号

^