Code Leader: Using People, Tools, and Processes to Build Successful Software

Chapter 4. Done Is Done

One of the most important sets of rules to establish with your team are those defining when a given task is "done" and ready to be turned over to testing. Typically, "done" means that the developer has completed coding to his or her satisfaction, and feels that it is time for testing to have a go at it. Sometimes that works, and sometimes it does not. If that is the only criteria, it is easy for developers to become sloppy, which in turn makes quality assurance (QA) defensive, and no good can come of this.

So what does it mean to be done with a task, and how is that task defined?

How a task is defined depends on your project management methodology. If you are following a waterfall model, a task might be a task as defined by the project manager driving the schedule. If you are using Extreme Programming (XP), it might be a story or a task that supports a story; in Scrum, a backlog item or a specific task that is part of a backlog item.

Part of taking your project (and your personal skills) to the next level is raising the bar on what it means to be done with one of these tasks. So what kind of rules should you establish for your team (or yourself for that matter) to make sure that done really means done? We will examine a few rules that I think are important; you may have your own. Almost all of them come down to discipline in the end. "Done is done" means sticking to the rules, even if you don't think it's necessary in one particular case, or if you don't ...