Greetings everyone, I hope you all had a fantastic spring break. As we begin a new week, I wanted to take a moment to reflect on the recently concluded sprint 1. Undoubtedly, it was a unique experience for all of us as we delved into the real-world work environment. For many of us, including myself, it was a significant learning curve as we navigated the intricacies of our new job. However, I firmly believe that the challenges we faced during sprint 1 provided us with an excellent opportunity to develop our skills and learn from our mistakes.

Personally, I found myself drawing on the knowledge I gained from my computer architecture class in the fall of 2021. Although there was a long gap between that class and my current class, I was able to recap the essential concepts I learned in the CS-343 class, which proved to be incredibly helpful in my work. As we move forward with the next sprint, I am confident that we will continue to learn and grow, both as individuals and as a team. Let’s take the lessons we learned in sprint 1 and use them to make even greater strides in sprint 2.

As a team, we faced challenges during the first sprint, needing more time to learn how things work. However, we did our best to adapt and make progress. Moving forward, we will continue to improve our work process and complete tasks efficiently.  During the first sprint, I faced an initial hurdle with getting visual studio code and docker to work on my new laptop. Fortunately, my Scrum Master and Professor were extremely helpful in guiding me through the process, and I was able to overcome the issue with their assistance.

After resolving the initial challenge, I was able to focus on other aspects of the work, and I quickly identified a pattern that required my attention. I noticed that the variables in the code were being declared with ‘var,’ even though they did not change throughout the program. Thanks to the previous team’s efforts, I was able to change these variables to ‘let’ or ‘const’, in a little amount of time. The second issue that I encountered during the sprint involved removing MongoID from guestinfoAPI. To accomplish this, I had to delete the MongoID schema from the schema folder and remove the schema from the Index.yaml file. With these changes implemented, the guestinfoAPI was updated and functioning as intended. To resolve the third issue, I updated the code in the Dockerfile to replace the existing Swagger CLI image with a multi-architecture version. This was done to ensure that there were no issues running the code on my M1 laptop and to ensure compatibility with other devices. By using a multi-architecture version, the code could run smoothly on different architectures and avoid any potential conflicts or errors.

To improve team performance in the next sprint, dividing the workload efficiently is crucial. This will ensure that tasks are assigned according to each team member’s skills and expertise, leading to a streamlined development process and successful outcomes.

Links to GitLab issues:

1. https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/guestinfobackend/-/merge_requests/62  “Change ‘var’ variable declarations to ‘let’ [or to ‘const’ when they don’t ever change]”
2. https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/guestinfoapi/-/merge_requests/92 “Remove MongoID schema for GuestInfoAPI”
3. https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/guestinfoapi/-/merge_requests/93 “Replace swagger-cli image with multi-architecture version”

From the blog CS@Worcester – Mausam Mishra's Blog by mousammishra21 and used with permission of the author. All other rights reserved by the author.

This week, the first sprint has concluded! And boy, there was a lot to learn and improve upon. For one, within my group, I was the Scrum Master, and it is a bit harder than I anticipated. I had some ideas to organize coming into it already, but sometimes, ideas don’t always meet with reality. At times, things were really effortless, and at others, they were rather difficult.

Some things that worked really well, was the overall organization. As a group, I realized that we were all heading into unknown waters, working with a code base that, though we had some idea of, in reality, we truly had no idea how much of it worked. Because of this uncertainty in many areas, I knew it was crucial to try and share our knowledge with each other as the sprint progressed. Some of the biggest boons, and though it was a bit of luck as well, was splitting our different members into the different portions of our issues.
As an example, we had a cluster of issues in our frontend, backend, and API that dealt with the same thing. Essentially, we had to update/add lots documentation, licenses, etc! This looked very simple at first, but there was some difficulty with clarity, since we simply weren’t familiar with what the specs were. We split three of our members into the three issues, and as we worked on the issues, I made a effort to make sure everyone is keeping each other updated, and this allowed us to realize that despite it being the same issue, we were actually doing things differently from one another. This allowed us to quickly establish what we should do as a group, and from there, we were able to progress forward without additional confusion.

