As we conclude Sprint 3, it’s essential to take a moment to reflect on our experiences, the hurdles we overcame, and the knowledge we’ve gathered. This sprint has been a time of significant learning and adjustment, marked by both challenges and achievements that have contributed to our team’s development and cohesion. In this retrospective, we will explore the difficulties we encountered, the lessons we learned, and outline our strategies for future improvement.

One of the primary challenges this sprint was writing test cases for the frontend using Vue.js and Jest. What we anticipated as a routine task turned into a more complex issue due to the nuanced behaviors of Vue components and their interaction with Jest. Initially, our team struggled with the integration of Jest into our existing Vue projects, facing issues with mock dependencies and asynchronous data handling. However, this challenge provided a profound learning opportunity. We dedicated time to in-depth research and team discussions, which enhanced our understanding of both Vue and Jest. This ordeal not only improved our technical skills but also highlighted the importance of persistence and in-depth understanding in tackling software testing.

Another significant aspect that defined Sprint 3 was our collaboration with another team regarding testing strategies. Initially, communication gaps and differing expectations on testing methodologies posed substantial challenges. These issues were exacerbated by our remote working arrangements, which sometimes led to misunderstandings and delays. To address these issues, we implemented more structured communication protocols, including regular joint meetings and shared documentation. This approach not only smoothed out the wrinkles in cooperation but also fostered a stronger relationship between the teams, setting a foundation for more efficient and effective collaboration in future projects.

Despite the hurdles, Sprint 3 has been pivotal for our team’s growth. We’ve sharpened our skills in frontend testing, deepened our understanding of effective cross-team collaboration, and strengthened our adaptability to new tools and environments. Open communication has once again proved to be the bedrock of our success, ensuring that every team member was engaged and that issues were addressed promptly and transparently.

Moving forward, we aim to build on the lessons learned during this sprint. Our focus will be on refining our testing practices further and enhancing our communication strategies with other teams. We plan to conduct workshops to share knowledge and best practices on Vue and Jest, aiming to elevate our collective expertise. Additionally, the establishment of a cross-team “best practices” repository for testing is in the pipeline, which will serve as a central resource to aid in future testing endeavors.

In conclusion, Sprint 3 was a testament to our team’s resilience and capability to adapt to new challenges. We’ve not only navigated through complex technical issues but also improved our collaborative processes, setting a robust precedent for future sprints. With a commitment to continuous improvement and a supportive team environment, we are well-equipped to tackle upcoming challenges and work towards our collective goals. The road ahead is promising, and with our team’s shared dedication, we are poised to continue our journey of growth and success.

Issues addressed during this sprint:
Write test cases for Header.vue
https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/checkoutguestfrontend/-/issues/51

Get in touch with Team: 01-2 and discuss Frontend Tests and their findings
https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/guestinfofrontend/-/issues/92

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

Sprint 3 Retrospective

What worked well

The issues the team had made for this sprint were larger in scale, but broken into smaller issues. This was done mainly to have enough issues for everyone to work on. However we found that working together during the scheduled class periods led to greater success rather than working on the issues individually. The team utilized mob programming in order to complete many of the issues for sprint 3. We preferred this approach because some of the issues were dependent on other issues being completed first. Therefore each member would have to wait until the previous issue was completed to work on their issue. Because most of the team members had little experience with the topics related to the issues we worked on, mob programming was also beneficial in allowing us to problem solve together.

What didn’t work well

One thing that did not work well was how the team managed our time during this sprint. By the end of the sprint, the team had completed most of the issues in weight, but failed to complete all issues. The team could have communicated better to ensure we had completed all the issues before the sprint review. Although the team benefitted from mob programming, mob programming did not have to be as heavily relied on if our issues were better written. In the effort of making the issues small and concise, we may have went to far when breaking down issues. Because this was the team’s third sprint working together, we have had enough time to get used to how each other work, the workflow, and GitLab itself. Therefore for this sprint, there was more that worked well than what did not work well.

Changes to make as an individual

A change that could be made as an individual is to encourage others to voice their opinions on what they think should be done. As stated above, the team completed issues through mob programming which led to multiple in person meetings and discussions. During some meetings, when we would get stuck and unsure what to do, I noticed I would list ideas of what I thought the team should do. Rather than always voicing my opinion, I would make the change of asking the other team members what they thought was the best plan to solve the current issue. This change would help everyone feel that they are included in the discussion and voicing their opinion is encouraged.

Changes to make as a team

