翻译(5): 技术债务墻：一种让技术债务可见并可协商的方法

原文：

翻译：

0x01 介绍

术语“技术债务”(Technical debt)，是对软件设计中那些次优的、不再有效的、甚至错误的设计选择的隐喻。它们增加了软件进一步开发的成本。出来混的总是要还的，你今天选择的临时或山寨做法，将会在明天拖你的后腿，直到你修复了对应的问题，“偿还了”债务。技术债务并非都是代码：构架、文档、测试、以及领域模型都可能欠下技术债务。

问题并不是技术债务本身，而是未经管理的技术债务(unmanaged technical debt)。任何一家公司的CFO都精确地知道有多少财务债务(Financial debt)。他们拥有债务表格、季度报告、支付计划、以及再融资或出售债务的选项。但是如果你问一家公司的CTO，他所在的组织有多少技术债务，你会得到吞吞吐吐的回答：“额，...挺多的吧？”

技术债务墙(Wall of Technical Debt)是你办公室里的一个平面，你可以在上面用便签纸把技术债务一个个贴上去，所有人都可以看到它们。这很容易开始并且维护，然而我们如何选择增加、减少、偿还、甚至忽略技术债务都会产生深远的影响。它当然不是技术债务管理的完整的有伸缩性的方案，但是它恰好能用(it works)，因为它不需要买什么东西。

0x02 如何构建技术债务墙(How to do it)

很简单：让债务可见、建立习惯、定期协商，并且放弃控制。

图片来自twitter:Pim Elshoff，以Creative Commons Attribution 4.0 International License授权。

0x03 让债务可见(Make it visible)

  1. 选择团队办公地的一面墙。
  2. 保证它最大限度公开可见。
  3. 命名这面墙为“Wall of Technical Debt”。
  4. 画一个好玩的Logo.
  5. 保证旁边有足够的N次贴和记号笔。

0x04 建立习惯(Build a habit)

  • 每当你在工作时：
    • 思考债务问题：是什么让你变慢了？是什么让代码变得难以理解？是什么导致了BUG难以跟踪？哪些部分应该有更好的文档？哪些部分应该有更好的测试？然后在便签上记下你所遇到的技术债务。但是要保证事后你知道自己写的是什么。
    • 估计机会成本：如果这些问题不存在，你可以花在其他事情上的时间有多少。把你的估计写在便签上。商定好时间标记，例如计数符号(Tally_marks)或每个点表示半天。相对于时间估计的精确度，更重要的是让机会成本估计本身被团队成员所知道，遵循可见性大于精确度的原则。
    • 估计修复时间：需要多久修复这个问题？同样的需要在便签上写下这个估计。
    • 考虑怎样修复：可选的，你可以写下怎样才能修复该技术债务。你可能会在一个issue管理软件里跟踪该问题的修复，写下issue管理软件里对应的ID。
    • 最后，把便签贴到技术债务墙上。
    • 每当有人碰到同样的问题，添加更多标记，累计损失的时间。

记住：每当你引入了一个技术债务的时候就应该自觉添加一个技术债务便签。对自己诚实，这没什么好羞耻的，因为你并不是你写的代码。

记住：技术债务是一笔投资，不是一次犯罪。----除非你在隐藏债务，那你就是在-烧书（cooking the books)-。

译者注，小节参考，西文/中文计数符号：

0x05 定期协商(Negotiate)

随着技术债务的增加，组织中会有人开始有一点点焦虑。这没关系，债务总是在那，你只是让它可见，并希望一些习惯开始改变。

无论何时，如果有人给已存在的债务便签上的时间记号增加一个点，就应同时和团队讨论该技术债务。比较该债务上已经浪费掉的时间和预估的修复它所需要的时间成本。当然，你可能需要花一天时间修复它，但是相比于你每周都要在这上面浪费两个小时，你很快就回本了。又或者，它并不值得你去修复。技术债务再也不是一个审美问题或观点问题了，而是一个经验收集的指标问题。恭喜你，你们作为一个团队协商，并取舍(tradeoffs)。

无论何时，如果有人添加了一个新的技术债务贴，并覆盖了一个已发现的债务，考虑一下是否是时候修复问题了。但是让技术债务继续呆在墙上也毫无问题，那就是它应该呆的地方。没有证据显示该债务会让你继续付出成本？那就让子弹飞一会儿，从现在开始收集更多的点。

然而，当你引入了一个新的技术债务，那是不同的。考虑一下团队是否可以对临时做法或山寨做法说不，立刻就修复它，并且保持最小代价。我们不应该问：“我们有时间吗？”，而应该问：“这个债务是否值得延后关注？代价多大？”。答案应该在“没关系，就提交这个债务吧”到“很多事情都依赖它，在继续前进之前，让我们干掉它”之间。

