Category Archives: Sprint 2

My Second Sprint: An Improvement in the Journey

                Over the past few weeks I have once again had the opportunity to take part in developing the LibreFoodPantry software platform. From start to finish this second sprint has challenged our team in creating a solution to the question of security for this software. In this sprint we had mainly focused on how key cloak deployment would work and how we would adapt the existing web pages to utilize this security platform. We learned much throughout the sprint however we found that there was still much more to our role than just the webpages.

                Just to reiterate our goals, a group of my peers and I were tasked with creating a secure login service for LibreFoodPantry that would allow users to sign up and sign into the food pantry’s website. We had previously spent the last sprint attempting to understand how this third party software functioned and what we would need to do in order to implement it. This sprint would focus on the implementation of Keycloak and what would be the least disruptive method of doing so. The goals were as follows; create a working instance of keycloak with a front page without any containerization, understand how to create and maintain users, roles, secure each new page we added within the same login system, then transition this system to a container system such as Docker.

Getting started we first focused our efforts on everyone getting an instance of Keycloak running. After ensuring that I could get it working reliably I posted my results on Gitlab for my peers to have their own working version of Keycloak with a frontend page. We were then able to move on to our other issues. I was tasked with reviewing NPM and how to adapt existing frontend pages to Keycloak as well as ensuring that permissions and logins could be carries between different pages. Others among us worked on researching the deployment of Keycloak on a Kubernetes cluster using AWS as well as communicating with other groups to begin to synchronize and ensure we were working on features that mattered for the other groups.

                The team worked well together, and we once again made a point to meet twice a week to discuss progress and synchronize ourselves outside of normal meeting times. It was worth the extra meeting times as I was able to assist group members in ensuring that they could have Keycloak working and that their computer was set up to properly install and run Keycloak and the frontend page.

                Our main problems came about once again in properly updating our work in the issues tab and a failure to properly estimate the weight of some issues we had created. I once again found that I was stuck on a single job most of the sprint trying to adapt existing pages to utilize Keycloak. It would be apt to say that I was again immersed in my own work and communicating less than would be ideal. However unlike last sprint I was able to work past this in a shorter time frame and was able to communicate this to my groupmates. With this out of the way I had started work on adapting this system to work in containers such as those found in Docker or in a Kubernetes cluster.

                At the end we had started to make more progress quickly but by that time the sprint had come to a close. While this was not an ideal sprint, it was definitely an improvement over the last and I feel that we had done better in estimating the weight of certain issues although not solving this problem entirely. We hope to continue practicing working in the Scrum format and improving our grasp on what issues need to be created and how much weight they should carry.

From the blog CS@Worcester – George Chyoghly CS-343 by gchyoghly and used with permission of the author. All other rights reserved by the author.

Sprint 2 Retrospective

For this sprint my focus was to get the frontend and backend talking to each other. This worked well and now they are communicating and sharing data as seen from the commit below. During the sprint we like during the last one was on teams of three, three assigned to the frontend and three assigned to the backend. Like last time this team dynamic worked well as we were able to complete a lot of issues in a timely manner.  Also, I found that the new commit scheme using commitlint made commits much easier to read. Due to the way you must commit a message, it made it so much nicer and easier to read know what type of commit they were sending such as a feature, fix, etc.

During the sprint however I did think that there was an issue with the team dynamic. On the frontend we didn’t have a lot of issues for this sprint. This sprint was mainly to focus on integration and adding files to make commits and other applications work well. For this it was mainly me and Sandesh who were working on this. Brendan did some work as well, but I thought to my self what the best team dynamic as Brendan when he would finish his issue most of the other issues were already assigned. Also, during this sprint, the backend team had their hands full with issues such as rabbitmq and making sure that it integrates with no issues. They managed to get most of the issues done as their team dynamic is structured very well and they all have a passion for working on the backend. Like the last sprint, I think that if the teams changed to 2 and 4 then every group member would have things to work on as the backend team normally has many more issues to work on during a sprint then the frontend team.

