This was our second sprint of the semester and I would say we definitely did better in some aspects as a team while we still need to work on other aspects. I personally worked on one issue on my own while we did all the other issues completed during the sprint as a team during our meetings. These issues included ensuring the proper linters and pipeline stages in a repo, researching how to write vue code and implementing said code as well as developing the frontend with buttons and input fields to prepare for a confirmation page next sprint. Our group issue that we completed included researching vue as well as redesigning the wireframe for the addInventory frontend.

Overall I did not have any trouble with my individual issue during this sprint. My issue I worked on regarding the addition of linters and pipeline stages was straightforward and I was able to complete it without much delay as there were not many issues in any of the files after implementation of the necessary linters. The first issue that we worked on as a team regarding the research of vue code and making an example button also went well and did not take us long during our meeting. The second issue we worked on as a team included working on the frontend which was rather challenging as we do not have much experience with the frontend between us but we were able to add two buttons along with input fields in order to have a displayable frontend. Our last issue as a team was to redesign the wireframe for the frontend in order to prepare for sprint 3 which went very well as we are planning on adding a second page to the frontend which confirms the addition to the inventory.

We did not have many problems during this sprint but I still feel as though there are things we could work on to improve as a team. One thing we can improve on is everyone making it to scheduled meetings, during the sprint we had meetings where we were not all in attendance and the team members in attendance did not know that others would not be making it to the meeting so I believe we need to work on communicating more when it comes to having to be absent from a meeting so the team knows what to expect. Another problem we had during the sprint was being willing to ask for help when needed, although we all have little experience when it comes to frontend coding we still can bounce ideas off of each other in order to work through issues faster as it is more useful to the team if we all understand what we are working on and we all agreed when writing our working agreement that we would all be available and willing to help eachother or answer questions as needed. In my opinion we worked well together during our second sprint and I hope we are able to work together even better during our final sprint of the semester.

Issues worked on:

Verifying that all Thea’s Pantry projects have the correct extensions, linters, and pipeline stages – CheckInventoryFrontend

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/checkinventoryfrontend/-/issues/35

Research code for `button` implementation in Vue and HTML

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/addinventoryfrontend/-/issues/40

Develop `Submit` button Vue and HTML files

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/addinventoryfrontend/-/issues/45

From the blog CS@Worcester – Dylan Brown Computer Science by dylanbrowncs and used with permission of the author. All other rights reserved by the author.

Overall I think the second sprint went well. Like the last sprint, I think we all did a good job of keeping each other updated and asking each other questions if we became stuck. For this sprint, we worked on a lot of the issues as a group. We also were open enough to communicate with each other when we realized that issues may not have been merged for a long period after being reviewed. Unfortunately, there were a couple of times when we didn’t keep up with issues that were in the “Needs Review” column. This resulted in a lot of merge conflicts that need to be resolved for those issues. We continued to display aspects of the original description of the culture we wanted in the working agreement: open-mindedness, honesty, respect, and accountability. We decided how much weight everyone should try to complete to divide the work evenly and fairly before the sprint started and we kept to it for the most part.

I worked on multiple issues that involved verifying that the pantry projects had the correct extensions, linters, and pipeline stages. For this issue, we examined the file types on the project, made a list of linters that were needed based on the files, added any linters, made sure the new linters passed, checked which stages were needed, and fixed the stages accordingly. I worked on verification for GuestInfoBackend, GuestInfoAPI, and GuestInfoSystem/General. I worked on the first two issues with the group and worked on verifying GuestInfoSystem/General by myself. We also had an issue for talking to group 3 about InventoryFrontend and InventoryBackend because they decided to work on some issues for it. Towards the end of the sprint, I realized they didn’t reach out so our group initiated a conversation to confirm if they were all set. Once that conversation finished I moved that issue to the done column. I also worked on reviewing the issue for getting InventoryBackend test working and getting the InventorySystem General test and build working. The issue for getting the InventoryBackend working was an issue that was left in the  “Needs Review” column for an extended amount of time and needed an extensive amount of work to resolve merge conflicts.

