Gitlab activity:
- https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem-weight-based/inventorybackend/-/merge_requests/59 – Most important change was: console.log(“Updated inventory”, updatedInventory); to console.log(“Updated inventory”, inventory); This allows AddInventoryFrontend to make PATCH request to inventorybackend to update inventory weight. This merge request fixes the issue from Sprint 1 where the weight wasn’t able to actually be updated
- https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem-weight-based/addinventoryfrontend/-/merge_requests/39 – This merge request addresses logic errors regarding the weight of the inventory (weight shouldn’t be less than 0, and also ensures communication between the frontend and backend is working)
- https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem-weight-based/addinventoryfrontend/-/merge_requests/40 – This merge request implements a pop-up in AddInventoryFrontend which gives users examples of accepted values to add weight with. A regex was also used to ensure no invalid combinations were allowed for submission (submit button greys out)
- https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem-weight-based/addinventoryfrontend/-/merge_requests/41 – This merge request implements a confirm pop-up in AddInventoryFrontend when users press the submit button for adding weight. They can confirm, which then makes the request to the backend, or cancel and then change their entered value.
The most important thing that worked well during this sprint, as addressed in all of the Team Project Effectiveness Reports, was communication. Our team communicates really well in person, and online after class. We use discord as our primary source of communication and everyone is really prompt in responding, whether it be in regard to simple questions or chronic issues that one of the systems is causing a team member. The use of the issue board in Gitlab improved during Sprint 2, which allowed the team to keep better track of what was happening, and more importantly, getting completed during the sprint. This allowed us to easily showcase our work during the Sprint Review because we were able to just look back at the issue board.
The primary thing that didn’t work well this sprint was a clear idea of the work that should actually be getting done. Plenty of work was completed, but it was done on a basis that should have been pre-defined. Doing work as we find issues or come up with ideas is not the most efficient way to make beneficial changes to the “InventorySystem – Weight Based” and we need to work on this.
Establishing stricter goals for the sprints will allow us to complete more meaningful work. This is the biggest change I think that needs to be made as a team. Personally, I think my best traits are ensuring that everyone’s voices are heard, and I’ve gotten positive feedback in this regard, and that my teammates are always informed of the work I’m doing. The team has decided that I should remain scrum master, and to fulfill my role, I will encourage us to define the stricter work goals that I previously mentioned.
Relevant Apprenticeship Pattern:
The pattern I have chosen to describe Sprint 2 is “Rubbing Elbows.” This pattern states that the act of collaboration can be referred to as “rubbing elbows” and if you reach a plateau in your individual abilities, collaborating with others may help you continue making progress. It is obvious that collaboration is taking place as this is a group project, but sometimes it is apparent that team members, myself included, struggle with our own work. I chose this pattern because I noticed the prevalence of it today actually. I was working on updating the design elements of AddInventoryFrontend and couldn’t figure out why my changes weren’t being made in the browser. I would’ve pondered over this issue for more minutes than I’d like to admit, but I “rubbed elbows” with Guilherme and was able to notice that merely a single line of code needed to be changed. Being more aware of this pattern during Sprint 2 probably would have encouraged more pair-programming, the use of the TV, or rubbing of elbows to navigate issues. The work doesn’t have to entirely be done alone. Overall, if stricter goals are defined for work that needs to be done, and we emphasize a greater sense of collaboration in class, Sprint 3 will hopefully reap the most benefits in terms of code contributions compared to Sprints 1 and 2.
From the blog CS@Worcester – Shawn In Tech by Shawn Budzinski and used with permission of the author. All other rights reserved by the author.