问轻重缓急在敏捷项目和非敏捷项目中是如何工作的

EN

一个通用的答案是:它是与上下文相关的；团队和利益相关者(他们更好地理解上下文)应该致力于找到一种好的方法--并定期分析其有效性并在此基础上加以改进。

然而，我看到了三种主要的方法。例如：

1.小组为标签规定了严格的规则：

• 高级:用户不能使用某些功能。
• 媒体:用户可以使用一些变通方法执行操作。
• Low:一个基本不影响使用的错误(例如一个小错误)，可以同意所有High都将在- sprint中处理，而每一个X冲刺都会有时间进行中等和/或低的操作。

2-利益相关者审查所有的错误，并决定哪一个和何时处理每个错误。

3- 零错误策略：

零错误策略很简单。所有的bug都优先于所有新特性的开发或改进。就这样。没有更多的东西了。这种方法的一个重要推论是，不存在诸如bug优先级、关键错误或小错误之类的东西。问题要么是错误，要么不是。如果它是一个bug，你需要在做其他工作之前修复它。

在更传统的软件开发周期中，用户在测试阶段和生产过程中都会发现缺陷。缺陷将记录在缺陷跟踪器中。根据缺陷的严重程度，它可能会阻止一个或多个用户，并且可能需要尽快修复。

在更多敏捷软件开发周期中，在迭代(Sprint)期间发现的缺陷，如果是迭代期间更改的结果，则在迭代期间修复。生产缺陷将放在待办事项上，并由业务代表(产品负责人)进行排序。我总是建议您使用零缺陷政策，因为您不想在流沙上迭代，并且越陷越深，陷入脆弱的应用程序。

敏捷和传统的软件开发周期都不能定义您需要如何处理缺陷。从技术上讲，你可以对两个人进行相同的处理。但是在敏捷中，延迟修复缺陷可能会给团队带来一种不公平的感觉，让他们对他们的速度有多快。缺陷是过去交付的项目(用户故事)的一部分。如果您的计划是基于您处理的项目数量，您应该始终优先考虑任何缺陷，以保持您的速度真实。

就像非敏捷一样。

记录错误，设置优先级和严重性。

也许你是在问在敏捷和非敏捷中接下来会发生什么？

这要看情况了。与敏捷的主要区别可能是

• 开发人员没有提交bug，而是立即修复它(比如在一天之内)。
• 输入bug，但是不需要花几周或几个月的时间来处理它，而是立即处理它。
• 而不是输入bug和向待办事项中添加bug，而是将它们输入并添加到当前的工作中。
• Bug在新特性出现之前就已经开始研究了。

这些并没有定义敏捷的特性，其中许多特性可能是在采用质量方法的非敏捷商店中完成的。但这些可能在某些地方是不同的。

因此，问题可能是‘敏捷开发中如何以不同的方式处理bug？“