Gota Handle On Status

I've seen something far less "hi-tech" than ye olde PERTGanntHarvard standard+tool used to get a handle on project status and generate reports. These folks simply used a standard tracking tool, like the kind commonly used to track bug-reports and change-requests. They created a new category of report for software development tasks, decided what the states (lifecycle) of a task should be (New, Assigned, Open, Closed, etc.) and what pieces of information (fields) they wanted to know for each state-transition. Typically they had anywhere from 5-10 "fields" for each transition, each of which was either a menu selection, or a simple number (perhaps an actual number, or a rough estimate), and typically there was one free-form text field for each state-transition for any comments that the "transitioner" wished to make.

Rather than planning the whole thing all at once, "tasks" were planned and "created" approximately 2 weeks in advance. When it was created, someone (typically the project lead, and/or the person who envisioned the need for the task) would fill out the fields for things like the project/product, priority, the initial target release the task was intended toward, and the person(s) to whom the task was assigned. Once "committed" to the assigned-state, the assigned developer(s) received an email-notification, and the task would show up on their "to do" list in the tracking system (prioritized according to selected fields and ordering criteria entered into the system at some earlier time, which could be modified later).

The assignee(s) could then "Open" the task, fill out any extra information they thought was needed regarding estimates, and correct information in other fields too if they felt it was necessary. They could use the "Notebook" portion as a scratch-pad or log for recording thoughts (at any time, even outside of the tracking system's GUI using a single "notebook" command with the task name/id) and when finished, they would moved the "task" to the completed-state, filling out what they thought the actual effort/calendar times were.

They would typically use the task name/id as part of the checkin/checkout comments in the version control system. But this became annoying to enter every time, so they automated it with a checkin/checkout "wrapper" that automatically determined the task name/id from their workspace (in an environment variable and/or a "settings" file in the workspace or the current directory). They found this useful for finding the "notebook" of comments associated with a task encompassing many changes to many files. Per-file comments for checkouts only gave "local" info, and didn't say much about the overall perspective of the task.

They used the notebook fields like diaries. The information in them might go out of date, but it still was helpful for knowing what the person was thinking at the time to understand what they did and why. They weren't forced to do this, they did on their own because they found it useful. In fact they started doing it more often, and even started adding some minimal "markup" commands into the "notebook" field which could be auto-extracted for use in things like release-notes and status reports.

It was relatively painless, and not very time-consuming to use the tracking system this way. In fact it helped streamline workflow and facilitate communication due to the short+sweet email notifications sent by the tracking system to the involved parties. And it made a nice TO-DO list to help keep the developers focused on what the present tasks and priorities were.

They didn't try to use rocket science to calculate estimates. They just took their best guess at first. After they had a baseline of data to compare estimates against actuals, they were able to use that to make better guesses. They gradually started adding some more fields, when they felt the information was helpful for generating reports or refining estimates (for example, later on they added a "task-type" field to try and categorize the task into things like building, coding, testing, integrating, reviewing, etc.).

The tracking system was able to generate reports that were useful in planning based on previous history, and other reports that were useful in tracking status and priority of tasks. But it was a long way off from the kind of visual diagramming and estimating and critical-pathing that something like MS-Project does. Still, they found it fit their needs well, and was useful for making accurate estimates and tracking status; but they didn't try to use it to plan out all the tasks in advance. They never tried to enter more than a month's work of tasks in advance, and usually averaged around two weeks of "in advance" planning at any one time. (I can see how something like this might fit in very well with the SCRUM methodology.)

-- BradAppleton

With only two weeks to a month of advance planning in the tool, isn't it a bit hard to predict when you'll be done? -- RonJeffries

The tool wasn't used to predict when they'd finish. That was done the same way it would have been done with or without the tool. After a while, info in the tools database could be used to adjust estimates for tasks, but the whole point here is that they didn't try to create a master plan in the tracking tool and didn't have to spend oodles of time trying to readjust the entire plan after every task/schedule change. The "way off in the future" stuff was done very simply at a very high-level only, and one didn't try to flesh out the task details until it was in the "near future" (think of it as YAGNI for detailed project plans ;-).

Whatever XP uses for that could have just as easily been used here as well (checklists or anything else you like). The tool was used for piecemeal adjustment and refactoring of current stuff that could then have details readily accessible in a database once they became recent or were completed. That doesn't mean you don't still have at least as much information as you had before for predicting when you'll be done (with or without the tool). -- BradAppleton

Just one more question. How did this project turn out?

Well - the project management aspects of it were very successful (meaning nothing more than that customers, managers, and developers were happy with the effects). That's not to say it didn't have problems in other areas though. ;-) -- BDA

I've done this sort of thing on personal projects, and thought that it might possibly scale up a bit. It's nice to see that it would. Eventually, though, I always got off-track, because I was the only one reading the code, and I know the code, I know the project, right? (Of course, I'd go back to it for other projects because the obvious answer is, 'Eventually, no.') --EdGrimm

This sounds very much like the way (or one of the ways) that the MozillaBrowser project uses Bugzilla. From http://www.mozilla.org/bugs/ - RFEs often get wind up being called bugs. Enter the tasks you're planning to work on as enhancement requests and Bugzilla will help you track them and allow others to see what you plan to work on. If people can see your flight plan, they can avoid duplicating your work and can possibly help out or offer feedback. -- DanBarlow

CategoryPlanning