Apart from the team dynamic, I found that there were no other things that could be improved as a team. From an individual standpoint, there could be some things that could improve. Like last sprint I am still experiencing issues with too many commits. It has definitely gone down but every once in a while, when I commit work, I sometimes accidentally leave my test objects in the code which if not explained to other group members could confuse them. Due to this, I find myself sending a “fix” commit to remove all these test objects. What can be done to remedy this is to read all my code again before submitting. Like if were taking an exam, double checking my answers would ensure that every test object is removed form the code before any commit is sent through. Apart from that I really enjoyed this sprint and the work that I was submitting.

Commits

Added Commitlint to frontend repository: https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/guestinfofrontend/-/commit/6179634a126b7dadb3e2edb193a87195a9aa6281

Change frontend skema to match backend: https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/guestinfofrontend/-/commit/cc60a90c708823c01d47e705946363d7cf94c274

Make gitlab.ci file for frontend: https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/guestinfofrontend/-/commit/57cca658ba91a8707934a246d31912dc63f8a19d

Frontend docker container with nginx: https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/guestinfofrontend/-/commit/5842bad96d66457b3574bd54d48096e0ad2938d7

Fix container to reload and not crash: https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/guestinfofrontend/-/commit/59a5599f7d3440f8472c4a5adc4f8abdb7b89e24

Integrate frontend image with backend:  https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/guestinfofrontend/-/commit/321de2c87834105dabf1ecdb185cda3e699705d0

From the blog CS@worcester – Michale Friedrich by mikefriedrich1 and used with permission of the author. All other rights reserved by the author.

Sprint2- Retrospective Blog

For this sprint, my team, team-1, have worked with two epics, which are refactoring backend and adding commitlint to gitlab-ci.yml for all projects which are reportingAPI, reportingFrontend, reportingBackend. We have finished the epic of adding commitlint to gitlab-ci.yml for all projects by following the instructions. However, the most important goal that our team wants to achieve in this sprint is to make the backend work as expected. First of all, we checked the code to see how they were written, and to see if they were written correctly. However, after I found many errors in syntax and some logic implemented incorrectly in the old code. I decided to create the new backend instead of spending time to fix all of those bugs. As a result, we divided our team into three subunits to work independently with the backend. One would try to refactor or fix the old code as much as they can, one would try to create the new backend, and one would create the test for the backend.

My role in this sprint is to create the new backend and refactor it in the new style. I worked with a docker file and index.js to create a backend server. Then, I created a docker-composed.yml containing node image, mongodb, and rabbitmq, to ensure all the services work correctly. After that, I used javascript to generate all possible methods that can be used to make required http requests, endpoints. In the end, the new backend worked as I expected. It has Rabbitmq service and Rabbitmq functions used to receive all messages from a queue. Then, the backend will store those data into mongodb as two collections, guestInfo and Inventory. Finally, this backend will generate the .csv report when we send the required http request.

As for the results of this sprint, I believe our team has achieved its primary goal which is to make the backend work. However, it is not perfect. There are still some issues that we need to solve in the next sprint to meet the customer’s requests, such as creating a function that automatically consumes messages using Rabbitmq, adding some more required columns to the report, change the _id property in the fake data to studentID. On the other hand, we have also created a test for this new backend even though it is not completed yet. We are planning to complete it in the next sprint.

In summary, there are some differences in how things work in this sprint. We have worked independently on the same problems but in different ways. This sounds like we wasted our time having multiple people working on the same problem. However, for this project, I think it makes sense to do it this way. That is because we all do not have enough knowledge to solve the problem, so there is no guarantee that we can successfully create a new backend. So, we decided to keep it safe by preserving and refactoring the old code while working on the new code. I think this is one of the disavantages of this sprint and needs to be improved in the next sprint. In the next sprint, we will back to work with the regular way, each person should take care of different issues to use their time effectively. For myself and my entire team, we have made some improvements comparing to the first sprint. The only thing I think our team should improve more is that we need to communicate more to understand the project deeply, to be ready for the presentation.

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

Sprint 2 Retrospective

I think that in this sprint we greatly improved our workflow as a team, we knew what we were doing and were a lot more efficient about knowing what we were doing and completing it. We were also a lot better at communicating with each other this sprint than in the previous one, keeping each other updated on what we were doing and what we had to wait on in order to complete our section of the work. We just overall worked a lot better together and were able to complete things as a team as needed in order to get the job done.

