技术债务偿还计划

标签: 技术债务 偿还 计划 | 发表时间:2015-06-06 21:47 | 作者:
出处:http://kb.cnblogs.com/

   英文原文: Technical Debt: A Repayment Plan

   什么是技术债务?

  许多团队都受技术债务困扰,不过,很少有团队能真正地设计一个计划从中挣脱出来。为了更好的理解如何才能摆脱债务,我们首先要正确地理解什么是技术债务。

  技术债务是由团队为了短期的项目利益故意做了欠佳的技术决策而招致的。例如,为了使一个产品更快的投放市场,团队可能不会像面对一段棘手的代码那样,编写深入的自动化测试。或者,他们可能会决定基于一个很快就会过时的框架构建项目,而不是花钱购买那个框架的一个经过升级、服务支持更好的版本。不管决策是什么,关键是要认识到,真正的技术债务是团队为了获得短期利益故意做了会招致长远债务的决策。

  这意味着,许多我们通常归咎于“技术债务”的事情实际上根本就不是债务。例如,随着系统使用年限增加,团队会无法一直保持最佳编码实践,在那种情况下出现“位衰减(bit dot)”是正常的,不是债务。或者,团队自愿做出的技术决策在随后实现时竟然发现是不正确的,这也不是技术债务。在任何一种情况下,团队都不是为了获得短期利益而故意做了欠佳的长远决策。这种差别很重要,因为我们只有在究竟是什么组成了技术债务的问题上达成一致,我们才能针对如何减少技术债务做出最佳决策。

  考虑我们在无意间引入代码库的债务所带来的影响也很重要。不过,由于这类债务不是有意承担的,所以我们无法计划如何提前解决它。在这些情况下,我们一定要在发现的时候优先考虑并解决这种债务……就像团队解决新发现的Bug所做的那样。

   一个金融比喻

  我们经常将技术债务与金融债务进行对比。但是,这是一个对等的类比吗?比如,如果不首先确定何时以及如何偿还,银行真会愿意借给我们钱吗?很可能不愿意。既然不首先描述如何偿还债务,我们就确实无法借到金融资本,那么我们也就不应该以这种方式对待技术资本。

  这个金融比喻确实非常有效,因此,我们将对它进行更充分的讨论。

   偿还计划

  正如金融债务一样,在谈论技术债务时,我们需要确定两件事:如何偿还债务和何时偿还债务。

   如何偿还债务

  让我们以前文提到的放弃自动化测试为例。如果为了一项功能能够尽快投入生产环境,我们的团队自愿决定放弃为棘手的代码段编写自动化测试,那么我们需要确定我们将如何纠正那块债务。在这种情况下,我们只需要表明,我们会在将来的某个时点回到这段代码,然后添加测试。不过,只表明“我们将在稍后添加测试”并没有合理地解决这个问题。为了帮助干系人真正地了解我们的决策对招致技术债务会有多大的影响,我们需要尽我们最大的能力准确地说明等到后来添加自动化测试的影响。比如,我们应该指明需要添加测试的代码段。我们也需要明确指出,在已有的代码段上增加自动测试比在代码段创建时直接添加测试总是难度更大成本更高。最后这点很重要,因为它明确指出,将这项工作推迟到后来完成,我们实际上要比现在直接完成花更多的钱来做这项工作。换句话说,……债务是会产生利息的。

  在讨论完偿还方式之后,团队及其干系人可能会意识到,这个问题要比他们是否应该在编写代码时编写自动化测试更复杂。实际上,他们可能会发现,在两个极端之间,他们确实有多种更适合整个项目的选择。比如,他们可能会决定,使用类似“ 圈复杂度(Cyclomatic Complexity)”这样的指标识别出新特性中最复杂的部分是非常有意义的,并立即添加测试覆盖那些方面,而把简单一些的方面推迟。或者,他们可能会决定,像单元测试这种更简单但同时价值也更低的自动化测试类型可以立即添加,但像自动化用户验收测试这种难度更高的自动化测试可以推迟到将来的冲刺中。不管是哪种决定,团队及其干系人都不大可能做出,因为他们没有在第一时间对技术债务进行讨论。

   何时偿还债务

  除了指明如何偿还债务外,我们还希望指明何时偿还债务。通常,债务越早偿还越好。出于这个原因,最好是在债务产生的时候安排债务偿还工作,以便更好地传达承担债务的影响。比如,如果你的团队遵照一个由冲刺构成的时间表,那么你可能会选择将工作安排到下一个冲刺,或者,在最坏的情况下也不超过几个未来的冲刺。

  通常,团队都会有最美好的愿望,就是在债务出现的时候偿还,但他们只是似乎从来都没有时间那样做。当你要消除债务的时候,在日历上记下最后偿还期限,并坚持按时完成。

   如果违约会怎么样?

  对于我们的金融比喻,最后一部分是弄清楚,如果我们选择拖欠债务,会出现什么后果。在金融领域,如果我从来不偿还汽车贷款,那银行会开走我的汽车。拖欠技术债务的后果同样应该明确指出。

  让我们继续自动化测试的例子,如果团队决定不偿还技术债务,那么以现有的未经测试的功能为基础构建新功能只会使难度越来越大成本越来越高。在生产环境中,我们可能会看到更多的Bug报告,这意味着,客户可能会对我们的产品质量产生不好的印象。我们快速响应市场变化的能力也会被削弱,因为我们产品的很大一部分要么很难快速修改,要么快速修改风险太大。

  上述各点都需要向干系人讲清楚,帮助我们避开技术债务违约的诱惑。

   应对位衰减

  截至目前,我们讨论的所有内容都集中在有计划的技术债务上,就是那些作为正常项目的一部分团队故意招致的债务,而如果我们不讨论未计划的技术债务,我们就失职了,因为它们也困扰着许多项目:位衰减。

  如前所述,位衰减不是我们故意招致的,我们无法提前决定如何以及何时偿还,在这个意义上,它不同于正常的技术债务。不过,虽然我们无法确切地知道位衰减在我们项目中的呈现形式,但这并不意味着我们无法计划它。

  就像我们计划偿还已知技术债务时所做的那样,我们也可以在我们的项目计划中加入一个缓冲区,用于在每次冲刺中处理位衰减。虽然那时可能并不知道填充这个缓冲区的具体任务,但有一个这样的缓冲区在那里,使我们有了一个专门的空间,可以应对那些未计划的问题,如Bug,必须立即处理的小规模重构,或者我们称之为代码库自然老化和衰减的小块系统维护。

  但是,对于那些用几个小时的开发时间都无法解决的更大的问题,该怎么办?可能会有更多让我们倍感困扰的系统性问题,如基础设施故障或架构日益老化无法再满足业务需求。由于这些问题太大,不容易解决,我们就可以使用这个缓冲区确认和研究这些问题,那样,我们后续就可以在项目中给予它们应有的注意。比如,在基础设施故障的情况下,或许我们能够确定基础设施中最经常出现故障的部分,那样我们就可以在待办事项列表中增加故事,用于替换这些部分。然后,我们会在正常的开发中排定优先级并照此调度那些故事。或者,在架构日益老化的情况下,我们可以花些时间来确定,我们对于架构能够动态做出的最有价值的修改是什么,然后将那些修改分解成可以在将来的冲刺中分段处理的故事。不管问题是什么,有时间确定问题并制定计划就意味着可以像解决其它任何技术问题一样解决它。

   预算

  既然我们已经对招致技术债务的影响有了一个更好的了解,那么我们该如何真正确保偿还技术债务?为了对此有一个感官的认识,我们将上述金融比喻向另一个方向扩展……预算。

  我们中有许多人每隔几周就会挣得一份固定工资。这份工资是年度工资的一部分,全年平均分布。比如,如果我们每年能挣52000美元,那么我们可能每隔2周就会收到2000美元……就是说,每年26次。

  不过,虽然按规则我们每次都能领到2000美元工资,但我们实际上不大可能全部存放在活期账户上。相反,我们更可能只将一部分存放在活期账户上,而把其它部分用于长期投资或者偿还债务。比如,我们起初有2000美元存款,预算分解实际上可能是下面的样子:

  • 500美元用于长期投资,比如存入退休账户
  • 200美元用于偿还短期债务,如信用卡
  • 300美元用于偿还长期债务,如按揭贷款或汽车贷款
  • 250美元直接扣除,用于支付地方或国家税收
  • 剩下的750美元存入活期账户

  现在,虽然没人对这种安排感到特别兴奋,但也基本没人质疑。在某种程度上,它简直是公认的规范。既然这种安排被如此广泛地接受,那么为什么不将它扩展到我们的项目计划中呢?

  想象一下,我们正以故事点为单位计划一次冲刺,并且,我们为那个冲刺分配了50个故事点。尽管我们希望将所有50个点都用在新的开发上,但实际上,最合理的方式是安排一些点用于偿还技术债务。比如,对于原有的50个点,我们可能决定安排:

  • 10个点用于偿还技术债务
  • 5个点用于不间断的代码库维护,如修复Bug或处理位衰减
  • 35个点用于新的开发

  看看我们的点预算,我们可以看到它与我们前面描述的金融预算有一些明显的相似之处。虽然每个冲刺我们有50个点用来做事,但并不是所有那些点都用在新的开发上。更确切地说,我们必须把那些点中的10个用于偿还我们有意招致的技术债务,正如我们把工资的一部分用于偿还我们的长期和短期债务。此外,我们将5个点完全用于保持不间断的代码库维护,正如我们把每份工资的一部分用于税收,帮助维持我们社区的正常运转。剩下的点是我们自己的,可以根据我们的意愿用于任何新的开发,正如剩下的钱存入活期账户,我们可以根据自己的意愿自由支配。

  通过工作预算的方式,我们可以确保我们的项目仍然在向前进行,而不允许它在技术债务的重压之下崩溃。

  当然,就像个人预算一样,这种预算会有些偏差。比如,如果我们偿还技术债务的速度比预期快,那么我们就会有些剩余的故事点可以用在新功能开发上。而同样的,如果我们发现我们承担着特别多的技术债务,那么我们可能需要稍微降低新功能的开发速度,直到技术债务的数量回到一个更可控的水平。

   小结

  通过以金融债务做类比考虑技术债务,我们可以对什么时候会招致技术债务有一个更明智的判断,有利于项目改善。在项目进行过程中,我们还可以更好地计划试图偿还债务所带来的影响。

  而且,通过在日常工作中计划日常预算,我们可以更好地了解我们的债务什么时候是可控的以及什么时候会让我们负担过重。

