每周总得有点思考。
朋友圈看到个挺有意思的标题
“假如彩票中了一百万,能还清技术债吗?”
我仔细想了下,可能还真的还不了(手动狗头)。
一般来说,我们应该怎么偿还技术债呢?
当然,现实情况,线上故障往往是技术债偿还的第一驱动力。。。
技术债这个东西,只要业务还在运行,我相信 “永远还不完”。
一方面,业务迭代为先,很少有时间和资源投入偿还历史技术债。
另一方面,业务迭代过程中,总是会因为各种妥协,引入新的技术债。
所以从这两方面来看,技术债都是永远还不完的。
管理技术债最有效的方式:
让技术债可见。
如何做呢?
原则一:创建一个专门的技术债清单,清晰地列出每一项技术债。
团队成员在发现新的技术债时,可以随时将其添加到技术债清单中。
技术债清单的形式可以因团队而异,例如使用技术债白板贴在墙上或使用便利贴或卡片记录在白墙上。
原则二:将技术债纳入缺陷管理系统,与其他功能BUG一同记录。
这样,开发团队在解决功能BUG时,能够时刻关注技术债的存在。
原则三:为技术债创建产品待办项,确保其参与每个迭代的需求排期。
每个技术债的待办事项,应该具备明确的优先级与风险说明,在每次敏捷迭代计划上,需要跟其他需求、BUG一起评估优先级,决定是否放入当前迭代。
通过以上原则,我们可以有效地让技术债可见,并确保开发团队时刻关注和考虑技术债的解决。
偿还技术债的时候,也有一些方式方法可以参考,来最大效率、最低成本偿还技术债。
原则一:不再迭代的产品,一般不考虑技术债。
行将就木的产品、一次性原型、不再迭代的产品,任何额外的开发工作都是浪费,更不用去考虑偿还技术债。
原则二:难啃的技术债,尽量“分期付款”
在某些产品中,技术债的难度非常高,历史包袱非常重。
团队要一次性付清所有的技术债难度很大,就可以采取“分期付款”的形式。
我们可以把技术债拆分为更小,更容易修复的一个个的小问题,像偿还房贷一样,每个月都去偿还一部分。
每次迭代开发需要承担多少目标技术债,由整个开发团队在迭代计划会议上协商解决。
原则三:尽量和产品迭代结合,顺势而为。
将技术债的削减工作与客户有价值的需求结合在一起,有利于产品负责人合理安排需求的优先级。
这样可以确保在开发过程中同时考虑技术债的解决,以及满足客户需求,提高产品的整体质量和用户满意度。
当然,我们也能通过这个原则来甄别技术债,避免浪费时间去清偿实际不必要的技术债。
希望真的能中一百万彩票,我就不用去还技术债了~~
往期热门笔记合集推荐:
原创:阿丸笔记(微信公众号:aone_note),欢迎 分享,转载请保留出处。