Skip to main content

Sprint 4 Retrospective (Capstone)


This sprint, in my mind, one of the most important things that I was able to figure out was getting connected to AMPATH team through the Zeplin app. It seems that someone, perhaps accidentally, disconnected me from the group. Once reconnected, I was able to connect the rest of my group.

Although it hardly was a difficult task, it is hard to overstate how important it is to be on the same page as the team you are building the product for. It could have prevented a lot of wasted time on our end, and it makes it more likely that they get the end product they want.

Probably the most important thing I did in terms of learning about the tools we will be using was creating a “spike.” It is a new term I’ve learned that I will add to my lexicon, meaning to build a prototype of a product, diving deep to learn as much as you can. I touched upon it in my last apprenticeship patterns blog post, on “breakable patterns.”

I failed to make a successful working prototype that did everything I wanted. It seems that I have less knowledge of how all these work together than I thought. This brings to mind the apprenticeship pattern mentioned earlier, “breakable patterns” — I leaned through failing.

I will return to the Angular “Tour of Heroes” the next day or two to fill in the gaps in my knowledge. I don’t think there’s very much that I’m missing, but what I am is important to making it work. I would like to do this as soon as possible to be as much of a useful contributing member of the group as I can be.

Last retrospective, I was optimistic about how much we would be able to do this sprint. In truth, I am a little disappointed that we were not able to complete as much as I hoped. I am still optimistic about what we can accomplish coming up, but I have to bear in mind there are only two sprints left.

I am hopeful we will get a lot accomplished, but I have to be realistic that it might not be as much as I would like. This is the time where I should be thinking about buckling down and dedicating several more hours per week on top of what I already dedicate to this class.

I do have to keep in mind the learning curve we are experiencing when working on a team project like this. It took us a long time to just get the program to build and run on our computers. We didn’t hear what we wanted the final product would look like from AMPATH until relatively recently.

However, I think we are approaching the end of the end of that learning curve. Once our scrum team gets one component finished, I am confident the second will come a lot easier. It is reasonable to hope we are able to do a third, and maybe a fourth if we we split up into smaller scrum teams. Anything beyond that might not be wishful thinking, but I learned my lesson for setting my expectations too high.

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