As a team, I think we did fairly well but we needed to keep up with the issues that need review more. We also did not rotate reviewing issues as we originally planned when creating our working agreement and or set up a system that will ensure that there aren’t certain people who are reviewing the majority of issues. Because a lot of the issues involved us working together, we didn’t address how we would make sure to stay on track of issues that needed review. As an individual, I need to make sure I can review issues as soon as possible to prevent the possibility of having a team member work through multiple merge conflicts. I think as a group we could benefit from a specific plan for keeping up with completed issues. For the next sprint, I plan on picking a schedule to check on the needs review column.

From the blog CS@Worcester – Live Laugh Code by Shamarah Ramirez and used with permission of the author. All other rights reserved by the author.

Sprint 2

What worked well this sprint

Sprint 1 was a good opportunity for the team to become familiar with each other, how we like to work individually, and the general workflow that we were to follow. After Sprint 1, Sprint 2 was much easier in terms of knowing what the team wanted to accomplish and how to accomplish it. During this sprint, we continued our weekly meetings because it was a good way for everyone to go over what was done the past week, and what needed to be done for the current week. Last sprint, we ended up leaving all of our merge requests open until the end of Sprint 1 which resulted in many conflicts which created extra work to resolve those conflicts. This sprint we decided to review and merge as issues are completed rather than leaving them until the end of the sprint. Reviewing as issues are completed helped the team to avoid merge conflicts.

What did not work well

Throughout the sprint, the team had issues that were dependent on the completion of other issues. An example of these issues were when the team were adding to the AddInventoryFrontend. The goal of the issue was to implement the functionality of actually adding inventory to the database which required multiple components to be added such as text fields, buttons, etc. Because the team as a whole had limited experience with frontend work, we spent time together researching implementation. When spending time together for research, we realized that implementation would be easier with the approach of mob programming. Utilizing mob programming rather than each of us being assigned an issue and completing individually helped save time. This is because if we were all assigned an individual issue then we would have to wait until the first person finishes their issue, then the next person could start their issue, and so on. Each of us would also have to pull the changes the previous person made. This process seemed inefficient, so the team decided to group the issues together and do them at once in one meeting where everyone was present.

Last sprint we also came across problems where there was miscommunication about when we would be meeting, which we aimed to resolve this sprint. However we still faced attendance issues regarding the team’s weekly meetings.

Changes to make as a team

One change that we tried to resolve last sprint was the issue of some team members not attending the weekly meetings. Unfortunately this issue was not fully rectified. In hopes to settle this issue for the next sprint, the team should have a discussion to clearly restate expectations which were initially defined at the beginning of the semester.

Changes to make as an individual

A change that could be made as an individual is having a better grasp of what needs to be done. Mainly due to having spring break in the middle of the sprint, there were a couple instances where I would forget a standup message to inform my team on the progress I have made individually. Although this sprint was longer than the previous, it actually felt shorter to me because of spring break and canceled classes which contributed to me having to rush at the end of the sprint to get my work completed in time. I plan to manage my time better, so this does not happen for Sprint 3.

Activity on GitLab

• https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/checkoutguestfrontend/-/issues/38
  • Resolved the issue “Verifying that all Thea’s Pantry projects have the correct extensions, linters, and pipeline stages” for the CheckoutGuestFrontend subsystem.
• https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/addinventoryfrontend/-/issues/40
  • As a team, researched button implementation in Vue for the AddInventoryFrontend subsystem.
• https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/documentation/-/merge_requests/11
  • Reviewed and approved the merge request for “Verifying that all Thea’s Pantry projects have the correct extensions, linters, and pipeline stages” related to the Documentation under the InventorySystem.
• https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/addinventoryfrontend/-/merge_requests/25
  • As a team, we utilized mob programming to resolve the issue of “Develop `Submit` button Vue and HTML files” related to the AddInventoryFrontend subsystem. Also acted as the reviewer

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

