Sprint 2 Retrospective Reflection
In this blog post, I will reflect on the second sprint of my capstone project. I will discuss what worked well, what didn’t work well, changes we can make to improve as a team, changes I can make to improve as an individual, and I will end by listing links to the work I have done with descriptions.
To start off discussing what worked well, one of our biggest accomplishments, if not our biggest accomplishment (in my opinion) was successfully creating a functioning docker image that we were all able to pull and use on our individual laptops. This was a big milestone for us because during sprint 1 we were running into compatibility issues and had no standardized way of creating and sharing code with one another.
For things that didn’t work that well, I would like to bring up something that was a common theme in our retrospective meeting: our lack of regularly documenting our work. I think this was something that we started off on the right track at the beginning of our sprint after having discussed this as an important thing to do in our first retrospective meeting. But with spring break, the week we had off from class, we fell back into the habit of doing work without documenting as we go along. Another thing I would like to mention for this category were the issues we created that started with “Learn to…”. By creating these kinds of issues, it made it difficult to deliver something tangible as it relates to our capstone project. While there was a lot that we learned, it should be represented in the future by applying our new knowledge in a practical way. Lastly, I would like to mention that although we had a functioning docker image to use, it has been incredibly slow to use while on campus/in class. There were classes where I felt like I was simply working on setting up my container just to shut it down by the time class was over.
In our retrospective meeting, one of the big things we discussed we could all improve on as a team is thoroughly knowing our issues board. As a team, we should constantly be reading, updating, asking clarifying questions, and breaking down issues into manageable steps. Part of me was afraid of touching issues that my peers created because I didn’t want to change their original idea, but it is exactly this collaborative process that is needed to create a productive sprint. Doing this clarifies the work at hand and prevents things like creating duplicate issues.
When it comes to changes that I can make to improve as an individual, my goal for sprint 3 is to use my class time more effectively. This last sprint has taught me that it is especially difficult for me to dive into my code when my peers are around me. Some of the best technical work I have done comes from me working in an independent, library-like environment. Because of this, I will focus on using daily standup meetings and my class time as an opportunity to get very comfortable with our issues board. If there are issues that require further details I can add them in class and if there are questions I need to ask my peers about issues they’ve created I can ask them in person. I believe making this small change will be more effective than spending my hour and fifteen minutes in class trying to code with intermittent distractions that may pertain to the capstone, but do not always pertain to what I’m coding.
Links to evidence of activity on GitLab with descriptions:
https://gitlab.com/worcester/cs/naturalization-interview-confidence-environment/demo-react/-/issues/21
I created this issue.
While I did not post the comments on 3/1, I helped Sofia write the comments where we created smaller steps on how to go about setting up a Docker image with the React Native framework.
While I did not post the comment on 3/14, I encouraged my teammate to write up the documentation on creating a container for React Native and the third party application, Expo. Additionally, I followed the steps in case there were any clarifying edits that needed to be made.
https://gitlab.com/worcester/cs/naturalization-interview-confidence-environment/demo-react/-/issues/22
I created this issue.
We learned that adding the extension ID of the dependency in question, along with its version, to the package.json file is how we go about adding/removing dependencies to a Docker image.
https://gitlab.com/worcester/cs/naturalization-interview-confidence-environment/demo-react/-/issues/23
I created this issue.
I responded to my classmate by adding a clarifying description to this issue.
https://gitlab.com/worcester/cs/naturalization-interview-confidence-environment/demo-react/-/issues/24
I created this issue.
I had a conversation with Sofia on how another issue essentially covers the basics of this issue so it was redundant to have both. As a result of this conversation, this issue was abandoned.
https://gitlab.com/worcester/cs/naturalization-interview-confidence-environment/demo-react/-/issues/25
I created this issue.
I created a clarifying description with steps for this issue.
