I felt like I went into this sprint confident that the tasks we planned to approach at the start would go well based off of what we learned from the first sprint. To start the sprint off our team met with Team 1 on Discord. We discussed what we learned about frontend testing, including vues and how to build a frontend in gitpod. This is where that confidence was immediately squashed when I began to realize the depth involved with setting up all the linters for a frontend and linting all of the files.

During the entirety of the sprint I was stuck tackling this one issue; setting up linters in GuestInfoFrontend. This issue was originally weighed by the team as a 2 based on everyone linting their repositories in the previous sprint. Come to find out, linting a fully built front end can take some time.

The initial Issue I ran into was understanding how to enable each linter in the pipeline. The main reason I failed to properly lint the GuestInfoFrontend in the previous sprint was that I never enabled the linters. To make sure I had every linter I needed I read the documentation for each linter and picked ones that linted any file that existed in the frontend. The linters I used were alexjs, cspell, hadolint, lint-package-json, markdown-link-check, markdownlint-cli2, shellcheck, spectral, eslint, htmlhint, and style lint. 

Eslint, htmlhint and style lint didn’t end up working with the pipeline and were removed. Issues were made under each of their respective repositories detailing the error message. Eslint still worked locally, so linting was still able to be done to the files.

As for the other linters, I was able to learn a decent amount about configuring rules for each one of them. This includes understanding what to name the config file, how to format the rules, and what rules exist. Unfortunately It turns out that the rules I created are only checked locally, which makes sense. So my files would still fail the pipeline without the proper lint ignore comments. This was something I tried to avoid at all cost, as it just feels like a cheap and easy fix. That being said I look forward to maybe taking my proposed rules further up the pipeline.

What Worked Well:

The team’s communication was again the best part of the sprint. There were times where one of us would get stuck or fall behind. Having them communicate what is going on allows the rest of the team to be aware of the situation and adjust accordingly. 

What Didn’t Work Well:

With me being stuck on one issue the whole time, I felt guilty as my team was responsible for the entire rest of the board. Because my one issue encapsulated other smaller issues, none of the progress on each of the smaller issues could be reflected on the issue board.

Team Improvements:

As a team we have noticed that there have been issues that essentially have child issues. These child issues get overlooked when we are weighing the issues before the start of the sprint. In my case where I was stuck on one issue, if it was originally built as the 9 separate issues I could have been easily divided up amongst the team. At the very least it would have reflected progress being made on the issue board.

Another improvement we can make is our documentation. Although we do a great job relaying information internally, it is important to remember that we are not the only team that will see these issues. Having comments explaining why we did what we did or sources for where we got our information can assist others who look at the issue.

Personal Improvements:

At some point during the sprint I installed at least one package in the wrong directory. There were times this was done because I didn’t know any better, and others by accident because I just forgot to move the working directory. This created many issues and a mess of unnecessary files. Moving forward I need to double check the working directory before installing. Not only this, but having better commits could help revert back to before the installation. Overall this has given me a better appreciation for the power of git commits and its record keeping. 

Issues:

Meet with Team 1 to discuss frontend testing:

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/guestinfofrontend/-/issues/96

Set up linters and lint the GuestInfoFrontend repository:
https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/guestinfofrontend/-/issues/95 

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

Sprint 2 Retrospective

Introduction

• In this sprint we were focused on scaling up our productivity and getting the UI underway.
• This sprint lasted longer than sprint 1 but ended up feeling very back heavy because we were delayed on working on the front end until we had access to the new template.

Links to Activity on GitLab

• https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/guestinfofrontend/-/issues/93: This issue covered our meeting with team 2 as and what we planned to accomplish with what they found. We ended up making a meeting notes file with our conclusions and next steps.
• https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/checkoutguestfrontend/-/issues/45: In this issue we went over our UI design and tried to think of ways to improve it with a consistent color scheme and matching the aesthetic of the rest of the UI.
• https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/checkoutguestfrontend/-/issues/43: This issue was by far our largest and was very substantial. This issue entailed actually creating and implementing the front end that we had discussed.
• https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/checkoutguestfrontend/-/issues/39: This Issue was focused around looking through the other projects and determining if there was an existing UI framework. We found none that were working and had to wait on out template

Reflections on the Sprint

What Worked Well?

• Like the last, In this sprint I found that communication as a group was key to our success. Any problems that we faced were made much easier when we tackled them as a group instead of alone. I think that our review process was good and allowed us to effectively tackle our goals.

What Didn’t Work Well?

• I think that the main thing that we struggled with was managing the time of this sprint, considering that we were halted in our efforts to make the front end until we had a working template to base ours off of. In the end we got it done after a busy end of sprint.

Improvements for Team Performance

The team’s ability to communicate and tackle problems collectively was a strong point during this sprint. It was an effective carry over from the last sprint and will hopefully be reflected in the next sprint as well with some of the following improvements:

1. Keep a consistent schedule: In hopes to avoid a repeat of the last sprint where everything was stacked at the back of the sprint, It would be beneficial to manage our time better as a group with a more consistent meeting time.
2. Division of Labor: we continue to ensure that one person does not get stacked with to much to do while others get left with little to work on.
3. Streamlined Communication Channels: Same as the last sprint, ensuring that all discussions, especially those related to problem-solving and decision-making, are logged in an accessible and organized manner would help maintain clarity and continuity.

Personal Improvements

Reflecting on my personal challenges during this sprint, specifically around managing merge requests correctly, I see valuable opportunities for growth:

1. Gitlab Use: I still struggle with some aspects of gitlab and hope to improve that for sprint 3.
2. Proactive Communication: To prevent and swiftly address any uncertainties or errors in my work, I commit to being more proactive in seeking feedback and clarifications from team members.

From the blog CS@Worcester – Abe's Programming Blog by Abraham Passmore and used with permission of the author. All other rights reserved by the author.

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.