跨职能团队:敏捷的核心思想


跨职能团队并不是一个新的想法,但不知何故,我们似乎还没有得到备忘录。

上周,我收听了斯科特·汉塞尔曼的精彩播客“汉塞尔分钟”。他让Angie Jones来谈automation。在所有关于确保自动化在您的开发过程中是一个一流公民的伟大建议中,有一件事对我来说很突出:

“你需要让你的自动化工程师加入你的Scrum团队。”
--安吉·琼斯

我不知道为什么,但这让我很吃惊。是不是真的有这样的公司,他们的测试自动化速度足够快,但却落后于敏捷的时代,以至于他们认为把自动化工程师从开发团队的其他成员中剔除出来是个好主意?

跨功能团队是敏捷的一个非常核心的思想--打破孤岛,并确保每个需要生产更多工作软件的人都是一致的,并且一起工作。这当然不是一个新的想法,但它显然是一个我们仍在努力吸收的想法。

然后,回想起来,我记得在一家大公司工作时,他们决定要“做更多的测试自动化”,于是他们雇佣了一屋子自动化工程师,他们坐在一个远离开发团队两层的隐蔽房间里(老实说,我们甚至好几个星期甚至几个月都不知道他们在那里)。这个团队负责为应用程序创建一个自动化测试包(而不是使用Scrum团队中的测试自动化工程师在过去几年中一直在工作的那个包)。然而,他们甚至没有和Scrum团队交谈,所以他们一直在追赶,以跟上他们的步伐。可以想象,欢笑接踵而至。我说搞笑。争吵,真的。然后是愤怒。最后,当我们意识到所有这些努力都白费了,因为Scrum团队不会--事实上不能--支持这个新的自动化代码时,大家都笑了。

显然,不了解跨职能团队的概念是一个老生常谈的问题。与我最近的一个客户相比,他拥有一个真正的跨职能团队。Scrum团队不仅有自己的自动化工程师,而且还鼓励开发人员(实际的开发人员,而不是重新命名的测试人员)为每个人的利益而工作测试自动化工具。测试工具是按照与生产代码相同的标准编写的,具有测试自动化专家的洞察力和经验。这正在从跨职能团队转向跨技能团队。不仅在同一个Scrum团队中需要的每个技能集,而且每个人都可以拥有多种技能,承担多种角色。

当然,你还需要专家。然而,与泛化的专家,你得到了最好的两个世界:专家在他们的领域的经验与灵活性和广度的想法来自于整个团队能够工作的任何需要。当整个团队可以蜂拥在任何区域时,你就拥有了一个非常灵活的团队;如果我们需要一个测试自动化的大推动,整个团队都可以集中精力。同样,有了充足的配对和轮换,团队中的每个人都会看到每一个领域,每一个角色,让每个人独特的视角去改进产品和流程。

然而,作为一个反例,同一个客户遭受了另一个古老的筒仓:操作。我原以为DevOps已经杀死了这个发射井,但看来并非如此。如果Scrum团队不能向实际用户发布更多的软件,那么它就不是一个完全独立,自给自足,跨功能的团队。一个scrum团队与一个单独的测试自动化团队一起工作似乎是一个疯狂的想法,然而,不知何故,一个scrum团队与一个单独的操作团队一起工作要正常得多,也更容易被接受。然而,这是一个完全相同的问题:如果在同一个scrum团队中没有您需要的所有人,那么您将会遇到瓶颈。你会有沟通问题的。你会有一种“他们对我们”的态度。

每次我遇到这个问题时,反对运营人员嵌入Scrum团队的典型论点是,他们不是一直在处理“你的东西”,所以其余时间他们会忙着做与“你的团队”无关的其他事情,或者他们会感到无聊。好吧,也许如果我们释放出额外的容量,我们就可以更频繁地释放。也许他们可以努力使它更快,更容易,更安全地释放更多的时间。也许他们可以更深入地参与开发,当我们做决定时,这些决定会影响到他们将要发布的内容,以及如何在半夜叫醒他们。也许他们甚至可以帮助其他的,非生产环境--那些被忽视的,每家公司似乎都很难给予足够重视的生产中的小兄弟姐妹。

也许,甚至,随着时间的推移,团队从拥有操作专家演变为拥有跨技能的团队成员来操作。在专家的密切注视下,我们可以让测试人员接触产品--让他们惊恐万分。广管局能放行吗?在某些行业,这是完全不可能的,因为监管的原因,但在所有其他行业,这是“不可能的”,因为仅仅是武断的原因。

打破孤岛从来都不是一件容易的事,但我认为这是一个有趣的反映,我们已经取得了多大的进展,有些孤岛现在看起来很可笑,而有些孤岛则似乎过时了。我仍然坚持一个遥远的梦想,那就是真正的跨职能团队。每当我看到这种情况发生的时候,没有瓶颈和错误沟通会让一切变得更快,更容易。最终,一个跨职能的团队比竖井更好,但一个跨技能的团队更好--如果你能管理好的话。