For the first sprint of the semester, I individually didn’t get as much done as I hoped to. I did help others, and collectively as a team we got a good amount done,  but I hoped to get more done individually. For this first sprint, I spent a lot of time looking through the project and the different repositories to find out about each component, how it worked, and how it interacted with the other components. Due to this, I feel that I learned a lot about how the project currently works, how it’s supposed to work, and what systems currently function or do not function. However, this also means that I didn’t have a lot of completed tasks.

The only issue that I had assigned myself on GitLab was the one to rename the subprocess files in the Reporting Backend. We felt that the names ‘send.js’ and ‘receive.js’ weren’t very descriptive, and in order for them to properly reflect what they were for, they would need to be renamed to something more descriptive. This sent me down a rabbit hole of looking through the project files to see everywhere the files were referenced so that nothing would be broken by renaming them, and also to be able to update the names in any documentation in which they were referenced. This led me to discovering that many things in the project were pulled from an old version of the backend, and that many things would have to be redone in order for it to pull new changes and build the image from the new repository. Additionally, I noticed that there were two sets of send and receive files, one in the subprocess folder of the backend, and one in the RabbitMQ folder. This had me very confused, as I at first didn’t know what the send file was for because our module wouldn’t need to send any information through the queue system, but then I discovered that it was simply to insert dummy test data into the queue for it to be received by the backend. I still don’t fully understand why there are two sets of these files, but I now understand what they’re for and will be able to modify and use them.

What worked well within our team was everyone being individually proficient, as well as being proficient in certain areas that others were not. Everyone on the team had their own strengths and weaknesses, and we were able to coordinate so that people’s strengths complimented each other, working towards a more cohesive whole. For example, I am more knowledgeable about the backend systems more so than the frontend systems, so I know more about how the docker containers work and some JavaScript, whereas others know more about Vue and the design of the frontend and are much more proficient than me in JavaScript.

What didn’t  work very well was our team communication. We communicated mostly only in class, and only minimally out of class such as on Discord. Given that we were all individually proficient, we had less of a problem completing tasks individually, meaning we had less of a reason to communicate what we were doing and what progress was being made. I think that sharing more information with other team members periodically, such as what progress has been made, what you’re working on, and what still needs to be done, outside of the scheduled times, could have been very productive and helpful for the team.

To improve upon this, we could have scheduled times for meetings outside of class via Discord, where we could discuss the details of what each of us is currently doing and ask others if they need help or if we need help. This way, we could more immediately resolve an issue that someone is facing, rather than having to wait until the next class to discuss the issue with the other team members. Additionally, the extra time spent as a team could help us to figure out each other’s strengths and weaknesses, and to discuss how we could work better as a team.

Individually, I could have improved upon a few things. First, I should have focused more on completing certain tasks, rather than exploring the project independently of any tasks. I could have learned everything I did about the project while completing tasks, rather than without completing tasks. Second, I could have better shared what I learned about the project with other team members.

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

The first sprint for the Libre Food Pantry software went very well for the most part. Since it was a spike sprint, it was mostly looking up tutorials, making sample projects, and brainstorming ideas.

What worked well for me was that I found a great tutorial on Node.js with Express which also shows you how to connect to and use a MongoDB database. This tutorial gave me a great foundation on how to run a server and handling HTTP requests. The tutorial had great explanations of why we are doing each thing step by step while other tutorials lack such explanations and just show you how to do whatever you are trying to do. From this tutorial I made a To-do list web application using Express, MongoDB, Ajax (Ajax code was provided from a source), Mongoose, and EJS(Embedded JavaScript) as practice for the Libre Food Pantry backend and also to make my skill/understanding more solid by practicing everything I learned from the tutorial. This also gave me a reference to look back on if I ever forget how to do a certain thing.

What did not go so well was my understanding of the project as a whole/how it all fits together. Studying the architecture of the project a few times did not do it for me. It took a while but learning Express, eventually asking my teammates about the technologies they are working with, how they fit in with the rest of the project and studying the architecture again after each new piece of knowledge finally helped it all click.

Some things my team and I could improve on would be to be more interactive on GitLab. By the time we made a repository to upload all of our progress, it was more than half way through the sprint. This meant that we could not review what our teammates were doing and have an understanding of our progress as a team. Also, our communication and teamwork could have improved as well. Instead of working on individual sample projects, we all should have worked together on a single sample project using everything that we learned. This would have been a better learning experience for us since that is what we will be doing eventually for the main project. We also could have had better communication with the product owner. I felt at times that not just me but my whole team was confused or stuck with what was wanted/expected from us. Towards the end of the sprint we eventually asked the product owner some important questions that really helped us move forward for the next sprint. Since we were mostly learning the foundation for new technologies this sprint it did not necessarily effect our productivity, but our motivation and confidence.