关键不在于解决所有的技术债务，关键在于学会协商什么时候添加、修复、以及规避技术债务。在此之前，这些通常都在看不见的地方发生着，团队中的成员在不知道全部细节的时候，默默添加或修复技术债务。而现在，集体的智慧加上真实的数据，在发挥力量。

0x06 放弃控制(Give away control)

现在，是时候展示我们的魔法了。因为技术债务墙是如此的可见，管理者应该开始注意到了。（如果他们还是没注意到，那就用红色加粗字体添加一些 € 或者 $ 符号到墙上。毕竟钱是通用语言，并且亏钱两次是令人肉痛的。）

当一个团队申请时间解决技术债务时，并不能直接看到商业上或者用户可获得的收益。一个管理者就没法判断这些技术债务修复是重要而关键的？或者仅仅是为了使用最新的技术？又或者是为了把代码写漂亮？即使是有着深厚技术背景的管理者，如果他们不是直接去看代码，他们也无从判断一个技术债务的修复是否重要。

但是有了技术债务墙就不一样了。现在，它不再是一个观点问题；不再是一个编写优雅代码的工匠者的欲望；不再是关于解决难题的挑战。现在，它是事实，数据，债务和投资，以及投资回报。你开始讲管理者的语言。好的代码做为资产，坏的代码做为负债。他们被训练成：看数据、做出决策；他们开始学习这些方法：CBA，OODA，PCDA，SWOT。([1],[2],[3],[4])

放弃控制。管理者知道更多关于公司的策略、预算和风险。让他们在你的帮助下做出决策，哪些应该修复，什么时候计划等等。真实的数据足以支撑这些决策。

译者注，小节参考：

0x07 提示和陷阱(Tips and Traps)

不要从对代码的全面审计开始管理技术债务。你当然可以花好几天识别所有的债务，但是这样你就开始花钱、安排日期、从而也就把事情搞大了(making it a big thing)。“我们会在夏天做”或者“在这个大项目结束后”或者其他任何相对于“永远不做”来得委婉的词，都是可接受的。今天在贴到墙上的一张便签，带来了今天的价值。你总能延后做一个大的审计，就是不要让它成为瓶颈。

缺了计数标记或者点号代表实际消耗的成本，我们就躲在了观点后面。某些干扰你的事情，也许并不会对未来的开发产生实际的影响，但只在你开始运行它们的时候才会带来问题，你的技术债务墙将会记录实际浪费的时间，而不是一些感知的质量。你需要建立一个协商债务的习惯，而不要回到老路子上做单方面的努力。

它使用另一种方式产生效力。如果你碰到丑陋或奇怪的代码，但你没有在上面失去时间，那就不要标记它。我们不是在测量你是否喜欢它，只是在测量它消耗的时间。

不要忽略心理上的墙。抵抗把所有事情都使用数字化并使用BUG跟踪软件管理的欲望，日志和指标只在人们看它们的时候有印象（译者注：所有issue管理软件都依赖人主动打开去看，例如需要项目管理者定时汇总并在通信工具里发送以保证可见性）。数字工具更容易隐藏事情。债务墙则是可见的，扑面而来的。

0x08 结论

在阅读了我（译注：指原文作者@mathiasverraes）在2013年的博客后(译者注：参考下一节)，一家创业公司引入了技术债务墙。它们是一家很小的公司，并且所有的墙壁都已经被用来展示商务计划和App原型来。它们把技术债务便签贴到了公司里一面玻璃窗上。于是有一个笑话是：如果房间开始变的太暗，大家就知道是时候解决技术债务了。更重要的是，他们曾被完美主义和临时方案之间以适应快速的市场变化所困扰。技术债务墙帮助他们打破了困局，从而很快地运转了起来。我们听到很多成功使用技术债务墙的团队故事，也许你也可以。

0x09 致谢

这篇文章是为“Visual Collaboration Tools”而写的，这是一本由 Kenny Baas-Schwegler 和 João Rosa 编辑的书。它松散地基于“Managed Technical Debt”, Verraes 2013.([1]) 这篇文章而写。感谢Indu Alagarsamy 和 Rebecca Wirfs-Brock
对稿件的审校。

译者注，小节参考：
[1] Managed Technical Debt:We should make a distinction between Managed and Unmanaged Technical Debt. Published on 21 July 2013 by @mathiasverraes

--end--

posted @ 2020-02-11 09:26  ffl  阅读(657)  评论(3)  编辑  收藏  举报