Is there a purpose to estimating the effort that a bug (defect) will take to fix? I think not.
Presuming that the bug has been properly prioritized (id est -- will it be fixed in this release or the next), there is little reason to spend the time estimating the effort that bug will take to fix.
For the purposes of this argument, I don't consider the following bugs:
- Text and UI fixes. The UI shouldn't be implemented by a traditional developer; it should be largely defined and implemented by the team UI designer.
- Misunderstandings. Spec said this, developer implemented that. This isn't a defect in the code, it is a misunderstanding or failure in the communication process -- both of which should be examined and fixed.
- Spec changes. Not a bug, but a feature request or revision.
So, considering legitimate bugs -- something implemented to do a certain behavior, but doesn't -- what is the point of estimating? Presumably the original implementation by the developer was thought-out (and developer tested!), but it isn't behaving now as expected. How can someone actually presume to know how long it will take to: first, find the issue; second, fix the issue? Assuredly most any estimate provided will either be too short or too long -- so what is the value?
Bugs should be prioritized, and then fixed. Don't waste effort on estimation.
Friday, July 18, 2008
Does Agile/XP Work? Part II
Mindy brings up a good point about communication. Ah, communication, simple communication, where art thou?
Where I agree that communication is essential for success in any group or methodology, I've observed a deeper core issue that has negatively impacted the success of Agile projects that I've been involved in: a failure to account for group personalities.
If you are politically correct and don't agree with generalizations, the following is probably going to rub you wrong. That is fine, you can ignore reality all you want.
The simple fact is that there are generalizations that most definitely apply to a development team. Think about it for a moment: what kind of person chooses and becomes a developer? How about a tester? Writer? In general terms, there are specific personality characteristics for each of these types of classes of people.
Consider developers -- usually quiet, pensive, not combative, don't ask too many questions, and don't like to admit they are wrong.
Now consider testers -- opinionated, always right, looking for problems.
The other classes are equally different.
For traditional development methodologies, there are teams constituted from the same people, so why would Agile be any different? The reason is that Agile is dynamic -- things change by the moment because some customer requirement changes, something is hard to do, there is a better way for something else, etc. -- all of these changes are spawned by someone voicing something. For those groups of people that like to voice opinion -- no problem; for those that don't... See my point?
Where I agree that communication is essential for success in any group or methodology, I've observed a deeper core issue that has negatively impacted the success of Agile projects that I've been involved in: a failure to account for group personalities.
If you are politically correct and don't agree with generalizations, the following is probably going to rub you wrong. That is fine, you can ignore reality all you want.
The simple fact is that there are generalizations that most definitely apply to a development team. Think about it for a moment: what kind of person chooses and becomes a developer? How about a tester? Writer? In general terms, there are specific personality characteristics for each of these types of classes of people.
Consider developers -- usually quiet, pensive, not combative, don't ask too many questions, and don't like to admit they are wrong.
Now consider testers -- opinionated, always right, looking for problems.
The other classes are equally different.
For traditional development methodologies, there are teams constituted from the same people, so why would Agile be any different? The reason is that Agile is dynamic -- things change by the moment because some customer requirement changes, something is hard to do, there is a better way for something else, etc. -- all of these changes are spawned by someone voicing something. For those groups of people that like to voice opinion -- no problem; for those that don't... See my point?
Monday, July 14, 2008
Does Agile/XP Work?
I've now been involved in three different projects of about five releases, each using a slight variation of the Extreme Programming (XP) (we are using the Industrial -- IXP -- variant) for approaching 5 years.
So, in a nutshell, does it work?
My opinion is YES and NO.
YES, the TEST DRIVEN DESIGN (TDD) aspects work and have lead to much more maintainable code, not to mention a better code design.
As for the NO part -- agile/XP ONLY works if there is complete buy-in from the entire team, and related supporting (read: management) personnel. Without a strong and ongoing commitment from all involved, XP doesn't work.
Further, XP can't be forced -- the individual must have the vision and the self-determination to follow that vision. Forced XP produces poor results: estimates that aren't accurate, non-optimal productivity, and code that suffers in quality and maintainability.
Each team (customer, QA, development) must continually train, review, evaluate, and improve their practices. If this isn't happening, organically, then there is more than likely a problem, or soon will be.
So, in a nutshell, does it work?
My opinion is YES and NO.
YES, the TEST DRIVEN DESIGN (TDD) aspects work and have lead to much more maintainable code, not to mention a better code design.
As for the NO part -- agile/XP ONLY works if there is complete buy-in from the entire team, and related supporting (read: management) personnel. Without a strong and ongoing commitment from all involved, XP doesn't work.
Further, XP can't be forced -- the individual must have the vision and the self-determination to follow that vision. Forced XP produces poor results: estimates that aren't accurate, non-optimal productivity, and code that suffers in quality and maintainability.
Each team (customer, QA, development) must continually train, review, evaluate, and improve their practices. If this isn't happening, organically, then there is more than likely a problem, or soon will be.
Subscribe to:
Posts (Atom)