For this sprint we decided to split up the work a little differently, as a group we agreed that we should switch what projects we were working on to get a better holistic understanding of the inventory system. This somehow led me to wanting to work on creating the entire inventory integration project here.
which completes this issue
I learned a lot during this sprint about the intricacies of each file and how they work with each other to create a working project and, at large, a system. I remember early on wanting to work on the frontend for the purpose of being able to work with visual design and UI but from working on the integration project I learned the skeleton and bare bones nature of what we are working on, even considered vaporware. Piecing this project together allowed me to realize what kind of work is required to have things up and running so I then realized I might have to hold off on wanting to work on that aspect of the front end, at least for now. What made it even more challenging was that I had to figure out how having multiple frontends changed creating the project as it was a bit different from other guest info and reporting. Even though I was able to use most of what other groups had, it required some time that was spent looking into the contents of the docker compose file.
Before I worked on creating the integration project I updated to the modern java script within the check out guest front end project, this issue was pretty straight forward and only required finding the right lines to change. Thinking that I was going to be working with the design and presentation I was mildly disappointed. I actually think that this issue and the integration project issue could have switched weight as making sure the integration project worked ended up taking much more time and research. The only thing that I think we can improve on is properly assigning weights to issues.
I think what is good is that a group member and I traded the scrum master position for the sprint, he did good and kept the team working well even through some struggles. It led me to wonder a little more about how other groups or even in the industry how people approach the scrum master position, even wonder how well a team functioned based on the certain characteristics of the scrum master. During this sprint we played around a little more with the projects that we were working on and even the structure of the class, which ultimately made working through the struggles that much more enjoyable.
This last sprint was a whirlwind of emotions and struggles for a variety of different reasons. While reflecting for some reason it appears to me that I felt the need to do individual work during this sprint, which probably isn’t the most productive idea while working with a team. There is a lot that can be taken from this; I have a strong tendency to often go out and explore myself, that I should be a bit more cognizant of my own impulses, and that there’s always a good time for some play. I think I could’ve changed what I was doing so that I could help my group members with what they happen to be struggling with at the time, and that was something that was taken into the next sprint. Overall, this was a very enlightening and insightful sprint that helped me understand the work that it takes to develop software.
From the blog CS@Worcester – Sovibol's Glass Case by Sovibol Keo and used with permission of the author. All other rights reserved by the author.