As a team, a change that could be made is having better time management and keeping better track of important dates. As mentioned previously, the team failed to complete all issues from this sprint. This was partly due to the team thinking we had another in person meeting to continue working on our issues. This could have been avoided if we had been more on track with due dates. There were times where a team member did not communicate well resulting in missed meetings and confusion. A change the team could have made is to work with each other so that everyone stays on task and does what is necessary to forward the team’s progress.

GitLab Activity

• Created issue “Update Documentation”
  • https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/addinventoryfrontend/-/issues/46
• As a team, worked on getting the AddInventoryFrontend up and running on Gitpod along with confirming the functionality of redesigned AddInventoryFrontend
  • https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/addinventoryfrontend/-/issues/49
• Updated gitpod.yml for AddInventoryFrontend
  • https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/addinventoryfrontend/-/issues/48

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.

This sprint was heavily focused on the InventoryBackend repository. One of the main goals of this sprint was to have made some meaningful refactorization to the backend that would take care of out of date code. This old code would turn out to cause a lot of confusion later on when we would attempt to write automated tests for the backend.

Our team met with members from OL Team 2 to discuss what resources they had to help us implement nodemon. This was then taken over by another member of the team as I mainly worked on designing the tests for the backend. Afterwards I would work with another team member who was working on researching and setting up mocha and chai in the backend. Together, we would take the tests I designed and attempt to develop working tests for each of the API calls. The biggest issue we ran into was that the test we were using as an example from the GuestInfoBackend seemed to be unit testing the endpoints rather than testing the API calls. This paired with the errors involving Gitpot and trying to connect to a local host left the team unable to get working tests by the end of the sprint. However, the information we have learned can still be documented so that the next team/developer who looks at this issue wont have to start from square one.

What Worked Well:

This sprint felt like we had a better understanding of the issues on our board before going to the sprint. This led to us having a good plan for the order in which the issues needed to be addressed. This also means that unless one of us ran into an issue, a lot of these issues could be handled individually. While this was great for cutting down on the lengthy meetings we were having in the past, it did also hinder the communication between the team.

What Didn’t Work Well:

Throughout this sprint, we had significantly less time in meetings. Although it feels like the same amount of team and individual effort was put into this sprint, the overall takeaway from the sprint feels less. With most of the work being done individually, there were a lot of opportunities for information to not be shared with the team. This made it hard to keep up with issues and what was going on outside of the standups. 

Team Improvements:

Moving forward, if we were to have another sprint together I would say that our biggest improvement can come from better documentation. Our first 2 sprints we were lucky enough to have a lot of time actually working together as a team. Having less verbal communication this sprint meant we were very reliant on our stand-ups and any documentation we created for issues. Creating better comments in the issues keeps everyone on the same page for what has been done to fix the issue. Especially if we are stuck and ask for help from another member of the team. 

Personal Improvements:

When it comes to working on sprints in the future, I plan to keep myself involved in what the rest of the team is doing throughout the sprint. While it was great knowing I could trust my team members to handle the issues on their own, it still felt like I was missing information or not keeping up with the collective knowledge. 

Issues:

Meet with OL team 2 to discuss implementation of Nodemon:
https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/inventorybackend/-/issues/100 

Design unit tests for InventoryBackend:
https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/inventorybackend/-/issues/96 

Weight accepts the wrong type of input in the frontend:
https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/addinventoryfrontend/-/issues/56 

Create removeInventory automated Test using Mocha and Chai:

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/inventorybackend/-/issues/55

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

The third sprint was uniquely challenging for our group, because each of our members were faced with personal challenges and setbacks while we worked to resolve our assigned issues. I was primarily concerned with writing a unit test for the ‘InventoryBackend’ microservice that would evaluate the operation for adding a weight value to the weight stored in the inventory. This test was supposed to ensure that responses were returned for either of the operation’s two outcomes – a ‘200’ HTTP status reflecting a successful addition to the Inventory’s weight, or a ‘401’ HTTP status, indicating that the HTTP request contained invalid values for one or both of the ‘weight’ and ‘Id’ fields.

While discussing the unit test design process with Professor Wurst, we realized that the HTTP ‘401’ error code was the incorrect choice for communicating the error to the user. According to the list of HTTP response codes hosted by Mozilla, the ‘401 Unauthorized’ error code from the server reflects an unauthorized or unauthenticated request from the client. In our situation, where there exist invalid values in our HTTP request, the error code ‘400 Bad Request’ would be more appropriate.

I was not able to get my unit test to a point where I felt that it was ready to be merged into the main ‘InventoryBackend’ branch. I was having difficulty getting the backend server to build in my Gitpod workspace with the ‘bin/up.sh’ command, which caused the portions of the test which checked for a valid HTTP response to fail. I also had doubts about the construction of my test, as one of my groupmates had pointed out that my test should be using the getInventory function to monitor the value of the Inventory’s weight as the operations are performed.

