During this sprint, team one performed extremely well. Despite being a new team that is completely new to this project, everybody did their best to be as productive and cooperative as possible. I thought that the team operated efficiently and worked as a unit. We were able to come up with great methods to communicate, find issues, divide the labor, as well as a method to review and approve completed tasks. In the end we managed to finish the vast majority of our tasks and we are already preparing for the next sprint. Personally, I thought I did well during this sprint as well. I completed all of the tasks that I assigned myself, and I found the time afterwards to help my teammates with any issues that they were having with their tasks.

With that being said, we did struggle as a team trying to understand what the project was about. Most of the files in the project had little to no functionality, and the backend was basically missing. The backend was only a skeleton with placeholder files. The only things were able to do during this sprint was moving files around for organization purposes as well as spend time trying to understand this project. I personally had issues trying to understand how the architecture works as well as what some things do like RabbitMQ for example. I also thought that spent too much time with my tasks than I should have especially when considering how easy they were. Most of my tasks were just creating new folders and moving files into them.

I think our team has a lot of room for improvement. For starters, I think we need to spend more time during the planning phase of our sprints to fully flush out what we want to do and how we want to do it. For this sprint, we all had an idea of what we were doing, but I felt like we did not use Gitlab or Discord effectively to plan or communicate as we could have. Another area that I think the team could improve on is appropriately allocating the amount of time it takes. I did the most the tasks during this sprint, however, all my tasks combined took less time than some of the issues that my teammates were working on despite their issues having the same amount allocated to them as any of my issues.

I also had a lot of room to improve as an individual. For example, I could have spent more time outside of class trying to understand the project. For the future, I’m going to put in way more time outside of class trying to make sure that I am prepared. Another area that I would like to see myself improve is coming up with as well as creating better issues. I thought that the tasks that I came up with and created were too repetitive and minor. For the next sprint, I want to create and work bigger, more relevant tasks. Other than that, I thought that this sprint went well, and I look forward to the next one.

List of issues that I worked on:

Issue Community#59: I created the Documentation repository

Issue Community#60: I moved files from general to the Documentation repository.

Issue backend#3: I created src/endpoints folder in the backend.

Issue backend#4: I created src/data folder in the backend.

Issue backend#5: I created src/lib folder in the backend.

Issue backend#6: I move items.js into src/data in the backend.

Issue backend#7: I move endpoints.js into src/endpoints in the backend.

Issue backend#8: I move config.js into src/lib in the backend.

Issue backend#9: I move database.js into src/lib in the backend.

Issue backend#10: I move logger.js into src/lib in the backend.

Issue checkoutguestfrontend#3: I created src/id-input-field/assets and src/id-input-field/components folder to aid with organization.

From the blog CS@Worcester – Fadi Akram by Fadi Akram and used with permission of the author. All other rights reserved by the author.

With the end of my first ever sprint experience, I would like to reflect back on what worked, what didn’t work, and what changes could be made. To be honest, I felt like we were kind of just thrown into the first sprint with little time to prepare, but as the sprint progressed, my team ended up getting the hang of it. As a team we managed to create enough issues to work on throughout the sprint and everyone took up different issues to work on. We were swift to approve merge requests and review other members’ changes, so I think we worked efficiently on that part. 

As for me individually, I took on three issues, all of them involving the rearrangement of the file structure for each of the frontends. Issue #3 involved refactoring the file structure of checkInventoryFrontend where I based it off the MicroServices example. Issue #4 involved refactoring the file structure of addInventoryFrontend where I based it off the MicroServices example. Issue #6 involved refactoring the file structure for CheckoutGuestFrontend where I based it off the MicroServices example. I didn’t have much of a problem with them, as they were not complicated to complete.

As for what didn’t work well, overall, I think we as a team spent a lot of time trying to understand what everything was supposed to do. From each of the frontend to the backend, there was basically nothing implemented nor functional. I think because there was the daunting task of having to create the inventory system from the ground up, I had trouble actually picking out what needed to be done for this sprint. That aside, we managed to dedicate this sprint to preparing the files for implementation so that we would be able to start working in the next sprint.

