【产品管理】更快、更好、更强:打造高品质产品

Chinese, Simplified

当谈到构建高质量的产品时,作为QA,我们可以从这个问题开始:“什么是质量?”它经常在学术上、哲学上或ISO定义上得到回答。但我想以一个大家都知道的产品为例:松饼。

什么样的品质才能做出高品质的松饼?当然上面还有巧克力屑!让我们直接来看看与质量保证的第一个比较:就像在松饼上涂上巧克力一样,许多团队只是在编程之后才开始关心软件的质量。两种情况下的问题都是:松饼(软件)中没有巧克力(质量)。

在本文中,我们希望了解一些方法和过程,这些方法和过程向我们展示了如何在软件开发中尽早关注质量,或者换句话说,如何将巧克力直接烘焙成松饼。

正如您可能猜到的,这将显著增加常规“QAs”的工作范围,从而使我们从“质量保证”的角色中脱颖而出,成为真正的“产品质量专家”。

如何在流程的变化中提高质量

如果我们仔细观察一个典型的敏捷团队的过程步骤,我们可以看到其中的细节。

在第一步(“分析”)中,我们计划创造价值。我们为此写了一个故事,然后将其放入一个“backlog”中——因此没有立即对它做任何事情。换句话说:我们在浪费时间。在最好的情况下,分析的故事在实现时仍然是最新的。通常,故事在这个时候已经过时了。在下一步(“开发”)中,我们将计划好的价值添加到产品中。然后,故事在流程步骤中再次等待(“等待QA”),所以在这里,我们也只是在浪费时间。团队等待质量分析师(QA)检查计划的值并将其交付给用户(“在QA中”)。

作为QAs,我们对“backlog”列没有什么影响,但是“等待QA”是“我们的”。为什么我们应该在团队中有一个过程步骤,其中唯一发生的事情就是浪费时间?如果我们将“等待QA”列与另一个工具(正在进行的工作限制)配对,那么删除“等待QA”列将对团队工作的速度和质量产生非常积极的影响。其思想是这样的:如果没有“等待QA”专栏,开发人员就没有空间在实现完成后留下一个故事,因此不能开始一个新的故事。因此,开发人员必须确保将故事传递给可用的QA。这种强制切换便于直接沟通:QA从开发人员那里接收有价值的上下文;开发人员可以利用与QA的对话来检查特定故事的所有验收标准是否都得到了满足。这段对话已经是质量的一大胜利。

我们在不同的项目和不同的上下文中使用了这些限制。在一个案例中,我们能够将故事的“分析”周期从13天缩短到4天,而不需要任何人“更努力”地工作,也不影响质量。由于开发中较少的故事不需要持续的上下文更改,因此,故事可以更快地完成。“在制品”的限制对团队的集中有积极的影响,因此不仅对上市时间,而且对产品的质量也有积极的影响。

 

分析人员的协同作用:业务和质量如何协同工作

要真正与业务人员(业务分析师、产品所有者或产品经理)合作,理解所有涉及的视角是很重要的:我们的业务分析师(BAs)通常非常积极地快速发布软件,因为较晚发布(软件)产品会导致更高的成本和更低的收入。

另一方面,QA的工作是确保一个可靠且几乎没有错误的产品被引入市场。

挑战在于找到速度和质量之间的平衡。为此,NASA曾经分析过错误产生的确切成本。

图1:错误的代价

在生产中,很容易发现错误成本激增的时刻。这不仅是因为服务器被称为“生产”,还因为到达生产系统的bug存在时间很长,因此成本更高。但无论成本大幅上涨的确切原因是什么,一个典型的反应是在投入生产前彻底重新检查所有东西。这些是我们CI / CD系统中的自动化测试用例。

但是,如果您更仔细地查看图表,尽早发现缺陷并从一开始就交付高质量的产品似乎是最经济有效的,这是在起草需求和分析案例的时候,而不仅仅是在测试的时候。

以我的经验,这是最好的时候,QAs和BAs实际上坐在一起。当他们一起处理需求,并在简短的计划会议上向团队展示这些需求时。通过这种方式,关于需求的知识(包括“边缘案例”和“sad路径”)可以在实现之前与整个团队共享。QAs可以确保最重要的“sad路径”已经被考虑用于实现,因此,也可以自动测试回归。这样,手工测试的工作量就大大减少了。与时间压力下的代码冻结测试相比,我们推出的产品质量更高,上市时间也更早。

