During this sprint it was very much of a learning process there was a lot of things that we had to do to first get used to working with teamsters and also with figuring out the scrum since it was the officially first time we were working on it as a “professional “ setting. As we worked together, we learned what we could do better in the next sprint. One of the things that we changed how we reviewed and worked on things. During some of the issues, we would assign a review and then have the review, review it, mark it as done and then have the original person that worked on it merge. That we learned took more time and there was more margins for error, therefore we decided that the reviewer would review and then they would just merge it and mark the issue as done. Another thing that we talked about improving on the team is communication, over all we had good communication but here and there we would forgot to say something about what we did and we had someone work on it doubled. Another thing we decided to do during this spring is when issues arise about during something we are working on to send it in the group or keep it in writing so that when it is time to come up with issues we have those to go back too. Since this time around when we were done with the sprint and it was time to write new issues we spent a lot of time going back and refreshing especially for the things that were in the initial part of the sprint. As an individual, I am trying to work on your review the issues as soon as it gets tagged. Sometimes it is hard because of my work schedule but I am trying my best so that if something does need to get fixed, that can be done as soon as possible so that we do not get behind. I think that this sprint even though we have more issues it will run more smoothly since we now know how the structure is and how it is supposed to go. A lot of last spring was figuring if the structure was right and if what we were doing was right. But now I feel more comfortable.
This was the issue that was used to plan out the test to make sure that the front end is compatible with and user friendly for this I had to do some research.
Like the one above this was our non program ones, where we researched and came up with ways to enchance the checkInverotryfrontend
This issue was to move commands and make it bins, we had a few of these and we separated it to team mates, mine was the ReportingAPI
This issue was set up to work with VSCode in Gitpod, since before we used devContainers, this was to switch it to gitpod
This was one we worked as in a group and thought that it was going be easier ended up being harder than we thought there for it carried on to the second sprint
From the blog CS@Worcester – CS- Raquel Penha by raqpenha and used with permission of the author. All other rights reserved by the author.