相关 [技术债务 偿还 计划] 推荐:

技术债务偿还计划

- - 博客园_知识库
  许多团队都受技术债务困扰,不过,很少有团队能真正地设计一个计划从中挣脱出来. 为了更好的理解如何才能摆脱债务,我们首先要正确地理解什么是技术债务.   技术债务是由团队为了短期的项目利益故意做了欠佳的技术决策而招致的. 例如,为了使一个产品更快的投放市场,团队可能不会像面对一段棘手的代码那样,编写深入的自动化测试.

【外刊IT评论网】技术债务(母鸡的遭遇)

- - 外刊IT评论
[caption id="attachment_3749" align="alignright" width="300" caption="本文的作者 Andrea Dallera"] [/caption]. 技术债务,是指匆忙的实现一个功能,却对现有的程序库造成了破坏(在实现的过程中污染了代码库的设计),这对于一些项目经理/客户来说就像是天书奇谈.

技术债务:究竟让你付出了多大代价?

- - 博客 - 伯乐在线
技术债务背后的 隐含的意思是,走捷径(有意的技术债务)或者犯错(无意的技术债务)都会有开销,而且不处理这些捷径或者错误的话,开销会随着时间而增加. 如果我们有一个财务债务,我们知道我们今天需要还掉多少钱,我们也可以计算出我们将来需要付多少利息. 而技术债务却是模糊不清的,我们不知道我们已经欠了多少债了 – 你可能已经欠了许多无意的技术债务了 – 你也可能不知情的状况下欠了许多债.