要积极主动

理想情况下,开发人员与QAs一起工作,按照测试金字塔(https://martinfowler.com/articles/practical-test-pyramid.html)的原则,从单元测试级别一直到所需的端到端测试,构建回归测试。然而,无论这些测试在设计时多么复杂,它们总是在实现之后执行。

为了从一开始就提高质量,我们尝试将一个简单的规则应用到所有团队:每个提交都投入到生产中。

设置此规则可以提高质量:当QAs不再是可能错误的最后守护者时,开发人员将花费更多时间确保他们的测试涵盖最重要的内容。而且,由于QAs是测试专家,开发人员和QAs之间的推拉关系被这个新规则逆转了。此前,门票已被推到QAs进行测试。现在,开发人员正在向QAs咨询关于如何最好地构建测试的建议——尤其是在实现之前。

第二个好处是你在紧急情况下有更大的灵活性。通常,在经典的发布管理中,对于如何执行一个发布,您有一个复杂的计划。如果出了什么问题,有一个热修复—选择—发布—流程,它绕过了团队中的大多数安全措施和质量控制。这听起来不太可信。

我们不再需要在我们的团队设置。如果发布周期不超过30分钟,我们就可以快速响应生产问题,而不需要热修复程序或分支。我们甚至不再需要回滚策略。

真正有趣的问题是如何设计监视,以便您能够更早地发现生产中的问题。这至少包含应用程序错误数量的可视化,以及服务器或数据库响应时间。如果你想达到真正的专业水平,你可以考虑完全自动化的异常检测。

因此,在使用特性切换以一种非常受控的方式启用新特性的同时,发行版的问题明显减少了。我们不仅能快速为用户提供新的价值,同时还能实现更高的质量。

创造一种接受错误并从错误中学习的文化是提高质量的根本

每个团队都会犯错,这是人性使然,也是好事,因为我们从错误中学习。作为QAs,我们非常关注错误的风险和影响,它们可以帮助团队在安全的环境中快速地犯错误,从而使团队能够非常快速地学习新事物。这不仅增加了团队的安全性和信任,提高了软件的质量,而且几乎是意外地增加了团队的创新潜力。

我们非常密集地使用的一种方法是结对编程,这也是团队不断要求的QAs方法。它特别帮助我们避免小的失误——这是必然发生的有时。有效的损害控制是两个人的“配对”,其中大多数是开发人员。

但错误并不是结对的唯一动机。你知道当你尝试了一些新东西并理解了它是如何工作的时候,你会有一个“啊哈时刻”吗?我们试图通过“尝试”(故意挑起错误)让团队尽可能轻松地经历这样的时刻——并在两人内部谈论它!

最后,确保你的团队玩得开心。

“有趣”,你可能会问——“真的吗?”

是的。想象两个不同的团队。在第一个团队中,人们非常兴奋,他们快乐地工作,早上互相打招呼,他们交流和讨论他们正在做的事情。然后是第二组人,他们更喜欢在早上拿到一个待办事项清单,然后在剩下的时间里一个人待着,直到他们完成了那个待办事项清单。你认为哪个团队会开发出更好的产品?哪个队会犯更少的错误?哪个团队更有可能按时交付?

质量专家通常是开发人员和业务之间的纽带,我们连接人员和他们的观点,我们帮助建立信任的文化。这些都是构成伟大文化的小因素,而我们这些高素质的专家通常就在其中。

将所有这些结合起来:一个积极的团队氛围,QAs和BAs之间的紧密联系,一个出色的形状的测试金字塔,以及一个实际上使团队能够快速交付软件到生产中的过程,最终将导致一个更好、更快、更强的高质量产品。

 

本文:https://architect.pub/faster-better-stronger-building-high-quality-product

讨论:请加入知识星球【首席架构师圈】

 

本文地址
https://architect.pub/faster-better-stronger-building-high-quality-product
SEO Title
Faster, better, stronger: Building a high quality product