从经理的角度看技术债务
英文原文：Technical Debt a Perspective for Managers
作者：Mark Levison 译者：赖勤毅 发布于 2010年11月5日
现在已经到第十次迭代开发周期了，你的项目开发速度开始变慢。在之前的几个迭代周期中，团队没有像以前那样完成很多的“故事场景”（stories）。此外，最近在新的故事场景和回溯中却发现更多缺陷(bug)。项目经理知道，团队成员没有变，他们也花同样的时间工作。但是，客户会发问：“发生什么事情了？这个团队还在努力工作吗？”
很多敏捷团队的产品改进率为150-500%，可是你们的项目看起来却貌似只有20-40%左右的改进率。这到底是怎么回事呢？在此我们找不到什么大问题；相反，只是有无数的小问题。有时，这些只是一些为了方便而使用的捷径（开发人员没有时间去清理这些修改），有时开发人员仅仅是不熟悉这中语言。还有一些问题就是，代码跟灌木丛一样凌乱，需要大幅度的修整。所有这些都属于“技术债务”。
什么是“技术债务”？
它就是“那些内在的事物，现在你不去解决，遗留下来（不干完），它就会阻碍未来开发”[Ward Cunningham]。 表面上，应用程序看起来质量很高且状况良好，但是这些问题却隐藏在下面。 QA（质量保证部门）甚至可能告诉你说，这个应用程序真是不错，几乎找不到缺陷，但是其中仍然存在“技术债务”，如果我们没有很好地管理并设法降低这些“技术债务”，那么，程序编写和维护的代价最终将会超过它对客户的价值。
技术债务就像信用卡一样，会有很高的利息率，就如同给团队留下了大量的帐务开销。这种情况下，开销将会体现在时间花费和解决问题所需的努力上面。开发团队拖延债务的时间越长，所积累的利息就越多（会额外增加很多工作），付出的成本也就越高。
另外，这还增加了实际的财务支出：开发团队处理技术债务所花费的时间，可以用在对团队有价值的其它工作上。同时，这些难读的代码引起的技术债务也让我们难以找到软件的缺陷。再且，理解代码所损失的时间还可以用来做其它更有价值的事情呢。
我们为何要累积技术债务呢？
项目编码初期，不整理代码，不写单元测试，也不做测试驱动开发，整个团队粗制滥造出更多的“故事场景”。 这些问题通常都不会马上暴露出来，而循规蹈矩地编写代码往往需要更多的时间，特别是在早期阶段。
技术债务来自哪里？
- 没有经验的开发人员 —— 有些项目里面，编写Java/C#/Ruby的开发人员没有接受过培训，或者没有面向对象的观念。结果呢，他们会一直编写适用于他们曾经习惯的编程语言——像Visual Basic等——的代码。
- 项目工期的压力 —— 那些来自于经理或客户的显性压力和其它一些潜在的压力。“我们承诺在以后迭代（发布）的故事场景中做到这些”。开发团队会发现他们不会交付这些承诺的发行版本（迭代版本），而是采取便捷的手段。“我们不得不把事情做完；我们无法承担修整代码所耗费的时间。如果这不是新特性/缺陷，那么就不用去做”。 不幸的是，这些观点还会得到管理人员的支持，特别是在管理层没有意识到这些成本的时候。
- 凌乱而难读的代码。当一个方法或类中存在一些难读的代码，下一个开发人员继续这些工作的时候，就觉得他也没有必要迫使自己编写清晰的代码。所以，每次有人接手这些代码的时候，一小段脏乱的代码将会变成一大堆乱七八糟的代码。
- 专业领域的代码 —— 往往有这样的观念：这些代码看起来就是很差劲，但是这不属于我的领域，所以我不能或不会改变它们。另外，对于修改专业领域的代码，开发人员也会觉得力不从心。
- 过度复杂 —— 开发人员经常趋向于在需求之前设计解决方案。而且，很多情况下他们的代码没有找到正确的方向，还会写一些没有用处的代码。或者，这些代码没有真正地符合需求，因为代码在问题还没有完全明白的时候就已经写完了。还有另外一种情况，过度设计花费了额外的时间，产生的代码不是不能使用就是不符合项目的需求。
- 糟糕的设计 —— 有些解决方案只是设计不佳。但在设计不好的代码上面继续扩展，而不去解决这个问题，会使问题更加恶化。
解决问题
这个问题的并不是一下子可以解决的，解决方案需要通过几个迭代周期。并且，你需要耐心，并要从多个角度寻找解决途径。
解决方案中的要点
- 让开发人员接受语言方面的基本培训并教授他们面向对象的原理，从而把他们的理解力提升至入门阶段。要想既成功又有效的话，这需要花几个礼拜的时间培训，还需要有精通这方面的人员来跟进和支持这一系列培训。
- 告诉开发人员和管理人员，当前的这些问题都是需要花费企业资金的。这点尤其重要，因为它会使解决这些问题的意义更加明确。你要清楚地告诉他们，管理人员会重视这些问题，并且已经开始着手偿还这些技术债务了。不断支持这些工作使之成为常规的原则之一，这样整个团队就会信任这个准则。
- 提供一些培训，包括代码的坏味道，重构，单元测试和测试驱动开发等。还可以结合课堂会议，基于网络的材料和书籍来进行培训。
- 在工作的时候，给他们一些空余时间去研究和练习他们的技能（一个礼拜两个小时应该是达成这个目标的最小的时间量）。练习的代码应该被丢弃，这样，他们就能无拘无束地尝试和试验一些事情，不管怎么样，他们不用在基础代码库上面进行练习。花点时间练习和研究应该是最有用的建议了。假如没有为他们提供空闲的时间，就压根不会发现真正合理的敏捷开发方式。这种组织方式也被称为“道场”-Dojo（更加详细的资料可以参考 TDD Randori Session 和 TDD Randori Workshop）。
- 使用工具（静态分析，单元测试，持续集成，自动化可接受性测试）来帮助团队发现、减少和衡量他们的技术债务量。应该在团队层面利用这些度量数据，而不能分享给管理人员。团队成员需要知道，他们并不会因为对这些技术债务的度量而接受奖励或者遭受惩罚。如果我们把这些度量数据报告给管理层，并由管理层来追踪的话，开发人员很快会找到一些窍门来规避它们，这样就失去了本来应有的价值了。
- 当人们完成了他们的培训或者在技术上取得了少许提升时，应该得到奖励。奖励可以是给予一次认可的表彰或者是一些小小的礼物，但不要直接给予现金奖励。
- 每两个礼拜进行一次午餐聚会和一些关于技术方面的学习型会议。利用这些会议来促进开发成员之间的讨论。提供午餐可以提高参会人数。另外比较重要的是需要管理人员每次都来出席，这样就很清楚的表明他们也一直支持大家提高技术。
- 维护关于技术债务的备忘录 – 任何时候，如果开发人员发现一些无法立即应付的技术债务时，就需要填写一份技术债务登记卡。开发人员应该优先考虑这些技术债务，并花费10-15%的精力来偿还这些技术债务。大多数项目中，任何的一些小事都会使问题变得更加严重。
基于这样的立场，你会发现问题，也会拥有机会。你的问题是：项目的基础代码一直在积累技术债务，但是这些债务已经开始下降了。然而，现在跟客户申请用于处理这些问题的资金会跟处理这些问题一样困难。你的机遇是：提高了开发人员的技能；清楚地表达了管理层对这项工作的支持，还有，软件的代码质量会不断改善，软件缺陷的数目也会不断减少。同时这也会很好的提高团队的整体开发能力。
