This blog post is about the sprint 1 retrospective. This is our first sprint as a third group in the Cs-448 class. The topic of the project that we will be working on, which was presented to us as a team is about LibreFood Pantry AWS Deployment. In the first moment, the professor sent an email as a beginning to present us that what group we would be in, who would be the members of our group, and most importantly what would be the project we would work on. That was our first familiarization with our team members. Working as a group for one project, I took it as a very positive thing. I really like when I share ideas with other people about a specific topic, and I also like when I take ideas from others from where I can learn too.

The first thing we as a team did, was that we first created the issues. After that, we shared the roles on what we will be working on. We had very good communication as a team and we also were really clear about the project. The issues I worked on were the Deployment Option for EKS and the other issue was research I did about the Microservices Architecture.

These were the two issues I worked on. In the first issue I had about deploying options for EKS, I tried to give some tips about deploying applications Amazon EKS in the cloud, also I tried to determine which deployment options for EKS we should be using. For my second issue, I mostly did research on what is Microservice Architecture, when, and how to use it, and most importantly the benefits that microservices have.

Working as a team on one project like this, looked like a little challenge thing for me. But at the same time, it helped me improve my acknowledgments. We as a team on this first sprint tried to share ideas, and give our contributions regarding the issues that we created. We had some struggles mabey in the first days we started working on the issues, but got the point. And I think that overall we have done a very good job as a team. We also tried to find other communication ways, like writing for any question or suggestion through discord, and also we have met each other virtually through zoom meetings. These helped us a lot as a team too. And hope that all other sprints will work better than we start.

The issues I worked on:

Deployment Option for EKS: https://gitlab.com/LibreFoodPantry/common-services/aws-deployment/general/-/issues/15

Research Microservices architecture: https://gitlab.com/LibreFoodPantry/common-services/aws-deployment/general/-/issues/14

From the blog CS@worcester – Xhulja's Blogs by xmurati and used with permission of the author. All other rights reserved by the author.

At the beginning of the sprint a general overview was collectively made by the group and some confusion over the scope of work completed so far occurred. We were expecting a majority of our work to be code refactoring but at the time it was noticed that there was no actual operating code to refactor really, and our collective effort was directed at simpler cleanup tasks.

During the first sprint I assigned myself to two tasks created by Sebastian:

1^st https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/community/-/issues/61

2^nd https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/addinventoryfrontend/-/issues/2

The first task was creating landing pages for to later connect to the second task which was assigning href links to those landing pages.

I specifically chose these as I have never worked with html except for one occasion earlier in my youth during high school. I felt like this was a good opportunity for learning html and getting familiar with it as it is something I should know how to work with on at least a basic level. The majority of my time was spent on learning how to code in html and dealing with what I considered to be how weird it handles spacing and formatting.

My general experience with learning html did not go as well as I hoped. As with learning anything new the tricks of the trade generally do not surface early on and instead are buried deeper in more specific tutorials.

I generally struggled with spacing and formatting and in specific aligning a couple text boxes until my fellow team member Kurt off the top of his head mentioned that you could add spacing and tabs with specific code that made the pages look slightly more organized. He also told me about CSS and I spent some time learning about that and bootstrapping to find an easier way to automate the formatting of the landing pages.

Now I could have originally finished the landing pages and connecting them to the main landing page, but I had decided that without a more complete formatting style and still uncertain as to the future of those landing pages (the way the users will be directed to these pages depends on the Keycloak and Kubernetes systems being developed by the other teams and might require a complete design change to those landing pages), I chose not to finish the landing pages during the first sprint.

The second issue relates to a far simpler task that seemed a bit more difficult at the time but as I discovered it was far simpler. At the start it seemed like I might have to create other structures in the other front ends for linking together all the landing pages. Luckily after looking over the code it seemed to me that all I would need to do to link the landing pages together would be through the one hub located in the header.vue in the addinventory front end. It is the one point that has the href linking to the other front ends and I’ll be likely directing the landing pages from this point. Ultimately again it wasn’t implemented as the formatting was not completed for the landing pages. Overall I spent far too much time kind of randomly learning html and felt like I needed to find a more organized path to learning html. I also am expecting during the next sprint to have a far more coherent style and to format it based on Worcester States’s general website formatting and color scheme, as well as actually creating the pages and linking them together to finish these two issues

