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

During sprint 2, our team set a clear goal to maximize our production and efficiency. We aimed to complete more issues than we did in the previous sprint and were highly motivated to achieve this target. As a team, we analyzed our previous sprint’s performance and identified areas where we could improve. We realized that we needed a more effective approach to tackling our workload to achieve our goal of maximum productivity. To ensure that we were working efficiently, we focused on prioritizing our tasks. We spent time looking over all the current and new issues, and we carefully ordered them based on their urgency and complexity. Our strategy was to tackle the easier and more pressing epics first, before moving on to those that would take longer to complete. This approach helped us work through our tasks systematically and efficiently, ensuring that we did not waste time on issues that could be dealt with later. We also made a concerted effort to communicate better as a team. We set up regular meetings to discuss our progress and brainstorm ways to overcome any challenges we encountered.

During the second sprint, the first issue I was tasked with was, removing the openapi.yml file from the project’s documentation folder and deleting the build.sh command as they were no longer necessary. To ensure that my work was aligned with the team’s goals, I communicated with them before proceeding with the deletion and tested the project to confirm that everything was functioning properly. Streamlining the project’s structure in this way improved its efficiency and reduced the likelihood of errors occurring. The second issue was a small issue that we had inadvertently created during sprint 1. The issue involved adding a missing opening bracket to a call.http command. Although it was a minor fix, it was important to ensure the proper functionality of the command. After reviewing and addressing the issue, we ran tests to confirm that the command was working correctly. The third issue that I worked on was to make sure the correct types were used and to accomplish that I reviewed the codebase to ensure the correct types were being used to maintain the project’s high standards of quality and performance. The Forth one was to make sure API is complete and to accomplish that I had to go through the code again sure it’s good. The fifth issue I worked on is to design a comprehensive unit test for the guest retrieval process. The test was designed in a way that it returns code 200 for successful retrievals and a code 400 for non-existent guests. During the Third sprint we will be working on cleaning up and make tests better that were done during second sprint. As an individual I am happy with how much issues we were able to fix during second sprint.

During sprint 2, our team made significant progress and successfully resolved multiple epics. We identified which epics we plan to complete by sprint 3 and decided to leave the frontend issues to a subsequent team. Our teamwork and commitment to quality were evident throughout the sprint.

Links:

