6
零缺陷/缺陷策略保持敏捷
在我们的项目中，我们采用零缺陷（也称为零缺陷）方法。基本思想是，错误的优先级始终高于功能。如果您正在处理一个故事，并且有错误，则必须解决该问题才能使该故事被接受。如果在sprint期间发现了较旧的故事中的错误，我们需要将其放在待办事项列表上并加以解决-最高优先级。 我说解决的原因是我们并不总是修复该错误。有时我们只是宣布它“不会修复”，因为它并不那么重要。总而言之，这听起来很棒。我们正在运送高品质的产品，并且不会以积压大量错误的形式出现“驼峰”。 但是我不确定这种方法是否正确。我确实同意，我们总是需要尽快修复严重的错误，并且需要丢弃无用的错误。但是重要但不如新功能重要的错误又如何呢？我倾向于认为应将它们以适当的优先级提交待办事项清单。 为了使它更清晰，我将举一个示例-在我的项目中，我们使用用flex编写的UI。我们有一个向导屏幕，它以每种屏幕分辨率打开的大小相同。事实证明，当我们扩展向导窗口时，其中一个页面看起来并不好（虽然向导现在可以显示所有内容并且不需要滚动条，但是垂直滚动条并不会消失）。我认为这个错误很难看。我确定它一定要修复。但是我们的时间表很紧，我们有很多功能，我们担心这些功能不会成功并进入发行版。我觉得我们可以忍受这样的错误。它确实需要修复，但是优先级低于其他功能（因此，如果我们无法完成它，至少我们没有遗漏更重要的功能）。但， 我很想听听有关如何管理我不想标记为“无法修复”但也不是最重要的错误的意见。