错误优先级在敏捷项目与非敏捷项目中的工作方式

#1 楼

一个通用的答案是：它是上下文相关的。团队和利益相关者（他们会更好地了解上下文）应该努力寻找一种好的方法-定期分析其有效性并加以改进。

但是，我看到了三种主要方法。例如：

1-团队为标签定义了严格的规则：


高：用户不能使用某些功能
中：用户可以执行使用某些解决方法的操作

低：基本上不影响使用的错误（例如小错字）

可以同意，所有高级都将在以下情况下解决：冲刺和每个X冲刺都会有时间中和/或低。


2-利益相关者查看所有错误并决定解决每个错误的时间和方式。

3-零错误政策：


零错误政策很简单。所有错误均优先于所有新功能的开发或改进。而已。没有别的了。

这种方法的一个重要推论是，没有像错误优先级，严重错误或次要错误这样的事情
。问题可能是
错误，也可能不是。如果是错误，则需要先进行修复。

#2 楼

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

在更多的敏捷软件开发周期中，修复了在迭代（Sprint）中发现的缺陷，如果它们是迭代过程中更改的结果。生产缺陷将被积压，并由业务代表（产品负责人）确定优先级。我始终建议您使用零缺陷策略，因为您不想迭代流沙并越来越深入到脆弱的应用程序中。

Nor Agile或传统软件开发周期都无法定义您如何需要处理缺陷。从技术上讲，您可能对两者都具有相同的过程。但是在敏捷中，推迟修复缺陷可能会使团队对他们的发展速度有不公平的感觉。缺陷是过去交付的项目（用户案例）的一部分。如果您的计划基于要处理的项目数，则应始终优先处理所有缺陷，以保持速度真实。

#3 楼

与非敏捷相同。

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

也许您在问敏捷与非敏捷接下来会发生什么？ >
这取决于。与敏捷的主要区别可能是


而不是提交错误，而是由开发人员立即修复它（例如在一天之内说）
输入错误，而不是花费数周或需花几个月的时间才能立即进行
而不是输入错误并将错误添加到积压中，而是将它们输入并添加到当前工作中>这些并没有定义敏捷性的特征，其中许多可以在非敏捷性商店中采用高质量的方法来完成。但是这些漏洞在某些地方可能会有所不同。

#4 楼

回顾非敏捷项目，它存在一些问题：


不符合规范的一切都是一个错误。您有一个
合同，您编写了一个规范。您必须修复它。当然，还有歧义，讨论和解释的余地​​。交涉权很重要，未达到日期的合同处罚确实至关重要。
规范不完美，因此开发人员必须解决一些小的矛盾或漏洞。一些公司甚至禁止询问客户的域名专家。无论如何，您最终都遇到了与规范有关的错误，这些错误都是功能。
在大多数情况下，您需要在项目更新期间继续进行分析，而无休止的会议和电子邮件的结果就是规范的制定。有一些昂贵的工具可以追踪这种变化。
其中一些错误是如此的棘手，即使出于规范考虑，出于商业原因也需要解决。一旦产品正常工作，就需要某些功能，以使合同的延期得以协商。
时间是有限的，因此无论如何，通常都会在客户端的一些帮助下优先考虑错误和功能。一些客户提供了帮助。有人只是说这一切都很重要。在某些项目中，质量保证人员或经理确定了优先级。 X个月内没有发现的任何东西都不是错误。客户有动机去发现每个小错误或将更改或功能伪装成错误。开发团队将花费大量时间来修复可能用于创建新功能的“保证”错误。

敏捷：


质量水平取决于客户。他们在新功能和完善旧功能之间设置偏好。冲刺之间的优先级可能会发生变化。
开发成本/时间始终由开发团队评估。优先级由客户端设置。它不介意它是错误，更改还是新功能，因此我们可以避免这种讨论。
您不需要很多非常复杂的错误跟踪列表。最好让候选任务的子集为下一个冲刺做好准备。这意味着他们已被很好地理解并且对其成本进行了评估，以便客户可以做出决定。测试用例需要更新，错误概念也要改变。而且代码已经投入生产，因此优先级通常以客户为中心。
有些错误可能是技术债务影响了开发团队。他们可能会在回顾中发现提高速度的方法仅仅是修复错误。他们将修复它，因为它是产生更多价值的最佳方法。
即使您是敏捷者，也应遵循常识：如果您在银行中，并且有一个漏洞可能使您损失100.000.000美元，那么您将停止修复它。如果这是违法的，并且您正在生产中，则可以对其进行修复。如果您要修改类，并且可以解决几乎零效率的问题，那么您可以解决它。