Category Archives: Sprint 2

Sprint 2 Retrospective Reflection

In this blog post, I will reflect on the second sprint of my capstone project. I will discuss what worked well, what didn’t work well, changes we can make to improve as a team, changes I can make to improve as an individual, and I will end by listing links to the work I have done with descriptions.

To start off discussing what worked well, one of our biggest accomplishments, if not our biggest accomplishment (in my opinion) was successfully creating a functioning docker image that we were all able to pull and use on our individual laptops. This was a big milestone for us because during sprint 1 we were running into compatibility issues and had no standardized way of creating and sharing code with one another.

For things that didn’t work that well, I would like to bring up something that was a common theme in our retrospective meeting: our lack of regularly documenting our work. I think this was something that we started off on the right track at the beginning of our sprint after having discussed this as an important thing to do in our first retrospective meeting. But with spring break, the week we had off from class, we fell back into the habit of doing work without documenting as we go along. Another thing I would like to mention for this category were the issues we created that started with “Learn to…”. By creating these kinds of issues, it made it difficult to deliver something tangible as it relates to our capstone project. While there was a lot that we learned, it should be represented in the future by applying our new knowledge in a practical way. Lastly, I would like to mention that although we had a functioning docker image to use, it has been incredibly slow to use while on campus/in class. There were classes where I felt like I was simply working on setting up my container just to shut it down by the time class was over.

In our retrospective meeting, one of the big things we discussed we could all improve on as a team is thoroughly knowing our issues board. As a team, we should constantly be reading, updating, asking clarifying questions, and breaking down issues into manageable steps. Part of me was afraid of touching issues that my peers created because I didn’t want to change their original idea, but it is exactly this collaborative process that is needed to create a productive sprint. Doing this clarifies the work at hand and prevents things like creating duplicate issues.

When it comes to changes that I can make to improve as an individual, my goal for sprint 3 is to use my class time more effectively. This last sprint has taught me that it is especially difficult for me to dive into my code when my peers are around me. Some of the best technical work I have done comes from me working in an independent, library-like environment. Because of this, I will focus on using daily standup meetings and my class time as an opportunity to get very comfortable with our issues board. If there are issues that require further details I can add them in class and if there are questions I need to ask my peers about issues they’ve created I can ask them in person. I believe making this small change will be more effective than spending my hour and fifteen minutes in class trying to code with intermittent distractions that may pertain to the capstone, but do not always pertain to what I’m coding.

Links to evidence of activity on GitLab with descriptions:

From the blog Sensinci's Blog by Sensinci's Blog and used with permission of the author. All other rights reserved by the author.

Spring Two Retrospective

During spring two, we had more experience working as a team, and there were some big improvements and things that went well. There were also some areas in which we can improve, that we discussed in our Sprint Retrospective meeting. We started with what went well.

One thing that we improved with was using GitLab to better organize our collaboration. We used comments in the issues section of GitLab so that our development can be better documented. We were using discord and talking in person during the first sprint, when we should have been using GitLab comments. Another thing we did well was approving Merge Requests Asynchronously. During sprint one, we merged all of the requests as a group during class. This was tedious at best, and at worst led to merge conflicts, with branches being many commits behind. This time, we created a system in which any time a team member is the second to approve a Merge Request, he will merge the branch into Main. This streamlined the merging process.

Another area we continued to excel in is getting issues completed, and evenly dividing the work. With the exception of Issues that are not in our control, we completed all of our assigned issues. And we evenly divided the work. We faced some delays, as we had spring break, followed by a week of cancelled classes. But we still managed to get a lot done. We have a lot to celebrate as team, but there are some things that we can improve on.

We had a two week break from classes. And our productivity decreased during that time. We got better at using discord to collaborate remotely. And if issues like this arise again, we will be better equipped to handle them. Another thing we can improve on is naming issues more descriptively, and link issues to epics. We can also work on being more proactive with asking our instructor for help as needed. As a group those are the things we need to work on. And as a team member, I need to contribute to this.