Despite the fact that I think we did work a lot better as a team and we did communicate better, I think that it could still certainly use improvement. While we are better about it I still feel like there is some difficulty in communication about what each of us is working on at any given time, and we tend to just wait until class to talk to each other, other than the occasional discord message. We also still have trouble working on the technical side with git, making sure we are merging when we should and focusing on the epics, most of the time, at least for me, we just focus on the individual issues on the issue board and completely ignore the epics aspect of the project organization. Similarly, I think we are still having issues actually running the code with the backend in order to actually test things, but I think that is something we can definitely iron out in the last sprint.

To improve as a team, on the issues listed above, I think that we need to focus a little more again on communicating, especially when things are done and need to be reviewed, and then when they need to be merged. I don’t think we have huge issues in these areas, we just need to make sure we are letting everyone else know when we are done with things. We should also make more explicit what we are working on at any given time, only pulling things to in-process when we are actively working on them would fix this issue I think. Possibly we should focus more on completing epics than the individual issues, just to keep a little more structure to our workflow, but I don’t think it’s been a huge problem thus far, just something to think about. And lastly, I think a big focus of sprint 3 would be making sure we can actually run the code for testing and have the docker images work properly and everything. I think we have talked about it briefly, but getting that fixed I think should be a priority.

As an individual, I think I still need to be a bit more productive and involved in the actual coding process, a lot of what I have done this sprint was just refactoring the file structure and getting some documentation issues worked out (which come to think of it could probably use a little more work). Other than that I feel like I have done very little actual programming work in the past 2 sprints. I just feel like when it comes to doing things other than coding I have a little bit less interest and it is harder to motivate myself. This is a personal issue and I want to finish out the last sprint being as productive as I can be. I am definitely also a culprit of not communicating enough, so I want to make sure for our last sprint that I am keeping everyone updated on what I’m doing and when I’m planning on doing it.

Issue #18 Removed an old file that was a placeholder from a previous group called endpoints.js.

Issue #21 Merged the endpoints folder and the subProcesses folder to remove complexity within the system, keeping the endpoints folder as the main folder for the endpoints.

Issue #2 We discussed naming conventions as a group and I added a markdown file in the Documentation repository to keep track of any style conventions we want to keep a record of.

Issue #24 Created the endpoint for getInventory, using the endpoints from the API and the methods written in the Inventory.js file for functionality.

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

Sprint 2 Retrospective

I did the bulk of the work for this sprint in one sitting. I haven’t really figured out whether I think this was a good idea or not. On one hand, changing gears is something I’m not great at and I try to minimize it as much as I can. On the other hand, I wound up being pretty burnt out on the project.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/reportingsystem/reportingbackend/-/issues/15

Here’s the first issue I completed. “Learning RabbitMQ” is kind of an ephemeral goal, so I decided to only look into what I consider to be the bare minimum of what we will actually need, which is essentially just the ability to put messages in the queue and take them out of the queue. I feel like I know enough about it to work with it and help get other people up to speed.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/reportingsystem/reportingbackend/-/issues/16

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/reportingsystem/reportingbackend/-/issues/17

I’m sticking these issues together because I wound up having to do them at the same time. To refactor things in the backend, I had to at least make sure it ran without errors, and to do that I needed to sort out the dependencies so that everything being imported at the top of index.js was either removed or installed.

It wasn’t until after I finished doing all this that I remembered someone had already modified the backend server to get it to work, only on a different branch. While that kind of tunnel vision is generally a bad thing in my opinion, doing all this work enabled me to actually understand how this project works. Specifically, I had a breakthrough in understanding that the server is actually just a program with its entry point being the index.js file. My previous experience with web development lead me to believe that the actual flow of the program logic was obscured behind all kinds of layers of indirection and it is in my opinion a little embarrassing that I didn’t see sooner that that was not the case.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/reportingsystem/reportingbackend/-/issues/22

Finally, I deleted a directory containing a project from the previous developers that they were using to mess around with RabbitMQ. Not much else to say about that.

I also considered tackling the issue I wrote before about updating the documentation for every project, but I decided against it. Apart from being a little burnt out, I also figured that it’d probably be better to put it off as long as possible so that whoever tackles it can go into it with as much knowledge as possible.

