如何处理团队的技术债务

---

 

写在之前：

        今年年初给自己安排了一个任务，每个月写一遍感悟性的文章。促使自己沉淀并思考。 回望自己在软件行业的经历，总是感叹如果早知道某某事情多好。这篇文章主要写一些建议，如果这边文章有幸被你看到， 希望对你有帮助。

---

        沃德砍宁汗 （Ward Cunningham ） 是一位著名的计算机程序员，也就是上图的和蔼大爷。他之所以闻名是对“面向对象程序设计”的开发实践的贡献。他对模式研究和极限编程有很大影响，他还是wiki概念的发明者并建立了第一个wiki网站，并且他还是敏捷宣言的合著者。

1.什么是技术债务

      技术债务在过去几年中成为了一个开发团队的流行术语。它指随着时间推移，代码变得越来越差和系统设计变得越来越“粗糙”，这些问题让对代码或者系统做修改变得越来越困难。 技术债务这个词来自沃德砍宁汗（Ward Cunningham）的比喻，他首先提出了这个词并将其比喻成金融的债务，因为这些问题会像金融债务的利息积累一样， 如果我们不偿还，债务会越积越多， 并会对新功能甚至维护产生影响

2.技术债务带来的危害

       我们在设计和构建系统的时候为了短期的项目利益做了欠佳的决策，比如为了产品更快的投放时间，面对Deadline,团队有意或者无意降低代码质量， 即使团队一直关注系统设计保持最贱的设计编码实现，但债务也不能被避免。比如系统及其子系统都在不断的发展，几年前的完美解决方案已经不在适合当前的系统

        随着系统中的技术债务越积越多，很多危害就陆续显示出来， 上图直观显示公司的几条生产线一年内Bug数量，这反应出当系统升级后各个子系统总会产生大量的Bug，这就需要投入大量人力资源来处理。 这些投入就是偿还的债务

• 客户：系统运营不顺利，新需求不能及时上线。对系统信心下降
• 运营：不合理的界面设计、文档缺失、系统响应慢，常出现BUG影响系统运营
• 运维：频繁上线修复BUG的补丁，来自客户抱怨越来越多
• 研发：一边维护他人遗留的问题代码，一边在此基础上开发新需求并创建新的问题
• 管理层：各方的抱怨让管理层崩溃，BUG越来越多、项目又延期无法交付

3. 如何正确沟通技术债务

        团队存在大量技术债务的主原因是没有意识到其的危害，或者团队成员发现了危害但是没有正确沟通。开发人员大多数情况下不需要说服开发人员解决当前的技术债务，实际上他们很乐意来做这些事情。

       项目经理往往关注点在项目的工期和成本，增加偿还技术债务的工作会延长项目工期，减少技术债务对他来说是微不足道的事情。产品经理往往的关注点在于产品本身，而不会关系某个实现的实现方式是否合理。和他们讨论偿还技术债务我的经验是以利益驱动， 将技术债务与外部客户以及产品联系起来。比如：“这项任务花费时间很短，完成后却可以提高以后迭代的交付速度”，“这几项任务完成后可以提高XX速度，给客户更好的使用体验”等。

        当然沟通过程中最好有一些内容来支持自己的观点， 比如数据、图表来表示某几项任务对软件产品的改进情况，测试范围以及债务任务的预估工期能促使项目经理认真考虑你的建议,我一般从以下几个方面尝试说服他们

• 很难理解的代码会降低开发速度，团队成员投入大量时间和经理，但是新功能让然有很多新缺陷，这些缺陷也很可能是严重缺陷
• 在不是很好的架构上实现一个解决方案是很困难的，这会影响新功能提交速度
• 在正在实施的软件项目中， 如果在不合理的设计方案上修复原来系统问题并开发新问题，通常会增加系统的复杂性。甚至增加更多的技术债务。这是一个恶性循环

4.如何处理技术债务

         当我们了解到技术债务的危害并且想要处理它时，首先要做的事情是先整理并排序

        许多团队都会有积压任务，这些积压任务可能是产品的某些改进，也可能是某些技术改进。被积压的原因一般是因为时间关系，或者这些任务短期不重要。 如果没有一个待办列表， 那么他们真的会被“有意”或者“无意”的遗忘。此时，应该保留一个待办事项列表，并将这些任务添加入列表并标记技术债务，并将这些积压任务放在一起排序，工作中持续安排这些任务

        当整理处理技术债务列表后，需要持续解决它们，一般团队按照以下方式来处理

• 团队将sprint时间按照一定百分比来处理不同工作， 一个常见的设置是70%用于团队的项目工作， 20%用于技术债务，10%用于学习或者实践，这种方式很难处理一些比较大的技术债务，因为20%的时间可能不够
• 团队每次sprint中解决固定数量的技术债务，因为是按照数量分配，很难平衡技术债务时间和项目时间

---

前一篇：高效程序员10个习惯感触随笔