I think I did a great job during this sprint, and I learned a lot. But there are some things I can work on. Going back to some of the group feedback, I need to be more specific in naming issues. This is extremely important, so that if another team member works on an issue I created, he is working on the correct piece of the project. Another thing I can work on is the way I help other team members as problems arise. A few team members needed help getting Chai to work. And were facing a “Chai is not defined error”. I thought this was due to Chai or node not being installed. As when I was in my branch it worked fine. When I moved to main and pulled all of the changes I found that I was getting the same error. It was due to a missing import statement in one of our testng files. I learned that I should take a closer look when trying to help another team member. Meaning that I should switch to their branch and pull all of the recent changes.

The issues I completed / worked on during Sprint two are as follows:

Test File for products: https://gitlab.com/LibreFoodPantry/common-services/foodkeeper/general/-/issues/3

Create Data file for Products: https://gitlab.com/LibreFoodPantry/common-services/foodkeeper/foodkeeper-newbackend/-/issues/5

Test File for Returning API: https://gitlab.com/LibreFoodPantry/common-services/foodkeeper/foodkeeper-newbackend/-/issues/13

From the blog CS@Worcester – Jim Spisto by jspisto and used with permission of the author. All other rights reserved by the author.

Retrospective: Sprint 2

Christian Shadis

This past week, my development team in my Software Development capstone completed our second of three Scrum sprints for the semester and recently had our Sprint Retrospective meeting. This was my (and the team’s) second cycle in an Agile environment, so we were more comfortable with the process.

The most notable improvement from our first sprint to the second was the development workflow in respect to version control. Our largest difficulty was previously with the branching and merging process; team members were pushing code with conflicts, were pushing new code before fetching updates, and were having numerous failed merges. After having several weeks to acclimate, we were able to execute the workflow smoothly for the second sprint. After implementing a new policy allowing merges to occur outside of class, we were also able to better utilize class time to address problems team members were having instead of reviewing pre-written code.

Perhaps the largest roadblock in this sprint was a large block of time in the middle of it during which little work was done. We were off for a week for Spring Break, before having both classes the following week cancelled – no members were available to work on the project during this time. Thus, a significant portion of the sprint was spent completely idle. However, we were able to recover as a team and complete enough work before the sprint concluded.

There are some improvements the team can make for the next sprint to increase our effectiveness. First, the team should improve the naming of epics and issues and do a better job of linking the two. We have epics but have been failing to link issues to them. Additionally, the approval of merge requests needs to be done more continuously and quickly after the request is created.

However, there were several areas in which our team excelled. As in the last sprint, our team successfully divided tasks amongst all members to prevent any member over- or under-producing. Any problem a developer had was brought to the group and resolved in a timely manner, which was made easier by our improved merging workflow and increased available class time. We communicated much more in Gitlab than in the previous sprint, allowing conversation to be kept for posterity. It is also noteworthy that we completed most of the planned work despite a time gap