A change that I could make as an individual is to improve on communication. I felt that I did not have a good understanding of the technologies that my teammates were researching and how they intertwined with what I was working on. For example I did not understand what RabbitMQ was and what it had to do with the project when all I had to do was ask my teammate researching it to explain. Eventually towards the end of the sprint I did this and it helped my understanding of the project greatly.

Links:

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/reportingsystem/new-sample-project/-/tree/main/Backend/NodeJSTutorial/NodeJSPractice – Repository where I uploaded files from each tutorial video.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/reportingsystem/new-sample-project/-/tree/main/Backend/TodoListApp – Repository holding files for the to-do list web application

https://www.youtube.com/playlist?list=PL4cUxeGkcC9gcy9lrvMJ75z9maRw4byYp – The tutorial I used for my sample to-do list app.

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.

Links to evidence of activity on GitLab.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/reportingsystem/new-sample-project/-/tree/main/Frontend

I created a sample frontend using vue.js and learned how to build up the environment and set up a sample project.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/reportingsystem/new-sample-project/-/tree/main/Frontend

I learned how to create a climate for vue.js on Udemy and Youtube to set up my vue.js settings. I used my tutorials to build my first sample project.

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

I am working with Migena for the Small Frontend, which is going to test the login feature with keycloak. We will use vue.js to build the Frontend and the third-party system, keycloak to test it. We will see how a real example of securing our system with keycloak. Our goal is to build a simple frontend to test keycloak.

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

I will keep meeting with the other teams working on the Frontend to discuss the Frontend’s style, format, and other components.

Reflection on what worked well?

The reflection on what worked well is that we work together with the team members we have worked with before to complete the project plan. Because we have worked together in the same group before, we have a deeper understanding of our teammates and are more accustomed to each other’s habits. There will be a relaxed and happy working atmosphere in the group, and the chemistry between the groups will encourage each other and push the project forward.

Reflection on what didn’t work well?

The reflection on what did not work well is that we didn’t know much about the project initially and thought it was a big project. When faced with the unknown challenge, we were a little confused at first. As we got to know each other and started to move forward with the project, we found that labor division was not reasonable. Because in many issues, Frontend and backend are related. Being responsible for each task affects productivity. So we have overlapping project leaders working together to complete the job, which leads to increased efficiency. It was difficult or challenging to push the task forward, but we encouraged each other through the ZOOM meeting 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.

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

This is our example repository that contains everything we worked on for Sprint 1.

Review Docker: Reviewed old projects and main commands for docker.

Create Sample Docker projects: Created a sample Docker Project, Did the getting started activities.

Repository for event project: The main repository for the event project.

Learn About RabbitMQ : Learned RabbitMQ components and Implemented them using Docker.

Review Scrum :  Reviewed the scrum guide and understand the process.

For the project, I am part of the reporting team. I mainly work on the event system software that sends and receives a message to other systems using the RabbitMQ messaging system interface. I also work with the database person and did make a docker example project and a cheat sheet of all the docker commands.

What worked well / did not work well

 The thing that worked well for our group is that we were good at organizing everything and everyone was responsible for certain tasks, and I noticed that some of the tasks overlap between us. For example, the backend person must work more closely with the database person. The first few days we were a little confused, but as everything came together our workflow improved tremendously, which helped to complete all the issues for sprint 1. One thing that did not work well is that we had few problems with GitLab, our template was not loading properly at the start so we could not assign proper labels to issues. Also, during meetings, we should have done the group tasks together instead of a person just doing the task.

What changes could be made to improve as a team?

For a project, communication is the key to success. I think that as a team we should be communicating more rather than doing our tasks during the meetings. For instance, if someone is struggling to figure something out, the other team members can help the person and give insights to lead the individual in the right direction. Also, for the next sprint when we are making cards we should be more specific about the descriptions and properly think about the issue and how we can achieve it and it is clear to the person what needs to be done.  

 What changes could be made to improve as an Individual.

As an Individual, the change that I can make is to plan properly for the next sprint. The first sprint I started of slow because I was not sure how you do something or if I am doing it the right way. A properly planned sprint will help me to go with a flow and have a balance rather than getting overwhelmed by doing all the tasks towards the end of the sprint. My communication with the team should get better as we move on to the next phase.

Overall, this was a great learning experience. I think the first sprint was a success and a starting point for our team to move forward with a vision to complete the task that is assigned for us. I’m looking forward to working with the other teams to combine everything and see our progress.

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

If anything can be said about this sprint, it is that a lot was learned throughout. I was familiar with how the teams would work, but many of the day-to-day specifics and exact deliverables were a bit unclear to me. Before this class I had only really examined this sort of team structure in CS-348, and that more theoretical practice left me in the dark on some of the specific aspects. To specify, the issue board for our team was not utilized to its full potential in a few different ways. However despite these issues we were able to complete all issues on the board. First I will discuss exactly what worked well, and subsequently what did not.

