Achievements & Challenges

Reflecting on what worked well, one aspect was our organization. From the start, we established a strong foundation with clear and well-defined issues, allowing us to hit the ground running. The team demonstrated a balance between offering assistance and providing constructive feedback on each other’s work, creating a collaborative and supportive environment.

However, GitLab presented a learning curve that took us a bit longer to fully grasp and navigate. This resulted in occasional roadblocks, such as instances where work had already been done or where components were missing, requiring further elaboration. Recognizing these challenges is the first step toward overcoming them in future sprints. Another issue we faced and have already solved was our Sprint planning meeting, creating a more team-balanced approach. Originally, we had only one member creating issues as we talked about them. However, we realized this was not the best approach. For Sprint 2, we had each member create issues that we originally defined as a team. Then, we gave each member a chance to talk about their issues, how they plan to work on them, and if any improvements/clarifications would be needed.

On the team improvement front, our collective strength shone, especially when tackling potential ideas for more challenging tasks ahead. Moving forward, we aim to enhance our coordination by implementing more frequent check-ins. This approach will ensure that no team member is too far ahead, behind, or engaged in incorrect work, establishing a system of checks and balances within the team dynamic. Another improvement that will benefit the team as these issues begin to become longer and more challenging is more team-based work. After reviewing other teams’ work in the first sprint, I noticed multiple issues where more than one team member was working on an issue. This step will allow more time and a second pair of eyes on an issue, improving our productivity and furthering our ability to tackle an issue simultaneously.

Individually, I’ve identified areas for improvement that will contribute to both personal and team success. Managing time more effectively is a key focus, acknowledging that optimizing productivity requires a strategic approach to time mangement. Additionally, recognizing the importance of communication, especially on off days, will be crucial in maintaining a good workflow. The goal is to avoid getting too ahead of myself and attempting to tackle everything simultaneously. This includes refraining from taking on multiple issues beyond what is required, ensuring a more measured and sustainable workflow.

GitLab Work

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/documentation/-/issues/10

Description: In my individual assessment above, I recognized a mistake in attempting to tackle more than necessary. While working on issue #1, I unintentionally delved into other topics. In an effort to make the branch more user-friendly, I decided to combine these three separate issues into a single, comprehensive one. This new issue provides clear documentation for each step involved.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/documentation/-/issues/10

Description: This issue involved a straightforward review of the existing documentation. The focus was on ensuring the pipeline’s smooth operation by confirming the correct properties. Additionally, unnecessary extensions and linters were eliminated to simplify and optimize the documentation.

From the blog CS@Worcester – CS: Start to Finish by mrjfatal and used with permission of the author. All other rights reserved by the author.

For our first sprint in the software development capstone course at Worcester State University, our team was tasked to investigate epics attached to multiple repositories within the Thea’s Pantry Gitlab page. We also needed to learn how to use Gitlab’s productivity and team management tools as we went along so we could appropriately divide up tasks among ourselves and monitor our progress. Most of our work was accomplished within the GuestInfoSystem repository and its component microsystems. We also spent time investigating the component InventorySystems in preparation for construction of test suites in the next sprint. I personally contributed to the issues attached to GuestInfoBackend, as well as contributed to sprint planning during team standup meetings and meetings outside of classroom hours.

The specific issues that our team was tasked with resolving were configuring the repositories within GuestInfoSystem for remote Gitpod development environments, renaming the ‘commands’ directory of each repository to ‘bin’ and modifying any scripts that reference the ‘commands’ directory to reflect the name change, and integrating the AlexJS linter into the Gitlab commit pipeline. After that work was finished, we would be responsible for investigating the GuestInfoSystem and InventorySystem repositories to prepare to build testing suites for the frontend and backend services during our next sprint.

Before we started work on the issues, we came together as a team to discuss how much time and effort would likely go into the completion of each task, using the weight system used by Gitlab as an estimate. The weight system is a scale from 0 to 3, with each increasing level of weight meant to represent a relative increase in time and effort necessary to resolve the issue. We attached a weight of 0 to some of our tasks while planning our sprint, which may have led us to expect that some of our work wouldn’t take as long as the task would end up requiring of us. The 0 weight in this system represents a task that shouldn’t take more than a few minutes. The only issue that we worked on this sprint that I would still argue would constitute zero weight would be the renaming of ‘commands’ to ‘bin’. Everything else required more investment of our time and concentration than we had anticipated, in part because we were still learning how to use Github’s tools to coordinate as a software development team.

Once we had agreed as a team on which weight values to assign to each of our issues, we decided to begin our sprint with preparing the repositories for development in Gitpod. Instead of cloning code from the Thea’s Pantry Gitlab page to our personal machines, we can open the repository files in a web browser based Visual Studio. This remote workspace is maintained by Gitpod for as long as we are working in it, and for 14 days of inactivity afterward. To create a workspace for the repository we want to work on, there are tools within Gitlab that allow for easy creation of a new development branch based on an issue, as well as the creation of a new Gitpod workspace based on that branch. I’ve been getting to enjoy using these remote development features, personally, and I appreciate how I can have access to all the functionality of Visual Studio without needing to install extensions on my machine.

