让团队成员每天准时下班的4条建议

如何在迭代的早期发现风险，是团队主管（team leader）需要不断磨练和提高的技能，它和大多数技能一样，是一门艺术，也是一门科学。不幸的是，尚没有一门针对这种技能的培训课程。本文介绍了这些年来对作者帮助最大的4条专业建议，供大家参考学习。

四件可以帮助您团队避免错过最后期限的事情

我在我软件开发生涯的早期就已经被提升为团队主管（team leader）了。

我擅长编码。但不是很好。

不过我最擅长处理这样一件事：为其他开发人员解决问题。

您知道开发人员更喜欢编写代码而不是阅读代码吗？实际上我更喜欢阅读代码。我知道，这是站不住脚的。

晋升为主管之后，我很快意识到仅仅能为团队解决问题是不够的。我还需要能提前预料到对应的问题。

当我们能尽早发现问题时，解决问题的成本就会成倍地降低。左移策略（Shift left）。

如果我们在迭代的后期才发现问题，那么修复问题的成本会大大增加。人也会变得紧张，需要投入更多额外的时间，并且消极情绪会层出不穷，团队的很多人也都会受到影响。

我相信，这不仅仅是能否按时交付的关键因素之一（这是我老板所很关心的），并且也是软件开发人员能否拥有高质量生活（这是每个人都应该关心的）的最重要因素之一。

实现您的承诺，并阻止糟糕的事情发生，就要在迭代的早期发现风险。

我相信，在 sprint 的前期就能识别风险是一项团队主管（以及任何开发人员）可以随着时间推移不断磨练和提高的技能。它和大多数技能一样，是一门艺术，也是一门科学。

不幸的是，尚没有一门针对这种技能的培训课程。如下是这些年来对我帮助最大的几条建议，您可以尝试一下。

专注于杠杆点

我相信团队中的每个人都是同样重要的。但是在任何给定的迭代中，通常都有一小部分开发人员在处理某些事项，这些事项对整个 sprint 的成功完成有着不成比例的高影响。这些就是我们的杠杆点（ leverage points）。

在 sprint 的第一天，找出哪些是开发人员正在做的最重要的工作项。通常情况下，它是其他开发人员最依赖的工作项。其他情况下，则是开发人员所做的技术基础工作，所有的一切都依赖于此。

多关注他们一点。问一些尖锐的问题，以确保他们考虑到了所有的角度：技术设计、可扩展性、测试、发布等。如果您能帮助他们成功地完成这些，那么您的整个迭代就很可能会顺利进行下去。

利用“站会”

导致开发人员在“站（stand-up）会”时不去谈论他们阻滞点（blocker）的原因有很多。有时是因为他们怕延误会议时间。有时是因为他们相信自己能解决自己的问题。还有可能是他们根本不知道自己一开始就有问题。

我喜欢问一些尖锐的问题。您不需要和每个人都一起钻研，但您可以挑选一些人（杠杆点，leverage points）。我发现下面的问题可以告诉我很多关于开发人员工作的信息：

• 是否（填写依赖于此项工作的开发人员或团队）对此进行了评审（review）？

• 告诉我你功能的发布计划？

• 你对可扩展性测试有什么想法？

@LinearB 开发团队的每日“站会”（standup）

如果您得到的是一个附带日期的简洁答复，比如“我已经和 PM 和 XYZ 团队一起评审了计划，我们将在周二开始实施。如果你需要的话，我可以把文档（doc）发送给你“，您会顺利很多。

如果您得到的是“表象”，或者他们在与 PM 讨论或一起评审计划之前就已经开始罗列他们需要做的事情了，这时，您可能就需要深入挖掘下了。

专业提示 1）确保每个人都了解您在迭代中的位置。当您埋头写代码时，很容易忘记这一点。

专业提示 2）对于您提出的问题，无论您听到什么样的回复，都不要在会议期间回应。您必须让事情继续进行下去。如果您听说某件事可能会被取消，在脑子里记下来，然后继续。

为“站会”（或 1：1 会议）做好准备

当我刚被提升为团队主管时，我对待“站会”的想法和我作为个人贡献者时的想法并无差别。我从我的 VP（副总裁）那里得到的最好建议之一就是每天花 30 分钟做“站会”前准备。

