Gitlab Deliverables:
- (Issue Board Maintenance): Throughout Sprint #1, I supervised the creation and progression of issues in addition to readjusting them based on our current scope. https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/deployment/gitlab-profile/-/boards
- (CronJobs Research and Documentation): One of our goals of Sprint #1 was to research CI/CD, and CronJobs was a component of such. https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/deployment/documentation/-/blob/main/Documentation/CronJobs.md?ref_type=heads
- (Set-Up Documentation): After our group installed Docker-Compose and established a connection to Thea’s Pantry’s FrontEnd, I created documentation walking through the steps on how we achieved this. https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/deployment/documentation/-/blob/main/Documentation/Set-Up.md?ref_type=heads
Sprint #1 was a rocky path, but through our group’s collective efforts, we all learned new tools and skills we can implement in future sprints. At the beginning of this sprint, our group agreed that I would be the Scrum Master and, by extension, manage our GitLab activity. In hindsight, this was a perfect designation as I’ve had managerial experience in the past and continue to be a very organizationally driven worker. With these traits, I sought to make our workspace as clear and accommodating as possible, which would provide a strong foundation for our team to begin working. One area I could have improved upon is making sure everyone’s voice is heard. During Sprint #1, my confidence with Linux started at a 2/10, so over the next couple of weeks, I had to refresh my memory while learning new skills. Due to this lack of confidence, I was much more reserved during group conversations as I was trying to soak in as much information as possible. Consequently, I did not explicitly check if everyone felt as if their voice was being heard. Towards the end of the sprint, my confidence with Linux grew greatly. As a result, I was able to participate in group discussions and ensure that everyone was on the same page.
As a team, our biggest developmental challenge was understanding when problems should be taken on individually or as a group. At the beginning of Sprint #1, my bias weighed heavily towards solving problems as a team as it would grant everyone equal opportunities to learn from hands-on experience. As we soon found out, this approach is costly in time and does not let people engage with topics that specifically interest them. The task that gave us the most hassle was getting the FrontEnd certified so that the Backend could connect with it. This task was our “group task”, which we used working classes to try and resolve. Beyond this “group task”, we each had individual tasks we would look into. This approach to distributing work across teammates and holding each other accountable for learning unique material has been effective so far. After learning a new tool or skill, I request that the individual creates documentation listing the steps or sources they referred to so that all team members have access to what the individual learned. So far, there have been no issues with this approach, and we will continue to refine it in Sprint #2.
As previously mentioned in my review of Apprenticeship Patterns, the pattern that has resonated with me the most this sprint was “Be the Worst”. This self-assessment pattern has allowed me to refresh my knowledge of Linux through completing tasks such as organization and documentation of our completed tasks. This pattern has the individual actively learn and listen to their teammates discuss current issues. From this assessment, the individual can learn from the shared knowledge of the group and will slowly catch up to their level of proficiency. In the case of Sprint #1, my Linux skills were beyond rusty, making me the least proficient in the group. Although I was not able to start helping on the server immediately, I was able to help record our steps. By doing so, I could educate myself on how we approached problems as they arose. Towards the end of Sprint #1, I found my confidence in using Linux and began contributing to the server.
Moving forward, I plan on interacting with the server more, and I have already begun that process by researching encrypted volumes. Additionally, I will continue to refine my skills as our group’s Scrum Master. Now that I am nearly as proficient as other members of my team, I can now focus on making sure we all understand our current goals and have everyone’s voice heard. In terms of teamwork distribution, we have struck a fair balance at the end of Sprint #1. If there is any issue in Sprint #2, I will have to reconsider how we organize and assign tasks. Fortunately, we now have assigned days for backlog refinement, so we can discuss what changes we would like to make during those periods.
-AG
From the blog CS@Worcester – Computer Science Progression by ageorge4756 and used with permission of the author. All other rights reserved by the author.