Skip to main content

Sprint 6 Retrospective

At the very beginning of this sprint, on April 25, Mia was able to push the portion Dan worked on (“Tabs2”) so that we could all see it. Up until this point, the rest of us were not on the same page. We were looking at a previous one we had come up with. We were instructed by Mia to hang tight until she was able to push it.

Ryan and I were both unsure whether she would be able to, so we talked about doing it from scratch. That night, I started the process, but I didn’t get far before Mia let us all know that she was able to get it pushed. At that point, the majority of the component was done. I noticed that the button to create new slides was broken. It was a small fix, but I was able to fix the bug.

Most of this past week was preparing for the presentation. I feel somewhat that I was under utilized and that I could have done more. It is not that I did not want to do the work. I offered often to do more. Once I was able to see the component, most of it was done.

I suggested starting development for another component both before the first was completely complete and after. I was discouraged by my team from doing so. I feel like if we had, we could do at least one more component. I feel that even if we got a start and was unable to finish on another, it wouldn’t be much of a loss.

In the last retrospective, I felt different and that we should just focus on one thing and do it well. I did not realize how far along we were. (Again, I was not able to see it.) I feel that we could have easily done another component in this last sprint and a half. However, hindsight is 20-20, and I didn’t know then what I know now. This was the first time any of us had done something like this, so none of us knew what to expect.

Despite my regrets for not being able to do more, I feel this overall has been a positive experience for this entire capstone. I will be able to take what I have learned here and apply it to the next scrum team I work with. We have not been perfect in communicating, but we have done a pretty good job overall in keeping each other updated. I think we all have seen where we have fallen short, and I think we can use our failures as learning experiences.

Some of our problems came when one of us would run into a problem and the rest of us could not see what they were dealing with and, at the same time, be relying on that work. It would create a bottleneck. It was very frustrating for me to not be able to help in any way when it came to this. I am not the kind of person who likes to sit idly by when I feel I could be of some help.

What I can say about my team is that none of them are slackers. It isn’t often when I feel that I am not the one shouldering most of the work in a group project. This was a welcome change of pace, even if I wanted to contribute more. I found that in a group like this, I should have taken initiative sooner and more often. That lesson will be crucial to success in my next venture.

Comments

Popular posts from this blog

Testing: Like Destroying Sandcastles

https://joecolantonio.com/testtalks/223-testing-dream-journaling-smashing-sand-castles-with-noemi-ferrera/ In this blog for software quality assurance and testing, I decided to return to the “Test Talks” podcast, presented by Joe Colantonio, for another episode (#223). In it, he sat down with Noemi Ferrera, a software tester for a Chinese mobile gaming company to get her take on the subject. Noemi gave a few interesting metaphors that I appreciated for how to look at testing. In one, she gave the example of going to a movie where you had already read the book. It was different than how you imagined it while reading it, and testing is a way of making the “movie version” fit the way you envisioned it playing out.  The other metaphor for testing that she gave was, if you were children at the beach, the developers would be the ones building the sandcastles, whereas the testers would be the ones destroying them. I don’t know if that would be the most accurate way of looking at

Facade Design Pattern

For this week’s blog on Software Architecture and Design, I will revisit the same assignment that I have blogged about before. For the assignment, I had the option between three design patterns to write a tutorial for. I picked the proxy design pattern, and then I blogged about the decorator design pattern. Now, I would like to watch a tutorial on the third design pattern, facade, so that I might learn about all three. I chose to use the same YouTube, Derek Banas, that I used before for the other blog. I found his videos engaging and informative that I would like to learn about it again. I also like that it is fairly concise (11.5 min), which makes it much easier to rewatch sections that I don’t get the first time around.  It turns out that I did not understand it after finishing Derek’s video, so I turned to another video by another Youtube channel by Christopher Okhravi. Derek went straight into coding, whereas Christopher just drew diagrams and did not code. I needed more

Decorator Design Pattern

For this week's blog on Software Design, I decided to watch a short tutorial on one of the design patterns I didn't pick for a previous assignment. I picked Proxy Design pattern to cover before, and now I'm going back to learn about Decorator Design Pattern. It is only a thirteen minute video, so I won't be going as deep as I would had I picked it for the assignment. I am also going to talk about my reflections on it rather than create a tutorial, so I am not going to reteach it to the person reading this blog post. The tutorial I chose was made by Derek Banas on YouTube. He used an example of a pizza parlor to illustrate the wrong way to code it by using inheritance. He shows the problem with this because you would have to create a very large number of subclasses for all your objects (in this case pizzas). Composition, on the other hand, is a dynamic way of modifying objects. Instead of creating as many subclasses, you add functionality at run time. It has th