From the blog CS@Worcester – A Boolean Not An Or by Julion DeVincentis and used with permission of the author. All other rights reserved by the author.

For Sprint 1, I mainly worked on the frontend of the guest info system. In our group, we split our team into two teams, one for the backend, one for the frontend. This is how we operated until the end of the sprint. We found that this way of splitting the work between the two groups worked well. I don’t think there were any issues with how this worked. I think my only criticism would be that I wouldn’t know what the backend was doing but that was mostly due to us only now starting with stand up meetings. Also, could be due to the fact that we mainly communicated between our own groups. This is a issue I think we could fix, I also need to work on my communication skills more because I sometimes find myself lost at times with what we’re doing.

Another thing that worked well was how well we adjusted to Scrum. I think our Scrum master, Vien, was a really good leader and was the leading factor as to why we did well with this framework. He helped set up everything for us and set the structure for how our team should work and what we should do. He was also very helpful and considerate with me when I would be stuck on something or one of us had an error with something, he would try to figure out what the issue was.

This sprint, I think I could’ve done a lot more, although the work for the frontend was kind of scarce and were minor fixes. For the frontend, we just needed to refactor mostly in this sprint and format it in CSS. CSS seemed the hardest and I wanted to work on it with another team member but he ended up formatting it all alone so I ended up not being able to work on it. Again, this was a communication issue from me since I didn’t tell him I wanted to work on it collaboratively. He ended up doing a great job on the CSS formatting, it almost looked like what we wanted it to look like, a Google Forms page.

As for me, I definitely could’ve done more. The amount of work I did compared to my other frontend team members is definitely lacking and you can see it in the commits. I’m also definitely the weakest coder in the group and it’s very evident. I am trying to learn more and more as I go through the sprint and being in this group encourages me to learn more and become better. In this next sprint, I’m gonna try to do more work, maybe even some of the harder issues like integration and deployment. On a more positive note, I think the group I’m in is a great group of people and is motivating me to be a better coder because this would be similar to the type of work I would be doing when I go into a software dev job.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/guestinfofrontend/-/commit/cff5f606ea5df652e8e501c65e4166fb26401235
Here, I merged a branch to refactor the register form template into the main branch.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/guestinfofrontend/-/commit/e5c2de68f4566e2af0796095c46199b32ca55c1f
A small change to change the id-input into vue.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/guestinfofrontend/-/commit/97c14005f3c0198c412a9f680bb7309ac442d806
Here, I moved id-input.vue from main into our refactor branch, keeping most of the code.

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

INTRODUCTION: Looking back on this sprint, I can say that our group has performed quite well. better than expected, honestly. Perhaps I have an irrational fear of “events always going haywire”, but at least this phobia keeps me well aware of the situation (“on my toes”, you might say).

Considering the activity found on our group’s gitlab project, we can see that this sprint has consisted mainly of research write-ups, alongside some minor work for the frontend, backend and API of the IAMS.

POSITIVE FACTORS: Here are some factors of the sprint that I believe went well:

• Our group had satisfactory distribution of work.
• The group was able to present a “proof of concept” demo that met specifications for the current sprint. Examples include a basic frontend/backend/API system.
• A lot of research was done during this sprint; our group was able to learn a bit about Kubernetes, VUE, Node.js and other software that is crucial for the IAMS.
• Keycloak has not been set up, but a plan has been made to get it running by the end of the second sprint.

NEGATIVE FACTORS: Here are some factors that I believe can be worked upon:

