Project Aetherial Blog Three
|
Introduction Time for blog number three! The ALPHA is behind us and we look forward unto the second playtesting session and the BETA. After two blogs describing the design and creation process of enemies in the game, this week’s blog will venture into the topic of scrum. I will mention the pieces of the development procedure which I appreciate the most. Before this course, I personally had no experience working with scrum and if I had to guess, none of my teammates had either, so it has been a mutual learning journey. I suppose we also still have much to learn about the system and can only hope we follow it as “correct” as possible. Planning the work By having the sprint planning each week you have a clear overview of what is most important to complete that week and, considering we are two graphical artists in my team, who should do what. We thought the issue of dividing work was important, as we from week one decided who should do what art assets and which to create together. If I should be self-critical of my team, we have been poor at approximating the time each asset takes. Both when planning and doing reviews, the work time approximation has been vaguely answered and less prioritized. The team has also had times when quality assurance has been lacking. At times either the “wrong “person has checked off an asset, or the assigned person has been difficult to reach for an approval. I think we can further enhance our planning and lower our stress levels by being more proper in these areas. Reviewing the work With the sprint reviews closing the week’s work, you get a clear view of what has been done and if it meets the teams’ collective expectation. It is also a good way of estimating how much the team can handle per sprint, and if the team should put less, more or the same amount of assets into the following sprint plan. The sprint review is also a good time to look towards the next sprint and start talking about what is needed then. This ties together with the product backlog, which is a useful overview for all the games’ features. I suppose, without the product backlog, keeping track of all assets would be a more intricate matter. Without scrum Considering I have not done any game production with or without scrum before this, it is difficult answering how the development would be without the use of scrum. I can only mention what I appreciate about scrum and what it has taught me. Also, an important fact to know is that my teams’ work environment has not been the best, and a lot of time has been lost to arguments and “conflicting interests”. Therefore, our team may not be the best role-model when it comes to effective development. Still, I can see the positive aspects of adapting scrum, as I mentioned above with planning, reviewing, and keeping a backlog. I also suspect the daily standups are platforms for a better team dynamic, even if that unfortunately has not worked for my team. All in all, scrum is presumably a good tool for structure and teamwork. The big problem with my team is that we mostly have focused on taking each step forward and not completely be torn apart. That was a distressed note to end upon, but I can only look to the future and hope we will come out of this development stronger and more experienced than before! Thank you for reading!  |