偿还N年前的一笔技术债

- friedvan - Tony Bai
记得刚来公司时曾参与过一个项目,项目中用到了部门基础库中的一个B+树接口. 不过在程序调试过程中我们发现可执行程序总是dump core(在sparc solaris上),经初步分析,断定问题就出在B+树接口处,但一时又找不到问题原因. 还好这个B+树的实现者就坐在我的旁边. 他分析后告诉我:这个B+树接口要求用户自定义的索引结构体的size应该为4的整数倍.

oracle执行计划

- - Oracle - 数据库 - ITeye博客
所谓执行计划,顾名思义,就是对一个查询任务,做出一份怎样去完成任务的详细方案. 举个生活中的例子,我从珠海要去英国,我可以选择先去香港然后转机,也 可以先去北京转机,或者去广州也可以. 但是到底怎样去英国划算,也就是我的费用最少,这是一件值得考究的事情. 同样对于查询而言,我们提交的SQL仅仅是 描述出了我们的目的地是英国,但至于怎么去,通常我们的SQL中是没有给出提示信息的,是由数据库来决定的.

读书总结/计划

- tiger - 游戏人生
2010年读了一些书, 下面的数据都来自豆瓣, 有些书没有读完但短期内没有计划再读也标记为 读过, 而另一些书搁置了很久但希望继续读下去则标记为 在读.. Unix 技术手册(第四版 中文版). 作者: Arnold Robbins / 东南大学出版社 / 2009年11月1日 / 98. 虽然有 man, 有 info, 有这么一本放在手边的工具书, 还不错吧..