• The group seemed to struggle with suggestion a proper amount of weight for each issue. Specifically, we seemed to “underestimate” the difficulty of certain issues (such as setting up a Kubernetes distribution). In short, the group often weighted issues as easier than they actually were.
• I feel as though having “more concentrated roles” within the team would be beneficial. While we had two teams (coding and research) led by a scrum master, I feel as though we can have “individual” roles. Applying roles such as “Quality Assurance”, “Presentation Director” and “Merge Coordinator” would help make a better team.

TEAM IMRPOVEMENT SUGGESTIONS: In order for the team to improve, some suggestions that I would improvise include:

• More communication. While our group had used discord and gitlab to an impressive extent, I feel as though there can always be improvement. Additional communication can give us a better idea of our current position in the project, as well as create solutions for the next steps forward.
• Enforcing the “Scrum Structure” more properly. This is an extension of the previous criticism (“More Communication”). In addition to standup meetings, the group should be engaging in a “Daily Scrum” meeting every day, (regardless of class)

SOLO IMPROVEMENT SUGGESTIONS: Personally, I feel as though my team worked spectacularly. If anything, I believe that I was the worst one on my team (following the Apprenticeship Pattern: “Be the Worst”). In order to improve upon my own performance, I believe that I should look at the following shortcomings:

• Dedicate more time to the work. Unfortunately, while I am busy with other factors (such as work, other classes, and so on), this is not an excuse. This project is meant to be treated as though it is a paid job; the performance delivered should reflect a similar quality.
• I would also like to reach out to LibreFoodPantry staff, as well as other groups, more often. Communication and cooperation are key factors to creating this massive project; each group creates their “piece of the puzzle”, and then it will all be fit together towards the end.
• Finally, having a greater understanding of my role (such as “Coder”, “Quality Assurance”, and so on) would be crucial to future work. As of this sprint, I seemed to dabble on various topics without concentrating on anything in particular; this can lead to messy, unfinished work.

Most importantly, I would like to point out that this retrospective blog was posted late (it was meant to be done before the start of Sprint 2). This, in itself, is an error that needs to be rectified in future sprints – timeliness and containing work within the sprints is essential in order to keep the project from falling apart. It’s okay if work carries over to another sprint, but that usually needs to be planned from the get-go.

All in all, the first sprint never goes perfect. No matter how hard one tries to make it go right, something always goes wrong. The point of this lesson (and by extension, this class) is to ensure that we look back on these errors; we then perform research on them so we can modify our work habits. All of this is done to ensure that the mistakes don’t occur again in future sprints. As I look forward, I will do my best to enforce these new policies.

From the blog CS@Worcester – mpekim.code by Mike Morley (mpekim) and used with permission of the author. All other rights reserved by the author.

To be honest, I think this first round of figuring everything out went as well as it could have. To start with what could be improved, I’d definitely have to say our team should establish much more concrete issues to deal with the specifics of what we prioritize for getting done. While we certainly got the gist of it as we were progressing, I was feeling quite lost in organizing epics and issues to be more to the point. A second thing that I specifically didn’t do well with was communication with the team. While in class we had no problems (in my opinion) and we get along quite well, but out of class I am egregiously bad at keeping up with messages. Thankfully, I don’t think it interfered too much with the work flow, but it certainly remains an important thing I have to remedy as I owe it to my teammates. In addition, I think the Scrum Master position was a little up in the air, as most of us were looking at each other for help with direction in our sprint. As a result, we all sort of pitched in where we could, and hopefully in coming sprints the role will solidify into a more acute position with specific responsibilities.

As for what went well, I think the team’s communication was much better than I was expecting. In some areas there was a bit of tension when it came to explaining a concept, or deciding what should get done first, but it was amicably resolved with no real issues. I personally enjoy working with everyone in the team, as everyone was ready to come to the table and pitch in. The only area of improvement I can really pinpoint is staying in contact with what each of us may be specifically working on at the moment. At one point me and a team member began to overlap what we were working on, which went on for a little longer than it needed to.  However, I don’t have much to say on this, as I think on the whole it went smoothly. The things that might need to improve I believe will just come with time as we continue to work on the project. 

