Every QA person uses a bug tracker. I had thought all our teams used bug trackers religiously. Turns out some of our QA people have adopted the idea that they should just walk over and talk to the developers and show them when they find a bug. Often those bugs get fixed quickly and never enter the bug tracker. If it’s going to be a significant effort to research and fix only then does it go into the bug tracker.

Another sign that our Agile adoption is taking a deeper hold. The point of QA is to improve the quality of the code. Fixing a bug when you find it is a better practice. Bug trackers can still be handy, but for a collocated team they’re less important.

It’s been about 7-8 months since we started to serious pilot Fitnesse on a project. Looks like its turning the corner. Instead of developers driving it, the QA staff are starting to build out acceptance tests and add scenarios. It’s coming in very handy for testing a huge number of edits based on a positional file format.

I still wonder if we’ll evolve to tools beyond Fitnesse, but it’s starting to prove it’s value.

Chapter 3

Ruby Eye for the Java Guy

Rails For Java Developers

One of those silent chuckle to yourself moments.

Apparently JB’s entry on Wikipedia is up for deletion. He comments on the whole process of the debate around his deletion as:

The whole experience makes me feel like I’m in a room with people talking about me while not acknowledging my presence and not seeming to care what I think about that.

I can’t even believe there’s a debate around it. JB has obviously contributed much to unit testing, TDD, XP, and Agile in general. His book, JUnit Recipes, I still use as a reference when I run into a nasty testing problem. I re-read sections on testing EJBs just a few days ago and it was better than anything you can find by just googling around. He’s hosted workshops at XP conferences, run XP days, written a popular JUnit tutorial. I still love his post on BDD:

What is Behavior-Driven Development (BDD)?

It is Test-Driven Development (TDD) practiced correctly; nothing more.

For all that work he really doesn’t deserve this sort of treatment.

In number the great bulk of projects I see are small maintenance or minor enhancement projects. They’re done in a day or a week or two by a single developer. Adding anyone or even the overhead of something like Scrum is counter-productive.

My assumption has been you hand off the assignment and let the individual self-organize with say a business analyst, QA person, and maybe a PM. I wonder if they’re aren’t some emerging ideas on how to handle this from the Agile community. I know some people organize a maintenance list and just pull things off a prioritized backlog when they have downtime.

The best way to tell if your one developer project is Agile. The developer and business analyst meet the documentation requirement by emailing back and forth a one page or less document and the PM runs it around for signatures a bit before or sometimes a little after the code has been pushed out to production. The only thing we typically miss is some way to do an inspect and adapt cycle.