厕纸瘦身计划

- EG - 设计|生活|发现新鲜
设计师Kim Jungwoo, Ahn JoongGeun提出这一理念,将厕纸原先的每格大小减半,从而达到节约能源,爱护地球母亲的目的. 看到这突然想起成龙大哥对房祖名不管大小便都只能用一格纸的要求,想必房祖名看到这设计,会欲哭无泪. 「设计,生活,发现新鲜」在新浪微博,更即时地获读更新,更直接地交流沟通.

酸奶养成计划

- han - 果壳网 guokr.com - 果壳网
事实上,酸奶可能是地球上那些“伟大”的乳品公司所生产过的“最好的”乳品了. 其实并不是所有尝起来是酸味的奶都可以称为酸奶. 酸奶,或者说酸乳(Yoghurt),是发酵乳(fermented milk)的一种. 世界大多数国家对于酸乳奶都有一个严格的定义,使得酸奶在2个极其重要的方面区别于其他尝起来是酸味的奶:第一,它必须是由2种特定的乳酸菌菌种(保加利亚乳杆菌(Lactobacillus Bulgaricus)和嗜热链球菌(Streprococcus Thermophilus))发酵而来;第二,在消费者食用时它必须含有一定数量的活菌(中国国家标准规定,每克酸奶中的乳酸菌数不得低于100万).

WEB-DICT词库计划

- - CSDN博客互联网推荐文章
欢迎大家支持晓阳童鞋的词库计划,建立一个庞大的中文词库. 地址如下: http://webdict.info/. 什么是WEB-DICT词库计划. WEB-DICT词表计划目标是通过机器学习算法以及人工标注构建一个包含大量网络词汇的、无版权限制的中文词库,从而提高中文网络文本自然语言分析以及开源中文输入法的效果.

Oracle执行计划详解

- - Oracle - 数据库 - ITeye博客
本文地址: http://blog.chinaunix.net/u3/107265/showart_2192657.html.     本文全面详细介绍oracle执行计划的相关的概念,访问数据的存取方法,表之间的连接等内容.     并有总结和概述,便于理解与记忆!.     Recursive Sql概念.