报告敏捷中的缺陷

Question

I am working in sprint. At the end of sprint I need to send a defect report per sprint. Considering the below scenario please let me know your views.

两个团队(A& B)在Sprint-2的不同位置工作，我是A组的测试人员，并报告A组在每个sprint中开发的项目的缺陷。

问题

1. 我报告了Sprint-2中关于Team在以前sprint中开发的功能的几个缺陷。我是否必须将此视为观察或缺陷，并向A组报告？

1. 我报告了Sprint-2的5个缺陷，用于team开发的功能。所有的缺陷都是由我在同一冲刺中修复和关闭的。在sprint结束之前，我观察到两个缺陷由于某种原因被重新打开。现在，缺陷计数应该是5或7(5+2)应该考虑对此冲刺？

谢谢

可汗

Answer 1

我认为在你的例子中“完成”的定义有一个根本的问题。

如果在sprint中发现了“缺陷”，我会认为没有缺陷。这个项目根本不是‘完成’，应该重新加工，直到它是。我将修改“已完成”的定义，以包括这样的要求，即项目没有已知的缺陷(如果它尚未包括在内)。

对于在sprint完成后识别的缺陷，只需创建一个新项来修复该缺陷。

关于你正在编写的报告，我很难理解它的价值。

我认为开发人员理解他们的工作可能低于标准的地方是在冲刺期间，或者在回顾中，来自他们的同龄人组。从报告上看不是。

此外，如果您对so的定义是明确的，则没有必要让其他团队知道项目有缺陷，因此，不应该被认为是“完成”。项目在冲刺结束时被“完成”或“不完成”，而不管以后是否会出现缺陷。

Answer 2

有些事情看起来不对劲:听起来，测试人员(你)不是团队的一员，而是一种外部助手，报告错误。

如果你认为记录所有错误有助于提高质量，那么为什么要停止作为测试人员发现的错误呢？为什么编译器没有发现任何记录错误？为什么不记录不匹配的括号或未初始化的变量，编译器报告这些变量呢？

三个经验法则和一个工作流程：

1. 在Sprint中，您不会浪费时间记录错误--您可以修复它们。
2. 你不能用已知的错误来交付工作，因为它不是“完成”的。您不需要在工作项N上提交bug，因为程序员没有“完成”工作项目N，只有当每个人都同意完成时，他才会“完成”，这符合“完成”的定义，并且没有错误(不是因为我刚才以3种不同的方式说了相同的话)。只有到那时，程序员才会继续下一个工作项。所以没有必要记录错误。
3. 当处理错误，特别是来自其他冲刺或团队的错误时，请遵循以下工作流：
   • 程序员能在<4小时内修复它吗？如果是，那就修好它。完成
   • 如果没有，团队是否可以将其纳入当前的Sprint中？如果是，那就把它放在Scrumboard和修理它。好了。
   • 如果没有，请与产品负责人联系。无法在当前Sprint中修复此错误。他能否将错误作为产品待办事项放在要稍后修复的中？如果是的话，把它放在PB上。
   • 最后一个也是最不理想的选项:如果它不能与当前Sprint一起修复，并且不能推迟，则PO可以中止当前Sprint。团队发出呻吟，然后修复错误。

Answer 3

在关于缺陷数量的统计报告中，您应该区分不同类型的缺陷：

• 在之前的冲刺中传递的故事的缺陷。除非团队始终在应用程序的不同部分(即前端和后端团队)上工作，否则每个团队都没有必要将这些缺陷分离出去。
• 发现并完全修复了当前sprint中的故事的缺陷。
• 当前sprint中在sprint末尾打开的故事的缺陷。如果问题在sprint期间已经关闭并重新打开，在这里并不重要。只有在演示的时刻状态是相关的。

前两类可以通过问题解决进一步细分(固定、重复、拒绝)。

这样，与当前工作有关的问题的数目与与过去工作有关的问题的数目就有了明确的区别。

在处理缺陷统计时，有两件事您应该小心：

1. 一个报告中的多个缺陷。
2. 变形缺陷:修复原始缺陷后，相同的票证将被重用，以报告不同的问题。

这两种方法在解决/验证问题时都很麻烦，但对统计数据来说却是一个彻头彻尾的噩梦。在这两种情况下，都应将其报告为多重、不同的问题。

关于是否在有缺陷打开的情况下完成了故事:通常，如果一个故事具有与其相关的公开缺陷，则不应认为它已完成；但是，如果PO认为该缺陷不足以阻止故事继续进行，那么您也应该允许产品负责人接受一个故事。

可以有业务原因来接受产品的小问题，但是这个调用只能由客户的代表(即产品负责人)进行。