I contributed to the project in several ways. Perhaps my most significant contribution was the revision of the API repository to produce a valid API that passes the npm test. This consisted of fixing naming errors and references in fifteen different files (https://gitlab.com/LibreFoodPantry/common-services/foodkeeper/foodkeeperapi/-/issues/4). I also added a few necessary files to the backend repository (https://gitlab.com/LibreFoodPantry/common-services/foodkeeper/foodkeeper-newbackend/-/issues/17, https://gitlab.com/LibreFoodPantry/common-services/foodkeeper/foodkeeper-newbackend/-/issues/18 ). Previously to validating the API I renamed several files in the repository to ensure all files were capitalized consistently in camelCase (https://gitlab.com/LibreFoodPantry/common-services/foodkeeper/foodkeeperapi/-/issues/10). Finally, I contributed by opening a dialogue with the IAM and AWS teams to inquire about incorporating access management into our API, and about deployment on AWS (https://gitlab.com/LibreFoodPantry/common-services/foodkeeper/foodkeeper-newbackend/-/issues/14, https://gitlab.com/LibreFoodPantry/common-services/foodkeeper/foodkeeper-newbackend/-/issues/15 ).

Though I performed better than in the first sprint, there are some areas in which I can improve for the final sprint. First, I would like to be more consistent in my work. In the previous sprints, I have been taking multiple days between work sessions and doing work in bulk. This increased the amount of time needed to orient myself with the task at hand and catch up with other work done in the span. Working more continuously would prevent that. Furthermore, I would like to write more code for the next sprint – while I completed several issues, I wrote very little code this sprint. I believe my backend development skills could use the boost of writing more of the code. I will choose different types of issues to assign to myself for the following sprint.

I would consider the sprint successful overall. Essentially, we have a working and validated API, most backend code, and are working on integrating the two together, leaving testing for the third sprint, which is in line with our pre-semester goals. We have worked well as a team, I have worked well as an individual, and we are well on our way to a (near) finished product at the end of Sprint 3.

From the blog CS@Worcester – Christian Shadis' Blog by ctshadis and used with permission of the author. All other rights reserved by the author.

Sprint 2- Retrospective

This sprint went slightly better than the first one. Though we didn’t get to full completion of what we had planned for the sprint, we definitely tackled it understanding what needed to be done and how to do it.

What worked well:

As a team

The most noticeable thing was how comfortable everybody felt tackling the different tasks. During the first sprint everybody was sort of new to this whole process and it was hard to find the right balance on how to work as a group.

Another success was that we had “better” issues than previously. Now that we knew what actually needed to be done it was easier to pinpoint and address them. We originally thought we would just have to modify the backend but then we quickly realized that the backend endpoints actually needed to be re-made from scratch because the work left by the previous team was not really functional. Thus that was the main focus of the sprint

Individually

I worked on finalizing the complete move of the Api to its own repository and creating the addInventory and getApiVersion endpoints. At first, I was very hesitant to work on any of the endpoints because it just seemed like a lot of complicated work. It turned to be way easier than I thought. I ended up mirroring from the microservices example for the most part. 

What didn’t work well:     

As a team

The one thing that did not work too well was breaking down some of our issues. We definitely knew what needed to be done and created issues for it but for some of it was not broken down enough for more people to work on.  That resulted in some team members without issues to work on and some other members with too much to do.

Another point is that we were not able to make the backend work because we had issues connecting to the database. It could be because one member was in charge of it the whole time while others could have jumped in when they did not have anymore issues to work on.

Individually

Everything went pretty smoothly on my end. The endpoints were not hard to create or update. The one thing I would change is that I wish I looked at the front-end a little bit in preparation for sprint 3. 

Changes to be made

As a team:

As a team, we need to do a better job creating issues. We also need to better communication, discussion, and recording of decisions taking place under the GitLab issues and epics. We are looking forward to this sprint because we will most likely all work on the frontends for a while so there will hopefully be a lot more to communicate on GitLab

Personally:

Do more research on the material to bring my focus more on the learning than just getting things done. I will make an effort to look over the issues that are not assigned to me.

Links:

Add an endpoint that returns the API version (#26) · Issues · LibreFoodPantry / Client Solutions / Theas Pantry / InventorySystem / InventoryBackend · GitLab

Create and implement addInventory.js endpoint (#23) · Issues · LibreFoodPantry / Client Solutions / Theas Pantry / InventorySystem / InventoryBackend · GitLab

Rename addItem.yaml and give it a more fitting name (#1) · Issues · LibreFoodPantry / Client Solutions / Theas Pantry / InventorySystem / InventoryAPI · GitLab                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                      

From the blog CS@Worcester – Delice's blog by Delice Ndaie and used with permission of the author. All other rights reserved by the author.

Sprint 2 Retrospective

Our second Sprint had the end goal of deploying a demo Kubernetes Cluster. This cluster would most likely be deployed locally using Minikube and Kubectl, and would use a demo so we could understand the process.

We weren’t able to get to the issue that would have us create a Kubernetes Cluster, but we still made a lot of progress and ended up getting close. 

What worked well was the use of teamwork between issues. What I mean by this is, one team member would research something for one issue, and that research would be important for another team member working on another issue after the fact (1). The research and the results of what we produced while working on our issues is informative, and is vital for our goal of our team for this class and what was our goal for Sprint 2. The quality of our work was pretty good, and I think we’re progressing nicely, albeit a bit slowly, to a competent end product.

What didn’t work well was some of our organization during the sprint. As mentioned above, we weren’t able to finish the demo for the end of this sprint (2), and I believe there were a few examples for this. The first reason was spring break. We didn’t progress on any issues during the break, and coming back took time to get back into gear. The second reason was the class cancellation on the 21st of March. This was right after spring break, and it was a bit difficult to get back into it. Even still, we should’ve started working on issues like normal, but it took some time to organize and it caused us to stall for a few days (3). Finally, a lot of work relating to a Kubernetes Cluster is a concept that is new to us, and it involves quickly learning new things. (4) This spring required us to deploy a demo within a relatively short amount of time. As such, I think Sprint 2 was more difficult than the first sprint, and this spike in difficulty was a big factor in our work progress.

As an individual, I felt that I could improve by interacting with my team more. Some of our issues could’ve been worked on concurrently, and it’s very easy to simply keep working on individual issues without understanding the greater context of what we’re doing. Since we’re trying to set up the infrastructure for a Kubernetes Cluster, everyone needs to understand the context of their work in the project (5). I felt like maybe I could’ve started a conversation or two with my teammates about the project. I did it once or twice, but maybe initiating one or two more conversations would have been helpful.

As a team, communication is something that I think we need to improve on. For example, after the break we should’ve started communicating to roll back into action after not working on anything for a while. Another thing that we struggled on was communicating outside of class on setting up some of the sprint issues, which caused us to lose one point on our grade.

By the end of Sprint 2, we progressed and learned a lot. I feel comfortable about this project, and our work for our next sprint as laid out by our second sprint.

(1) https://gitlab.com/LibreFoodPantry/common-services/aws-deployment/general/-/issues/28 – This issue provides a lot of good information about Kubectl, which will be very helpful on deploying a demo cluster.

(2) https://gitlab.com/LibreFoodPantry/common-services/aws-deployment/general/-/issues/41 – This issue is the demo issue. It is not yet done at the time of writing this.

(3) https://gitlab.com/LibreFoodPantry/common-services/aws-deployment/general/-/issues/24
– An example of me starting this issue a few days after coming back from break, which should’ve been done by Monday.

(4) https://gitlab.com/LibreFoodPantry/common-services/aws-deployment/general/-/issues/24 https://gitlab.com/LibreFoodPantry/common-services/aws-deployment/general/-/issues/35 https://gitlab.com/LibreFoodPantry/common-services/aws-deployment/general/-/issues/28 https://gitlab.com/LibreFoodPantry/common-services/aws-deployment/general/-/issues/39
– Four examples of different things that we need to know while working with an issue.

(5)- For example, the demo would require us to deploy the projects listed by this issue: https://gitlab.com/LibreFoodPantry/common-services/aws-deployment/general/-/issues/34, concurrent to understanding and creating anatomy posited by this issue: https://gitlab.com/LibreFoodPantry/common-services/aws-deployment/general/-/issues/35

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

Sprint 2 personal Retrospective

For our second sprint I think our group improved in many aspects of the process. Last sprint there was a lot of confusion around what exactly needed to be done and how, as well as issues with managing time and expectations. The group also had relatively poor over all communication over discord, although that was more attributed to the fact that many tasks did not really need to involve more than one team member at a time. We addressed those issues in the last sprint retrospective and this sprint I believe that we did much better over all. Firstly we communicated much more than before, using discord more often to ask questions or gather information that we need from other groups. We also had more clear goals this sprint, which consisted of getting many aspects of the back end written up and hopefully working, as well as finishing up refactoring the front end. The team did a good job getting all the tasks done in a timely manner, even writing in stand-in code in areas where another team member was working on implementing a feature. In this case that team member was me, as I was working on inventory.js my team was finishing up their endpoints, and since they could not connect to anything they created stand-ins while I finished up my portion of the project. Another area I think we did good in this sprint was being timely with merge request approvals. This sprint if a merge request was created it tended to be approve within a few hours.

As a team I think we did much better this sprint compared to the previous sprint, and we flushed out pretty much all the big issues we had before. I do not really have any suggestions for things that we could improve going forward as a team. We communicated well, managed our time and work load well, and in the end got almost everything we needed done. As a team we have found a system that works. As an individual however I definitely have some things that I know I can continue to work on to improve going forward. The biggest is still time management. I did better with my own time management this time but I still could do better as I did leave many issues for later in the sprint; however I did not save them for the last second like I did before.

Since there was not too much that can be criticized with the teams performance this sprint, there are not many things I believe that we need to directly address to improve on next sprint. We will however need to keep this level of performance, and most likely bring it up a notch next sprint. While we have not had a planning session yet, we have discussed an abstract of what will happen next sprint, and the main focus will be testing and fixing bugs. Given that this will be a very involved task we will need to be communicating even more and there will have to be more collaboration between members as bugs may pop up in multiple areas of the project.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/backend/-/blob/BackendCreation/src/data/inventory.js

I primarily worked on getting inventory.js written out with the correct endpoint connections so that the team members working on the endpoints can use them to connect to the DB.

From the blog CS@Worcester – Sebastian's CS Blog by sserafin1 and used with permission of the author. All other rights reserved by the author.

Sprint 2 – Retrospective

I thought this sprint went well. While the team definitely has room for improvement, I thought that the team cooperated and managed to accomplish our main goal for the sprint, which was to give functionality to the backend of the project. We managed to add the necessary endpoints as well as give invesntory.js functionality. We also managed to accomplish other tasks like adding commitlint to the gitlab-ci.yml file in all the projects repositories as well as coming to a consensus regarding the naming conventions and style decisions. I thought that, overall, the team was much more cohesive this sprint compared to the previous one. The team was able to communicate much more effectively, and the team was more aware of what needed to be accomplished.

I think the team still has room for improvement that could help us become even more cohesive and efficient. I think the biggest area where we could improve is how we come up with tasks and divide the labor. The tasks that we had in our sprint backlogs over the past couple of sprints were rather imbalanced. There were some tasks in there that were important, challenging, and took a lot of time to complete. But at the same time, there were also other tasks were minor, easy, and took little effort to complete. This led to some team members having tasks that would take them more than one sprint to complete, while other team members did many simple tasks and were left with little to do by the end of the sprint. I think this sprint we should try to break up the big tasks into smaller ones, and group minor tasks into bigger, more general tasks. I think team members should also ask the other team member for help if they think that they cannot finish their task by the end of the sprint.

Individually I thought that my performance was satisfactory. I mainly worked on adding commitlint to the gitlab-ci.yml file in the project repositories, but I also spent time trying to understand how RabbitMQ worked. For the latter, I created a demonstration for RabbitMQ that shows how things are sent and received. Ultimately, I managed to complete six tasks by the end of the sprint that are worth seven points. I think my biggest issue was that the tasked I worked on were either too specific like adding commitlint or too broad and vague like figuring out RabbitMQ. I also think that I didn’t communicate with my teammates as much as I should have.

Personally, I have a lot of room for improve in several areas. One of the areas that I want to see myself improve is communication. I felt like I did not communicate with my teammates as much as I should have. For example, I felt like I should have kept my teammates updated with my progress on the RabbitMQ demonstration. For the next sprint, I want to use Discord as well as class time to communicate with my teammates more. Another area where I want to improve is taking on more challenging tasks. Over the past couple of sprints, I felt like my tasks were either too simple or too minor. So, for the upcoming sprint, I want to try taking on a bigger and more challenge tasks.

List of issues that I worked on:

Issue InventoryAPI#2: Added commitlint in gitlab-ci.yml in InventoryAPI.

Issue AddInventoryFrontend#6: Added commitlint in gitlab-ci.yml in AddInventoryFrontend.

Issue CheckInventoryFrontend#4: Created gitlab-ci.yml in CheckInventoryFrontend and added commitlint.

Issue CheckOutGuestFrontend#7: Created gitlab-ci.yml in CheckOutGuestFrontend and added commitlint.

Issue InventoryBackend#27: Created gitlab-ci.yml in InventoryBackend and added commitlint.

Issue InventoryBackend#22: Spent time learning how Rabbit MQ works and created a simple demonstrations that shows how things are sent and received.

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

Sprint #2 Retrospective

With reflection on the previous sprint we had a more clear vision of what we could modify and change about the front end systems and possibly some work to be done about the back end system. We also as a group decided to reach out to the IAM and AWS teams to see if we could integrate their work with ours. I also had not finished my previous tasks so it was an issue that I personally needed to address and focus on during this sprint.

I still had the two previous issues from the last sprint on my hands but I did take the responsibility of communicating with the other teams and start working on understanding their work to help integrate it with our team.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/checkoutguestfrontend/-/issues/8

On this sprint the majority of my time was working learning html and CSS, but in a manner that was constructive and effective as my previous sprint learning session did not go well. In this sprint I had a far more effective learning period by following a six hour html and CSS course which helped me greatly [https://www.youtube.com/watch?v=1Rs2ND1ryYc]. A major portion of my time was watching this, pausing to test out the things I learned and working on the html pages for the Worcester state styled formatting. This would all have been added to their necessary repositories, but I noticed something both funny and disappointing at the same time that changed all the work that I needed to complete.

While I was nearing the end of the sprint I felt as if the pages I did have were ready for testing and possibly creating a branch for and wanted to test it in one of the front ends. I tried running the front end docker containers on my desktop, but I never could get the local host page to run. It would load forever and never show me anything. I also tried separate front ends to see if it was just one front end’s issues, but I still had the same issue. It wasn’t until I tried running two front ends at the same time and had to change one of the ports to discover that it was just local host 8080 that was having a hard time. I tried connecting to it without any containers running on those ports and a page I had not seen in a while showed. It turns out somewhere on my mac laptop Jenkins was running [https://www.jenkins.io/]. This was preventing me from running and I had to do a deep dive through my laptop to find it and stop it completely which had taken far more time than I wanted to. With it disabled I ran the containers and connected to the local host page. It was there that I found that a front end landing page had already been made and implemented and I had unnecessarily wasted my time on trying to create pages for the front end systems. Now I don’t feel as if my time learning on html was wasted but the app.vue already had the needed formatting and style that was appropriate for the landing pages.

Right at the weekend before the end of the sprint was around the time that the IAM team contacted me and provided information on how to set up the keycloak system and I had spent a little bit of time that weekend looking it over. That same weekend was when I had made the discovery about Jenkins. The href task was easy enough to implement and I had tested it and it worked. I just did not have the time at the end to create my own separate branch for each front end as I felt like it needed to be split into separate and specific issues for documentation reasons. The next sprint will have those two fully solved and I’ll probably be focusing the majority of my time on integrating the IAM teams work and testing out their work with ours, but at least I understand html fairly well now!

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.

Sprint Retrospective 2

For this sprint we did much better as a group. Communication improved and we are comfortable with the project now. After the first sprint I was worried about how we would perform but now I am much more confidant in our abilities. I am excited for what we will achieve during the upcoming sprint.

Over this past sprint we have gotten the backend to work, added commitlint, updated config files and pipelines, and learned how to use RabbitMQ. I personally did the commitlint for the backend, frontend, and API projects, and worked on the pipeline. I am happy about how everything turned out, and I feel like I learned a lot about how commitlint and the gitlab pipeline works. When working on commitlint I decided it would be cleaner to work in a separate branch since I needed to push to gitlab in order to test my work. I am happy about how it worked in the frontend project, but in the backend I accidentally worked on the main branch instead of the commitlint branch. When working in the future I must always be aware of which branch I am working on and review my work before pushing, since you should not orphan public commits.

When working on the frontend I ran into a problem that was not present for the other projects. I found a solution on stackoverflow and made a comment about it. I am not sure that this is the best place to explain myself since I wonder if people will be able to find my comment in the future.

One thing that I am happy about is that I have increased my workload. I still want to do more in the future, but I am happy that I am doing more to help my group out. I think this is something we could all work on as a group. Most of our work is done in class which is ok, but we would get much more done if we all worked outside of class. One thing I think we could do to improve this is to schedule out-of-class work sessions where we would work for a few hours.

One thing that I think didn’t go well was branching. We made many branches this past sprint, and I do not think we used them properly. In my case, I made a useless branch since I did not use it at all. I feel as though using many branches, while useful, can contribute to confusion with our team and future teams. I do think we should be branching, but I feel as though we could do it better.

Overall, I am happy with the progress we are making. I am glad that the backend works finally, and I am glad that the gitlab project is coming along. I am excited for the upcoming sprint since we have almost finished refactoring, and we can begin working on new features. I am concerned about making new features since I do not have any ideas as to what to do, but whatever we decide to do as a group will be fun to work on.

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

Sprint restrospective #2

For this second sprint, we did have good communication with my team, and also we had progressed a lot in our organization. We came up with new techniques to work on the project, divide tasks, and also we were meeting every week on Thursdays and Saturdays to talk about what we have done so far, what needs to get done before the next class, what needs more help and support from the other teammates. I personally took a lot of time trying to find a solution on how to make Keycloak work on my computer because I had a lot of issues with that. All my teammates have been able to make it work on their computers, but mine was still causing issues. So, because of that, I did not spend too much time on the rest of the tasks like working on Docker for example, which made it hard for me to complete that issue before our sprint review. One thing that I noticed during our second sprint, is the fact that we were all one when it came to knowing what to do and were always available to help one another whenever someone is stuck or is having difficulties doing part of the project. After having my Keycloak running, then I started focusing on the other issues I had to work on.

So, the issues that I assigned to myself were first to make Keycloak run, but also to create basic Kubernetes/ Docker Container with Keycloak, deploying Keycloak on AWS Kubernetes.

I got Keycloak working on my computer after having George help me to figure out the problem. Once it started working, I also tried to create a docker container with Keycloak and see what it will do. I am still working on this issue, but there have been improvements compared to the last class. Also did some research on how to deploy Keycloak on AWS Kubernetes and put both under the status done because there was nothing else left to do with those issues. But since I am still working on the Docker container issue, I moved it back to the product backlog and include it in the next Sprint planning on Monday. I also did some research on RabbitMQ and how to deploy it on Docker/Kubernetes. It’s not really part of our project but I thought it was necessary because we were going to work with another team that will actually need Kubernetes and RabbitMQ. I did not put too much of my time into this issue but I did find some good links.

As an individual, I think this sprint two went way much better than sprint one. For the first one, I was still getting familiar with the project, still not close to my teammates and I was not contributing at all (creating issues, writing comments, fixing issues,…). In this second sprint, I actually worked on what I did wrong on the first one and improved it for the second one. There was more communication with the team, and I was more involved (sharing ideas with others, creating issues to help go forward with the project,…) and that was just very helpful for me and my team.

I still need to improve some things like being more active on GitLab, posting important information, writing/responding to comments, making changes/and fixing issues. It is very helpful to have a person in the team that always make sure that we are all on the same page and that we’re all getting closer to put goal. Mike has been a great help for the team when it comes to making sure that we need to get things done, issues, and what needs to go where (sprint backlog, in progress, needs review,…). I am also planning on being more vocal in class and sharing more opinions and ideas to help the team. I am looking forward to the next Sprint on Monday and seeing how it goes.

Links to the GitLab issues that I worked on:

https://gitlab.com/LibreFoodPantry/common-services/identity-and-access-management-system/general/-/issues/15

https://gitlab.com/LibreFoodPantry/common-services/identity-and-access-management-system/general/-/issues/24

https://gitlab.com/LibreFoodPantry/common-services/identity-and-access-management-system/general/-/issues/5

RabbitMQ links:

https://phoenixnap.com/kb/install-and-configure-rabbitmq-on-kubernetes#:~:text=Install%20RabbitMQ%20on%20Kubernetes%20With%20Helm%20successfully%20installed,git%20repository%3A%20helm%20install%20mu-rabbit%20stable%2Frabbitmq%20–namespace%20rabbit

From the blog CS@Worcester – Gracia's Blog (Computer Science Major) by gkitenge and used with permission of the author. All other rights reserved by the author.