Category Archives: Sprint 2

Sprint-2 Retrospective

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.

Sprint 2 Retrospective

Hello and welcome back to my blog. 

This is the second and last sprint retrospective blog post for my computer science class CS-448. For this sprint, our group needed to continue working on the epics created by the professor. The tasks included updating JavaScript code to modern JavaScript, converting all Docker images to multi-architecture images, and writing tests for the backend of the InventorySystem. I worked on these issues in the CheckInventoryFrontend and in the Inventory Backend. 


To update the JavaScript to modern JavaScript, I had to replace “var” with “let” and use “const” whenever possible. This required me to research how JavaScript’s “var,” “let,” and “const” work.

  • Issue #1: Update JavaScript to modern JavaScript

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

For this issue, I checked every JavaScript file and added “use strict” to the beginning of them as well as checking if there were any “var” variables.


Continue reading →

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

Sprint 2 Retrospective

Hello and welcome back to my blog. 

This is the second and last sprint retrospective blog post for my computer science class CS-448. For this sprint, our group needed to continue working on the epics created by the professor. The tasks included updating JavaScript code to modern JavaScript, converting all Docker images to multi-architecture images, and writing tests for the backend of the InventorySystem. I worked on these issues in the CheckInventoryFrontend and in the Inventory Backend. 


To update the JavaScript to modern JavaScript, I had to replace “var” with “let” and use “const” whenever possible. This required me to research how JavaScript’s “var,” “let,” and “const” work.

  • Issue #1: Update JavaScript to modern JavaScript

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

For this issue, I checked every JavaScript file and added “use strict” to the beginning of them as well as checking if there were any “var” variables.


Continue reading →

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

Sprint 2 Retrospective

Hello and welcome back to my blog. 

This is the second and last sprint retrospective blog post for my computer science class CS-448. For this sprint, our group needed to continue working on the epics created by the professor. The tasks included updating JavaScript code to modern JavaScript, converting all Docker images to multi-architecture images, and writing tests for the backend of the InventorySystem. I worked on these issues in the CheckInventoryFrontend and in the Inventory Backend. 


To update the JavaScript to modern JavaScript, I had to replace “var” with “let” and use “const” whenever possible. This required me to research how JavaScript’s “var,” “let,” and “const” work.

  • Issue #1: Update JavaScript to modern JavaScript

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

For this issue, I checked every JavaScript file and added “use strict” to the beginning of them as well as checking if there were any “var” variables.


Continue reading →

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

Sprint 2 Retrospective

Hello and welcome back to my blog. 

This is the second and last sprint retrospective blog post for my computer science class CS-448. For this sprint, our group needed to continue working on the epics created by the professor. The tasks included updating JavaScript code to modern JavaScript, converting all Docker images to multi-architecture images, and writing tests for the backend of the InventorySystem. I worked on these issues in the CheckInventoryFrontend and in the Inventory Backend. 


To update the JavaScript to modern JavaScript, I had to replace “var” with “let” and use “const” whenever possible. This required me to research how JavaScript’s “var,” “let,” and “const” work.

  • Issue #1: Update JavaScript to modern JavaScript

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

For this issue, I checked every JavaScript file and added “use strict” to the beginning of them as well as checking if there were any “var” variables.


Continue reading →

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

Sprint 2 Retrospective

Hello and welcome back to my blog. 

This is the second and last sprint retrospective blog post for my computer science class CS-448. For this sprint, our group needed to continue working on the epics created by the professor. The tasks included updating JavaScript code to modern JavaScript, converting all Docker images to multi-architecture images, and writing tests for the backend of the InventorySystem. I worked on these issues in the CheckInventoryFrontend and in the Inventory Backend. 


To update the JavaScript to modern JavaScript, I had to replace “var” with “let” and use “const” whenever possible. This required me to research how JavaScript’s “var,” “let,” and “const” work.

  • Issue #1: Update JavaScript to modern JavaScript

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

For this issue, I checked every JavaScript file and added “use strict” to the beginning of them as well as checking if there were any “var” variables.


Continue reading →

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

Sprint 2 Retrospective

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.

Sprint 2 – Retrospective

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.

Sprint-2

Hello, welcome to the Second-Sprint Retrospective Blog. I contributed to the group project by working on the tasks assigned on GitLab. I chose to complete one of the jobs, but it was more difficult than I had expected. I am currently participating in an activity that calls for additional alterations, and adding more details is more complicated than I had anticipated. It is up to the team and me to decide whether to put the modifications for the necessary measures. 

