Par Oaz » 12 juin 2006, 20:41 - In English
I must confess that I had not fully understood the arguments in his first post. Indeed, one of the biggest misconception in software development is that bugs don't need to be prioritized just like any other feature.
That being said, it is a wise decision to let the business, the customer or the product owner, decide if the development team should implement new features or fix a few more bugs. Now the problem is : does the business have enough information to make a good decision ?
- be aware of the final user needs at a fine level of details
- know the technical impacts of an issue whether it is fixed or not
Regarding #1, one could tell that it's the business people job to make decision regarding actual user needs. Things are not so simple.
If we are talking about in-house software development and the final users are a group of people working at the next floor, they are probably involved in the decision process, or, at least, someone will ask them when a decision on a tricky issue is needed.
If we are talking about a software shop and the final users are people working in other companies, things are getting touchy. In this case, the product owner probably has a customer's business background but she might not have the knowledge required by every position in this business. It is ok when prioritizing features at a coarse level but it can turn into dice rolling when dealing with detailed activity of a real user.
Listing #2 as a pre-requisite for business people might look counter intuitive : why should we care about technical details when deciding on which bug or feature the development team should work on ? The answer lies in the nature of a bug.
When a feature is not implemented, there are no side effects. One can find a workaround to fulfill the same needs but does not get unexpected behaviour.
When a bug is not fixed, it is a different story. The bug might be hidden in a lower layer of the software. From there it can have impacts on many features of the application. These "other" bugs were not discovered (yet). It is just a matter of test coverage. Of course, we could just do "more tests" but then the economic argument (do not spend time on fixing bugs because time is money) is no longer valid. Things turn into an arbitration between spending time on tests/spending time on bug fixes/spending time on new features...
I have no answer for these two items but I know for sure that letting the business people unilaterally making the fix/not fix decisions is as bad as letting the developers or the QA people making these decisions. At some point, all these people have to talk to each other to find an agreement regarding the prioritization of bug fixes.