我们不可能永远都在救火 ——Scrum 中技术债务“偿还”指南

查看 95|回复 7
作者:doudou456   
技术债务是指开发人员为了加速软件开发,在应该采用最佳方案时进行了妥协,改用了短期内能加速软件开发的方案,以至于未来给自己带来额外的开发负担。
软件工程师 Ward Cunningham 首次将技术的复杂比作为负债。 简单来说,技术债务类似于金融债务,软件开发就像是去银行  “贷款”,而技术债务就像是贷款的“利息”。“利息”是需要以未来额外的时间来偿还的,所以重构才相当于支付“本金”。
表面上,软件的应用程序看起来质量很高且状况很好,但是这些问题却隐藏在下面。如果没有很好地管理并设法降低这些技术债务,那么程序编写和维护的代价最终将会超过它对客户的价值。
这些技术债务到底是从何而来?为什么某些团队在 Scrum 开发过程中会导致技术债务的积累呢?我们该如何解决技术债务呢?
一、 Scrum 环境产生技术债务的原因
为了满足 Sprint 冲刺目标、发布功能和不断变化的需求,开发人员可能会更加关注短期收益,而忽视长期代码质量和可维护性。 因此,开发人员会在必要的修改没有完成时就匆匆发布,权宜之计在不知不觉中就产生技术债务。
技术债务会导致 Scrum 团队产生生产力下降、代码质量下降、项目风险增加等多种影响。 虽然在下一个迭代中偿还技术债务是可行的,但团队需要关注每个迭代的新需求,不可能永远都在救火。
那么我们该如何偿还技术债务?或者该如何避免产生技术债务呢?
二、技术债务如何还债
在 Scrum 环境中,偿还技术债务是一个重要的任务,以确保软件的可持续发展和质量。下面是一些偿还技术债务的方法:
  • 识别技术债务

    首先,团队需要识别和记录技术债务。这可以通过代码审查、静态代码分析、系统性能监测等方式来发现潜在的问题和改进点。技术债务可以包括代码质量问题、未完成的任务、过时的技术选择等。
  • 优先级排序

    一旦技术债务被识别,团队需要对其进行优先级排序。这可以基于影响业务价值、风险和复杂性等因素来确定。团队可以与利益相关者协商,以确保优先处理对业务和用户最重要的技术债务。
  • 制定计划

    根据优先级排序,团队可以制定一个技术债务偿还计划。这个计划应该包括具体的任务、时间估计和分配给团队成员的工作量。团队可以将这些任务添加到产品待办列表中,并在每个迭代中分配一定的时间来处理技术债务。
  • 项目结构化

    减少技术债务的有效方式之一是通过更好地构建项目来最大程度地减少技术债务。使用项目管理工具(如禅道)可以帮助团队跟踪开发状态,保持进度,并提高团队的整体协作效率。
  • 自动化测试

    在偿还技术债务的过程中,团队可以优先考虑编写自动化测试来确保代码的正确性和稳定性。自动化测试可以帮助团队及时发现和解决问题,并减少未来的技术债务积累。
    禅道团队自研了开源的自动化测试框架 ZTF 和通用数据生成器 ZenData ,加上禅道项目管理软件构成了专业的自动化测试解决方案,可以帮助用户实现规模化自动化测试,提升测试效率。
  • 分配固定重构时间

    重构相当于贷款需要偿还支付 “本金”,所以 每个 Sprint 中分配固定的时间进行重构。这可以是若干小时数、若干故事点数,如一个团队可以为重构预留 30 个小时、4 个故事点等。在 Scrum 环境中,持续改进是一个核心原则,只有定期回顾和评估偿还技术债务的进展,才能够一定程度上避免技术债务带来的消极影响。
    通过遵循这些策略, Scrum 团队可以有效地管理和减少技术债务,从而产生更高质量的软件产品并提高团队生产力。
    三、写在最后
    正如电影《无间道》所说 “出来混,迟早要还的”,技术债是无法避免的,只是产生技术债务多少的问题,但如果不及时处理技术债务就会产生破窗效应。 团队欠下太多技术债务,必然导致影响后期的代码质量下降,这也会间接影响到完全没有关联的其他用户故事的研发。
    因此,从现在开始把偿还技术债务纳入待办事项中,把避免产生技术债务作为工作准则!

    债务, 技术, Scrum, 偿还

  • tikazyq   
    将技术债保持在可控范围内,最开始就要在开发团队中养成好的习惯:
    1. 代码规范( Coding Standard )
    2. 自动化测试( Automated Testing )
    3. 代码审查( Code Review )
    4. 健康迭代速度( Healthy Velocity )
    否则,就会导致屎山、加班、甩锅之类的有毒文化
    42joker   
    更可悲的是,新入职的员工就要面对这些屎山,最后还要被负责人说跟不上进度
    wu67   
    说的这一堆, 是针对有规范、团队有足够人手、老板对技术有一定程度的认知和对重构耗时有一定程度的容忍的前提下的说的, 不然还不如提桶跑路来得快, 公司活不活得了那么久还不一定
    maggch97   
    赚钱就能解决所有问题,没见过哪家公司是被所谓技术债拖累死的。
    shyrock   
    写这么多还是在考虑怎么擦屁股,为什么不是从根本上解决导致债务问题的非理性冲动和妥协呢?
    就算形势所迫必须妥协,也应该列入待办工作,而不是时候再来识别债务吧?
    jones2000   
    只要项目能持续盈利, 前期技术债务在多也不怕。 业务模式跑通,重新招一波人重构都没有问题。 务实才是最重要的。整一堆流程,有什么用,不赚钱就是不赚钱。
    twofox   
    楼上说的太轻松了,技术债是无可避免的
    一行代码写下去的时候,你认为它可能会在将来会成为技术债,那它 99%的可能会成为技术债
    但是你觉得成就满满,认为自己的代码写的精炼、健壮,简直完美无瑕了的时候,这部分代码以后就不会成为技术债的一部分吗?
    不是,随着业务发展,可能回过头来看,这部分代码不够灵活,不能满足业务需求了。但是耦合度已经太高了。
    你改起来很麻烦,这就是技术债
    实际情况更多是,进度催得紧,代码敷衍一下吧,以后优化
    新技术没用过,先用旧的技术栈过渡一下吧
    实习生新来的,代码写的一坨答辩,但是没办法了,没空帮他 review
    技术债实际上还是**业务变化**导致的,你一个产品做出来,以后不再迭代了就没有什么技术债可言
    您需要登录后才可以回帖 登录 | 立即注册

    返回顶部