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

Mark Richards on the Evolution of Software Architecture

For this week’s blog on Software Architecture, I listened to Episode 3 of the “Software Architecture Radio” Podcast, which featured Mark Richards, an independent software architect. He has 32 years in the industry, with more than twenty years as a software architect.  They mostly talked about the evolution of software architecture. Although some of the things they talked about went a little over my head, I was able to pick up on the majority of what they were talking about.  He divided up the evolution of architecture into five stages. He talked about evolution happening in vertical and horizontal slices, that is within each layer and one layer affecting those above and around it. The layers were (1) hardware, (2) software, (3) human interaction, (4) social interaction, and (5) the environment, such as the internet of things. He said one thing in particular, need, drives change the fastest. As an aside, he also said that that’s the best way of teaching something in this fi

Apprenticeship Pattern "Nurture Your Passion"

In this week’s post, I will be discussing the apprenticeship pattern “Nurture Your Passion,” as presented by Adewale Oshineye and Dave Hoover. I chose this chapter because I think I have felt like I’ve been just getting by for a while now. The  problem it identifies as, “You work in an environment that stifles your passion for the craft.” I don’t think that’s quite fair to my school or professors. I think that in any discipline, if someone is only studying for the tests or working on the assigned projects and calling it a day when they have passed them in, they are not truly adopting the apprenticeship mindset. Without a constant push forward, I will stagnate. I may get an “A” on the exam or project, but if I forget the material the next day, there is no point. The pattern suggests finding something that sparks interest and pouring myself into it. I have been wanting to do this for a while, but I have made excuse after excuse of not having enough time. The next sentence in th

OOP Basics

For this week’s blog on software design, I chose to watch a video presented by Dr. Steve Bagley on some fundamentals of object oriented programming (OOP). I’m embarrassed to say that although I am taking several upper-level computer science classes, I am unsure I would be able to give a good definition of what object oriented design was. To be fair though, it has been several years since I have taken CS 101, and it seemed like such a foreign concept at the time. I felt silly learning about something so elementary again, but it made a lot more sense when I’ve had as much exposure to OOP as I have now. For the video, he uses a game of “Pong” as an example of how OOP might use objects to represent the “ball” and “paddles.” From there, he talked some about inheritance and touched on a few more topics, albeit briefly. The main reason why I didn’t understand the benefit of this way of programming is that I didn’t know how else you would do it. I didn’t realize that without declari