Although things did work well because of our constant sharing of what we learned, not everything went smoothly. Some things that I tried to do as Scrum Master was make sure my group was not overly pressured or crunched for time. In my initial thoughts, I figured that we would have enough ‘brawn’ to sort out the issues with some commitment, and knowing how stressful a time crunch can be, I was very, very lax at times when important issues were being resolved. This relaxed attitude helped with the team morale, but it also did not do much to help with the issues and even stalled some issues. Moving forward, I hope to strike a balance between calming the team when things are not coming to a close, and trying to nudge them forward more when the deadlines are approaching.

As a team, I genuinely believe that we did very well. The biggest flaw in our teamwork, was not actually when we collaborated, but some team members doing things on their own, but these were only very minor issues such as changing issue names without telling anyone, which caused some confusion, as well as encountering a problem and trying to fix it without telling any other group members. Both instances, were very minor at best, and as soon as they were noticed, were stamped out already. Specifically, we know that moving forward, all group members need to try to communicate problems with the team before silently fixing them, and if a issue needs a new name, the new name needs to properly describe what the issue is.

Individually as well, I believe that I was very caught up with making sure that the team functioned, and though that was a great thing, it also negatively impacted my performance as an individual. I oversaw much of the progress, and was kept updated on how various systems worked, so I believe I have a good understanding of how the project works, but I have very little real work to show for it. Moving forward, despite being the Scrum Master, I have to not only manage the group and keep an eye on things, but also use my own abilities to push things forward.

Updating Dev container files
Updating/adding Documentation, licensing, etc

Finally, as much as there was lacking, I believe that moving forward, things will be much smoother. Our group has many great developers, and this was our first time doing a sprint. I already have many ideas on how to improve, and though it might be a bit of trial and error at times, we as a team, have all the ability to clear out our issues!

From the blog CS@Worcester – Bored Coding by iisbor and used with permission of the author. All other rights reserved by the author.

While there were some issues along the way, I feel like the first sprint was a success in the end. I ended up doing three issues with one done, and two issues still having problems and needing to be saved for the next sprint. The links to all three issues can be found below. The first issue I completed was update or add all doc, licensing, lint config, .gitignore, and .gitattribute to General, and I found no issues, so it was pretty easy, and did not take that long. The second issue was updating the pipelines, where I thought I completed it, but there was still more to do, so it was saved for the next sprint. My final issue was the same as the first but for the API, and I managed to finish it, but it had a problem from the pipeline, and needed to be saved for the next sprint as well. This blog will go over my retrospective thoughts of the first sprint now that it is over.

Throughout the sprint, there were many things that worked well. One thing that worked well was how our team developed a genuine camaraderie, which is important when it comes to teamwork. You need to have trust in each other that you will get your work done, and trust that we are there to help each other, and I think our team has developed that. Another thing that worked well was our communication during class hours. During the time we were in class, our communication was great, and we really helped each other out with our problems. Later in the blog, I will mention how we should find time to do more of it after class hours. Having these positives after the first sprint is great, and it can only get better from here.

There were also some things that did not work well throughout the sprint. One thing that did not work well was our time management. Every task we did ended up taking one weight over what we predicted. I think this experience will help this, and it will improve for the next sprint, so it is not too big of an issue. Another thing that did not work well was how one member made a change in the name of an issue, and it confused everyone else. We should be more open to the whole team for any little change made next time. We can definitely improve on these issues for the next sprint.

For our team to improve, there are plenty of changes that we can make. One change is having more communication from Thursday to Tuesday, as it is a long break to have no meeting with the team. We are planning to fix this by finding some time between the days to meet for an hour and check up on each other’s progress. If we have an issue after class Thursday, we won’t need to wait until Tuesday’s meeting to look for a fix, and waste all of the time that is precious in a sprint. Another change we can make to improve as a team is our experience. In the first sprint, we had no experience with sprints before, and it led to our issues. Now that we have the first sprint as experience, I think that will improve our team to better prepare for the next.