Regardless of what could have been improved, which will be discussed, this was overall a successful sprint. Each team member did, at the minimum, read through the material they were assigned and documented any relevant information in the wiki. So by definition this was a successful sprint, but it’s true value for us was what we learned for the next sprint in my opinion. One part that could have been worked on were the actual issues themselves. These could have been streamlined a bit, as we simply decided to read through all of the documentation because it was the most logical thing to do. However the documentation often contained much superfluous information that may not really end up  being useful. It felt as though this was mostly being done to meet our SCRUM goals. Besides this, it was still difficult to communicate all of this information with each other. Throughout the sprint we also forgot to move issues through the board as we worked on them, and I personally did extraneous work that could have qualified as a new issue but did not think to create one for them. After all of these issues however, there are some changes that can be made for this next sprint.

This first sprint was an extremely valuable learning experience as previously stated. There are a few ways that our community of practice could improve the effectiveness of our teamwork. One idea that was brought up was to simply communicate more often using the community of practice channels. This will allow us to simply have one location containing all information we may need, and allow us to be on a similar page with each other. To further improve this, we also discussed having small work sessions in the community of practice from time to time to ensure none in the group are behind. This would also allow us to have more consistency in the method that we use to connect our respective systems to Keycloak further down the line. As for myself personally, my major flaw was simply getting behind on my work. If I am being honest, I had to do much more reading towards the end of the sprint than should have been necessary. To improve on this, I have set aside specific time frames during the week to work on projects. I will also try to share any more useful information in the project-wide community of practice, as I have a tendency to just share information in my team’s text channel only. I am excited to put all of the changes into play for this next sprint!

From the blog CS@Worcester – My Bizarre Coding Adventures by Michael Mendes and used with permission of the author. All other rights reserved by the author.

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

Here I put links for tutorials and relevant articles for learning MongoDB.

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

This card shows I was allocated to the event system cross-cutting team.

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

This is a card I created for learning how to connect the backend to mongoDB.

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

This card is for an example mongoDB project.

Our first sprint was filled with learning, both about the tools we need and about the sprint process. I think there are many things that worked well. First, I think our team composition right now is good. We all know each other from previous classes, and we are comfortable with talking casually to each other. This is good because there was no initial awkward phase – we were able to get straight to working with each other. Another thing that worked well was asking important questions for each other on gitlab. While we did not use the cards to their fullest potential, having email notifications for gitlab really forced me to pay attention to the cards. My discord does not have notifications turned on, so I must actively check for new messages. On gitlab the email notifications made me extra aware of new comments on cards and any changes to the cards.

There were of course many things that did not go so well. Somethings I failed to realize is that gitlab should be the place where I keep all my work. I followed quite a few tutorials, so I have a few mongodb projects on my own computer. I should have been actively adding them to gitlab as well. My issue was that I did not feel like I had a finished product worth sharing. I should have realized that was okay and posted that anyway.  Another thing that did work so well was communicating mostly on discord. We did a lot of brainstorming and communicating in class through voice chat. Because we did not write down every single thing we spoke about, some things were forgotten or missed. We should definitely be trying to use text chat more, but most of our communication should probably be through gitlab to maintain a permanent record of what is being discussed.

As a team we should definitely work on mostly using gitlab cards for communication. As a team we should also try to contribute more evenly in discussions and with product owner meetings. I know I am not contributing enough and we should all be taking responsibility for our team instead of just letting one or two people do all the talking for us. Overall though I feel like my team is very solid and we work well together.

As an individual I should work firstly on time management. Having sprints like this is almost deceptive in a way. This isn’t the kind of thing you can do all the work right at the end of the sprint. It really isn’t possible to complete most of the cards like that. The work should be spread out, especially since it is cumulative. Some cards need to be completed so you know how to complete other cards. I also have to work on communicating with my group more. As the system is more fleshed out, we are going to have to work together more to combine the parts we have created. Right now we are sort of working independently and just checking in with each other. I will have to share the work I am doing with he rest of my team very frequently by pushing it to gitlab instead of just waiting to show them during class.

I went into this sprint very intimidated by the size of this project. After finishing it I feel a bit better because I know how sprints work now and we have a clearer vision of what we are going to do for this project. The next sprint will definitely be an improvement over our first.

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

