Week 5 Blog


Chapter 10 is about agile technology, as its title implies. One of the first points the chapter covers is that the author was given an 80 page document detailing all the features the tool he was developing, which came as a surprise to him. It allowed the artists to detail what they needed, rather than leaving it up to him to figure out what the artists needed. However, the artists ended up not finding much use in the tool, as they didn't have the foresight to know what they wanted. Agile programming aims to fix this problem. Later in the chapter, it goes into detail on Extreme Programming, or XP, and its advantages and disadvantages.

Chapter 11 involves the use of agile methodologies for art and audio. Audio in particular I find to be an interesting subject in this regard, as the book mentions that the audio team is often delegated to doing work at the end. In my opinion, it would make more sense to develop the audio at the same time as everything else (which would be more natural to a sprint) as it could make the sound design part of the design process itself. Other than this, an important aspect of this chapter is the "One more day" problem where an artist might say that they could make something even better if they have only one more day- But you have to cut it off sometime, or else they'll be working on it forever.

Chapter 12 is about agile design. An interesting aspect of it that I noticed were the comments on the designer as a product owner. It lists a few pros and cons of this idea. One of the pros is that the designer most closely represents the end user and has a better idea of what they'll want. One of the cons is that designers often might get in over their heads and request ideas that are way above the potential scope.

For this week's progress on the Life or Death team, I found myself looking at getting the social media pages finally up and running. My plan as of now is to update daily with screenshots of the current build, and eventually add video. I already have the video ready, but starting small and getting bigger makes sense, and taking screenshots from my video is surprisingly easy.

I've found that my communication with the team needs improving a lot. Thanks to some life issues I've encountered, I've been unable to attend their meetings and while I'd still like to (and probably will at some point), I decided to take a different approach. I told every member of the team to, when they get a free moment, to send me a sentence or two about what they're working on so that I can potentially discuss it one on one with them and maybe make things easier for them. I've yet to discern how well this will work, but I hope it ends up being useful.

Comments

Post a Comment

Popular posts from this blog

Week 6 Blog

Chapter 14 is about the myths associated with agile project management. One that stood out to me in particular is that "Change is Bad", which is often taken on by studios that already have processes that work. This reminds me some of how the studio Rare once mentioned that they hired new employees who had no experience so that fresh ideas could always be brought to the plate to avoid stagnation. Another point that stood out is that not every person believes that Scrum works for them, and may leave due to this style being forced upon them, although some studios may choose to give them specific roles that do not involve Scrum. Chatper 15 is about working with a publisher. The chapter starts off with an example of how Nintendo handled new game ideas in the 90's, in which they'd search for fun first and would tell their outside company to scrap a project if the game they were currently making wasn't fun. This is definitely an agile form of development, focusing only...
Read more

Life or Death and Reading Post 1

Reading: Chapter 3 of the book covers how Scrum came to be in the modern era, what team roles are and how they should be allocated, and the core principles of what Scrum is.. The history in particular is fairly interesting. In the early 1900's, factories were synonymous with dehumanization. They required humans to become robots, working on a factory line with no input of their own. Following World War II, however, this began to slowly change, and finally in the past few decades, the concepts of Scrum started to arise. Scrum's principles include details such as Empiricism, Emergence, Time Boxing, Prioritization, and Self Organization. These are accomplished through Sprints, which are explained in more detail in Chapter 4. The team role that stuck out to me most was the Scrum Master. The Scrum Master is the one that encourages the team and does everything he or she can to make sure they succeed. This includes being stubborn enough to make sure the Scrum processes always go t...
Read more