度量敏捷测试成熟度:Bob Galen访谈录


Bob Galen是一位敏捷方法学家,实践者,教练,并且作为软件开发人员,测试人员,项目经理和领导者拥有超过30年的经验。我们最近与Bob坐在一起了解了更多关于成熟的敏捷测试团队与其他团队之间的区别,以及领导者如何最好地支持这些团队,以便始终如一地交付工作软件。

Noel:我们听到很多关于缩短反馈循环的要求,以及提供持续反馈的开发,测试和发布循环。持续的反馈当然是必须要有的,但我很少听到人们谈论的是,能够迅速地对反馈做出反应,并做出明智的决定是多么重要。

能够做到这一点有多重要,不仅仅是收集或记录反馈,还要随时调整以做出新的决定,调整和持续的响应?

Bob Galen,RGalen咨询集团总裁


鲍勃:我认为这是非常重要的一点,诺尔。它不仅与持续的反馈有关,还与持续的改进周期有关。例如,在团队,项目或组织回顾中提出的调整反馈。对你来说,我们的贫瘠时代应该对我们的发现做点什么,采取行动。

这也是我把“停线”作为一种心态来谈论的原因之一。

如果我们是生产丰田卡罗拉的装配线的一部分,并且我们注意到现在的汽车是没有后门交付的,我们会拉下绳索并停止生产线。

那我们怎么办?

我希望我们能修好汽车。事实上,我们越早停线,我们需要修理的门就越少(返工越少,时间影响越小)。

但我们结束了吗?不!

我们必须在我们的过程中检查根本原因,并找出是什么造成了问题。那我们得…把它修好!只有这样,我们才完成了事件,并可以再次启动线路。

这个有点做作的故事集中在:

  • 早期发现
  • 立即行动-停止你正在做的事情
  • 立即修复
  • 深思熟虑的根本原因分析
  • 最后,修复“过程”,使故障不再继续
  • 然后,重新启动线路

我想重新构建这个问题,把重点更多地放在持续改进上,更倾向于快速反馈,快速理解和快速调整。


工作软件是“我们到了吗?”和“我们完成了吗?”的最终目标和衡量标准--鲍勃·盖伦


Noel:你在DevOps East做过一次会议,讨论了团队是什么让敏捷团队变得“成熟”。成熟团队有哪些品质是其他团队可能没有的?

鲍勃:我猜,首先,他们表现得像一个团队。他们有共同的目标,为了取得成果而分担工作。因此,技能并不是协作和共同工作的障碍。像在工作中结对这样的活动是很平常的。

成熟的团队也会相互问责。对高质量的可交付成果负责,对彼此的承诺负责,并对交付结果负责。你可以在他们的工作中看到这一点,但在他们的回顾中非常清楚--在那里艰难的对话在必要时浮出水面。

他们也勇于向外,向上挑战。例如,如果他们觉得领导不能给他们成功的机会,那么他们就会推倒不信任,工作的过度投入和支持资源的缺乏。

他们是一伙的。他们作为一个团队成功和失败。事实上,他们互相保护。他们互相帮助。他们努力工作,最大限度地发挥他们的全球优势,最大限度地减少他们的弱点。

最后,他们把她搞定了。我的朋友Josh Anderson在他的报告中谈到了他对高性能敏捷团队的3部分招聘要求。他的标准是:

  • 聪明,快速的学习者
  • 团队合作精神
  • GSD-完成SH**

Josh关注的是那些能表现出所有这三个特征(Venn图中的交叉点)的候选人。

我认为这是有效思考“成熟”或“高性能”敏捷团队的另一种方式。但请不要被这些条款或目标所困。

我也想让球队一起玩得开心。去发现做伟大的工作所带来的乐趣,这会带来巨大的客户价值。

Noel:您在会议中提到敏捷领导者--以及其他领导者--需要“对软件测试人员有更多的理解和尊重,并承认测试人员是一流的公民”,这对测试人员来说是如何变得如此糟糕的呢?我们是如何走到一个可能需要提醒“领导”这样做的地步的呢?