After the first month of my final semester, my capstone course has proved to be an interesting experience so far.  As much as we are working in groups to create a database dedicated for the food pantry, I believe we really are striving to strengthen our skills with using the SCRUM method of group work.  Our first sprint went very well in my eyes.  We have not gotten much done in terms of making the frontend and backend of our database, but we accomplished a lot when it came to getting tasks done that we chose to try to complete at the beginning of the sprint.  Our team worked very well together and it seemed as though everyone was contributing heavily towards finishing our tasks quickly and completely.  Personally, I thought I contributed a lot of research, work, and extra effort for the team to help everyone out.  We decided to make me the team’s SCRUM Master which in all honesty did not force me to have much more responsibility at all, but it was helpful for me to learn from the product owner and relay back to the team.  I tried keeping helpful information posted both on discord and on gitlab for the team and for myself.  This proved very helpful.  In the future (for later sprints and for in similar situations in real life), I believe we could have done a better job communicating outside of our class periods.  It may have help our group get things done even smoother than how we already did if we had been running a better communication system.  This however was not really anyone’s fault as we were still able to get most of our tasks done and because of the fact that everyone is taking a lot of classes right now and not just this one.  On a personal note, I think it would have relieved some stress for me if I could have tried spacing my work for this group out throughout the week rather than getting things done in one or two sessions per week.  This would have made it easier for me to communicate problems if I had had any and would have reflected better on my final completions at the end of the sprint.  Again though, it is more difficult when I am taking other courses and not having this project as my main job or focus.  The main issue that I think my group and I will run into for the next sprint is that we will have more tasks related to building the database now rather than the more learning and reviewing bases tasks we had in sprint one.  Like I stated earlier, this sprint seems more like one in which we get familiarized with how the rest of the sprints will be done and how to work as a group with SCRUM.  However, I think we picked up on what we needed to do very fast, and everyone seemed to have put in a lot of good work and dedication.  Because of this, I know that even if the tasks in the next sprints become more difficult, we will still be able to get great work done and have a successful product in no time!

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

Sprint #1

For our work on the InventorySystem component of the Thea’s Pantry software project, our team worked throughout sprint #1 to learn about necessary tools, skills and technologies which we will be using throughout our development of the project. This meant that a majority of our focus was on learning, although a small number of useful artifacts were also produced. Much of our communication throughout the sprint was coordinated with the issues board for the project on GitLab (https://gitlab.com/groups/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/-/boards) which allowed us to keep issues organized based on whether they were actively being worked on, completed, or in need of review.

More specifically, much of my work during the sprint was focused on learning about the Vue.js front-end framework. I organized this process into a number of issue cards, with one central card (https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/community/-/issues/2) which I used to connect three interrelated cards concerning the same topic.

First, I went through introductory content (https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/community/-/issues/3) from sources including the official Vue tutorials on the website for the framework, as well as introductory materials produced externally, such as this intro to Vue 3 series: (https://www.vuemastery.com/courses/intro-to-vue-3/intro-to-vue3/) produced by Vue Mastery.

Furthermore, I went through some of the most important highlights of the Vue documentation to learn the fundamental concepts of the framework (https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/community/-/issues/4), and then practiced using Vue by building a simple Docker container with a Vue Installation (https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/community/-/issues/5).

Combined, I feel that this sequence allowed me to gradually build up a familiarity with Vue and to become fairly confident overall in my ability to work with it. When the group begins working on the actual implementation of the front-end during the next sprint, I will be prepared to make use of Vue for the creation of the three different front-ends necessary for the InventorySystem portion of the Thea’s pantry project.

In regards to how this sprint went overall, I would say that it went relatively well. We managed to complete the majority of the work which had been staged for completion, accumulated a lot of valuable information, and built a wiki for the project (https://gitlab.com/groups/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/-/wikis/home) which we can now use in the future to store documentation as well as the sort of syntax/procedure which we focused on during the sprint. Everyone on the team was able to find a large number of resources, tutorials, and documentation related to their chosen topic/focus throughout (ie: https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/community/-/issues/6, https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/community/-/issues/10). Additionally, we were able to get the basic structure of the project setup (multiple repositories to hold the corresponding front-ends, the back-end etc) (https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/community/-/issues/14, https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/community/-/issues/13).

One minor issue we did have was in relation to the database/data persistence layer of this project. We didn’t have enough people allocated to the team for someone to focus on learning about MongoDB (the database software being used for this project) specifically. Given that the front-end and back-end were deemed the most important components necessary to get started with actual development & implementation, we decided to focus on MongoDB during the next sprint, after we have some of the front-end and back-end frameworks implemented and in-place for the database system to hook into.

In conclusion, I would say that the sprint was a success, a good majority of the work planned was completed, a great deal of information which will be useful in the future was collected, and then categorized/organized on the project wiki. The example project using Vue and Docker will be an important reference during the next sprint when we will need to begin working on the implementation of the project, and we will be ready to start working on the functionality and layout of the InventorySystem during the next sprint period.

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