Individually, I think my main issue is just a matter of setting aside time for this project. As a team, I think our biggest problem is the granularity of our issues, although it’s somewhat necessary considering our experience level and the nature of the project. While I struggle to put the work in, I don’t think the team as a whole has this problem. 

All that being said, I am kind of excited about this project now. I was initially skeptical of my ability to contribute to this project, but now I feel like I actually sort of know what I’m doing

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

Sprint Retrospective 2 – Thea’s Food Pantry

The second sprint definitely improved from the first sprint. In this sprint we mostly worked on the Message Queue, sending and receiving JSON data and then inserting it into a local MongoDB database. We did this with RabbitMQ and the ampqlib Node.js package. To do this we first created sample JSON objects then stringified these objects in order to send it to the message queue. Then we pull them off the message queue with our receive module, parse the string back to JSON, and send it over to the Insert module where we then put a timestamp on the data and insert it into the database. I also designed the endpoints and researched how to put JSON data into a CSV formatted file for the report.

What worked well was our teamwork this sprint. Me and Derin worked together to make the send and receive files, changing them to send to two queues, and deciding how we were going to do it. I would say that the teams teamwork has improved greatly from the first sprint where we all kind of did our own thing. This sprint we took the time to communicate and combine our knowledge to get stuff done.

What did not go so well was our production rate. We did not get a whole lot done, as we only worked on the message queue. This could be partly due to getting used to working with others as we had to focus more on communication than work. This means that we did not get to work on dockerizing our application, working with Migena to integrate our keycloak system, or any other of the backend functions such as the endpoints.

Changes that can be made include improving our teamwork/communication skills, everybody should learn at least an overview of the other technologies even if we are not the people implementing them, and communication with the other teams as well. We still do not know the data that will be sent to us, how we will connect our containers together etc. The last thing we should change is our productivity rate. Designing the endpoints and working on the message queue is not enough work for the sprint. There is still a lot to be done and only one more sprint left to do it. For the third sprint, we will all have to pick up the pace to get it done.

Changes I can make as an individual would be making an effort to communicate with the other teams, learning technologies I will not use directly such as keycloak, and communicating with Migena and Haoru to combine the backend with frontend and the keycloak system. I think it would be extremely beneficial for me to at least learn how keycloak works so that I can properly work with Migena to implement it into the whole system. A last thing I would change as an individual would be to take more time to understand Docker as I will be using it in the third sprint to containerize our application. I do not have a great understanding of it just yet.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/reportingsystem/reportingbackend/-/tree/main/src/subProcesses

From the blog CS@Worcester – Austins CS Site by Austin Engel and used with permission of the author. All other rights reserved by the author.

Sprint #2 Retrospective

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/community/-/issues/34

This is the card I made about meeting for the event system cross cutting team.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/community/-/issues/44

This card was for deciding the message format we would use.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/community/-/issues/43

This card was to learn how to use rabbitmq with docker.

This sprint was not significantly better than the first for me, at least in terms of productivity.  Something that worked a little better than last time was adding details to cards. Last sprint I used the cards very little, if at all. I mostly added links to cards with no explanations. This time I added explanations for the cards’ purpose and updated them (at least the meeting card was updated).

Many things also did not work well this time. Because I did not join the event cross cutting team until this sprint, I had no idea I would be working with RabbitMQ. This sprint a lot of time was spent learning about it. That probably should have been done during Sprint 1. I also just did not do as much work as I should have or wanted to do. It was a little tough having to coordinate between two teams as well. I felt like I was neglecting my original team as I worked with the event system team. The even system team if really more like two pairs though with Rainiery and I trying to coordinate with the reporting system separately to send messages to them.

As a team I think we did really well, or at least the rest of my team did really well. Adding Cameron did not disrupt our workflow at all, and he meshes really well with us. I also feel like he brings a lot to the table and is just a really smart and cool teammate in general. We are able to communicate what we need with from each other well too. Like when Tim would show us and keep us updated with the mock front end design. We were able to give some input as to what we thought needed to be changed or what we thought was working well. We were generally just on the same page and I was very satisfied with my team for this sprint.