As for myself, I think some members may not like me as much, as my participation could for sure improve, but that’s neither here nor there; I only say that to remind myself I need to be better. Another place I may need improvement in is with my explanations. I can be quite ramble-y with some assumptions about what others may believe, or already know. I don’t think in a condescending way, but only insofar that the gap in understanding of communication doesn’t help me to get my point across.  

As for some of my contributions, they are as follows:

https://gitlab.com/LibreFoodPantry/client-solutions/nest/guest-information-system/api/-/commit/8303274a7264a636ee71a2bc10ae57e4578b6806

Here is when I added a few schemas to the API repository.

https://gitlab.com/LibreFoodPantry/client-solutions/nest/guest-information-system/api/-/commit/9fe22f78eaa34a46c3cb32eedb7080bfe33b9bd5

https://gitlab.com/LibreFoodPantry/client-solutions/nest/guest-information-system/api/-/commit/71d797e318075cba6f1ded1bb31ceb0c4fcb7dd5

Here are a couple examples of when I added some basic files to get the API repository updated; I believe there are about 12 similar creations of basic files, but it would be repetitive to include them.

https://gitlab.com/LibreFoodPantry/client-solutions/nest/guest-information-system/api/-/commit/9412a5433a4e8adb9f617d0f892e5a879d1b2455

And finally, here’s an example of me updating a basic attribute file in the repository.

From the blog CS@worcester – Dummies that Code by howbrash and used with permission of the author. All other rights reserved by the author.

This sprint I feel we all did pretty well all around, and were able to accomplish almost all of what we set out to do. The workload felt very balanced throughout the sprint, not too heavy, but not too light either. My contributions to the sprint were adding files to our Documentation Repository, researched Ingress & Gateway, & researched RabbitMQ.

https://gitlab.com/LibreFoodPantry/common-services/aws-deployment/general/-/issues/3

https://gitlab.com/LibreFoodPantry/common-services/aws-deployment/documentation

The above links will take you to the issue to add the files to the repository, along with the repository with the files added to it.

https://gitlab.com/LibreFoodPantry/common-services/aws-deployment/general/-/issues/11

Here is the issue to research Gateway & Ingress, what they do and how we can take advantage of them.

https://gitlab.com/LibreFoodPantry/common-services/aws-deployment/general/-/issues/5

Lastly, I researched RabbitMQ and what it does and how we could use it.

I cannot think of much to add with regards to change, maybe add a bit more detail to my research posts, but otherwise I think everything was solid.

From the blog CS@Worcester – Erockwood Blog by erockwood and used with permission of the author. All other rights reserved by the author.

As my team moves on to our second sprint, I am reflecting on our progress so far. Our project, deploying LibreFoodPantry to AWS EKS, is new this semester. My group is essentially starting from scratch. As such, we spent most of our first sprint researching and compiling information about AWS EKS, Kubernetes, and other relevant tools.

Overall, I think my group did a very good job during our first sprint. Since it was mostly research, I think it was easy for our team to excel. We were able to complete all of the work we had laid out at the beginning of the sprint and now have a better idea of where our second sprint will lead. Everyone was very efficient and got their work done in a reasonable time. It felt like everyone was doing an equal amount of work; it didn’t feel like one person was doing the bulk of it. We all worked well together and were able to communicate when we needed to.

My team did struggle initially trying to break down the work we needed to do into smaller issues, and I can see this may be a problem going forward. No one on our team has extensive experience with AWS EKS, so it can be hard to tell what needs to be done and what is worth researching. I think this will get easier as we become more familiar with our project and how we want it to progress. But this did make it difficult to plan our first sprint.

Something I think my team could improve upon is communication, especially on Gitlab. Most of our conversations about our project were held either on Discord or in person. This sometimes makes it difficult to review what we had talked about afterward, and I imagine it will make it difficult for the group that takes over this project next to understand what we did. It would probably be more useful to have these conversations in the comments of a relevant Gitlab issue.

