Sprint 1 Retrospective Blog Post

This was my first instance of using and being a part of the scrum workflow. Even though I knew how scrum worked from learning it in a previous class, I was still shocked at how enjoyable and manageable the scrum workflow process was. Our group was assigned the InventorySystem component of Thea’s Pantry. For this sprint, I focused on the CheckInventoryFrontend part of the InventorySystem. Our group did a sprint pre-planning, and we created issues for the “Convert all InventorySystem projects to new project structure” epic. I first made a sub-epic, made each bullet point its own issue, and then linked those issues to CheckInventoryFrontend (Link: https://gitlab.com/groups/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/-/epics/29). I will now go into more detail about what I have accomplished during the sprint. 


Evidence of Activity

Issue #1: Update devcontainer files

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/checkinventoryfrontend/-/merge_requests/10/diffs#6e656a06857650151f28f253233ed97584044098

For this issue, both the devcontainer.json and Dockerfile files in the .devcontainer folder were compared and updated to match the same files in the GuestInfoFrontend.


Issue #2: Update Pipeline/CI files

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/checkinventoryfrontend/-/merge_requests/9/diffs

For this issue, the .gitlab-ci.yml file, the Dockerfile, package.json, and Header.vue found in ./src were updated to match the already updated and working pipeline found in the GuestInfoFrontend.


Issue #3: All documentation, licensing, linting configuration, .gitignore, .gitattributes files must be updated or added

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/checkinventoryfrontend/-/merge_requests/7/diffs

In this issue, docs/developer and linting files were added, and the .gitattributes file was updated.


Issue #4: Revise directory structure:

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/checkinventoryfrontend/-/merge_requests/8/diffs

For this issue, bin was renamed to commands, files were moved from the top level into src, new commands such as build.sh were added, and some files and folders were deleted to match the GuestInfoFrontend.


I reviewed, approved, and merged the following issues:

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/checkoutguestfrontend/-/merge_requests/10

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/addinventoryfrontend/-/merge_requests/9

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/backend/-/merge_requests/17

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/backend/-/merge_requests/18


What worked well?

Working as a team went really smoothly during this sprint. Our team had three frontends that were very similar, so once one person who was working on a frontend was able to figure out how to solve an issue, they would be able to help the other members working on frontends. Communication between team members was also great. When one member needed help, myself and other members would communicate over discord to discuss and fix the issue.


What didn’t work well?

I feel like there wasn’t much that didn’t work well. Very rarely in class we would get off topic and start a conversation about something else like discussing what computer parts are good. That time could have been better spent working on the issues.


What changes could be made to improve as a team?

We split the work so that basically one person was assigned to a part of the InventorySystem. We could have picked up issues in other parts of the InventorySystem to diversify our knowledge on how the InventorySystem works as a whole.


What changes could be made to improve as an individual?

Changes that I could have made to improve as an individual would be to actively search for a solution to problems that may have arised. When updating the pipeline, the program was giving me an unknown error and the professor said that he would look into the problem. Instead of trying to solve the issue myself, I waited for the professor to figure it out. Instead, I should have been also trying to find the solution to the error.


Comments

Post a Comment

Popular posts from this blog

UML Diagrams

Hello everyone and welcome back to another week of my blog. This week I will be talking about UML diagrams. UML stands for Unified Modeling Language and it is used to model business, application structures, programming languages, analysis, design, and implementation of software-based systems. In other words, it is a way to visually represent the design and implementation of complex software. There can be many lines of codes in your software and it can be difficult to keep track of all the class relationships and hierarchies. UML diagrams can make it easier for developers to see the relationships and hierarchies. UML diagrams can work for many different programming languages. It is a standardized modeling language that any language can incorporate into the language of their choosing. There are two different types of UML diagrams. The two different types are structural and behavioral. Structural UML diagrams show how a system is structured. They show how classes and object components wor...
Read more

Expose Your Ignorance

Hello and welcome back to my blog. After presenting what we did in this capstone class, the apprenticeship pattern “Expose Your Ignorance” was brought up and I wanted to check out what this pattern was. The pattern "Expose Your Ignorance" in "Apprenticeship Patterns" by Dave Hoover encourages apprentices to embrace their ignorance and actively seek opportunities for learning and growth. Rather than hiding gaps in knowledge or pretending to know everything, the apprenticeship pattern suggests acknowledging what you don't know and being open about it. Embrace the lack of knowledge and use it as a stepping stone for learning. “Expose Your Ignorance” is about normalizing the learning process. It is about showing your willingness to learn, and acknowledging that the only way to fill gaps in your knowledge is to first admit that these gaps exist. I can use this pattern in many scenarios, such as during team meetings. Instead of pretending to understand a concept, I sh...
Read more

YAGNI.

Hello and welcome back to my blog! In this blog, I want to discuss YAGNI, which stands for "Ya ain't gonna need it" or "You aren't gonna need it." My professor for CS-343 briefly mentioned it in class one day and I wanted to go over it more in depth. In the past, I've done something in my projects where I should have followed the concept of YAGNI instead. I made several methods to change a variable before I actually made the main methods of what that variable would do. In the end, it turns out the methods I made were useless toward my goal and I lost a lot of time. I hope to start applying the concept of YAGNI to my future programming in order to not waste time. YAGNI is a really important concept in programming. Basically it means programmers and developers should only implement classes, methods, or whatever things they need only when they need them. By doing this, you can avoid doing unnecessary work and save a lot of time. When you think ahead and try...
Read more