站立会议
我可能会去找我的机械师，我们早上有一个小型站立会议：
我告诉他我希望我的轮子对齐，我的轮胎旋转，我的油换了。我提到“哦，顺便说一句，我的刹车在进来的时候感觉有点软。[他]可以看看他们吗？我多久可以把车拿回来，因为我需要回去工作？”
他把头探到我的车底下，又跳起来说我的刹车漏油并开始失效。他需要一个在上午 10:30 到达的零件。他的人不会在午餐前完成，但我应该在下午 1 点 30 分左右把车还回来。他已经预约好了，所以他今天不能做任何其他事情，我将不得不再预约一次。
我问他是否可以做其他事情，然后我回来刹车。他告诉我他真的不能让我在不修刹车的情况下开车离开那里，因为它们可能会导致事故，但如果我想去找另一个机械师，他可以要求拖车。
因为午饭后车很快就到了，我问他的人能不能吃晚饭，这样我就可以提前一个小时把车还回来。
他告诉我他的人早上 8 点进来，经常工作到晚上。他们赢得了每一次休息，他的男人应该和其他人一起吃午饭。
这些都不是我想听到的。我想听到我会在半小时内开车离开那里，轮子、轮胎和油都做好了。
我的机械师对我很坦诚。你对你的管理层坦诚和诚实吗？或者你是否避免告诉他们他们不想听到的事情？
单元测试
我不会碰我不理解的代码行，也不会签入我没有彻底测试过的新代码行。（至少，不是故意的。）
您的问题似乎暗示，不知何故，大量记录不良的代码在没有任何单元测试的情况下通过了审查。也许你参与了，也许你没有。每个参与的人都需要为此承担责任——包括管理层。无论如何，已经完成的事情。你不能回去改变它。
然而，就目前而言，每个人都有责任首先停止导致问题的行为。你说你花了一年时间编写你觉得难以理解并且没有单元测试的代码。在那一年，当您努力提高自己的理解力时，您编写了多少单元测试来记录并验证您的理解？
当你努力通过代码慢慢获得理解时，你添加了多少评论，这样你下次就不必费劲了？
Scrum 积压工作
就个人而言，我认为“Scrum backlog”一词用词不当。要做的事情的清单只是一个清单——如果你愿意的话，一个购物清单。我去修理工的时候有一份清单。我与机械师的站立会议实际上更像是一次冲刺计划会议。
冲刺计划会议是一次谈判。如果您的管理层在没有协商的情况下进行时间拳击，那么他们就没有管理任何事情。他们只是想把 10 磅的屎塞进一个 5 磅的袋子里，你有责任告诉他们。
当你参加 sprint 计划会议时，你应该承诺做大量的工作，你有责任为此做好准备。准备意味着对完成列表中的每个项目需要做的事情有所了解——包括理解晦涩代码所花费的时间和编写单元测试所花费的时间。
如果有人邀请您参加您没有时间准备的计划会议，请拒绝会议并建议何时重新安排，以便您有时间。
如果您有一个没有单元测试的现有代码体，并且可以想象某个功能可能会影响该代码的操作，那么您需要为可能受到影响的尽可能多的旧代码编写单元测试。当您致力于编写该功能时，您就是在致力于完成这项工作。如果这让您没有时间致力于其他一些功能，那就这么说吧。不要承诺其他功能。
当您承诺修复缺陷时，您承诺测试您的工作。显然，这意味着为缺陷编写单元测试。但是，如果它涉及没有单元测试的旧代码，这也意味着为尚未破坏但可能由于您的更改而破坏的东西编写单元测试。您还将如何测试修复？
如果您的缺陷列表保持不变的大小，那么您的团队会在修复的同时退步。礼貌地向任何需要了解单元测试防止当前使您的缺陷列表缩小的回归的人解释。
如果你因为提交了太多特性而未能编写这些单元测试，那是谁的责任？
重构
当您重构代码时，您必须测试所有代码，这意味着为所有代码编写单元测试。如果您有大量没有单元测试的代码，则必须在重构之前编写所有这些单元测试。
我建议您推迟重构，直到这些单元测试到位。与此同时，如果你坚持在你所承诺的工作的估计中包含单元测试，最终所有这些单元测试都会在那里。然后你可以重构。
一个例外是重构可测试性。您可能会发现某些代码不是为测试而设计的，并且您必须在创建单元测试之前重构依赖注入之类的东西。当您致力于编写需要单元测试的功能时，您就致力于使代码可测试。当您提交该功能时，将其包括在您的估计中。
承诺+责任=力量
你说你无能为力。当你接受责任并承诺做需要做的事情时，我想你会发现你拥有你需要的所有力量。
PS 如果有人抱怨任何人在修复单个缺陷时“浪费时间”编写多个单元测试，请向他们展示这段关于 80:20 规则的视频，并将“缺陷集群”灌入他们的大脑。