In addition to communicating more on Gitlab, something I feel that I personally could improve on is time management. I was still able to get my work done in a timely manner, I would not plan out my time well. I am not good at predicting how long a task will take me to complete. I would underestimate how much time a task would take and leave it until the last minute, or I would overestimate the amount of time it would take and wind up with nothing left to do. I want to plan my time more efficiently for the next sprint.

Contributions:

Look into how to set up AWS access for us – I worked on this issue to get our team access to an AWS account so that we could start learning the tool.

Research AWS EKS – This issue provides a set of resources for someone looking to familiarize themself broadly with AWS EKS.

Research and report best practices for Kubernetes – This is a listing of some best practices to keep in mind as our team begins to work with Kubernetes.

From the blog CS@Worcester – Ciampa's Computer Science Blog by robiciampa and used with permission of the author. All other rights reserved by the author.

The first sprint for Software development capstone class was believed to a successful event. Our objective was based upon the epics given to us and broken down to smaller issues to tackle the epics. Our team’s goal is to create new repositories for the backend and API. The nature of this sprint was to make sure the backend and API were setup with their schemas, endpoints, and dev containers to be running toward our next sprint we going to formulate.  Throughout the sprint we did a successful job at setting up the infrastructure and revisiting the previous semester assignment from Software architecture was a major help to us to progress at a steady rate.

There were some issues that our team that we came across our sprint that we struggled and affected our productivity and time management. First, whenever we conduct our standup meetings, we tend to get sidetracked and off topic, one person over speaks another person and bot waited till the end of the meeting thus making us waste our meetings and lose track of time. Second, as we learn more on GitLab and its functions we had many problems with repositories and understanding the merge requests as well as its purpose. The team was stuck upon making the appropriate comments to make a record of what we have discussed during the standup meetings or in general if needed for the next team to look through. Third, making unnecessary repositories, this is what we really struggled with because once we were working the API and we made a repository to accommodate each issue we had, sometimes we accidently work on each other repositories and created a workflow mess and had to revert the commit we made to detangle the situations that occurred.

To be sure we don’t have these issues reoccur, we had made an understand on the major conflicts we have faced to be squashed towards our future sprints. We agreed that for our standup meetings is to be respectful and allow the person to finish speaking their side and wait for all questions till we are finished. To make our own repositories in general to reduce confusion when we are working on our own issues and committing them to the correct repositories. Applying up to date comments in the issues we create and after our discussions to keep a record. 

Other than my team’s performance, there are improvements I want to make towards myself. When I was making one of the schemas for the API repositories, I had trouble on making one myself and had to ask a teammate and do research on a detailed explanation of it and to compose one. An issue like this one could’ve been done in a class period, but it took me two because of it. Backend is a weak point for me and to squash this fear is to resort to the previous classwork and material. As well as do massive amounts of online research to completely understand how to about be implementing the backend which is required for the next two sprints. Another improvement I can make is that for the issues I create are too broad and vague to understand, had some of them revised to be more meaningful. 

Sprint 1 Issues

• Created documentation for the General repository which was created during this sprint. [https://gitlab.com/LibreFoodPantry/common-services/foodkeeper/food-keeper-backend/-/issues/2]

• Created API Paths for the schemas . [https://gitlab.com/LibreFoodPantry/common-services/foodkeeper/food-keeper-backend/-/issues/14]

• Added Dev Containers to the Backend Repository. [https://gitlab.com/LibreFoodPantry/common-services/foodkeeper/food-keeper-backend/-/issues/18]

• Added the generic responses in the API src folder for the paths and schemas to correspond. [https://gitlab.com/LibreFoodPantry/common-services/foodkeeper/food-keeper-backend/-/issues/13]

• Added Dev Containers to the API Repository. [https://gitlab.com/LibreFoodPantry/common-services/foodkeeper/food-keeper-backend/-/issues/17]

• Created Two additional schemas which are named CookingTipsArray and CookingMethodsArray. [https://gitlab.com/LibreFoodPantry/common-services/foodkeeper/foodkeeperapi/-/issues/3]

From the blog cs@worcester – Dahwal Dev by Dahwal Charles and used with permission of the author. All other rights reserved by the author.