随着时间的推移，我发现某些数据点是我可以发现潜在问题的准确指标。

WIP（Working In Progress，在制品）与剩余天数的比率。假设您的迭代还有 5 天，并且大多数团队都还有 1-2 个 WIP 处于打开（open）状态。如果您的一个开发人员还有 6 个，这可能意味着他们不能完成了。查看整个团队及单个开发人员在迭代之间的平均 WIP 与剩余天数的比率是很有用的。如果您的 WIP 与剩余天数的比率高于正常水平，这就表明您的开发人员有工作超载问题，即使他们还不知道。

高交互 PR（pull request）。如果您团队的平均 PR 有 5 条评论，而您看到了一个有 30 条评论的 PR，这可能意味着您的开发人员正在努力交付一个大家都很期待的东西，或者是存在尚未解决的内部争论。

闪电 PR。这就是我所说的没有审查就合并的分支。有些团队对此并不介意。我们必须避免这样的事情发生，因为它能很好地预测质量问题。提前投入审查（review）时间总比事后返工要好。

复杂分支。我认为有大量的代码变更及具有高百分比重构或返工的分支都是复杂分支。这些分支具有很高的风险，因此您需要确保它们有 100%的测试覆盖率，如果有必要，甚至可以提前安排审查周期（在 PR 发布之前）。

如果您把这些信息放在“站会”（或 1：1 的会议）上，它将能帮助您把时间集中在您个人能对团队产生最大积极影响的方面。

专业提示 3）在日历上标出“站会”准备时间，以确保您不会分心。

明确周期时间

周期时间（Cycle time）是将一项工作编码、审查并发布给内部或外部客户所需的平均时间。我认为这应该是开发主管用来衡量团队效率的主要指标。它还有助于了解周期时间的关键阶段：

编码时间（Coding time）。第一次发布 PR 之前，编写代码的时间。我们也称之为欢乐时光😊

拣取时间（Pick up time）。PR 需要花费多长时间才能被拣取进行审查。

审查时间（Review time）。审查开始后合并 PR 所需的时间。

发布时间（Release time）。合并后向客户发布功能所需的时间。

如果您使用的是持续集成，那么合并时间（merge time）实际上就是您的周期时间。

对于在迭代过程中您从您的团队那里了解到的信息，周期时间是一个很好的检查，因为它指出了您通常需要多长时间才能交付。如果您在每个迭代中都度量周期时间，并跟踪团队的平均值，那么就能很容易地看出您当前的迭代是否偏离了基线。

专业提示 4）如果您正在寻找全面加速交付速度的方法，请查看下您周期时间的各个阶段。这是检测团队瓶颈的一种简单方法。

帮助你的团队，帮忙业务方，帮助你自己

随着我在早期诊断问题和帮助解决问题方面的进步，我开始注意到人们对我的态度发生了变化。

我的团队更加尊重我了。他们知道我是来帮助他们，而不是来评判他们的。他们对我更加开放。我们都变得越来越亲密了。

我的老板注意到我们经常能在最后期限之前完成任务。他开始更加信任我了，让我更多地参与战略决策。

CEO（首席执行官）知道我的名字 🙂，他开始给我安排越级 1：1。他真的听我说话。后来，当我的老板离职时，他支持我晋升为 VP（副总裁）。

为你的团队每天晚上能回家负责

我读了很多关于如何导致软件开发团队有时会倦怠的有缺陷的文化或不准确的规划。但并不像很多人所说的那样，开发团队在 sprint 中可以以不同的方式来阻止倦怠的产生。

确保您的开发人员能够回家和他们的家人、朋友、在线游戏协会、或其他对他们来说最重要的事情呆在一起。

所有开发人员应该能每天晚上准时回家，花时间和家人在一起，看足球，玩《塞尔达传说：荒野之吸》（Zelda Breath of the Wild）。

我认为团队主管应该对此承担个人责任。我们的人民由我们照顾。

关于这个话题，我还有很多话要说，我将在 3 月 11 日做一个现场直播。单击此处观看直播或获取录音。

原文链接：

https://linearb.io/blog/my-team-goes-home-on-time-every-night/