As we conclude Sprint-2 and gather for our retrospective meeting, it’s crucial to delve into what went well and identify areas where we can enhance our performance moving forward. Here’s a detailed reflection on our observations and insights:

Reflection on what worked well:

During Sprint-2, our team made notable progress in several areas compared to the previous sprint, demonstrating our ability to adapt and improve:

1. Enhanced Communication: Communication within the team showed significant improvement, with members actively engaging in discussions, sharing progress updates, and addressing challenges effectively. Our meetings were more focused, productive, and purposeful, leading to better collaboration and decision-making.
2. Productive Meetings: Our meetings were more structured and goal-oriented, providing valuable opportunities for planning tasks, discussing issues, and aligning on project goals. This contributed to a clearer understanding of individual responsibilities and project progress.
3. Improved Task Weighting: Adjusting task weights based on our learnings from Sprint-1 resulted in a more accurate reflection of task complexity. This led to a better-balanced workload distribution among team members, ensuring that tasks were appropriately scoped and assigned.
4. Enhanced Understanding of Project Management Tools: Our team gained a better understanding of using GitLab, particularly the issues and epic boards. This improvement allowed for smoother task management, clearer progress tracking, and better coordination among team members.

Reflection on what didn’t work well:

Despite our progress, Sprint-2 also presented us with challenges and areas for improvement:

1. Persistent Docker-compose Issues: We continued to face challenges with Docker-compose issues and documentation, impacting task completion and overall efficiency. Addressing these technical hurdles remains a priority for future sprints.
2. Individual Workload: While collaboration improved, some team members still worked on tasks independently without seeking or receiving sufficient support from others. This hindered overall productivity and efficiency in task execution.
3. Task Dependencies: Certain tasks were blocked due to dependencies on issues assigned to other teams. This led to delays in task completion and affected our overall task completion rate.

Reflection on changes to improve as a team:

To enhance our team’s performance and effectiveness, we have identified several key areas for improvement:

1. Promoting Better Collaboration: We aim to foster even better teamwork by encouraging more collaboration, knowledge sharing, and mutual support among team members.
2. Improving Code Cleanliness and Documentation: Clearer documentation, standardized coding practices, and a focus on code cleanliness will contribute to smoother development processes, easier collaboration, and improved project comprehension.
3. Effective Task Prioritization and Dependency Management: We plan to prioritize tasks effectively, address dependencies proactively, and communicate any blockers or challenges promptly.
4. Enhancing Communication Channels: We aim to enhance communication channels within the team, ensuring that information is shared transparently, decisions are communicated clearly, and feedback is provided constructively.

Reflection on changes to improve as an individual:

During Sprint-2, I successfully completed two assigned tasks. The first task involved checking linters and configuring them if necessary for the reporting integration with Victor. This task required running all linters and ensuring that the project passed all tests. I encountered errors related to disallowed words and had to decide whether to reword, add exceptions, or disable certain rules before the relevant code lines to pass the linter tests. Despite these challenges, we completed the task smoothly without any major issues.

The second task was updating documentation to reflect recent changes for reportingAPI and reportingbackend. This included addressing references to the “commands” folder instead of “bin,” adding information about GitPod to Development-environment.md, and updating the outdated Cheat-sheet.md. I successfully completed this task as well, ensuring that the documentation accurately reflected the project’s current state without encountering any obstacles.

As an individual team member, I have identified areas for personal improvement and growth:

1. Attention to Detail: I recognize the importance of meticulous attention to detail in my work to avoid oversights and ensure thoroughness in task execution.
2. Proactive Collaboration: I aim to offer more assistance to fellow team members, proactively collaborate on tasks, and share knowledge and expertise.
3. Effective Time Management: Prioritizing tasks effectively, managing time efficiently, and communicating any challenges or delays promptly will contribute to smoother task execution and improved productivity.

From the blog CS@Worcester – Hieu Tran Blog by Trung Hiếu and used with permission of the author. All other rights reserved by the author.

