We all know that software product on defects are difficult to avoid. These defects have mild to severe, there are some drawbacks if not timely and effective solutions, can cause very serious consequences, while others have slight imperfections, even without repair almost everyone will not notice.
It's like most things, fix software bugs there a law of diminishing returns: Unless you have unlimited resources to allocate all of the bug fixes good job, or you need to concentrate resources on priority defect fixes return on investment. So the question is - " How to determine the reasonable priority ?"
Do not waste time to assess each defects
I've seen some of the product development team, they'd all known defects exhaustive list, and then carefully assess the severity of each defect, can again, the frequency of occurrence, bug fixes needed work, possible defects in which the code and so on. These evaluations looked like a very reasonable, but wasted too much time. In many cases, the assessment of time even more than the repair time.
So, when I started to lead the product development team, I tried to find a more efficient way.
Develop a set of guidelines for handling Bug
To deal with defects and efficient, we need to establish a process to establish a procedure, there is a need to develop a common team between Bug treatment guidelines. In this way, we do not have defects for each detailed assessment, but in accordance with the guidelines established by our fast processing. Initially due to differences in theory and practice, our criteria may not be suitable for all problems, but with practice, our criteria become more reasonable and more efficient. So we developed the defective product system: Bugout, we can even set up based on our guidelines for setting an automated process Bug priority evaluation function, so that every one of our defects automatically sets the priority according to the preset criteria, and in accordance with product module for processing automatically assigned to the developer.
We set up two dimensions of defects collected: scope and severity
- The number of users affected or affected system functions: the scope
- Severity: Importance of defects, such as: loss of data, data corruption, and so the appearance of a problem
Develop grade standards
The following is the standard we set the level of product form the basis of our reader is referred to, and in accordance with its actual situation to set their own grading standards:
Sphere of influence
Level 1: very little impact user / system functions affected by a small range
Level 2: Effect of a small group of users / a small part of the system functions
Level 3: Effect of a number of user / system function
Level 4: impact of large numbers of users / wide range of system functions
Level 5: affecting system functionality most or all users / wider range of
Severity
Level 1: irrelevant issues or certain features are not available, but there is a simple solution
Level 2: Accessibility is not available, but there is a reasonable solution
Level 3: Important features are not available, but there is a reasonable solution
Level 4: Important features are not available, there is no solution
Level 5: data loss, data corruption or system unusable
× scope severity priority =
We will influence the scope and severity multiplying two variables, obtained priority score, and set priorities based on the score:
Then, we set the guidelines for the priority processing Bug:
- The highest priority : must be dealt with immediately inserted into the current version of the product iterations, the demand is higher than other developers.
- High priority: rapid processing, into the current iteration of the product, but part of the iteration is lower than demand development tasks.
- Intermediate priority : processing, can be processed with the next iteration of the product.
- Lowest priority : selective processing, according to an iterative progress can be placed in the next iteration or the next few iterations for processing.
The key advantage of this approach is that it greatly reduces the discussion of how to deal with every time a defect. In addition, two factors that affect the extent and severity team considered relatively objective is to reduce the error due to the subjective factors that brought us make it easier to measure judgment, it can be simpler and more efficient system Bug handling priority.