As a team, I think we were able to come together and get work done. Some of the members of my team are people I have yet to work with, but there was no issue there. I am happy that I was able to help a fellow teammate resolve an issue they were having with the API. Aside from that, there was not much else communication between teammates during work periods as everyone was focusing on more individual tasks. This first sprint was more focused on the housekeeping tasks so there wasn’t much need for collaboration in the first place. I think in the next sprint, we will be able to greatly benefit from more communication and asking for help when needed. 

What I can improve on individually is to come up with more meaningful issues. This last sprint, I only created a handful of issues, all of them involved creating or moving files around. Now that this coming sprint will be more hands-on, it will give me a chance to come up with more specific issues, focusing on parts of the project that need to be implemented. I would like to work more efficiently, finishing issues within their estimated weight time. Overall, I am looking forward to the next sprint now that I have an idea of how the entire sprint process goes.

From the blog CS@Worcester – Null Pointer by vrotimmy and used with permission of the author. All other rights reserved by the author.

Overall, with my work on the issues listed below, I think that the methodology of using the GitLab boards worked really well for us as a team, allowing us to pick which issues we personally wanted to tackle and notify everyone of what was currently being worked on. I also think that the methodology that we figured out as a group of requesting someone to check over our commits before we merged the branches worked really well.

Overall, I just don’t think we had a handle on the project when we made the first set of issues, so a lot of them were undefined and others really had no purpose. Our first sprint had no real direction and was just a bunch of random issues that we thought we had based on random comments in the code and what we thought should be done. This lack of direction, I feel, really hurt our productivity as we were focusing on things that had very little to do with each other and were just in there as things that could be done to grab some extra time units that it seemed like we needed. I also don’t think we communicated enough over the course of the sprint as to what everyone had done, which caused a bit of confusion. I also felt like I personally didn’t do as much as I would’ve liked, as some of my issues fell flat and left me feeling like I hadn’t contributed as much as I would’ve liked. The biggest issue we ran into on the technical end was the fact that our backend had almost no functionality at all, and needing a backend in order to properly try out and work on frontend behavior really put a damper on the amount of progress that was possible for us.

To improve our team issues I think we just need to flesh out what we need to do as a group, in order to fully grasp the scope of our sprint and what functionality the project needs as a whole. We also need to flesh out how we want to handle organization in terms of the file hierarchy and structure within the repos, as well as a proper naming system. These issues would be easily possible with a refactor I think. This first sprint was really a trial run, in my opinion. We are slowly figuring out and narrowing in on what needs to be done to get this thing working and finding examples to go off of to start to create some real functionality.

As an individual, I think I need to communicate more with the group and see if anyone else needs help, I guess so far I haven’t felt like as much of an active member as I would have liked. I also need to be less rigid about issues and not feel like I can add them as they come up because sometimes I feel like I shouldn’t add things to a sprint that is underway because of the seeming rigidity of SCRUM. There are things that can be done and issues that can be added or modified over the course of the sprint, at least I think there should be. I just need to let go of my personal hangups with SCRUM in order to work more effectively with the team. That and manage my time better, as this sprint, I kind of dropped the ball.

Issue #17 This issue represents work done by Sebastian and I trying to figure out how the backend worked, and our conclusion that it needed to be completely rewritten

Issue #62 I added dev containers to each of the repos of the project, however they may need to be updated as we go.

Issue #16 This was abandoned after figuring out that the file the comment was part of was just copy-pasted as a placeholder.

Issue #15 This was also based on a comment about a file being used as a test, I moved it to its own folder but have determined it has no functionality, but we will keep it around just in case we need some of the code.

From the blog CS@Worcester – Kurt Maiser's Coding Blog by kmaiser and used with permission of the author. All other rights reserved by the author.

During this past sprint session my team and I worked on the LibreFood Pantry Identity and Access Management System. Our goals in this sprint were getting a KeyCloak implementation going and building a small API to work with keycloak and LibreFood Pantry. The first issue I created was designing our API (what endpoints should it have and what basic structure should it have). This issue had a weight of one and I was able to complete it between class on Wednesday and the following class on Monday. This involved creating the LibreAPI/src folder and using NPM to initialize the folder with a package.json file and manually add the folders. The next issue I created was to begin creating the API and writing code. This step involved watching a lot of videos and reading tutorials on how to implement a simple API. The API has two basic functions: Post a string and get an array of all the strings. Two YAML files were created in order to service the endpoints using OpenAPI implementation. I also created an issue on linking KeyCloak with our API and put in in the backlog until there was more research available and I would be able to have the other team mates catch me up on their KeyCloak information. 

