Issue Driven Management

I recently had an opportunity to develop experience in issue driven management for a software project.  What is "issue driven management", you may be asking?  Well, it is a form of project management where the project as a whole is divided into smaller, more manageable portions.  These portions, or issues, are then much more easily processed.  With this particular project, I was working with a small team of software engineers.  In such a scenario, you can then assign issues to each member in order to spread out the work evenly and ensure faster production.  Giving people smaller, more specific issues to deal with enables the group to work with less confusion and prevents people from doing work on the same tasks.  Each issue can then be broken up into smaller issues and assigned to appropriate members of the team if the issue is initially too large or complicated.

To implement issue driven management for a project, it is best to find a project management solution that allows for communication, issue tracking, and a central repository if you're working with code.  My group chose to use Google project hosting at Google Code to host our project.  This allowed for us to implement issue generation and tracking, as well as giving us a central repository.  Our project was to create a command line interface for the WattDepot application.  This command line interface we developed queries the WattDepot server for information about energy usage for the Hale Aloha building at the University of Hawaii at Manoa campus.  Our team also used a combination of build automation with Apache's Ant and continuous integration with Jenkins.

Our project team was team "tiger" and the project was named "hale-aloha-cli-tiger", which you can find here at "http://code.google.com/p/hale-aloha-cli-tiger/".  All together, the experience was an educational one to say the least.  I learned a great deal about working with other people on a project, but also a lot about continuous integration and how you can have a build work locally but then fail an automated build on Jenkins.  It certainly slammed the importance of running "ant -f verify.build.xml" before every single commit to the repository!  And to make sure that if build directories find themselves in the repository, even if by someone else, you should immediately remove them.  This prevents issues with Find Bugs failing a build when the problematic file has been removed.  Another thing that is key is communication, which can be relatively difficult when people on the team all have different schedules and heavy commitment loads elsewhere that prevent consistent communication.

My group and I accomplished the task for which we were aiming.  It was a great experience, and I enjoyed working with the others.  It was a lot of fun and energizing to meet with each other and toss ideas back and forth regarding solutions to problems.  I hope that I get another chance to work with each of them and I am glad that I was able to have this experience.  We had a few problems, of course as any project might, but my group always came through.  Is our project completely done?  Well there are always areas in which we can improve a system, but yes it accomplishes what we wanted to achieve.  We did a lot of automated quality assurance, but no system can completely account for everything a user can throw at it.  Not without a much more exhaustive system of tests.