As an individual, first and foremost I should contribute more to my team. While I do not feel like I was holding anyone back, I do not feel like I was adding anything to the team. I understand we are all working on separate systems, but I do not think I did much to move our team forward. I also should have kept my team updated better on what we were doing in the event system so we could plan ahead for sending messages from our back end. Personally being able to communicate better with everyone is something I have to work on.

Overall, while this sprint was not my best performance, it was one filled with a lot of progress of my team as whole and at the end of the day that is what is more important. I am part of a team and we have a task to accomplish. I should be a part of accomplishing that task and sharing the load equally with everyone else.

From the blog CS@Worcester – Half-Cooked Coding by alexmle1999 and used with permission of the author. All other rights reserved by the author.

Sprint 2 Retrospective

Links:

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/reportingsystem/community/-/issues/40

This was for designing how the database would look and the schemas for all the different fields required.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/reportingsystem/community/-/issues/30

This was for the implementation part of the reporting database that I designed.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/reportingsystem/community/-/issues/26

This was for reviewing css and html using tutorials online.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/reportingsystem/community/-/issues/23

I worked on designing the API for some of the backend endpoints by playing around with swagger.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/reportingsystem/community/-/issues/80

We worked on creating an open api yaml file that will be used in the next part of the sprint.

The thing that worked well in this sprint for our group, the reporting system, was that before we started the sprint we were able to break down more efficiently what everyone’s role would be. For this sprint we added one more person, and they were responsible for their iam system and each of us had our roles. However, this time I was able to work separately on my issues and then meet with them team for issues that are related to the whole team and how we can help each other out. A lot of the database stuff I was working on was related to the backend aspect, so I worked on that with the other teammate who was assigned the backend role.

Some things that didn’t work well was that we had problems with some of the things we were supposed to do with the report. It was unclear in the beginning what aspects would go in the report and which teams would be sending what. So for this sprint there was a lot of meetings to figure out more of the aspects of the report and not as much as being able to implement the features required.

A few changes we could have made as a team for future sprints are to have the meetings with other teams or product owner about the specifics earlier on in the sprint. This way we can focus on creating the different schemas and backend as well as frontend implementations that are required for the overall pantry and not be stuck on the details. With this procedure, we can get more work done and if there is any confusion we can meet and clear it up after we have done some more implementations on our parts.

Changes I can make as an individual to improve the sprint is to figure out all the details of my role first, then start working. There is not point in getting confused on what to do and start working without a clear grasp. This is where I can work with my team more and ask more questions about a certain issue I have. Instead of working independently on all my tasks, I can ask my team for certain things that there are issues on.

Overall, I think the second sprint was really helpful managing confusion with the project and sorting it out to a solution by meeting with the team and others. I think we helped each other out with the details by meeting with other teams and the product owner who had more details about the product we were supposed to make. I think it was a good learning experience and successful sprint and I am looking forward to the next sprint.

From the blog CS@Worcester – Roller Coaster Coding Journey by fbaig34 and used with permission of the author. All other rights reserved by the author.

Sprint 2 Retrospective

 Links to evidence of activity on GitLab.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/reportingsystem/generatewcfbreportfrontend

I created a new generate WCFB report frontend which I used the sample frontend example from the professor. I have already had a basic model for the frontend, the one I need to do more is to connect the backend API which can let customers download the report for the inventory.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/reportingsystem/community/-/issues/23

I designed the API for backend endpoints.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/reportingsystem/community/-/issues/34

I met with Marcos and Matt and talked about the difference between each group’s FrontEnd design. Also, for the next sprint, we will be having more meetings to help each other out on the API.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/reportingsystem/community/-/issues/35

I looked for WSU visual standards to use for the frontends.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/reportingsystem/community/-/issues/61

As a team, we created a Docker_compose file for the Integration of all systems.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/reportingsystem/community/-/issues/67

I implemented FrontEnd for Reporting with the most recent version

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/reportingsystem/community/-/issues/55

I am stilling mak OpenAPI.yaml fileReflection on what worked well?

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/reportingsystem/community/-/issues/71

As a team, we are looking at the new architecture and plan accordingly.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/reportingsystem/community/-/issues/66

As a team, we are looking over TheasPantryReport.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/reportingsystem/community/-/issues/20

I am researching Kubernetes with Migena.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/reportingsystem/community/-/issues/22