There are also many things that I could change to improve individually as well. One huge thing I could change to improve is my knowledge of VSCode and Docker. In the beginning of the sprint, I was having many troubles with the simple parts of VSCode and Docker, as I had not used it since Fall 2021. It got better throughout the sprint, and I am feeling more confident in my abilities now as we start the second sprint. Another change I could make to improve is to more quickly admit when I need help. There were many times during the sprint where I delayed asking for help, so I could try to fix the issues by myself. I think if I tried to come to everyone faster, it could have freed more time to worry about other issues. I think with the experience from the first sprint, I will be better with this in the next sprint. This first sprint started off a little rocky with inexperience showing up, but it ended with the whole team confidently looking ahead to what is next.

Issue Links

1. https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/reportingsystem/community/-/issues/96
2. https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/reportingsystem/community/-/issues/98
3. https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/reportingsystem/reportingapi/-/issues/8 

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

This was my first instance of using and being a part of the scrum workflow. Even though I knew how scrum worked from learning it in a previous class, I was still shocked at how enjoyable and manageable the scrum workflow process was. Our group was assigned the InventorySystem component of Thea’s Pantry. For this sprint, I focused on the CheckInventoryFrontend part of the InventorySystem. Our group did a sprint pre-planning, and we created issues for the “Convert all InventorySystem projects to new project structure” epic. I first made a sub-epic, made each bullet point its own issue, and then linked those issues to CheckInventoryFrontend (Link: https://gitlab.com/groups/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/-/epics/29). I will now go into more detail about what I have accomplished during the sprint. 

Evidence of Activity

Issue #1: Update devcontainer files

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/checkinventoryfrontend/-/merge_requests/10/diffs#6e656a06857650151f28f253233ed97584044098

For this issue, both the devcontainer.json and Dockerfile files in the .devcontainer folder were compared and updated to match the same files in the GuestInfoFrontend.

Issue #2: Update Pipeline/CI files

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/checkinventoryfrontend/-/merge_requests/9/diffs

For this issue, the .gitlab-ci.yml file, the Dockerfile, package.json, and Header.vue found in ./src were updated to match the already updated and working pipeline found in the GuestInfoFrontend.

Issue #3: All documentation, licensing, linting configuration, .gitignore, .gitattributes files must be updated or added

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/checkinventoryfrontend/-/merge_requests/7/diffs

In this issue, docs/developer and linting files were added, and the .gitattributes file was updated.

Issue #4: Revise directory structure:

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/checkinventoryfrontend/-/merge_requests/8/diffs

For this issue, bin was renamed to commands, files were moved from the top level into src, new commands such as build.sh were added, and some files and folders were deleted to match the GuestInfoFrontend.

I reviewed, approved, and merged the following issues:

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/checkoutguestfrontend/-/merge_requests/10

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/addinventoryfrontend/-/merge_requests/9

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/backend/-/merge_requests/17

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/backend/-/merge_requests/18

What worked well?

Working as a team went really smoothly during this sprint. Our team had three frontends that were very similar, so once one person who was working on a frontend was able to figure out how to solve an issue, they would be able to help the other members working on frontends. Communication between team members was also great. When one member needed help, myself and other members would communicate over discord to discuss and fix the issue.

What didn’t work well?

I feel like there wasn’t much that didn’t work well. Very rarely in class we would get off topic and start a conversation about something else like discussing what computer parts are good. That time could have been better spent working on the issues.

What changes could be made to improve as a team?

We split the work so that basically one person was assigned to a part of the InventorySystem. We could have picked up issues in other parts of the InventorySystem to diversify our knowledge on how the InventorySystem works as a whole.

What changes could be made to improve as an individual?

Changes that I could have made to improve as an individual would be to actively search for a solution to problems that may have arised. When updating the pipeline, the program was giving me an unknown error and the professor said that he would look into the problem. Instead of trying to solve the issue myself, I waited for the professor to figure it out. Instead, I should have been also trying to find the solution to the error.

From the blog Comfy Blog by Angus Cheng and used with permission of the author. All other rights reserved by the author.

For sprint 1, I did insufficient work. The only changes that I ended up contributing are in this commit, which adds a Node script that runs an example unit test on GuestInfoBackend.

Before this class, I had not written any JavaScript unit tests, I was not aware of any testing frameworks for the language. I assumed that implementing simple unit tests would be trivial. I ended up spending a few hours learning how to use the mocha testing tool and chai assertion library. Because I needed to make HTTP requests, I spent the rest of the sprint trying to get chai-http working in order to do something similar to the previous testing implementation that I wasn’t aware of at the time.

Many projects will export an Express app as a node module. This makes it easy to use the same module both as a listening server and to serve requests by some parallel testing environment. Because we instead define our own entrypoint in src/index.js, I was gradually exploring how to define a second testing entrypoint when sprint 1 ended.

Many of the changes that both I and the team need to make for sprint 2 are circumstantial. We understood very little about many of the issues early in sprint 1. Some were small syntax changes, but others required quite a bit of domain knowledge. We’ve since developed enough of that knowledge. Especially now that we’ve agreed to delay significant front-end changes to sprint 3, we have most of the information needed to be confident we can address most of the sprint 2 issues.

Personally, I was much busier leading up to the end of February, and didn’t always reserve enough of my weekend time to work on issues, which obviously just need to change for sprints 2 & 3. I also was slow to bring my chai-http woes to our professor, when he could have shown me the branch with most of this work done for me.

One change that I’m interested in is finalizing a collection of changes before pulling a merge commit branch. Sometimes we may want to swap to another issue without committing to the current branch or using git stash, and sometimes it became clear we should have split an issue into multiple issues. For sprint 2, we’ve found a work-in-progress workflow where we instead work on a local branch, and then, after we’re ready to push code, create the merge request and set the remote to that remote merge request branch.

From the blog CS@Worcester – Tasteful Glues by tastefulglues and used with permission of the author. All other rights reserved by the author.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/backend/-/issues/40: The documentation of the project needed to be updated for the Backend

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/backend/-/issues/41: The directory structure was outdated and needed to be revised for the Backend

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/backend/-/issues/42: The dev containers needed to be updated to reflect new settings and extensions for the Backend

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/backend/-/issues/43: The pipeline files needed to be adjusted to reflect new standard for the Backend

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/addinventoryfrontend/-/issues/11: he dev containers needed to be updated to reflect new settings and extensions for the AddInventoryFrontend

Our team worked very well together. We were always in communication on when we needed help and what work we accomplished. The standup meetings were efficient which allowed us to jump straight into the work for the class. Whenever someone needed help with an issue, there was at least one team member available to help out and solve the issue. The way the epics were divided allowed everyone to pick a project that they were comfortable working in, and helping each other out allowed people to delve into different project types.

While everyone was working in a project they felt comfortable in, the way we structured the work didn’t allow us to really experience different project types. I focused on the backend for the entire sprint, so I did not gain much experience in working within any of the front ends or the API. This caused issues when someone asked for help, we didn’t necessarily have all of the answers to help them.

Overall, the team accomplished a lot during the sprint. We completed all of our work before the sprint ended, which gave us time to fix a few major issues we ran into completing the last few issues. For the next sprint, we should focus on spreading out the work through the different projects so that one person doesn’t just work with one project type. The whole team should be experiencing the different projects so that when an individual, even if they are not from our team, should be able to respond and help with the issue. This will also help for future careers, as when we get jobs in the real world we can say that we have experience working in all different types of environments. The different projects also contain different languages which will help with development.

Personally, I put a lot of effort towards my team and towards our work. Next sprint, I should consider spending more time at home doing work so that more of the epic can be completed. I was available most times to respond to my teammates and any other individuals who needed help, but my out of class time could have been spent better working on my own issues and completing them. Now that I am the scrum master for this sprint, I can work on my leadership skills as I did not really show them and use them effectively last sprint. Overall I feel I did well for the sprint, and I learned a lot to be able to enhance this current sprint.

From the blog CS@Worcester – Noelan Chabot's Blog by nchabot1 and used with permission of the author. All other rights reserved by the author.

Sprint 1 is now over and overall I believe my team and I did a good job for our first sprint. I think there are lots of things we did well but there is still plenty of room for improvement. 

The first thing our team did that I thought worked well was breaking up and weighing our epics. We took the larger epics like updating the documentation or revising the directories and split them up so each problem subgroup would have one. This worked well because each team member got to work on a piece of each epic which gave a good experience to everyone. Everyone working on similar issues was also good because when one or more of us ran into a problem the others were able to help or the team members working on frontends were able to tackle a problem together since what we had to do for this sprint was very similar. Our weights for the issues were also a pretty good estimate. We were able to get the full 35 points of work done right in time for the end of the sprint. 

Something our team can do to improve for the next sprint is to spread out the work better. In this sprint, we mostly worked in a single subgroup but I think switching things up would benefit us. Since we only worked in a single subgroup only three of our group members got to work on the frontend, one person got to work on the backend, and the last member only worked on API. For our next sprint, we want to switch these roles so every team member can get experience in each area. 

I worked on the CheckOutGuestFrontend as well as reviewed and merged code from other team members. The issues I worked on are the following:

The first issue I had was to update or add the files for the documentation, licensing, linting configuration, .gitignore, and .gitattributes to match the inventoryAPI. 

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/checkoutguestfrontend/-/issues/13

The next issue I worked on was revising the directory structure to match the inventoryAPI again.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/checkoutguestfrontend/-/issues/14

I then worked on updating the devcontainer files to match the inventoryAPI.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/checkoutguestfrontend/-/issues/15

The last issue and the most difficult one I worked on was updating the pipeline/CI files.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/checkoutguestfrontend/-/issues/16

A change I could make to improve as an individual is spending a little more time outside of class working on issues when I get stuck instead of waiting for the next class to ask about the problem. Some issues need more direct help to figure out but I think spending more time trying to figure out an issue instead of asking for help after a short time would be good for improving my problem-solving skills. I think another individual issue that can be improved is getting over the fear of completely breaking the code since I am unfamiliar with how certain things work. Sprint 2 seems like the work will be less trying to match the code up to already existing code so having to dedicate more time outside of class will be necessary. 

Overall I think sprint 1 was very successful but there is always room for growth. By doing the changes the team discussed I think sprint 2 will be even more successful.

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

Sprint 1 of working on the LibreFoodPantry was a nice dip in the water of how the scrum framework works. So far, I understand why this framework is very important to the software development process and the added organization it brings when it comes to producing software.

The first thing I worked on in sprint 1 is “added use-strict to the backend” (Link 1). Before working on this issue, it was important for me to understand what “use-strict” was used for. I found out that the “use strict”; line is used to define that the JavaScript code is in “strict mode.” When JavaScript code is executed in “strict mode,” it means that non-existing properties, variables, and objects will throw an error. This was very simple, and it didn’t take too much time to understand the issue and how to resolve it.

Another issue I worked on was “removing the MongoID schema in the GuestInfoBackend” (Link 2). This was also very easy; it consisted of changing the OpenApi.yaml, which included a MongoID schema. The MongoID is unused in the GuestInfoSystem; thus, it must be removed. The biggest problem was merge conflicts. One team member had made a change in the OpenApi.yaml file in the backend in one branch while I was making a change to the YAML file in another branch, and Git didn’t like this. In the future, I think it’s important for us to recognize when issues will show a merge conflict; it’s important to understand them too. I spent some time figuring it out, but then I ended up watching this video on YouTube that perfectly explained the point of merge conflicts. Anyways, I will be able to resolve this better in the future.

The third issue was to “create docker-compose.yaml for the guestinfointegration” (Link 3). I’ve never worked with Docker, so this was a big task for me. I had to attempt to understand Docker the best I could. When I try to read over documentation of another system, I tend to get very frustrated because I’m only left with questions. I think the best thing to do when it comes to this is to take it slow and grasp all the information that makes sense at the moment, then take it from there. Also, it’s best to ask a lot of questions whenever possible. I tend to try and figure things out on my own when I don’t really need to. I have all these resources and people I can go to, and I’m not capitalizing. Despite this, I learned a lot about Docker, and I will definitely come back to it whenever I need to.

The final issue I worked on before ending the Sprint was “Configure guestinfoIntegration” (Link 4). When going into this issue, I didn’t know exactly what the guestinfoIntegration was used for, but from my understanding, it is used as a mock repository showing how the GuestinfoSystem works. Configuring the file wasn’t hard; the only thing I had trouble with was understanding that the Integrations had no build image, thus no build meant that I needed to change the Git testing pipeline. It seems like I should invest more time into looking at the resources that have been presented in the LibreFoodPantry common services. I spent a lot of time getting the pipeline to work, which is good because now I have a better knowledge of how it all works. My concerns are that I take a significant amount of time on issues that can easily be resolved, so it’s my job to look at all my options before scrambling for a solution.

As an individual, I spent a considerable amount of time working on these issues and learned a lot about certain aspects of the project. I want to be able to better organize my findings and solutions in the next sprint. I also want to get a significant amount done between classes. This means setting deadlines so that I’ll have one issue done between each class.

Regarding the team, we have decided that we need to better space out our issues so that no one is doing too much and spending a lot of time on a certain issues, as this could be a problem for productivity. We have also decided that we need to capitalize on local branches before merging, which could help when it comes to merge conflicts. Heading into Sprint 2, maximizing our productivity is the goal.

Link 1: https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/guestinfobackend/-/merge_requests/59

Link 2: https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/guestinfobackend/-/merge_requests/60

Link 3: https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/guestinfointegration/-/merge_requests/3

Link 4: https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/guestinfointegration/-/issues/2

From the blog CS@Worcester – FindKelvin by Kelvin Nina and used with permission of the author. All other rights reserved by the author.

Sprint 1 has come to an end, and it’s time for the sprint retrospective. For the first sprint of this semester, I worked on issues for AddInventoryFrontend for the Inventory System. The following are links showing my activity for the project:

• https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/addinventoryfrontend/-/issues/9. This addressed the creation of developer documentation that was not previously present in AddInventoryFrontend but is present in GuestInfoFrontend, and I made sure that it had the licensing files, and added the linting files, and edited the .gitattributes file.
• https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/addinventoryfrontend/-/issues/10. This addressed the revision of the directory structure in which I compared files in AddInventoryFrontend to GuestInfoFrontend and created any files that GuestInfoFrontend had that AddInvenoryFrontend did not have and renamed and relocated files, or created folders to match GuestInfoFrontend.
• https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/addinventoryfrontend/-/issues/12. This addressed the updating of the pipeline/CI files in which I updated the package.json and .gitlab-ci.yml files.

I have also reviewed a merge request from a teammate in which I checked if they created the necessary files with content similar to GuestInfoAPI: https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/inventoryapi/-/merge_requests/5 

What worked well with the group is that we all separately worked on the same type of issue. If one member had difficulties with the issue, then another member who figured it out would be able to guide them. For example, we all worked on updating pipeline/CI files and there were some cases where a few people working in frontend had the same errors like issues with using commads/build.sh and were able to work it out with each other. We also had great team communication and were able to freely communicate what we were stuck on or working on, and could easily reach each other outside of class. 

We cooperated well as a group and didn’t seem to have any issues. We had just technical issues rather than teamwork or workload issues. Even then, we did help each other out and I took note of what we may need to remember moving on. When I was stuck facing some errors on an issue, a teammate helped by picking up an issue for AddInventoryFrontend that I was too preoccupied to handle.

To improve as a team, we could work more on projects at home and also try to branch out more. We sort of stuck to our own projects–for example, I handled most of the issues for AddInventoryFrontend, one person worked on InventoryAPI, one for CheckInventoryFrontend, one for CheckOutGuestFrontend, and one for InventoryBackend. It might be more fair to work on different areas for people who ended up working on an area they didn’t want to work with.

In terms of improving as an individual, I could put more time outside of class into my issues–but of course this would happen naturally since this next sprint would have more “intensive” work rather than some copy-pasting situations we had for issues this sprint. I should also be less afraid to make some changes thinking it could mess something up.

I think this first sprint went well with our communication and team support system.

From the blog CS@Worcester – CS With Sarah by Sarah T and used with permission of the author. All other rights reserved by the author.