在过去,缺陷管理是一个非常明确、易于理解和严格把控的过程,但这些都只不过是无稽之谈。在敏捷交付的世界中,我们要对整个交付团队交付工作软件的整个流程负责,却从未告诉团队究竟应该怎么做。


如何对敏捷项目进行缺陷管理


每个团队都有不同的缺陷管理流程,本篇讨论其中之三,希望对您有所帮助。

...

类型1 正在进行的缺陷


场景:交付过程中,在团队内部进行测试时发现了缺陷。

第一种情况是我希望成为大多数敏捷交付团队运行任何提供新功能的方法的标准。

在这种情况下,用户故事应该返回给开发人员以解决缺陷,然后重新测试,直到修复缺陷。这里经常有一个关于是否应该以某种方式记录缺陷的辩论。简而言之,这取决于团队知道在开发和测试之间的反馈循环中发生了多少浪费,这是记录缺陷的唯一真正价值。因此,团队使用这些指标或依赖于与故障单一起记录的信息以解决缺陷。

当您遇到这种类型的缺陷时,我建议您不要重新估计故事的大小,例如故事点数。您的用户故事不应该标记为“完成”,因为它没有完成,不起作用,这点已经通过存在缺陷的事实被证实了。

如果您在发现缺陷后查看指标,会有两种可能性,首先是用户故事看似被低估了,其次是团队效率显著下降。分析根本原因后第二种可能性更准确一些,没有重大缺陷的情况下那就是过程中出现了问题,这也是在下一次回顾中需要查询和解决的问题。


类型2 “延期”缺陷


场景:用户故事正在交付过程中,并且由于历史原因或者因为修复开发过程中发现的所有缺陷并不务实,故事被视为“已完成”,以致缺陷被推迟。

在这种情况下,应该引发一个新的用户故事,因为如果一个缺陷被“推迟”,那么实际上缺陷代表了一个尚未完全实现的故事的子特征。实际上,您已经选择在测试确定缺陷的要求后推迟实施特定的验收标准或子功能。

有时,缺陷所针对的具体要求或验收标准可能在故事中没有明确确定,但是在测试过程中它们被定义为预期要求。在这种情况下,这些仍然是缺陷,只是具有需求规范而不是需求的实现。在瀑布型开发中,这些可能会成为变更请求,并通过正式流程来更新范围。值得庆幸的是,我们不会在敏捷项目中遇到此种问题。

在任何一种情况下,缺陷都可以成为另一个用户故事,其大小和优先级与其他一切一样。

从指标和分析的角度来看,这些缺陷肯定应该被测量和评估,因为它们是导致质量下降的过程问题的明确指标。


类型3 回归测试期间发生的缺陷


场景:应用程序正在进行单独的回归测试或其他一些“后期”测试,并发现缺陷。

请注意,此类型与类型1之间的重要区别在于测试与特定用户故事的实现分离,或者是因为测试是在用户故事被团队视为“完成”后进行的临时测试,或者是因为无论什么原因,某些类型的测试已经推迟到实施之后。这在安全测试或性能测试中很常见,但有时也包括回归测试,即使在具有相对成熟的敏捷技术的企业中也是如此。

这些缺陷实际上是技术性债务,处理它们的方法不止一种。大多数团队都没有为这些缺陷记录用户故事或任何内容,这与运行持续集成的团队在“破坏构建”事件中所期望的响应相同。整体效果为团队效率的降低,最迟应在下一次回顾中讨论。

另一个选择是记录和推迟修复这些缺陷,然而,这会成为一个滚雪球问题,导致迭代传送系统很快转入瀑布式,所以在我看来应该不惜一切代价避免这种情况。

...

方案摘要


总而言之,“完成”的定义应涵盖质量水平,因此大多数缺陷应在类型1下处理。在这种情况下,开发人员应立即修复缺陷并仅在使用指标或通信需要记录时跟踪它。不要重新估计故事,因为这只是将问题伪装成一个糟糕的预期,而要更好地提高质量。

如果您以某种形式或其他形式推迟缺陷(类型2和3),则将其作为系统中的浪费进行测量。这与在交付节奏之外发现的那些缺陷一样,是过程问题的指标,导致质量和生产率问题。如果没有解决这些根过程问题,那么这些问题将开始削弱团队进行迭代交付的能力。在更广泛的IT部门的背景下,这将成为创建单独的“支持”或“BAU”团队的驱动因素,因此如果您的目标是DevOps,这是一个特别重要的事情,需要注意。


缺陷管理应该对敏捷项目更加严格


很明显,仅仅因为你是敏捷交付团队的一部分或者设立了敏捷交付团队,并不意味着你应该在围绕缺陷管理的流程实施中不那么明确或毫无规则。它实际上比瀑布项目更重要,因为它会产生很大影响。

没人告诉你该怎么做,并不意味着你什么都不做。我们都是专业人士,我们已经通过不同的方式完成了所有工作,所以在没有具体指导的情况下,从您习惯的方法开始,找出如何使流程更有效率的方式,持续改进。