善用技术债

01.png

白话的解释就是技术上的债务。

比如：

（1）功能已经实现，但是需要手动做很多配置的事情，不可复用；

（2）某个功能为热点功能业务上更重要，因此单位时间内对该功能的技术支持更完善，其他功能凑合能用。

（3）由于思路不严谨，导致某个功能状态为开发完成，但是其中功能并不完整。

以上 3 个是常见的技术债，类似的技术债还有很多。

技术债具有两面性：

（1）技术债带来的好处：

技术有杠杆，加杠杆，有可能带来高的ROI（投资回报率）；

有限时间内将精力用到最关注的地方；

（2）技术债带来的坏处：

技术债有“利息”，债务积攒多了会带来后序很多问题，因此需要花精力持续关注技术债；

技术债团队中默认并不是可视化的，因此容易被忽略；

技术债的还债时间有风险，管理不好会急剧降低生产力；

技术债能够为团队带来好处，同样也能为团队带来困难，因此重点是如何处理好技术债，让技术债更好的服务于团队，而不是让技术债将团队拉进泥潭。

下面整理了工作中经常使用的技术债的管理方式：

如下图：

02.png

处理好技术债的前提是先发现团队实践中的技术债，例如，

当前数据库连接池可用，但是 debug 困难；

某模块可用，但是复用困难；

发现这些技术债。团队会因为时间原因、焦点原因、事件重要度等多种因素而采用不同的策略来应对团队中出现的技术问题，选择权衡之后有所取舍，这些都很正常，重要的是意识到选择同时遗留了哪些技术债。

除了日常工作中发现的临时的技术债，还可以在 IPM（迭代计划会议）中进行估点的环节识别一些技术债，体现通过简单的分析识别技术债，达成共识有利于迭代计划顺利完成。

有些团队能够意识到团队的问题，很多时候和一线开发者聊天都能发现他们对团队的某些技术问题了解、知道，但是就是团队协作中，哪些问题不了了之了，原因有很多（有的合理有的不合理），让那些频繁出现的问题如何得到根治---- 将发现的技术债进行可视化。

如果团队使用 Jira、Trello、WorkTile 等电子看板，可以选择建立一类卡----技术债卡，将技术债详细的记录下来，就如同 User Story、Bug等卡片一样，可以选择不同的颜色标注，让整个团队都能看到这些技术债。

如果你的团队使用的是物理看板，那么选择一个颜色的便利贴来记录技术债，并在物理看板上添加技术债的燃起图等辅助可视化工具。

新建的技术债应该放在 Backlog列中，还是放在 Todo列中？

这取决于具体的卡片对当前迭代的影响，团队可以共同来确定放置的位置，比如，新添加的技术债会block 某个 User story卡，那么就放置在 Todo中，如果并不会 Block 当前的迭代任务，那么可以选择放置在 Backlog 中。

上面涉及到了简单的管理：新建技术债卡、并将技术债卡放置在对团队有利的位置。

除了这些还需要花费另外一部分精力来管理技术债。例如 IPM 时决定除了该迭代要解决的 User Story、Bug还需要解决那些技术债，以及技术债、User Story、Bug 的整体的优先级是什么。

另外如果一个技术债，在日常频繁的造成问题，那么不如停下来先将它解决点。这里可以使用“事不过三”的原则：当一个问题出现一次时可以不用关注，再出现一次时可以选择解决或者延迟解决，当出现第三次时那就停下来将其解决。

技术债有大有小，带来的收益也是有大有小，有的技术债能够解决我们的燃眉之急。

但是是债就得还。现在想想刚加入工作的时候，由于没有管理和消除技术债，及时发现技术债也不能帮助团队解决任何问题，反而被技术债消耗了越来越多的时间。

消除技术债时，可以采用如下手段：

对项目的技术债持续关注，有利于持续优化项目实施。

重点不是知道技术债的存在，而是真正持续管理技术债并在合适的时候消除技术债，让 ROI （投资回报率）最高。