One of the things that was holding me back the most, in addition to the challenge of researching and learning unit test design, was that I got sick in the middle of the sprint. It wasn’t anything serious, but my energy levels and ability to concentrate were impacted, which ultimately had an effect on my work this sprint. I would have liked to contribute more than I was able to in this last sprint.

Another thing that was holding me back form designing the best unit tests that I could was that I need to spend more time studying and reading about HTTP backend operations. I’ve realized the importance of setting aside the time to read, absorb, and reflect on the material through writing and taking notes as part of the learning process. Over the summer after this semester, I want to take the time to read a book on software unit testing and take notes as I read. I’ve been considering taking the advice from the Apprenticeship Patterns textbook to build my own personal wiki as a way to organize my notes on all the subjects I’m interested in, like software development, information technology, and data science.

Despite the challenges in my own life during the sprint, my team was a tremendous support during the sprint and I’m really proud of all the things they were able to get done while I wasn’t feeling my best. We all did our best to communicate over text between meetings to coordinate our next moves, and we all still showed up for our scheduled voice calls to work on our assigned issues together. I would be happy to work with any or all of them again, and I’m hoping to keep in touch with all of them after graduation.

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

During this sprint, I worked on three issues that were assigned to me. As a group, we all did well in our first and second sprints and felt we had much to improve on during both of those sprints as well as this one. There was mainly one area where we could improve as a team. The first issue that I worked on this issue was issue #99 “Investigate InventoryFrontend to ensure hot-reloading the backend doesn’t affect functionality”(3).

When looking into this repository’s script files I was initially very concerned with the possibility of nodemon being able to be implemented without causing functionality issues. Within the script files there was code that would need to be refactored, and code that connected the backend to the frontend was also outdated and would need to be refactored, they were both using an outdated way of classifying inventory weight. They were using individual item objects instead of a weight integer. I met with Dr. Wurst to discuss what would need to be done in order to progress, thankfully I was mistaken in thinking that both repositories would need to be refactored before nodemon could be implemented, I was told to look into the inventoryFrontEnd to see how I should implement nodemon. The next issue I started working on was “Research nodemon as a way to run backend in ‘development mode’ “(1).

I spent a very long time on this issue looking through nodemon documentation, articles discussing implementing nodemon on pre-existing repositories, blog posts discussing the best ways to implement nodemon into pre-existing projects and only after all of that, I decided to look at the inventoryFrontEnd which had already implemented it. After looking at where it was implemented I was very confused as the solution seemed to be deceptively simple. The implementation of nodemon falls under issue #98 “Edit script files to accommodate hot-reloading for InventoryBackend”(2).

Only one line of code was needed to properly implement it. I was both relieved and very upset by this. I had spent hours researching and reading what needed to be done being very confused by conflicting information from different articles and blog posts only for one line of code to be written. While I did not need to do as much research as I had done, I did learn a lot about nodemon and how it works. The last thing that I will discuss in this blog post is how our group worked together and what we could improve upon for future sprints.

Our group learned a lot from the previous two sprints and this sprint we were able to improve upon our performance significantly. However, we definitely could improve with checking the calendar for when the meetings with Dr. Wurst are. When the sprint review came up I had completely forgotten that it was that day, thankfully we were able to reschedule for the next class to have the review. We got very lucky this sprint, but in future sprints we would have to be far more careful with deadlines and important dates.

Issues:
(1) Issue 97 : https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/inventorybackend/-/issues/97
(2) Issue 98 : https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/inventorybackend/-/issues/98
(3) Issue 99 : https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/inventorybackend/-/issues/99

From the blog CS@Worcester – P. McManus Worcester State CS Blog by patrickmcmanus1 and used with permission of the author. All other rights reserved by the author.

This sprint, the bulk of my time was spent looking into ESLint and keeping up with the team to ensure that we are meeting our goals. I also made a tentative branch for how the pipeline should look like after the linters are added, as these changes were never pushed by the team that was in charge of actually putting the linters in the ReportingAPI repository. I also participated in a clean-up of previous issues that were completed, and reviewed some merge requests from team members.

ESLint Research and Configuration: I checked to see if ESLint could theoretically fulfill the needs for an active linter that shows JavaScript syntax errors in the editor, and it seems like with proper configuration it does fit that role. I found that the ESLint version we currently use is out of date, and the old style of configuration file (.eslintrc) was hard to get working properly. With the new format for ESLint configuration, I found that ESLint needs to probably be installed locally in order to have this take effect properly, and that we should update the ESLint version we use in LibreFoodPantry to adopt the new configuration standard.

