So, ever since we have worked on teams at Champlain, we have used Redmine as our project management system. Everyone has either learned to love it or hate it, but at least learned how to use it. However, none of that matters if nobody decides to use it in a proper way. Looking at the taskboard should be something to judge the progress of a team in the current sprint. However, when I see it, all I see is User Stories with no tasks, incredibly broad tasks that are marked as “In Progress” and many completed tasks with no one assigned to them. Everyone says they are doing Agile development, but they usually admit that they may not do certain parts of it. However, right now it seems we are doing our own development practice, and have decided to use they things from Agile development.
When being told that User Stories don’t work, something seems amiss. It’s true that User Stories don’t work when people just create them at any time and is seen as a gateway to being able to log time on a task. But if there was time spent planning before the sprint started to make sure everything was created then User Stories are great. I think part of this problem stems from the fact no one is taught how to use Project Management systems to their full potential. How does a carpenter make furniture if he does not know how to use a saw?
For this current Sprint, we have essentially abandoned Redmine in favor of the “Get Shit Done List”, which is just an excel document with a list of things that need to get done. What it looks like however, is just a spreadsheet of tasks that could be made in Redmine. Each item has a name, description, who it’s assigned to, current status, and priority. All of these things are fields for a Task on Redmine. Project Management is something everyone on a team should learn in order to be fully productive and allow everyone else to be working fully functionally.
For the entire semester, the way programming duties have been split up is between gameplay and engine rewriting. Coming into this semester, the majority of Dan Shredder was written in Blueprints, and it showed, the game could not run at 60FPS on anything except for the lowest graphics settings. The goal of the C++ transition is that it would help us reach the goal of having the game run at 60fps on the highest graphics settings. Today we decided to cut the rewrite that was being worked on for over five weeks.
The visible progress that we had on the C++ rewrite in those five weeks was very little. Externally, there was none, internally, we were only getting to the point where the game would be playable, but not in the way it was currently. The player could strum notes and songs could be played and all these individual functions were written. However, when it came time to start putting everything together, things starting breaking left and right. One of the biggest perpetrators of this, was that every system was very coupled into each other, unable to be tested until other classes were done. For instance, the InputHandler class required functions in the PlayerGuitarController class to be written, which those functions required the Fretboard class to be written, which required the Note Receivers to be written. This might seem like a worst case scenario, layers of layers of requirements just to get one thing working. However, this was commonplace.
The hole that was metaphorically dug while doing this C++ rewrite was also very deep. So deep in fact, that I never actually came out of it. I entered that hole when other team members were thinking about what to do this semester, and how we want to move forward as a new time. I emerged from that hole to a different landscape, as if someone built a city on top of that city. The game itself looked completely different. Ideas that were just that were implemented into the game. There was a very real disconnect between the C++ rewrite team and the rest of the team.
The problem with a hole is that by the time the hole is fully dug, there needs to be more added. We realized that by the time we rewrote the entire game, we would have to rewrite the new features that were implemented to work with the non- C++ code. And by the time we were finished with that, there would be new things to write. We would always be playing catch up, never fully being caught up to the rest of the team.