限制您的请求请求,看看会发生什么。 这是我们的故事。

许多开发团队面临的问题是拉取请求的数量不断增加。 您是否曾经听过自己说过“工作完成了,只需要对其进行审核”,只是几天后(或几周)合并?

信不信由你,我们的iOS团队也遇到了这个问题。 对于我们来说,有22个请求请求进行审查并不少见。 让我们将其放在上下文中:由8个开发人员组成的团队中的22个拉取请求。 如果将所有这些拉取请求都计为进行中的工作,那么我们每个人都会一次执行2.75件事。

似乎大多数人都进行了审查,这也意味着让任何人都对您的请求请求进行审查是一个艰难的过程。

我希望这不是您第一次听到此消息,但是多任务处理是一个神话。 我们人类在这方面非常糟糕。 当我们“多任务”时,我们实际要做的是任务切换(或上下文切换)。

最近加入并认为这是团队中的一个痛点,我觉得我们可以进行两次有趣的练习来突出这个问题。 进入我们的第一个游戏…

第一个游戏:证明您的多任务处理不好

  1. 在页面上绘制四列
  2. 在每列的顶部写下以下内容之一:“ 1–12”,“ 3–36”,“一月至十二月”和“ 7–84”

目标:填写所有列,以使第一列具有1、2、3等,第二列具有3、6、9、12等,第三列Jan,Feb,Mar等,以及第四列7、14、21等。

时间自己这样做。

第1轮:

通过在每一列中写入一个值来完成所有列,即,随即在各列之间跳转。 (您将在第一行写1、3、1月,7,然后继续到下一行,写2、6、2月,14等。)

这大约需要90-120秒。 前进。 我会等。

第二回合

在继续进行下一列之前,请先完成一列,以完成所有列。 (您将在第一列中写入1、2、3…12,然后移至下一列3、6、9…36,直到所有列都完成。)

这大约需要60秒。

结果

很抱歉将其破坏给您,但像数十亿人一样,您在多任务处理/任务切换/上下文切换方面也很烂。 在第一轮中,您花了几乎两倍的时间来完成所有列,从而付出了任务切换的代价。 在纸上写下月份的数字和名称不是一件容易的事。 想象一下,如果您是在重构,调试生产问题和检查Slack between之间切换任务

第二款游戏:证明您不必编写代码即可做出贡献

现在我们要折一些折纸。 是的,纸折的艺术。 这将需要您的整个团队。 因此,请大家聚在一起。 您可能需要4至8个人。

以下是说明:

我们将建立一条生产线来制造纸船。 在这样的团队成员中(假设有5个人),将说明中的步骤划分为以下几个步骤:

第一个人执行步骤1,下一个人执行步骤2和3,下一个人执行步骤4,下一个人执行步骤5和6,最后一个人执行步骤7、8和9。如果您愿意,可以进行更改有更多的人,但有目的地通过至少给最后一个人更多的步骤来制造瓶颈。

目标:3分钟内制作尽可能多的纸船。

第1轮:

时钟一开始,第一个人就将其折叠,将其传递给下一个人,然后立即抓住新的纸片进行折叠。 然后,队列中的每个人都继续折叠,并尽快将其传递给下一个人。

三分钟后,响起气喇叭并停止。 现在,计算三个指标:成品纸船的数量,未完成纸船的数量(队列中仍有折痕的任何纸张)和团队对质量满意的成品船的数量。

第二回合

这次,如果下一个人当前不忙于折叠,则仅允许每个人将工作传递给下一个人。 为了恰当地表明这一点,如果每个人都不忙于折叠,则双手悬空。 当某人举起手来时,排队的人将知道他们可以将工作传递给他们。 有些人会经常发现自己双手悬空。

三分钟后,再次发出气喇叭并停止。 再次计算三个指标:成品船数,未完成船数和优质船数。

结果

在两轮之后(或第二轮之后),您应该拥有相同数量的成品船。

但是,第2轮的未完成船将大大减少,而优质船的数量将相同(或更多)。

这是推入系统和拉入系统之间差异的一个很好的实际示例。 在第一轮中,每个人都在将工作推入系统,无论能力如何。 在第2轮中,有能力执行任务时,工作会通过系统。

结合两个游戏的结果

有了这两款游戏的结果,我们实现了两件事:

  1. 编写更多的代码和创建更多的拉取请求实际上在损害我们能够交付的工作量。
  2. 公开请求请求数量超过团队人数,会减慢我们的“生产系统”。
  3. 如果我们不断地在编写代码和检查代码之间切换(两者均未完成),那么我们会增加完成两个任务所需的时间。

我们如何改善

我们已将“允许的”打开请求的数量限制为六个。 如果我们提交拉取请求并达到限制(或通过限制),我们将不继续进行下一个编码任务,而不要先审查一些拉取请求。

我们已经看到,对我们的请求请求的审查时间大大减少,这导致产量非常可喜的增长,我们所有人都有更多时间审查其他请求请求。

我们不仅有更多的时间进行审核,而且审核已成为我们团队的共同责任。

作为奖励,我们感觉自己比以往任何时候都更像一个团队,因为每个人都参与其中,就我们的公开拉取请求进行协作和共享知识。

试试看

这些游戏和见解对我们的开发过程产生了重大影响。 我希望它能启发并帮助您打造出色的产品。 像Over

进一步阅读

精益软件开发:敏捷工具包

必须阅读有关软件生产系统中浪费的概念-如何识别浪费以及如何避免浪费。

排队论

关于工作如何流经带有队列的系统的数学分析。 本文介绍了如何避免排队以及如何实现进行中的工作限制(就像我们所做的那样),以避免不可避免的排队的陷阱。

Interesting Posts