Our team divided into two sections: I would work on the API, Mike would start with frontend and backend files then join me in API development, George (our scrum master) handled creating all the legal documents and licensing/documentation, Andrew and Gracia did research on KeyCloak set up and implementation. The research documents were very helpful when it came to better understanding KeyCloak’s structure, function, and how we could link it using a JavaScript adapter. Overall, the division of team labor felt fair when allocating individual team tasks. Having two students focus on development (Mike and I) and the rest of the team handle KeyCloak kickstart (George, Andrew and Gracia). KeyCloak is a very large system and there was a lot of research that needed to be done before we could begin a simple implementation. 

As an Individual I want to improve the way I communicate with my team and try to keep my focus narrowed in. During group meetings, I would find myself asking questions to the research team about KeyCloak that are very off topic from the current discussion. In reflection, I think this may sometimes throw off the group discussion and put my teammates “on the spot” to mentally shift gears to what I’m asking to try and best answer my question. I think this throws off the workflow and next sprint I plan on writing down questions that come to mind as I am working and near the start of the meeting (possibly during my stand up) and chip away at questions during that time, or bring questions up when they are relevant. 

As a team I believe we worked very well together. We all have a true interest in this project and put in a lot of time outside of class to get things done. For this next sprint, we plan on all focusing on getting keycloak up and running and will revisit the code we worked on once we get past our current roadblock which is getting one instance of keycloak to work and use that as the basis for our project. One way we can improve as a team is to communicate more outside of class via discord channels and also communicate with other teams.  We are in the same classroom as other teams working on LibreFood Pantry and our project needs to be linked together with everyone else’s work by the end of the semester. This means we need to take more time to talk with other teams during class or via discord voice channels. 

From the blog CS@Worcester – Site Title by lenagviaz and used with permission of the author. All other rights reserved by the author.

The outcome of the sprint was excellent. We wanted to get a working frontend and a working backend, and we had to familiarize ourselves with the code from last semester. The state of the project did not have a fully functioning frontend, and the backend was not working at all. The goal of this sprint was to clean up the existing code and make the current features work as they should. The nature of this sprint was to set up the GuestInfoSystem front end and back end, and we did well on that. We added several features, but a majority of it was refactoring existing code.

One of the workflows we struggled with was managing branches while we programmed. Because there were three people on the front end and three people on the backend, multiple people worked on the same area of code. The workflow that emerged, especially on the backend, was creating many branches from other branches. The effect of this was that we had a diverging codebase that was difficult to merge and maintain coherence. For example, a branch created from the main branch was to add JSDoc. Then we needed to update an API path, and a branch was created from JSDoc. An individual continued to work on the JSDoc branch while someone else worked on a new branch from this one. Creating a new branches from an existing branchx continued a few times, and updates to the code were scattered. New code was mixed with old code in each different branch.

To not have this issue reoccur, we will be changing our workflow for managing branches. What we will do for the next sprint is make a single branch for each issue and merge it into the main branch following it has been reviewed. If a significant feature needs adding, we will create a branch for this, and multiple people can work on it at once. If there are multiple active branches, we will ensure that one branch does not modify the area of code in another branch. By working on small features and performing common merging, we will make sure code is not lost and each member is working on the most up-to-date code at all times. It was difficult to do this during our initial sprint due to the amount of code that needed to be rewritten to get the backend working. In the next sprint, we will follow this improved workflow.

A change that I will make in the next sprint is to improve the issue creation process. The issues that I made for this sprint were overly broad, and the weight did not fully capture the issue’s headline. For example, ‘Add JSDoc’ has a weight of three, but it sounds like something that could be done in one class period. This issue actually required defining the type for each variable used in the backend, defining function input and output types, and creating object types for each object in the backend. This process involves studying the code, assessing the proper type for each instance, typing each file, and ensuring the types selected do not throw errors between files. What I could have done to improve my issues by creating smaller issues for each of these steps. Each one of these issues could have been done in the same JSDoc branch, but each small issue clearly defines what is being worked on. Following the closure of JSDoc related issues, the branch could be merged into main.

From the blog CS@Worcester – Jared's Development Blog by Jared Moore and used with permission of the author. All other rights reserved by the author.