We are reviewing Scrum issue boards

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/reportingsystem/community/-/issues/12
We are reviewing LibreFoodPantry Architecture and technologies used.
https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/reportingsystem/community/-/issues/58
I am creating a simple frontend to test keycloack with Migena.
Reflection on what worked well?

In terms of what worked well, through the first phase of working together, team members are working together more efficiently to complete the project plan than ever before. After a period of teamwork, we have a deeper understanding of our mission goals and become more accustomed to each other’s habits. There will be a relaxed working atmosphere and the chemistry between the groups will encourage each other to move the project forward.

Reflection on what didn’t work well?

As for why it didn’t work out, there was some confusion about the final product as to the future goals of the project. When faced with unknown challenges, we are still a little confused. As we communicated with the professor, we had some clear goals. Because the front end and the back end are related. Taking charge of every task affects productivity. So we have overlapping project leaders working together to get the job done, which improves efficiency. The task was difficult and challenging, but we encouraged each other through the ZOOM meetings after class.

Reflection on what changes could be made to improve as a team?

As a team with cooperation experience, smooth communication, and tacit understanding among team members are the basis and key to improving our team’s cooperation level. We would discuss the project after class and give some constructive suggestions about each other’s tasks. Good communication makes our team have chemistry. Through communication and cooperation, we have a thorough understanding of the team members’ tasks. Each knew the other’s project progress would be conducive to the overall advancement of the project. When a team member encounters a bottleneck in a task, we will appropriately slow down the overall progress and communicate with him to buffer his time to complete and push forward the overall task progress together.

Reflection on what changes could be made to improve as an individual?

As an individual, I need to improve my understanding of the Frontend more quickly to help my team better connect Frontend and backend. I need to arrange my group tasks more reasonably to help promote the whole group project’s completion. Besides, I also need to make clear my work objectives, continue to follow up on the team’s project, and make my part and the whole develop simultaneously. 

From the blog haorusong by and used with permission of the author. All other rights reserved by the author.

Sprint 2 Retrospective

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/reportingsystem

Here is the Link to the repositories that contains everything we worked on Sprint-2. Backend, Frontend, Event system, and Keycloak.

RabbitMQ Docker container:  Created a Docker container for Reporting Team

Learn how to get messages from Queue:  Learned How to send and receive messages using JSON object

Meeting with other Event System Team:  Met with the other teams to discuss the format and schema

Review CSS and HTML:  Reviewed CSS and HTML for the Frontend design.

Work with Backend/Database for MQ: Worked with Database and Backend to figure out the Receive file.

For the Sprint, I worked mostly on the Event System components with the Backend person. We figured out how to properly send and receive messages using the JSON object.

What worked well / did not work well

For the Sprint, I worked mostly on the Event System components with the Backend person. We figured out how to properly send and receive messages using the JSON object. I noticed that working together with the team has improved our work productivity significantly and working together helped us to solve problems as a team. For this Sprint there were still a lot of confusing elements. Especially, we had a hard time understanding how the report worked and what the data was involved in the report. Also, the issue description on Gitlab was not precise enough or was not broken down into steps. We were lost in some aspects and did not know what questions to ask. However, it is almost the end of the semester and everyone is busy with exams and project from other classes

What changes could be made to improve as a team?

As a team, we should be communicating more with each other and the professor whenever there is confusion or questions regarding the materials. Also, breaking down the task into small issues will help the team tackle problems one by one. I think it will be great for our team to talk with the other group for example all the FrontEnd people can meet and talk more about the issues and problems they are facing. The same goes for the backend, this will help improve as a team. We also need to add more info to the cards which solve the issue of any confusion regarding who is doing what task.

 What changes could be made to improve as an Individual?

As an Individual, I should be talking with my team more rather than just doing the issues that are assigned to me. If I am struggling with something, then I should ask my teammate or the professor for help rather than just waiting and trying to figure out myself. Since it towards the end of the semester and since every class, I have a project, I should be planning or a schedule to work on individual tasks rather than doing everything at once.

Overall, this was a great learning experience. I think the second sprint was a success and we got a lot of working parts done for the project. I’m looking forward to seeing what the reporting team will accomplish towards the end of the semester.

From the blog Derin's CS Journey by and used with permission of the author. All other rights reserved by the author.