鲍勃:我从事软件开发将近40年了,诺尔。而且,是的,这个数字让我从不同的角度感到害怕。

我认为测试人员一直在用二等公民说唱。开发人员一直被视为价值中心,测试人员被视为商品和成本中心。

我认为很大一部分是因为很多技术领导者都是软件开发人员出身,所以他们更容易理解开发的价值主张。多年来,我一直有机会领导开发和测试组织。我还把自己送进了很多课堂,让我更深入地了解软件测试的职业和手艺。

鉴于此,我认为我对每一个项目的价值有了一个更平衡的看法。许多领导人缺乏这种更广阔的视角。

事实上,我认为他们轻视了测试的概念。例如,在敏捷上下文中,他们认为它只是围绕着逐个sprint的“检查”用户故事功能。但远不止这些。或者,至少应该是。当您将它最小化为简单的功能检查时,它就成为任何人都可以执行的商品。或者,至少这是人们的看法。

他们也没有考虑到测试人员可以驱动的质量实践,我在下面的问题5中讨论了这一点。

Noel:你还描述了领导者需要“理解基于工作软件的客观证据做出决策的能力”,对我来说,定义“工作”有点像定义“完成”,意思是,极其困难。了解其他涉众如何定义“工作”有多重要,然后,一旦你知道了,每个人都需要以同样的方式定义它,还是有一些变化的空间?

鲍勃:我认为定义“完成”不应该是重点。我坚持我的评论,我想说的是,作为软件团队,我们经常要做很多事情来构建我们的软件。其中包括:

  1. 体系结构和设计文档
  2. UX设计
  3. 需求-从传统到用户故事
  4. 项目计划,开发计划,测试计划
  5. 各种各样的检查表和过程元素
  6. 状态报告,度量捕获,跟踪
  7. 各种工具基础设施
  8. 测试用例和测试执行
  9. 内部文件和客户文件

所有这些都不能直接为我们的客户或利益相关者提供价值。换句话说,他们并不为上述元素支付我们的工资。当然,所有这些都在某种程度上是必要的,但它们并不直接在价值流中。

所以,我认为重点不在于定义工作软件,但交付工作的软件。这样我们就可以决定我们的方向,而不是从文档,计划或谈话,而是从我们正在构建的东西,以交付客户价值。

它是有形的。它反映了我们提供的价值。客户可以触摸它,感受它,与它互动,给我们反馈是否满足他们的需求,解决他们的问题。

工作软件是“我们到了吗?”和“我们完成了吗?”的最终目标和衡量标准。

Noel:您已经谈到在成熟的敏捷团队中,“测试不是他们的欧力我认为这至少在最初会让一些人感到惊讶。在测试之外,什么有助于建立质量,其次,做任何能减轻测试人员负担的事情吗?

鲍勃:实际上,要明确一点,测试不是一个质量实践。这是一个核查过程。

质量实践是不同的。它们侧重于核查前活动。例如,“3个朋友”在敏捷团队中是一种常见的做法。在这里,开发人员,测试人员和产品所有者一起工作,在整个生命周期中审查用户故事。这是一个合作的隐喻,每个视角都在故事定义中起作用。

设计评审,代码评审和配对也是敏捷团队中质量活动的标志。与客户/涉众和产品负责人合作,以确保我们理解我们试图解决的问题。

有时人们把这些称为测试中的“左移”。也就是说,在验证之前,测试人员将重点放在确保我们正在构建正确的东西和构建正确的东西上。

考虑一下。在许多方面,测试都太晚了,无法捕捉缺陷。即使在敏捷团队紧密的反馈循环中,我也更希望测试人员在“前期”活动中花费一些时间,以确保在他们专注于测试之前我们已经掌握了配方。

是的,如果我们把“左移-右平衡”变成“右移-右平衡”,那么测试更多的是一种死记硬背或安全网活动。并且它失去了典型的,重复的测试-修复-测试的性质。

或者,这是当专注于建筑时的希望质量in vs。测试质量在。

要阅读更多鲍勃盖伦的文章,你可以访问他的website,跟着他Twitter,或浏览his authored books