During the course of this sprint, I spent most of my time looking at the ReportingBackend repository to figure out what was going wrong with the testing suite. I also had assigned myself to configuring the pipeline specifically in ReportingAPI with the linters, but unfortunately was unable to complete this issue because the team responsible for actually adding the linters to the repository was not able to push their changes before the sprint ended. I continued to act as the scrum master for the team, taking an active approach to making sure everyone is doing work, getting credit for their work, and setting up meetings when necessary. I had to help out a bit with other team member’s issues as well, providing some guidance.

Verify the Testing Suite works: Investigate the testing suite and see if I can get it to work, or at least figure out the magnitude of the problem. I applied a couple of fixes (one of which was in the build.sh script that I had a separate 0 weight issue created for, as I had already found the bug and fix prior to the sprint starting.), but it seems like the issue transcends the testing suite and is moreso an issue with the build process with the server.

This sprint was pretty rough, if I’m being honest. For what we did well, our communication overall improved, and the team was better able to utilize GitLab for their work. I think that everything on GitLab was better organized and most of the issues had better descriptions on them than what we had last sprint, and the weight assigned to issues seemed fairly accurate all things considered, aside from the testing issue (which I did spend a lot of time on). We also did work with each other more than we did on the last sprint.

Most of the issues that were assigned to our team were rushed together during the last week of the sprint (from my perspective at least, there may have been some confusion with pushing to GitLab). As such, we weren’t able to get to all of the issues, and only got 14 weight out of the 24 weight assigned to our team fully merged in. I was offering support during the whole sprint, but it seemed like team members were not able to coordinate into a meeting at the same time for most of the sprint. I don’t really have a great reasoning for this, it seems like things weren’t being done until the time was very short to were we couldn’t get everything done, taking all of our other schoolwork into account.

Ultimately, I think for next sprint our team really just needs to work on spreading work out during the entire sprint rather than getting things done last minute. We should also work on coordination and being more present, as when anyone asked if we wanted to do a meeting, the team would all say they were available and no one would take the initiative to actually begin the meeting. Part of that is on me as scrum master, but ultimately we should be willing to meet without having everyone on board if we are working on specific issues.

I was able to spread out my work fairly well as an individual, but I can’t say the same for other team members, and so as scrum master I should be more active in making sure everyone is doing their work not just so the project moves forward, but so everyone gets the credit they need for the course.

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

One issue our team was having during this sprint was that getting or deleting a guest, after creating the guest, was returning a 404 not found response. We were having a difficult time identifying the cause of this reversion of good behavior, so I learned how to use the git bisect subcommand to find the commit, found the change within the commit that caused the bug, and reverted that change. It ended up being that we could not refer specifically to the /guests endpoint token within the OpenAPI server URL value without other changes.

Evidence: https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/guestinfobackend/-/issues/89

Continued existence in frontend (we just need to make sure the right API YAML file is being used in all the repos now): https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/guestinfofrontend/-/issues/57

Chai has very nice syntax, which together with chai-http lets you call should on an object, such as object.should.have.status(200), or to call chai.expect(object) when the object might or might not exist. I wrote some simple unit tests, such as verifying that the version string has a range in [5,8] — ('0.0.0' - '99.99.99') — for getting the API version. As with other tests, being able to call them quickly with cd src && npm run test while the server is running on localhost is a useful holdover until we get the CI pipeline working.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/guestinfobackend/-/merge_requests/70/diffs?commit_id=69a9d2299335066166b6379bbdb83bd4d5594bde

I did some pre-sprint-3 cleanup by removing the Chai (not Chai-HTTP) example testGuest.js file.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/guestinfobackend/-/issues/90

I cleaned up our set of unit tests, for the create guest endpoint, which I think is now the first to be in a really good state concerning test coverage not including the get API endpoint. This includes a cleanup step at the end (so tests can be run repeatedly without rebuilding the server), several HTTP requests: both valid and invalid, examining many of the properties of the returned responses. One trick I learned was to assign a const object to store guest data and then repeatedly copy it with the spread ... operator. Otherwise JavaScript would copy by reference and disrespect the const-ness of the object: it would otherwise mutate a const! What a lovely language feature.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/guestinfobackend/-/merge_requests/72/diffs?commit_id=9e3ee6ee2b4202c5971445ead7fc8a10fc727992

