软件项目定制开发的技术债务是如何产生的？

软件项目定制开发通常会有两种开发方法：MDD模型驱动开发和TDD测试驱动开发。这两种方法可能会交互使用，通常情况下，使用合适的、恰当的MDD模型驱动开发可以消除和降低技术债务，而不恰当、错误与过度抽象的MDD模型驱动开发则会恶性增加技术债务，TDD测试驱动开发一般会良性地增加技术债务。

一般由TDD测试驱动开发，MDD模型驱动开发，TDD测试驱动开发，MDD模型驱动开发......这样交替运营可以通过良性增加技术债务来贴近真实需求和模型重构来消除良性技术债务。跳过TDD测试驱动开发的MDD模型驱动开发一般会增加大量恶性技术债务，而跳过大量MDD模型驱动开发的TDD测试驱动开发则会使得大量良性技术债务积累并培育成恶行技术债务。

软件项目定制开发通常会以项目成员与涉众当前对项目目标、需要、范围、风险、质量、预算、人力、资产、能力等方面的初始认识做出一个初始的项目计划及项目工作结构分解，采用MDD模型驱动开发的方法按照计划执行完成项目来得到一个可运行的初始版本软件。这个过程通常会持续1~2个月。

MDD模型驱动开发更多地是采用瀑布开发模型，只有完整的模型雏形完成后才能成为一个可运行的软件执行其中特定的业务逻辑。MDD模型驱动开发是一个自上而下的方法，需要领域背景知识和模型框架支持来做分解和计划。如果使用敏捷迭代的方法，通常一个迭代周期需要1.5个月来完成一个完整的模型实现。MDD模型驱动开发可以快速、高效和有效地建立初始框架雏形，但是交付结果一般非常粗糙。

TDD测试驱动开发和MDD模型驱动开发相比会更敏捷一些。TDD测试驱动开发首先需要设计许多详细的测试用例。TDD测试驱动开发可以使得一个迭代周期小到一个测试用例的尺寸，但是在实际的商业场景中还需要考虑项目管理和环境切换的成本，更短的迭代周期使得项目管理和新增的环境切换成本高于长迭代周期的项目运营。考虑到这些因素，一般推荐TDD测试驱动开发采用2个星期至1个月的迭代周期正常配置。一周或者更短的迭代周期只适合特殊情况下临时的应急补丁和客户演示。

在软件项目定制开发中，试验样品和原型可以成为或者合并到最终交付物中或者敏捷迭代开发方法TDD测试驱动开发的初始输入，有些试验样品和原型会演化和优化，有些则会随着它们的技术债务一起被丢弃。通常试验样品和原型经过几个迭代周期的迭代会演化为实际产品功能交付物，在演化的过程中随着软件需求的冻结逐渐稳定。如果在持续演化的过程中软件需求不能冻结并且仍然在持续不断地输入进来，新的不稳定的试验样品和原型也会随着新增的软件需求合并到软件交付物中，导致软件项目定制的技术债务不断增加。

耦合性是一种技术债务，在正常的公司运营和软件开发中通常都有一个资产负债表：资产(软件特性和功能)=股权(对软件资产的控制权既可控性)+负债(技术债务)。试验样品和原型是一种在预算资源和时间日程有限的情况下短期通过增加资产负债表右端的技术债务来快速增加资产负债表左边的资产(软件特性和功能)的软件项目定制融资投资的操作方法。这样可以快速和低成本得到一个可以工作的软件，但是它的可控性和可操作性有限和不太理想。

技术债务通常还来源于多个不同地方，比如：

(1).领域流程知识的缺乏和误解

(2).软件依赖数据接口设计和知识的缺乏和误解

(3).软件内部依赖数据模型设计和知识的缺乏和误解

(4).软件输出数据接口及格式的设计和知识的缺乏和误解

(5).软件与用户交互设计和知识的缺乏和误解

(6).软件与第三方系统或者依赖环境交互设计和知识的缺乏和误解

(7).项目管理领域的知识和经验的缺乏

(8).不稳定和正在发现阶段的需求

(9).软件设计、编程、测试和沟通方面的知识和经验

(10).系统集成方面的知识和经验

针对上述的大多数资产(软件，经验，功能，特性，需求，使用知识，文档)，通常都有这样的资产负债表：

资产(数据结构，数据关系，业务逻辑关系，概念，需求，部件，文档，软件，代码，数据，测试用例，使用方法等)

=

股权(知识，知道懂得的，懂得如何做，有经验的，设计足够的，文档编档的，完全跟踪记录的，沟通足够好的，用户友好的等等)

+

负债(不知道的，未设计的或者过度设计的，未工程化的或者过度工程化的，未沟通，无法沟通的，没有跟踪记录的，用户不友好的，重复的代码，耦合的，模糊误导的，大规模的文档，很难读懂的文档，重复和令人困惑的表达[比如没有更新的文档和持续更新的代码之间])

敏捷迭代方法更像是短期内受制于有限的股权而主要通过增加资产负债表右边的负债来快速增加资产负债表左边的资产，其中使用TDD测试驱动开发通过扩张资产负债表来开发更多资产。后续再使用瀑布、例行流程或者固化的工作流通过仔细和系统的方法，在保持左端资产不变的情况下操作资产负债表右端，逐步降低负债并增加股权。这样通过修复资产负债表到一个更加健康的状态结构，为下一轮资产负债表扩表做好准备，或者仅仅是通过减少技术债务来降低后续运营成本(技术债务导致的固定成本现金流支出)。

同时还有另外一种针对试验样品和原型的操作，用户可能根据在使用软件之后的经验反馈最终决定放弃这些资产(功能特性)，这时这些技术债务(负债)也随同试验样品和原型一同放弃，这样将负债转换为股权操作的成本可以节省下来。

当使用MDD模型驱动开发将一种形式的资产(比如，数据表单设计Excel案例模板)转换成另一种形式的资产(比如，软件的源代码)，它们的资产负债表(资产=股权+债务)也同时被转换。理想情况下，最好的转换操作结果是在去除新形式资产的增值之后，新形式的资产和旧形式的资产总量一样，新资产的股权会小于等于旧形式的股权，新形式的负债会大于等于旧形式的负债。但是在实际的商业案例中，考虑到转换损失，比如过程中的误解，一般新形式的股权会远小于旧形式的股权，新形式的负债会远大于旧形式的负债。

使用TDD测试驱动开发来针对新形式资产可以增值的功能特性增值使得新形式的资产远大于旧形式的资产，有的时候也使得新形式的股权增值大于旧形式的股权，并且有的时候也同时使得新形式的负债远大于旧形式的负债。这个时候可再次通过MDD模型驱动开发在保持新形式的资产不变的情况下来将新形式的负债转换为新形式的股权，来修复资产负债表到一个健康的水平。

在进行上述各种复杂的资产负债表操作的时候，就需要一套跟踪操作与审计的系统，来保证在将债务(负债)转换为股权的过程中不影响到资产。