敏捷迭代几乎总是围绕着将在短时间内建立一组特性来定义。以各种各样的方式描述这些特性——我最喜欢的是用户故事——但它们几乎总是以应用能干什么这样的一些简单描述告终。这种对于软件开发“能干什么”关注本身就源于敏捷开发能持续交付可工作软件的原则，这引起了确实能工作又使客户满意的软件解决方案的迅速出现。这个好处可能是敏捷软件开发最显而易见：相比于其他典型的软件开发方式，客户能够对软件开发更快，更频繁地观察并重新予以指导，尤其是对其中前期负担较重的分析和设计。

　　一些敏捷开发实践者——可悲的是，一些敏捷开发的指导员也是如此——会犯下过分专注于个别某一条敏捷开发原则的错误。他们忽视了敏捷软件开发中其它非常重要的方面，特别是：

　　•可持续发展

　　•需卓越技术和良好的设计的关注

　　•像在团队中一样定期地自我反省

　　忽视这些敏捷原则对于每个用迭代模型建立的工程会产生严重的负面影响。如果不处理，这种影响将会增长到它变成一个用短迭代持续开发的重大障碍。

　　有两种“迭代短视”的症状，就是主题专家失控的技术债务的滥用。下面我们看看这些问题和以及你可以采取的克服他们的步骤。

　　技术债务正在失控

　　这个问题最常见的症状是项目团队中一直增长的“技术债务”的意识。技术债务通常以一种不祥预感的开始，就是感觉有很多的“废物”需要“清理”。追溯是一个发现技术债务的良好接触点，因为开发人员，测试人员和项目经理常常会这样说“我很高兴我们推出了X特性，但是我们要是有更多的时间这样做就好了。”

　　越来越多技术债务的另一个迹象是对需要有效重构的现有代码过高地或爆炸式地估计。当真的难以强制现有代码转到一个新的方向时，可能是由于过早地采取了捷径或者因为你害怕你将打破它，那么你就已经发现了技术债务。

　　对于技术债务你应该做些什么？你应该做的事情和是信用卡债务一样的：尽量避免它。如果你已经欠下债务，那就要还清。

　　以下是如何避免技术债务：

　　•直到所有合理的自动化测试都到位，否则代码永远不会结束。

　　•每天至少运行一次你的测试代码，最好每次改变的代码都提交。

　　•切勿让坏掉的构建滞留超过几分钟。当构建失败时——即在代码提交之后你的一个或者多个自动化测试案例没有通过了——马上去修复。

　　要摆脱债务首先需要了解你是如何卷入这笔债务的。是开发人员懒惰，进度压力或是愚昧无知的结果？无论是什么原因引起的，修复缺陷都需要你为偿还技术债务划出时间。把它纳入日程表中并行动起来——利用这段时间写你需要的测试，清理旧代码，否则就删除让你彻夜难眠的问题。