1. https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/guestinfoapi/-/issues/108 (Deleted openapi.yaml and build.sh files)
2. https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/guestinfobackend/-/issues/85 (Added “{“ to calls.http file)
3. https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/guestinfoapi/-/issues/101 (Determine if correct types are used)
4. https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/guestinfoapi/-/issues/98 (Determine if API is complete)
5. https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/guestinfobackend/-/issues/78 (Design Unit test for retrieve guest)

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.

Now that sprint 2 is completed it is time for another retrospective. My team implemented some of the changes mentioned in our sprint 1 retrospective and I believe they were good for us. After completing sprint 2 we found some things we could improve in order for sprint 3 to be more successful.

Something that worked well for us was changing up who worked on what. We took the problem we identified in our first sprint and came up with a solution. In sprint 1 each team member only worked on a single project within our front end for all the issues. Doing this did not allow our team to become diverse and adaptable when we only stuck to one thing. For this sprint, we made sure to change our roles which was a positive for the team. Everyone got to work on something new instead of sticking with the same project they worked on in sprint 1.

Something that our team could improve on is how we break down issues. I actually think we did not do quite as well with breaking down issues as we did on our first sprint. Our sprint started off strong and the first few issues were broken down and weighed well but later we had a problem. For our testing issues, we did not break it down nearly enough. We thought creating the test would be simple enough but creating the test turned out to be more difficult. We split the issue by which test it was for instead of the steps needed to complete the testing. This was a mistake because as individuals it was a lot to try to take on at once. We ran into a lot of issues and then trying to share what we did to get past each issue and play catch up with each other still made things difficult. For our next sprint, we need to either work as a team to tackle a large problem or break down these larger problems into smaller chunks.

Since we switched up jobs for this sprint I mostly worked on the backend of the inventory system. The issues I worked on are the following:

My first issue was updating the JavaScript in the backend to modern JavaScript

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/backend/-/issues/46

My next issue was creating the test for getInventory

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/backend/-/issues/54

As an individual, I believe I could improve by getting a better understanding of how the project works as a whole. While working on my tasks, I only looked into the pieces of the project that needed to be worked on. I think going through the project more thoroughly and understanding what does what could have made fixing some of the issues easier. 

Overall I think sprint 2 was a good experience for the team. We took our changes from sprint 1 and implemented them for sprint 2 which was a good change for the team. We found some more weaknesses that can easily be adjusted for sprint 3. With multiple chances to update our strategy, I expect that sprint 3 will be even more successful than our previous two sprints.

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.

For this sprint, overall, the team work significantly better. Not only did we continue to communicate well with one another, but there was a lot of improvement because we were much more experienced with the project. Not only were we more familiar with the coding side of things, but since we had a much firmer understanding of SCRUM as a whole, it allowed us to skip through a lot of the learning process that happened in the first sprint and get right to work instead.

For one, we had accurate weights for almost all of our issues. This is a huge contrast with Sprint 1, as Sprint 1 was littered with issues that should have been weights of 2-3, but instead they were 1s. With this more correct weights, we were able to delegate a lot better, and we also were just more aware of the types of problems we were facing. In Sprint 1 for example, I had moments where I picked up a ‘1’ weight issue, only to be stuck on it for almost a whole week or more because I had to learning about how things worked. Now in Sprint 2, because I can skip a bit of the learning, since I had already did it during Sprint 1, many of the ‘1’ weight issues were actually ‘1s,’ thankfully!

On top of being more familiar with the code and the SCRUM process, we realized that we as a team, did not focus on the issues as heavily as we should have. Although we worked as a group somewhat in Sprint 1, Sprint 2 was much much more collaborative. We realized that the system is a lot more interlocked than we realized, and because of that, if Sam was working on one portion of the API, Moses might have insights, or vice versa. Many instances of issues being tackled was one of us starting it, and another member jumping in and finishing it together.

Other than the improvements in understand and our teamwork, I tackled setting up the Reporting Integrations repo. I figured that since everyone was working on the API, Backend, or a mix of the two, it would be a bit easier for me to tackle the creation of a whole separate part of the Reporting Systems. I think, this was for the best because although help might have useful at times, overall, I was worried that since the Reporting Integrations was going to be made from the ground up essentially, it would become a situation of too many cooks ruin the pot. I am glad I did this because once I set up Reporting Integrations, I had a very solid understanding of the different tools that we used such as the Pipeline, and with that understanding, I was able to help much of the team with some issues.

Pipeline updates
Reporting Integrations
Multi-Architecture Conversion Backend, Frontend, Swagger CLI

After that, things became much smoother as people collectively got a hold on the issues, and though we are still lacking experience in many areas, it feels like we have a better grasp on everything as a whole. I think that moving forward, we should keep our pacing, and improve our communication even more potentially. I do really enjoy how we are much more collaborative on the different issues, and though sometimes we have to focus on our own task, the team work aspect is very refreshing and helpful. We are almost like each other’s rubber ducks.

Somethings that still aren’t too good is that we still only focus on working together when we are face to face, but I think that is overall fine. It could be better if we paired up, or had meetings outside of class and would make things smoother, but things are passable. Also, this isn’t exactly our whole responsibility either!

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

The goal for sprint 2 was to maximize our production. The team and I wanted to get more issues done, at least more issues done than the last sprint. Compared to the previous sprint, we got way more issues and weight done this time. What worked well for us this time was to look over any current and new issues and order them so that the easier/urgent epics were done first, and then we set aside the epics that would take a little bit longer. 

The first issue I started to work on was refactoring the API file directory structure and infrastructure. So the first issue I tackled was collapsing all “YAML contents in /specification to a single/specification/open API.yaml file.” After that, I worked on disabling the build stage in the .gitlab-ci.yaml, which was pretty easy for me because I did a similar issue while working on the guestinfointegration, and I also worked on modifying the test.sh to validate the open API.yaml.

The second epic I worked on was to “Convert all Docker images to build multiarchitecture images” To complete this, I had to:

• Modify the build.sh to specify which image to build.
•  Use the variable PIPELINE_IMAGE_PLATFORMS in the “GitLab-ci.yaml” variable to identify the platforms for which images must be made.

 I worked on the front end while my other team member did this to the backend. We could quickly get this done using the information in multi-platform.md.

After getting these two epics done, the remaining epics we had were ones that we could only complete partially in sprint 1. The next epic we wanted to achieve was the Evaluate and Improve API epic. The work I did for this epic included the following:

• Making sure the values of the API were used correctly.
•  Determining the HTTP methods was correct.
•  Making sure the endpoint to return the correct API version was correct.

Finally, we could get back to backend testing after evaluating the API. A big problem we faced was how to test HTTP methods in the first place, so while doing some research, I found a plugin called “Chai-HTTP,” which allowed us to test HTTP requests using the npm test script that Liam provided in the first sprint. While we still needed to figure out how to get the test runner to work with Docker, having the ability to work on the test without having the test runner was an excellent way to get everyone involved in this epic. I was able to work on designing a test to create guests and list guests. And the test runner that will allow us to run these issues is currently being worked on with help from Noelan from the Inventory system since they are also trying to get it up and running. While developing the test runner allowed me to get more familiar with Docker.

As an individual, I am delighted with how I did this sprint and hope to ride this wave onto sprint 3. I planned to get two or more weights done weekly and ensured a specific timeframe to finish most epics in the team. Unfortunately, we didn’t get backend testing done, but I’m more confident that in sprint three we will complete it now that the test runner is almost done. 

As a team, we need to figure out a system so that everyone can lend a hand. Especially towards the end, we only had a few issues, or sometimes we would have to stop production because of one issue. In this case, it was the test runner for the backend. I’m hoping this will be avoided in sprint 3. 

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

Hello blog!

Sprint 2 has come to an end and it is now round 2 of sprint retrospectives. This sprint was a little different from the first sprint, where our issues were similar amongst the five projects and we all took one project. Instead of one person having to take on all issues for InventoryAPI, they were able to take on frontend work, or whatever was available. This was a change based on what we discussed during the first sprint retrospective–that we should rotate around what we’re working on rather than being stuck in one project. 

The first two issues I worked on were for AddInventoryFrontend:

• https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/addinventoryfrontend/-/merge_requests/12. I added code to .gitlab-ci.yml and build.sh to convert Docker images we are building into multi-architecture images.

• https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/addinventoryfrontend/-/merge_requests/13. I went through the JavaScript files updating them to modern JavaScript by applying “use strict” and checking if there were any variable declarations I could change from var to let or const.

The following issue is what resulted in the greatest struggle:

• https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/backend/-/merge_requests/26. I tried to get the manual test done for getApiVersion so I could write the automated testing in Chai for it but ran into countless problems.

I think what worked well was that in the previous sprint there was the suggestion of changing projects for teammates since they did not want to stick to one of the five projects the whole time, and teammates did swap where they were working. We were also able to help each other out well for a few issues since we all had similar things to change.

What didn’t work well was that we did not gauge well enough how to weigh the tests. We did believe that it would give us issues, but not to the extent that it did. The backend tests should have been split into manual testing and automated testing in Chai since just the manual testing was giving issues that took a long time to address. It was also an issue that almost all of us were making changes to InventoryBackend at once and getting errors from different sections that were fixed by one person but another person was not informed. 

To improve as a team, we could definitely communicate more on errors we have received and what we’ve done to fix them–as soon as we reach them. There are times when some teammates further ahead have gotten errors and fixed them somehow, but forgot what they have changed or updated. Doing so would be of great help for reference and also just good practice. We could also improve as a team by finding more time to work together, like the testing issues for example, since we were all in a similar position, and everyone collaborating on one test first would definitely push us forward. We all have busy and differing schedules so it has been difficult lately, but it can be an improvement.

On the topic of improving as an individual, I still have a fear of breaking things, so I should work on being less afraid of making changes. This sprint I’ve experimented a lot with trying to fix the errors I received trying to get my manual getApiVersion test to work. There were countless changes I made that ended up not making a difference, or would trigger the same error under different conditions. So while I did make efforts to be more “daring”, I could still use some more work on that. I think what scares me more is entering commands I’m not familiar with at all in the terminal, but that can just be an instance of reading more into them.

This sprint felt like a call to be more communicative with my team and also a call to communicate outside of the team with those who have worked on similar issues.

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.

INTRODUCTION: Compared to the first sprint, “Sprint 2” has gone better in some ways. However, in other ways. we definitely have dropped in performance a bit. It’s no one’s fault; part of working within these sprints is figuring out what needs to get done now, and what can be done later.
POSTIVE FACTORS: Here are the following improvements since the last sprint…

• We have set up a form of “login” based on Keycloak software. This Keycloak login has also been set up via JavaScript to act as a “re-direct” from the barebones frontend that we had created during the first sprint. I often refer to this “connected demo” as a HTML/Keycloak/VUE App or project. This is because that’s exactly what happens with the current demo: a user will start in the HTML index file, and then click on a button that redirects to a Keycloak login. Once credentials are entered, the Keycloak login will take the user to the VUE App.
• The group has figured out how to work with Keycloak – in particular, we understand how to create users, set up privileges for users, and group them within a “realm”. We also understand the hashing algorithms used to make JWT Tokens, alongside the structure of a token when de-coded.

NEGATIVE FACTORS: The following factors, as of this sprint, should be worked on…

• The group has reached out to other groups, as well as LibreFoodPantry staff. Still, I feel as though communication is key; the more communication that our group can make with other staff, the better.
• Our team’s organization of the Sprint board could have been better. Specifically, I feel as though moving issues to the “Needs Review” section as they are completed would be preferable to moving them all at once.

TEAM IMPROVEMENT SUGGESTIONS: Here are some ways that the team can improve for the third, final sprint…

• I have made the suggestion that the team could benefit from “POGIL-Style” roles, where each team member performs a specific task for the group. As emphasized throughout this blog, the role that comes to mind is “communications”; while not very “programming-heavy”, this role involves reaching out to other teams and staff. This keeps everyone “in the loop” so that they can plan their sprint work accordingly for the eventual project integration.
• Similar to my discussion within the self-improvement section below, I feel as though the group can benefit from work that is focused towards issue/epic progression. While we are making progress, it seems as though we have to scramble to figure out exactly what is done during our sprint review.

SELF-IMPROVEMENT SUGGESTIONS: As for myself, here are some factors that I need to work on for the future…

• I need to dedicate more time to this project. I have made this issue clear in the last retrospective blog, but failed to work on it. This project, and this class, are extremely important for my professional reputation. Having “outside factors” as a reason for why work isn’t done can only be justified for so long. Eventually, one side has to give: either the outside factors, or the project.
• I feel as though “issue-focused” work would be better for long-term progress. While it’s great that I seem to be making progress with Keycloak, my work is scattered. This issue reflects itself in the progress made on the gitlab issue board.

When creating this blog, I took a quick look back at my first Sprint Retrospective blog; I wanted to make comparisons on mistakes that have been amended during the first sprint. Unfortunately, having this blog posted on time is not one of those amended mistakes. Looking on the brighter side, I feel as though focusing on these blogs is not as important as I make it out to be (this was a mistake that I made during Software Architecture).

LINKS TO GITLAB ACTIVITY

• https://gitlab.com/LibreFoodPantry/common-services/identity-and-access-management-system/keycloak-research/-/tree/KeycloakWithoutDocker (Keycloak Software and Guide)
• https://gitlab.com/LibreFoodPantry/common-services/identity-and-access-management-system/keycloak-research/-/blob/main/npm_review.md (Example of file converted to .md format)
• https://gitlab.com/LibreFoodPantry/common-services/identity-and-access-management-system/keycloak-research/-/blob/main/Keycloak-Guide.md (Keycloak Guide)
• https://gitlab.com/LibreFoodPantry/common-services/identity-and-access-management-system/general/-/tree/APIDev/Libre_Frontend (Repository of Working Frontend Demo – HTML/Keycloak/VUE Connection)

From the blog CS@Worcester – mpekim.code by Mike Morley (mpekim) and used with permission of the author. All other rights reserved by the author.

For the end of Sprint 2, I would say the team really came together to help each other out. We were able to see each other’s skills and start coding. The communication seemed to improve throughout, and the group decided to let Joe continue to be the scrum master for the rest of the semester since the first Sprint he couldn’t really apply scrum master duties. This time around we were more focused and ready to tackle this sprint and give our best work. For this sprint, we assigned fewer task to people with higher weights because we knew it was going to take up some time to build the backend. We were able to produce an OpenAPI for the requested endpoints. We used the yaml file provided that helped us write, build and then test the endpoints in our backend. Then these methods were tested using Visual Code Studio to launch the HTTP request from the guest.http and the qs.http.

During this sprint, while building the backend, we ran into some issues on how to get the calls. http POST, GET, PUT to work for our guest information code. First, we assigned each call to a member in the group. I oversaw creating the get DELETE which was giving us some issues. The error ended up being just minor coding grammar on my end that was easily fixed. Unfortunately, I was operating under a different branch so every code that I sent or corrections to the code that I made, was being pushed to another section of the LibreFoodPantry. Once that was corrected, I was able to continue to help my team. Another issue that we ran into was our Questionnaire call. The reason we were having issues is because Mongold gets created and returned on a post. Any record access after that must pass with a key for that item. Another issue we faced were that the Android app was producing a Timeout Error which we sought counsel from Dr. Wurst on how to correct that in the next sprint.

Overall, I was really impressed with my team since we accomplished two of the major goals that we had. First, was to improve the skill-set of the team members. The first sprint was all copy and pasting documentations. This sprint we all had to show our coding abilities and was able to learn from one another if was lost. Second, was that we were able to help the general progression of the LibreFoodPantry.

For the next sprint, I believe we are starting off on a good start. We were able to fix all the errors that had with our backend, all of our calls are now working with no errors and has a team we have better communication and organization. Joe has really stepped up and lead us to a good position.

Links to my tickets:

API: add endpoint to return current version (#21) · Issues · LibreFoodPantry / Client Solutions / NEST / Guest Information System / API · GitLab

HTTP Get Range of Questionaire Submissions (#19) · Issues · LibreFoodPantry / Client Solutions / NEST / Guest Information System / API · GitLab

backend: set up devcontainer.json for extra tools needed (#2) · Issues · LibreFoodPantry / Client Solutions / NEST / Guest Information System / Backend · GitLab

From the blog CS@Worcester – The Dive by gonzalezwsu22 and used with permission of the author. All other rights reserved by the author.