|
Have you heard it said, "XP teams don't need a bug tracking tool"?
Well-rounded, simple, intriguing — and dangerous.
Of course, this saying can only apply to teams working on new code, not a morass of legacy code that they're afraid to touch. I've been on several "green field" XP teams (whether as a member or an external coach), and indeed, some didn't use a bug tracking tool.
The theory's simple:
- By using test-driven development (TDD), refactoring, pair switching and other collaboration practices, developers put in a lot fewer bugs than they otherwise would.
- Through rapid cycles of testing and customer interaction, more bugs are found and knocked out.
- Defects found post-iteration are also cleaned up rather quickly. (This process is managed through the iteration plan.)
- Any defects found in #2 and #3 and deemed less interesting (not worth the time to fix) aren't fixed.
Points 1-3 above are true. When an XP team brings a story to the "done" state, it is in fact in fantastic shape. As for the defects "deemed less interesting", some teams will log them and rarely look at them again, whereas others will invoke the Lean "eliminate waste" principle and say, if we never intend to get to them, let's not bother logging them.
Therefore, a well-running XP team always has high quality software and not enough bugs to justify logging them. Right?
I think where teams get into trouble is when they treat the title phrase, "we don't need bug tracking", as an axiom. I think they have way more bugs than they know about!
To use my good friend and colleague Michael Bolton's new meme, I'll say: Through the XP practices, the team's doing a whole lot of checking, but probably not enough testing. Here's what I often see:
- XP developers put a lot of faith in their automated tests, which leads to false confidence. These tests (sorry, checks) are incredibly useful for many purposes — assuming you do them right — but their coverage invariably falls short of optimum. They tend to focus almost exclusively on functional correctness, which is already probably intractable.
- Not enough testers on a team. At least the kind that tries to break, explore and surprise the software.
- Insufficient testing skills on everyone's part. I recently attended Michael's Rapid Software Testing course and let me tell you, that's an eye opener. Most testers and developers I know (including myself) will try to be exhaustive, clever, or repeat established test cases. I've met precious few people who really do exploratory testing effectively.
- The mistaken belief that quality means "free from defects". Many people know that quality is at least fit-for-purpose, but they are likely to stop short at "our project customer says the story looks OK".
Already, I firmly believe XP produces far better software than established methods. If you're following XP (with or without Scrum) and experience quality issues, ask yourself if the above points hold for you. Trust the process, and improve it: All it takes to correct these points is awareness, skill, and a little investment in your team.
Copyright © 2009, 3P Vantage, Inc. All rights reserved.
|