Overall, I think I did decently. I helped Kelvin a little with some of his issues. He individually, and our team as a whole, did a great job this sprint. We began and completed work on multiple epics. We ended in a state where now, 1 week from the end of sprint 3, we think we can finish up everything that we wanted and agreed to get to in our sprint 3 planning meeting.

One challenge I faced that I couldn’t resolve was an unfortunate technical difficulty. Despite multiple restarts, re-cloning the repos, and checking my installed program versions, my computer stopped being able to run the server. I eventually gave up after a few hours of trial and error, and moved to a different computer, but I suspect the problem was in an incompatibility involving the rolling-release software update model used by Arch Linux. I’ve now had 2 confirmed and 2 other suspected significant issues that might have been avoided by using LTS software.

Our team could probably improve our communication. It’s hard to find time after Thursday and before Tuesday to plan or collaborate on changes. Early this semester I supported working asynchronously, but in retrospect having an hour or two per week of planned collaboration probably would have led to more productivity and confidence without an unreasonable cost.

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

Our team hit the ground running in the second sprint to deliver a much better result than the first sprint in the end. I ended up working on three issues, with two being completed in the end, and the last one being saved for the next sprint. The links to all three issues can be found below. The first issue was an issue that had been unresolved in the last sprint. What happened was that I had finished the issue, but there was a problem with the commit. I received help from Scott on fixing the commit problem, and the issue was resolved. The second issue was another one that came from the first sprint. I had many troubles with updating the pipeline in the first sprint, and I really needed help with it in the second one. Sam jumped in and did an amazing job getting it to work, and we could not have completed it without him. The third issue I had started in this sprint was creating the test.sh file in the command folder. It took a lot of trial and error, but I just was not able to finish it completely, and I am looking forward to finishing it up in the next sprint. This blog will go over my retrospective thoughts now that the second sprint is over.

Many things worked really well throughout this sprint. One thing that was huge was how much we had learned from the first sprint. In the first sprint we started off slow as we were still inexperienced, but this time we just flew through the beginning, and hit a roll. This can be seen in the nearly 10 point weight difference at the end of each sprint. Another thing that worked well was how cohesive we worked as a group. Now that we had more experience working together, I felt that we talked with each other more, and worked together to finish issues more as well.

There were also some things that did not work well throughout the sprint. One thing that comes to mind is how even though we are better, our weight scaling is still a little off. An example of this is with the pipeline issue where we put it as a weight of two, and it ended up being a weight of five or six. Something else that comes to mind that did not work well is our understanding of new information. It has taken us way longer than we thought to understand Chai, and we are still entering the final sprint trying to fully figure it out.

When thinking about what we can do to improve our group, a couple of ideas come to mind. One thing is that we can try to fix our issue with weights. We could try to improve this by giving some issues more weight than we think it needs so that we can account for actually learning what to do. A lot of times we have overestimated our knowledge, and it led to us taking longer on sprints than the listed weight. Another thing we can try to improve is our communication with outside groups. I feel like we think that we can only communicate with each other, but we can also reach out to our friends in other groups for help as well, and I think we have not taken advantage of that as much as we should.

I think that I can improve in many ways from this sprint. One way is by getting more familiar with Git itself, and prevent small mistakes, like with the first linked issue, from happening again. This will allow for us to not waste time on issues that do not require it, and get our work done faster. Another way I can improve is by reaching out to the GuestInfoSystem team for help with creating the test.sh file as they have done a ton of work with that in sprint two, and have got it up and running on their system. This will help us in getting that issue resolved for the last sprint. This sprint felt like night and day compared to the last one, and our group will only improve more with this experience.

Issue Links

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

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.