As we just completed our first sprint, my overall thought is that we did very well, and we have learned from our mistakes. One of the things we did well was that we spit up the work evenly. Everybody had an issue they were working on at all times. And as a group, we agreed that we each did a fair amount of the workload. Another thing that went well is that we completed all of the issues we set out to, from the beginning. Another thing that went well was the merging workflow. With the exception of the first week of development, we were able to complete issues, and merge to main with minimal merge conflicts. How we were able to do this, was making sure we had the most current version of main, before commiting, and making sure to stay within the scope of the issue while coding. Overall I am pleased with our performace, but there are some things that did not go as well, and could be improved upon.
One thing that did not go as well was our communication in GitLab. We were mostly discussing our issue in person. So the discussion within the issue descriptions were not showing the entire story of an issue’s development. We were also relying too heavily on discord, instead of using GitLab comments. On a related note, many of our issues in GitLab were not named clearly. We also had issues that were created in the wrong project. Our naming conventions in general need to be standardized moving forward. We can also improve on only having one person working on an issue at a time. There are a few things we can improve on outside of GitLab communication.
One unrelated thing we can improve on is keeping our stand up meetings to the alloted 15 minutes. I know that this is very important in the real world. We can achieve this by staying on topic, and by not interrupting each other. As a group we have discussed how to improve moving forward. But in order to work effectively, I also need to consider how to improve as an individual.
One thing I can improve upon is staying on task when working on issues. In independent projects, or larger academic projects I did not use issue based Scrum development. So I could jump from one method, class, or subproject to the next, as I realized I would need them. This is not an effective strategy for large, group based development work. During our first week, I had to review a yaml schema, and I decided to validate the yaml, using node modules. I ended up spending an hour doing work that I was not assigned to, and made changes to the branch outside of the issue. This was an important lesson for me, and something I will avoid moving forward.
Add Standard Files to API repository: https://gitlab.com/LibreFoodPantry/common-services/foodkeeper/food-keeper-backend/-/issues/3
Add Paths for CookingMethods and CookingTips: https://gitlab.com/LibreFoodPantry/common-services/foodkeeper/food-keeper-backend/-/issues/16
Test Class Template for Backend: https://gitlab.com/LibreFoodPantry/common-services/foodkeeper/food-keeper-backend/-/issues/19
The issue that stood out the most to me was creating the Test Class template for the Backend. It was really interesting to learn about Unit testing in node. We are using J Unit in CS443. So it helped me solidify that knowledge to see unit tests written in a different programming language.