To get each repository configured for development in Gitpod, we needed to copy the names of our desired settings from the existing ‘.devcontainer/devcontainer.json’ into ‘.vscode/settings.json’, and to copy the names of the extensions that each repository requires into ‘.gitpod.yml’, a file that can be created in the repository while working in Gitpod by using the terminal command ‘gp init’. However, we found that because of a part of the Gitlab pipeline that lints the files in the repository, we needed to change the formatting of some of the files created by that command so that no lines were longer than a certain character limit. In hindsight, I think it would have been better to try and include those files in the ignore files for the linter extensions. Ignore files are files that point to other files and directories within the repository that we don’t want the linter to review or raise any issues with. We began to recognize the utility of ignore files near the end of our sprint, but at the outset it hadn’t occurred to me to try and get around the linter errors by adding the newly created Gitpod files to an ignore list.

The issue that challenged me the most was adding the AlexJS linter to the GuestInfoBackend and to the Gitlab commit pipeline. I wasn’t anticipating that I would struggle with a task like this, because I thought I would just need to type ‘AlexJS’ into a few files and I would be done with it. While that was part of the process, I also needed to add certain files like licenses and the Code of Conduct to an ignore file. The linting process would have returned a failure status otherwise because those files contained text that would be flagged by the linter. I also spent more time I would like to admit waiting for the linting process to finish while it was iterating through the lengthy ‘node_modules’ directory. That directory needed to be added to this repository’s linter ignore files to avoid an unbearably long (and doomed to fail) linting process. I also realized by the end of the sprint that I had misunderstood the task to add AlexJS to to the Gitlab pipeline, and I had only added AlexJS to the lint shell script within the development environment. In the future I’m going to make sure I review a linter’s ignore file when newly installing it into a repository.

My most significant takeaway from this first sprint is that I shouldn’t underestimate the effort I’ll need to invest into issues that sound like they’re well within my comfort zone. We’re working as part of a cooperative effort on a complex software project, and that requires an advanced degree of communication and attention to detail. I’m not going to be able to go into tasks assuming that they will be easy just because they sound similar to problems I’ve solved before.

Gitlab issues:

• https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/guestinfobackend/-/merge_requests/86
  • Configured GuestInfoBackend for remote Gitpod development environment
• https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/guestinfobackend/-/merge_requests/88#note_1785621795
  • Added AlexJS linter to GuestInfoBackend shell script
• https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/guestinfobackend/-/merge_requests/87
  • Renamed ‘commands’ to ‘bin’ and modified references to ‘commands’ in other files to reflect name change

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.

Sprint 1 Retrospective

What worked well this sprint

Because this sprint was our first working together as a group, learning how each of us felt about working in a team in general was important. One thing we all mentioned was how in our previous experiences, group work tended to be inconsistent in terms of communication and deliverables. This meaning that sometimes a group member would not communicate throughout the duration of the project, and would not have any work to show they have been actively working towards the end project goal. In order to combat this, we decided to have weekly in-class meetings (specifically on Thursdays). Having weekly in-class meetings worked well because there was consist communication throughout the sprint. If any group members had any questions, weekly meetings also gave opportunity for those questions to be answered in a timely manner, if not addressed between meetings. Something else that worked well was having a separate text group chat, rather than only having Discord as our main form of communication. Having a text group chat seemed to be a more reliable form of communication for the team.

What did not work well

As briefly mentioned above, having Discord be our main mode of communication did not work well. In the beginning of the sprint, some of us did not have the Discord app installed on our phones which led to not receiving notifications. This became problematic because there would be missed messages. What also did not work out well was leaving completed issues and merge requests to be reviewed at the end of the sprint. Leaving code reviews to the end of the sprint led to many merge conflicts and extra work that could have been avoided.

Changes to make as a team

One change that could be made as a team is to review merge requests as they are completed, rather than waiting until the end of the sprint. Resolving an issue and completing merge requests as they are finished is a more efficient workflow because the number of merge conflicts is dramatically reduced. When numerous merge requests are made on the same repository, some merge requests will have changes that others do not which is what led to the merge conflicts. Another change that should be made is being more clear as to when we are having meetings. Although stated above that having weekly meetings worked well, there were times where we had to reschedule to meet during the Tuesday class time rather than the Thursday class time. Normally this would not be an issue; however, there were a few instances where some would be there for the meeting, while some would not be due to confusion on when we were actually meeting that week.

Changes to make as an individual

A change that could be made as an individual is responding more promptly. Delayed responses from myself, mainly came from the beginning of the sprint when the team/I were having some communication problems when only using Discord which led to the suggestion of a separate text group chat.

Activity on GitLab

• https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/checkoutguestfrontend/-/issues/35
  • Resolved the issue “Add AlexJS linter to pipelines” for the CheckOutGuestFrontend subsystem.
• https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/checkoutguestfrontend/-/issues/33
  • Resolved the issue “Move from commands to bin” for the CheckOutGuestFrontend subsystem.
• https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/checkoutguestfrontend/-/issues/34
  • Resolved the issue “Gitpod Dev Environments” for the CheckOutGuestFrontend subsystem.
• https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/guestinfointegration/-/merge_requests/11
  • Reviewed and approved the merge request for “Gitpod Dev Environments” for the GuestInfoIntegration subsystem.
• https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/documentation/-/merge_requests/6
  • Reviewed and approved the merge request for “Add AlexJS linter to pipelines” for the Documentation subsystem within the InventorySystem.
• https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/documentation/-/merge_requests/8
  • Reviewed and approved the merge request for “Move from commands to bin” for the Documentation subsystem within the InventorySystem.
• https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/addinventoryfrontend/-/issues/35
  • As a team, we evaluated the current state of the AddInventoryFrontend to get a better idea of what issues would be appropriate for Sprint 2.

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.