Dev Blog #3 -How We Work
|
Hello again! This week I will be writing about how our team works during the game production, which we do by follow the Scrum framework. Scrum is an agile framework especially tailored for software development, so naturally it works very well for game production as well. When working with Scrum, the goal is to often and continuously produce increments/a shippable product, in this case working versions of the game. To do this, we work in sprints. Under normal conditions a sprint lasts between 2-4 weeks, but since our project is only 10 weeks long our sprints lasts for one week. At the start of each week, and each sprint, we have a sprint planning meeting. During this meeting we decide what we want to accomplish this sprint, and then we pick features from our backlog that will help us achieve our goal. We make sure that each team member accepts the tasks given to them, and we always strive to get as close to 20 hours of work each sprint as we can. At the end of each sprint, which is every Friday, we meet for a sprint review. During this meeting we go through what we have done this sprint, review what went well and what we struggled with, and the group as a whole reflects on how the sprint went overall. For our current sprint we are working on implementing all of the features we want the game to have for the beta the 5th of March. Personally I favour Scrum over other approaches. I think it’s partially because it suits my individual style and work ethics, but also because I see the results from developing a game using Scrum. This framework has allowed team Devourer to be very efficient, much more so than when we designed our concept document last semester. However, I don’t think we have followed the framework 100%. The reason for this is that when we have our sprint planning meeting to decide what features to work on that week, we simply pick what we believe we need, without considering the user stories. Why do we not just make our lives easier and pick a user story each sprint, I hear you asking. Well, honestly we didn’t actually have any user stories in place when we began our first sprint, and since then we didn’t pick up the habit of using them. I also feel like the team’s understanding of user stories was fairly limited when we started out. I don’t think this has caused us any significant problems, and it hasn’t affected our work efficiency (so far!).  |