Pipeline Configuration: I configured the pipeline based on the GuestInfoBackend repository, and it currently fails because there are no linters actually installed in the repository. The idea is that when the linters are merged into the main branch, this pipeline branch should fetch those changes, push them to the branch on GitLab, then check to see if the pipeline does work correctly with that. Theoretically it should.

Cleanup ReportingIntegration: I checked over the work I did in this repository and it looked fine. I also adjusted Hieu’s branch where he cleaned up some of the documentation.

Cleanup ReportingBackend: I checked over the work I did in this repository and it looked fine.

We had some logistical issues again this sprint, but ended up completing nearly all of the work that we set out to do, thankfully. The problem was that there was a kind of rush during the last few days leading up to the sprint review, which led to me having to take charge as scrum master and keep up with each group member actively in the days leading up to the review to make sure everything was completed. That being said, our communication was the best that it has been this semester during this sprint, the one issue I was consistently having is that we should be sharing communication with each other, but team members were direct messaging me personally for issues they were having.

On my part, I do think I could’ve spent more time with the ESLint issue and also looked into other solutions, but I definitely was feeling crunch from other courses and ended up putting the work for this course on the backlog while other courses were piling work on me. I’m happy I got to a relatively satisfying conclusion with the issue, but I feel like I could’ve done more. On the part of being scrum master, I performed much better at keeping everyone on task by checking in every week, though I could’ve been a little more strict so there was less crunch at the end of the sprint.

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.

Tasks/Issues that I worked on in Sprint-3:

1. Cleanup and Enhancement (Reporting Backend) (https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/reportingsystem/reportingbackend/-/issues/79):

Assigned alongside Isaac, Victor, and Andi, I undertook the task of consolidating enhancements made to the reporting backend during earlier sprints. My role involved conducting a thorough review to ensure clarity and accessibility for future developers. While I completed the task successfully, I acknowledged the need for additional time to refine code cleanliness further.

2. Documentation Review (Documentation Repository under Reporting System) (https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/reportingsystem/documentation/-/issues/11):

Independently assigned, I reviewed the reportingsystem documentation repository to identify any inaccuracies. After a comprehensive review, I found the repository to be accurate and well-structured, requiring no immediate changes. However, I recognized the importance of ongoing documentation maintenance to keep information up-to-date.

3. ReportingIntegration Documentation Update (https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/reportingsystem/reportingintegration/-/merge_requests/10/diffs?commit_id=c972ae9723af3eefcf3d2f09b4827c9c942b368c):

In another individual task, I updated the reportingintegration documentation to reflect recent changes. This included updating the lint.sh file to ensure proper linting functionality and modifying file paths for improved readability. Despite encountering an issue with dead links, which I consulted with our professor about, the documentation updates were otherwise successful.

4. Code Cleanup and Refactoring (Reporting Integration) (https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/reportingsystem/reportingintegration/-/commit/ece7535bbd6e9c5901083e541fb450dcbb9466b8):

Collaborating with Victor, I worked on cleaning up and refactoring code within the Reporting Integration module. This involved rewording, rephrasing, and highlighting phrases in documentation files to enhance readability. While completing this task without issues, I acknowledged the need to dedicate more time to code cleanliness for improved team collaboration and understanding.

Reflection on what worked well:

Improved Docker Pipeline Configuration: We successfully configured Docker pipelines, addressing path issues and ensuring smooth file copying into containers, enhancing our development workflow.
Effective Scripting: Our development efforts were streamlined with the implementation of scripts like bin build and push.sh, contributing to efficient Docker operations and backend development processes.
Communication and Task Management: Clear communication through GitLab issues and effective task management ensured that team members were aligned, contributing to productivity and progress tracking.

Reflection on what didn’t work well:

Linter Configuration Challenges: We faced difficulties in setting up linters, particularly with es.lint configuration files and syntax checking, impacting code quality validation.
Docker-compose Issues: Challenges arose in creating Docker Compose files that adequately handled starting MongoDB, RabbitMQ, and backend services, causing complexities in deployment.
Dependency Management: Struggles with dependency management led to inconsistencies in development environments across team members, hindering collaboration and code compatibility.

Reflection on changes to improve as a team:

Enhanced Teamwork and Collaboration: We aim to foster a stronger collaborative environment where team members assist each other with tasks and share knowledge effectively, improving productivity and problem-solving capabilities.
Improved Documentation and Knowledge Sharing: Documenting processes, configurations, and troubleshooting steps will facilitate smoother workflows, onboarding for new team members, and better understanding of project intricacies.
Streamlined Development Processes: Automating repetitive tasks like linting and formatting will reduce manual effort, enhance code quality, and ensure consistent development standards across the team.

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.