你是否曾在工作中遇到过不知道该如何应对的挑战?虽然你有一个清晰的愿景和使命,但之前没有人做过这样的事情,所以你不知道该如何实现自己的目标?这是我在技术行业中每天都会有的一种经历,可能发生在团队层面也可能出现在组织层面。在 FlixMobility Tech,每个团队产品和每一件产品都有着不一样的背景,那么该如何解决这个问题呢?做实验!在像软件开发这样的复杂环境中,没有人知道什么路径才是可行的,所以我们必须尝试一下。继续阅读本文以了解那些关键的挑战、见解和经验教训,并为自己的实验之路获得灵感。
实验驱动的质量文化
在我培养实验驱动的质量文化的过程中,我了解到持续改进是关键所在。这里的第一步是提升关于现状以及个人、团队、领导和系统的痛点和需求的透明度。
当我们清楚了解我们所处的位置以及想要改进的内容后,我们还要明确手头上都有哪些选项。然后,我们可以通过实验、在我们的特定环境中尝试事物,并观察结果将我们引向何方来应对已确定的挑战。
我们应将这些见解用于下一个实验,重复这一过程,这样就可以找出使我们更接近自身使命和愿景的路径。有意识的持续学习并应用我们所学到的知识,可以实现高质量的结果。
文化变革
几年前,我们在产品团队的测试和质量文化方面面临着相当多的挑战。我们对他们的表现缺乏透明的认知。他们是在顺利完成目标吗?能不能分享一些对他们有用的东西来激发别人的灵感呢?还是说他们陷入了困境并需要支持?我们知道,尽管有多项共享举措,但团队之间的知识并不是通用的。我们还知道自己想要扩展,所以我们希望主动面对这一挑战。我们的使命是通过提升知识、技能和实践来改善产品团队的测试和质量文化。但是如何实现这一目标,如何触发这种文化变革呢?在复杂的环境中,我们没有一条现成的清晰道路来实现使命。我们需要通过实验来找出答案。
为应对这一挑战,我们开始与各个产品团队一起做了一系列实验。我们从一个非常有见地的大型“实验的实验”开始,但最终它太重了所以无法扩展下去。随后我们与团队一起做了一个较小的实验,专注于之前影响力最大的层面上。这看起来是一种很有前途的方法,但随后疫情来袭,我们的优先级出现了变化。尽管如此,我还是将实验继续了下去,这一次专注于我们合作过的人们的潜在需求:产品团队、我的技术领导同事,以及我们的实验倡议小组。
每次我们都可以从上次实验中学习到一些可以为下一次实验提供帮助的内容,于是我们不断尝试,寻找更接近目标的路径。毕竟,这是一段旅程。
团队实验
我们举一个具体的例子来看看在实践中这是怎么一回事。在与团队合作时,我们首先帮助他们提高关于现状的透明度,明确他们的痛点,然后明确对手头选项的认识,从而改进他们的实践。其中一个团队认为他们缺乏早期测试策略以及深入的探索性测试是一项挑战。在集思广益寻找这个问题的潜在解决方案后,他们提出了以下假设:
我们相信,在计划的集成探索测试会议中引入团队外部人员,会在预制作阶段发现和修复更多问题。当在生产发布之前发现的错误与生产发布后发现的错误的比率有所提高,且团队感到我们有所改进时,我们就会知道自己取得了成果。
为了验证这一假设,该团队决定了以下实验细节:
在每个冲刺中都有一个集成测试的任务。
仅统计在会议中发现的错误。
每节会议 1.5 小时。
每周五使用心情机器人收集团队的感受。
使用生产前和生产后标签标记错误。
实验运行时间:2019-05-27 至 2019-07-10。该团队进行了上述实验,在定义的时间盒到期后,我们帮助他们评估了收集到的数据。他们发现自己运行的实验与原始计划略有不同,但依旧可以测试假设。
在每个冲刺中都有一项集成测试任务→相反,团队根据需要即兴召开会议。
只有在会议中发现的错误才算数→他们忘了跟踪了,但记得他们在第一个会议中发现了很多错误。
每节会议 1.5 小时→第一节 1.5 小时,第二节 1 小时。
每周五使用心情机器人收集团队的感受→他们在每次集成会议后做检查。
用生产前和生产后的标签标记错误→完成。
实验运行时间:从 2019-05-27 到 2019-07-10→遵循该设置。总体而言,他们对主要测量标准的评估是他们确实可以证明假设:通过集成探索测试会议,错误检测率以及团队的感受得到了改善——这是一个积极的结果。他们决定保留新的实践并将其添加到测试策略中。
现在是时候帮助他们设计第二个实验了。这次他们决定解决另一个挑战:他们想提高产品质量和开发人员的信心,并提出了以下假设。
我们相信在每个冲刺中创建一定数量的自动化测试会带来更多的信心。
当测试数量增加(以审核数量衡量)和团队感受改善后,我们就会知道自己取得了成果。
请注意,我们只会支持团队确定他们的挑战并设计他们自己的实验。我们有意鼓励他们自己尝试一下,看看在他们的环境中什么才是有效的;我们鼓励他们从他人的经历中获得灵感,同时不让自身受制于这些经验,因为它们可能不适用于自己的环境。
实验的实验及其影响
我们的第一个大型“实验的实验”的一个积极影响是,它引发了很多关于测试和质量的团队讨论。通过这个实验,我们还可以提高团队的认知水平并增加很多领域的知识和技能,例如探索性测试、可访问性等质量方面的测试和协作方法等主题。我们还观察到这些团队受到了鼓舞,开始主动改进他们的实践。
然而,也存在一些我们想要但没能实现的目标。并非所有团队都支持我们的倡议,因此孤岛仍然存在。此外,并非团队中的所有人都对新概念持开放态度。团队中普遍存在对测试和质量的误解。然而,我们观察到的最大问题是团队在进行实验时确实很费劲。他们中的大多数人又回到日常业务中,因为他们觉得自己无法专心做改进,毕竟有“工作”要做,还有“路线图项目”要交付。尽管高层领导提供了鼓励、支持和明确的背书,但行动胜于雄辩——团队显然已经将实验和学习放在了较低的优先级上。
如上所述,这是一个有见地的起点,但肯定不是实验的终点。我们接受了所学到的知识并提出了新的假设,以更接近我们的使命。
从实验中学习
实验本身是有意义的。我通过实验学到了很多东西,不去尝试的话我永远没法学到它们。特别是当我觉得某些事情没法处理的时候,如果我真心去尝试一下,结果往往会让我感到惊讶。如果我们从未在自己的环境中中尝试过,就根本无法知道什么方法才是可行的。
实验也改变了我对失败的看法和态度。如果我以实验的心态去尝试各种事情,那么就算我的假设最终可能不会正确,但我仍然会学到很多有价值的见解。就Amy Edmondson的一系列失败原因而言,这属于非常正面的失败。实验应该可以安全地失败——如果我肩负着必须解决这个问题的压力,那它就不再是实验了。
我意识到的另一点是我们的偏见在实验中起着重要作用。有时我发现自己成为了确认偏见的牺牲品,我其实是在寻找证明我的假设的数据,即使有足够多的证据反对它也置之不理。此外,我意识到如果一个实验没有产生预期的结果,你会很难接受的。特别是如果你已经投入了相当多的资源,你会很难放手。沉没成本谬论开始干扰我们的思维,我们很可能会做出无用的成果。我需要一次又一次地提醒自己像GeePaw Hill所说的那样走“更多更小的步骤”。或者像Linda Rising所倡导的那样做“许多小的、简单的、快速的、节俭的实验”。我们需要意识到自身的偏见才能真诚地学习下去。
还有一件事我想指出来。有时我觉得自己想出了对团队最有用的想法。所以我种下种子,围绕它建立一个实验——结果却发现它没有得到团队的认可,让我觉得自己是在强迫他们做事。一次又一次失败后,我了解到实验必须由最直接受结果影响的人们来定义和掌控。例如,如果一个团队被要求去做一个预先定义好的实验,即使这个实验是某个成员定义的,我也往往会看到它要么不能证明潜在的假设,要么没有被纳入团队的实践。这种实验就不是“接地气”的。另一方面,如果团队参与实验并为实验做出了贡献,那么他们就可能真正认真对待它并学到经验。迄今为止最有效的方法是首先关注灵感,创造吸引力,然后在人们的好奇心和内在动机基础上构建实验,以了解更多信息并解决他们面临的挑战。重点在于让他们自己构建并掌控实验。
培养实验驱动的质量文化
当人们分享他们的想法和愿望时,背后存在的需求可能是另一回事。例如,技术领导者可以表达他们对全局量化指标的需求,而他们实际上可能首先需要弄清楚自己想要产生哪些影响,以及他们需要哪些信息来产生这种影响。
还记得那些回到日常业务的团队吗?系统性部分在你的实验中扮演着重要的角色。例如,如果你打算改善团队的质量文化,请考虑哪些行为对质量有贡献,以及如何获得奖励。如果一个人的工作做得很好,但这些贡献和由此产生的影响没有得到重视,他们可能就无法因此获得晋升。
我们面对的主要挑战往往会归结到人们的互动以及我们与之互动的系统上。我们需要建立互相信任的关系,塑造一个安全、热情的空间,让人们可以展现真实的自我并有机会茁壮成长。我遇到的大多数挑战追根溯源都是上述内容,无论它们被贴上“技术”“工具”还是“流程”的标签。我们需要为能够让所有人获益的那些事情打好基础。
最后,质量是我们所有人共同的责任。我们需要共同掌控它、共同改进它,并分享我们学到的东西,让其他人受到启发。从我的经验来看,我们应该提升透明度,然后提高对可用选项的认识水平,最后在自身的环境中进行实验,共同发展优质文化。我们应该虚心学习,并用收集到的见解为下一步行动提供灵感。
作者介绍
Lisi Hocke 毕业于汉学专业,2009 年开始接触敏捷和测试,从此投身敏捷事业。她对整个团队的测试和质量方法以及背后的持续学习心态特别感兴趣。与优秀的人一起打造能带来价值的优秀产品是她前进的动力。她从社区得到了很多帮助;现在她通过分享自己的故事和经验来回馈社区。她的推特账号是 @lisihocke,也会写博客。在她的空闲时间里,你可以看到她在健身房里打排球,和她的朋友一起开心娱乐,或者沉浸在各种类型的游戏和故事里。
原文链接:
Growing an Experiment-Driven Quality Culture in Software Development
评论