Issue-Driven Project Management
The projects I've written about so far have been done individually, by me alone. For small projects this is certainly less complex and usually faster, but not exactly a realistic software engineering method. Serious systems are almost always created in groups, with developers coming and going throughout the life of the project. Group projects mean having meetings, planning ahead, and sometimes compromising strongly held beliefs on the best solution to a problem. When approached incorrectly, they can cause endless frustration. So the goal of this post is to reveal what worked and what didn't in my latest experience with a group project.
First I'll explain the project. My three-person team created a command line interface for WattDepot (the energy data system that I introduced in my last post). Four built-in commands produce current power usage, daily energy usage, energy usage since a particular date, and energy usage rankings for the four Hale Aloha residential towers on campus here at the University of Hawaii. New commands can easily be added by implementing the Command interface. The processor, which reads input from the user and passes it to the correct command class, can automatically find the new class and begin using it. We combined all of the software engineering skills we have learned so far: JUnit testing, automated builds, version control, and continuous integration. We also used the issue tracking feature of Google Project Hosting, which allowed us to easily keep track of what each person was working on and link code commits to issues.
During our first meeting, it seemed logical to split the project up three ways. One team member focused on the processor classes, which would read user input, and the other two would split up the command classes. We created issues for each of the tasks that would need to be done over the next few days and got started. Not long into development, it became obvious that the processor would be more difficult than we had expected. In addition, our planned design for the command classes had to change because we had forgotten about a few things that were needed. Adding to the trouble were the miscommunications we had over the first weekend as we tried to sort out all of the initial logistics via email. As soon as we met again everything was fine, but for a day or two I was cursing group projects. I think all projects will have some friction at first as the group dynamic sorts itself out. Since then, things have been much more smooth. Finding time to meet, even if it is online or just for ten minutes between other classes and meetings, helps keep everybody on the same page.
We have finished the processor and four commands. Our input checking and testing is robust, and we have manually inspected the code and the output to make sure everything is in order. As our project nears the end, we have been doing code reviews and finalizing documentation. We used issues in Google Project Hosting to request code reviews from each other so that our notes will be kept as part of the project's history.
So my experience with issue-driven project management had some frustrating times, but overall it was nice to be able to develop one piece of the system and not have to think too much about the rest of it. I could easily see from the Issue page how everybody else was progressing and how much we had left to do on the project. I knew that tests were in place to make sure each class was working correctly, and as long as verify.build.xml passed, our entire system was in a working state. I didn't have to worry that a change I was making might cause problems somewhere in somebody else's code. And better yet, I don't have to worry that a team member might accidentally permanently delete half of the project on the night before it is due, so this experience has definitely been an improvement over some of my previous group projects.
First I'll explain the project. My three-person team created a command line interface for WattDepot (the energy data system that I introduced in my last post). Four built-in commands produce current power usage, daily energy usage, energy usage since a particular date, and energy usage rankings for the four Hale Aloha residential towers on campus here at the University of Hawaii. New commands can easily be added by implementing the Command interface. The processor, which reads input from the user and passes it to the correct command class, can automatically find the new class and begin using it. We combined all of the software engineering skills we have learned so far: JUnit testing, automated builds, version control, and continuous integration. We also used the issue tracking feature of Google Project Hosting, which allowed us to easily keep track of what each person was working on and link code commits to issues.
During our first meeting, it seemed logical to split the project up three ways. One team member focused on the processor classes, which would read user input, and the other two would split up the command classes. We created issues for each of the tasks that would need to be done over the next few days and got started. Not long into development, it became obvious that the processor would be more difficult than we had expected. In addition, our planned design for the command classes had to change because we had forgotten about a few things that were needed. Adding to the trouble were the miscommunications we had over the first weekend as we tried to sort out all of the initial logistics via email. As soon as we met again everything was fine, but for a day or two I was cursing group projects. I think all projects will have some friction at first as the group dynamic sorts itself out. Since then, things have been much more smooth. Finding time to meet, even if it is online or just for ten minutes between other classes and meetings, helps keep everybody on the same page.
We have finished the processor and four commands. Our input checking and testing is robust, and we have manually inspected the code and the output to make sure everything is in order. As our project nears the end, we have been doing code reviews and finalizing documentation. We used issues in Google Project Hosting to request code reviews from each other so that our notes will be kept as part of the project's history.
So my experience with issue-driven project management had some frustrating times, but overall it was nice to be able to develop one piece of the system and not have to think too much about the rest of it. I could easily see from the Issue page how everybody else was progressing and how much we had left to do on the project. I knew that tests were in place to make sure each class was working correctly, and as long as verify.build.xml passed, our entire system was in a working state. I didn't have to worry that a change I was making might cause problems somewhere in somebody else's code. And better yet, I don't have to worry that a team member might accidentally permanently delete half of the project on the night before it is due, so this experience has definitely been an improvement over some of my previous group projects.
Comments
Post a Comment