技术债务距离我们有多远？

当我们看一些国外的技术文章时，经常会遇到“技术债务”一词。初闻之时，感觉特别地高大尚。但技术债务究竟指的是什么，却是觉得云里雾里，似乎它离我们的软件项目还很遥远。

直到我看到丛斌博士给出技术债务来源示例，我才发现，原来技术债务距离我们并不遥远。

丛博士给出了以下几个常见的债务来源：

• 由于进度原因主动裁剪掉工程实践带来的技术债务。这在我们实施GJB5000的组织也是屡见不鲜。系统设计师迟迟不给任务书，等到任务书下来的时候，距离系统联试的时间只剩下1个月，软件开发人员不得不简化很多评审、测试的活动，因此在软件中留下了诸多隐患。

• 不当设计带来的技术债务。软件开发人员没有理解业务需求，草率地选择了某个设计方案，到了后期确认的时候才发现问题。

• 不当修改代码带来的技术债务。软件开发人员在修复缺陷或优化代码时，改一漏万，由此造成软件产品中的不一致或引入新的缺陷。

• 没有做好需求分析带来的技术债务。软件开发人员在没有分析清楚需求的情况下就开始编码实现，导致实现的软件不符合用户期望。

• 没有评审或者评审的绩效很差带来的技术债务。评审是优秀的软件工程实践，它能够以较低的成本改善软件的质量。不做好评审，就等着后期债务上门吧。

• 不写技术文档或对技术文档应付了事带来的技术债务。如果没有一个表述清楚的需求文档，后期软件缺陷的定义和排队都会出问题。

这样看来，技术债务对于我们实施GJB5000的组织来说，它也是真实存在的，时常在我们身边出现。

从上面罗列的技术债务的来源可以看出，技术债务所以出现，实际上还是我们没有严格执行GJB5000A的软件体系造成的。如果我们都能按照GJB5000体系的指导来组织软件项目，上面的技术债务都可以避免。

比如，对于由于进度原因而裁剪工程实践带来的债务来说，它首先是项目策划出了问题，没有给软件开发预留足够的时间本身就有很大的问题。另外，对生命周期模型的裁剪不能太随意，要让专家来评判裁剪的合理性。另外，当进度和工程活动冲突的时候，是不是应该作为重大决策引入DAR？

总之，技术债务距离我们并不遥远。为了避免技术债务带来的可怕后果，我们要充分地运用GJB5000的各项实践来管理软件项目。

这正是：

技术债务不遥远，时时刻刻在眼前

严格执行五千A，预防债务少风险

参考书目：知行合一：实现价值驱动的敏捷和精益开发，作者：丛斌，出版社：人民邮电出版社

作者简介：王小双，长期从事GJB5000推广、实施、评价、改进的工作，创建《软件工程之思》微信公众号，一直在《软件工程之思》分享GJB5000、CMMI、软件工程的知识和感悟。现致力于GJB5000咨询以及软件过程改进、软件工程能力提升的研究工作。