Issue-based Project Management

So once again, I found myself working in a group. This time we were developing using issue-based project management under continuous integration. In other words, we tried to split the project into smaller issues that could be completed in a couple of days.  The point of this is to allow everyone to always be working on something without being bottle necked waiting for others.  Also, because issues are small, it's probably easier to not get discouraged looking at the size of the project.  Finally, by splitting everything in to manageable little pieces, we were able to clearly think about how to best split things and keep everything separate and testable.  Because we needed to make sure that everyone always had something to work on, we had to make sure that what we were doing was very modular. Then, because we were doing everything concurrently,we used a project host and continuous integration to make sure that everything kept working and we didn't bump each others' work out.  The hardest part of this for me was keeping up daily with working on issues.  I tend to like to sit down and work all day and then relax afterwards, but dividing things up requires a little work per day over a longer period which is something I still need to work on getting used to.

Getting to the actual project, we were working on a command line interface for use with energy data collected from the Hale Aloha residence halls at the University of Hawaii's Manoa campus.  It can be found here. The project involved creating a simple shell and then making various commands to interact with the energy data given.  We were able to successfully make commands for ranking towers, finding the energy since a certain time, finding daily energy and the current power. However, we had to hard code each command in to a list.  So any additional commands have to be added to that in order to work.  So it wasn't the most elegant solution, but it got the job done and did it in a modular fashion.  New commands are pretty easy to create, and the processor and main interface probably don't have to be touched.  As far as documentation goes, I think we did alright, although because I was working on the project and had a pretty in depth understanding of what we were doing, some things that I thought were sufficiently explained may not have been.  This is where I see the importance of testers who aren't directly involved with the project.

Overall, it was a good experience, and something that I think I need more practice in.  Working with people can be troubling but makes things so much better if you're good at it. <- main lesson for the day