Throughout the second sprint, we had a great basis to launch from for our project. We made great strides throughout the sprint and diagnosed some important issues barring our progress. Our second sprint was far more difficult than our first, but we remained determined as a team and hit some major goals. I thought we communicated in this sprint far better than before, and overall worked well on major progress blockers. The most important of these issues was an issue connecting the back and front ends and managing certificates for our server. We set fair and manageable goals despite these major issues, which were started or met by all members of the team. We were again very transparent in our communication, and our communication was frequent and on-topic. I spent my time doing three major tasks; setting up persistent data storage for our back-end, researching certificates and helping to set up SSL for the server, and troubleshooting our failing back-end at the end of the sprint.
What I thought didn’t work well in the sprint was the complexity of our issues. While I thought we set manageable and fair goals, they were complex and large. Many goals had to be reworked throughout the sprint, and were met in some capacity. Many issues got pushed to Sprint 3 due to issues we could not solve ourselves. This was a learning moment for me in particular. I would have liked to resolve all our issues on our own, but sometimes outside expertise or another team is needed to resolve an issue. Even if in our case that other team is the IT department, or Professor Wurst.
As a team I would say that we could better work independently once again. I felt that despite our fair communication, most team work classes resulted in everyone sharing issues. This is something I wanted to avoid, but it happened nonetheless. I would prefer that we work at most in pairs on individual issues, so that major issues do not get sidelined. I felt that my previous retrospective on Sprint 1 should have been vocalized. This is where I think I could improve directly as an individual. I should be more honest in my communication and bring up this flaw sooner, rather than wait for it to improve. Going into Sprint 3 I will be more open and clear about any flaws or issues I see for us all to improve together.
The apprenticeship pattern that best describes my work in this sprint is Retreat into Competence. This fit because the work done throughout the server this Sprint was charting new ground in complex errors. The groundwork we set up in Sprint 1 helped us get our foot in the door, but our SSL certificate issues and back-end connection issues became major roadblocks. I managed these roadblocks by frequently retreating to what I had learned so far, and it allowed me to chip away at the issues and diagnose what to apply to the server.
My tasks:
https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/deployment/gitlab-profile/-/issues/13
This was my first successful task in the sprint. I successfully connected our back-end to a local filesystem in our server and cleaned all our directories of unnecessary files. I tested persistent storage, and it works fluidly.
https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/deployment/gitlab-profile/-/issues/18
Most of my sprint was again spent working on the issue of SSL certificates for our server. I continued to research self-signed certificates until I decided that the best course of action would be to seek out Professor Wurst for a domain. I also worked out that there were unresolved DNS issues in the certificate that were brought to IT. Since this point we have had no SSL issues, and I have updated back-end URLs to accept https.
https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/deployment/gitlab-profile/-/issues/25
Here I made small progress testing the back-end’s failure before we rolled over to Sprint 3. This is an ongoing issue for Sprint 3 as of this retrospective. During Sprint 2 I made progress in diagnosing the issue of RabbitMQ’s failure, and tested various methods to attempt to resolve it and prevent the back-end from crashing.
From the blog CS@Worcester – WSU CS Blog: Ben Gelineau by Ben Gelineau and used with permission of the author. All other rights reserved by the author.