After the team and I adjusted to the issue board required for the work and practice. Completing this ISSUE Weight assignment with a total weight of 3 is reasonable and practicable. 

The Issue:
backend — write a test suite for API (changes); This activity writes test in Chai, ensuring that the backend works with the API while ensuring you get a file back in .xls format (get the simple tests working). 

My challenge concerning these works is researching the topic of “Chai.” It explains that Chai is an assertion library written in JavaScript with different test frameworks. It allows maintenance of your code’s functionality and checks that it follows those assertions. It has the “assertions” style comparable to Node.js’s built-in assert module, and the “expect” style uses a chainable API to create more legible and expressive tests. Chai can be used with any testing framework, including Mocha, to define test suites with a specific feature. Each test in a test suite will state how your code should act.
I learned that it has additional chai-related dependencies after researching the topic. These include additions to npm install chai, chai-HTTP, chai-as-promise, etc. Those additions make the process simpler, but it doesn’t look good. It has already gone through the potentially functional aspects, even after the review, code addition/construction, and code comparison phases. However, the conjunction of some codes didn’t pass due to some missing information and led to some failures. 

To improve myself, I plan to seek information regarding this kind of assignment from members of my group and members of other groups by asking questions. It will serve as a learning experience. Even though the end of the year is getting close, I have seen that my abilities to manage time have increased, and the learning steps for work are becoming the assigned time. We ran into various technical issues during the development process, which resulted in delays; the team and I had a fantastic mid-round in finishing all of the items listed on the sprint backlog. These delays are different learning experiences that require better comprehension and learning new specialties to avoid those misconceptions and repeated attempts resulting from communication breakdowns. The problems may avoid by increasing knowledge and diving into the serious issue with the other group collaborating. 

In conclusion, in the second sprint, our team had good objectives and executed them, though we succeeded wildly better after the First-Sprint. We overcame some obstacles and learned about new topics while working through the complex pipeline and completing one of the assignments.

From the blog Andrew Lam’s little blog by Andrew Lam and used with permission of the author. All other rights reserved by the author.

Sprint-2

Hello, welcome to the Second-Sprint Retrospective Blog. I contributed to the group project by working on the tasks assigned on GitLab. I chose to complete one of the jobs, but it was more difficult than I had expected. I am currently participating in an activity that calls for additional alterations, and adding more details is more complicated than I had anticipated. It is up to the team and me to decide whether to put the modifications for the necessary measures. 

After the team and I adjusted to the issue board required for the work and practice. Completing this ISSUE Weight assignment with a total weight of 3 is reasonable and practicable. 

The Issue:
backend — write a test suite for API (changes); This activity writes test in Chai, ensuring that the backend works with the API while ensuring you get a file back in .xls format (get the simple tests working). 

My challenge concerning these works is researching the topic of “Chai.” It explains that Chai is an assertion library written in JavaScript with different test frameworks. It allows maintenance of your code’s functionality and checks that it follows those assertions. It has the “assertions” style comparable to Node.js’s built-in assert module, and the “expect” style uses a chainable API to create more legible and expressive tests. Chai can be used with any testing framework, including Mocha, to define test suites with a specific feature. Each test in a test suite will state how your code should act.
I learned that it has additional chai-related dependencies after researching the topic. These include additions to npm install chai, chai-HTTP, chai-as-promise, etc. Those additions make the process simpler, but it doesn’t look good. It has already gone through the potentially functional aspects, even after the review, code addition/construction, and code comparison phases. However, the conjunction of some codes didn’t pass due to some missing information and led to some failures. 

To improve myself, I plan to seek information regarding this kind of assignment from members of my group and members of other groups by asking questions. It will serve as a learning experience. Even though the end of the year is getting close, I have seen that my abilities to manage time have increased, and the learning steps for work are becoming the assigned time. We ran into various technical issues during the development process, which resulted in delays; the team and I had a fantastic mid-round in finishing all of the items listed on the sprint backlog. These delays are different learning experiences that require better comprehension and learning new specialties to avoid those misconceptions and repeated attempts resulting from communication breakdowns. The problems may avoid by increasing knowledge and diving into the serious issue with the other group collaborating. 

In conclusion, in the second sprint, our team had good objectives and executed them, though we succeeded wildly better after the First-Sprint. We overcame some obstacles and learned about new topics while working through the complex pipeline and completing one of the assignments.

From the blog Andrew Lam’s little blog by Andrew Lam and used with permission of the author. All other rights reserved by the author.