Category Archives: Sprint-1

Sprint 1 Retrospective

Wiki: https://gitlab.com/groups/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/-/wikis/home

For our first sprint, we mostly focused on learning what we need in order to build the inventory system such as Vue.js, Express, and API. I worked on researching Express by finding, studying, and recording resources such as Express tutorials and syntax guides among other sources. I also got in some practice writing and running Express JavaScripts, though not as much as I’d like to since there weren’t many examples I could find online. The team also created repositories for each component of the inventory system and a wiki where each member can place links to helpful resources. The link to the wiki, which include the resources on Express that I found during the sprint, can be found in the link above. If I were to describe what worked well, I wouldn’t know what to say since this sprint focused on learning rather than building. The same also applies for what didn’t work well since components can’t work incorrectly if you don’t build any.

Overall, I feel our team did fairly well considering one of our team members was incapacitated for a good amount of the sprint. We were able to finish tasks that amounted to 13 weight out of the tasks planned that amounts to 18 weight. That’s six weight for each remaining team member with one extra. The only thing I remember the team really struggling on was getting used to working in the structure of a sprint. So, I can’t really think of a way the team can improve outside of getting use to the workflow and structure of a sprint. It’s about as specific an area I can think of for improvement and it’s a pretty general area. And when I talked to my team in our sprint retrospective, they couldn’t think of much to improve on as a team either.

However, I can think of a bit more to say if we’re talking about what to improve as an individual. For example, the entire sprint I had a general feeling that I didn’t have a clear goal in mind outside of “study Express”. This probably resulted me to not have as fast of an output as I could have and also caused me to worry more that I wasn’t doing enough work. It’s also one of the major reasons why I couldn’t practice writing and running Express JavaScripts as much as I’d like to outside of the other reason I mentioned earlier. Another area I could improve on is summarizing the outcome of each task assigned to me. I say this because I didn’t realize I was supposed to do this until the meeting near the end of the sprint. But then again, this issue kind of ties back to what to improve as a team; getting use to the workflow and structure of a sprint. So, all I can really think on what to improve on as an individual is planning on a specific goal for each sprint to give a clearer direction and remembering to summarize the outcome of each of my tasks.

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

Sprint 1, a Retrospective

Mired by a litany of confusion and growing pains our group managed to come out on top. Actually, that is a boldfaced lie; our group disbanded but I assure you these two things have little to do with each other! All joking aside, our plan at the outset was to learn about utilizing the information access management software known as Keycloak. As it was our first sprint working with completely unfamiliar technologies, the sensible thing seemed to be to read the darn manual and document our findings. While this worked for reinforcing our individual assigned topic from the official documentation, I have to wonder if it really helped us deliver a tangible product or just slowed us down. To elaborate, it seems as though we read a lot about the technical aspects of Keycloak but at the end of the day there was little to analyze and report other than that the documentation seemed to be thorough. In hindsight, I believe the better approach would have been to work together as a group and walk through the configuration process, documenting the whole thing. Moreover, we should have raised questions about the size and scope of user volume and based on those factors decided on a configuration (cluster versus standalone comes to mind) to attempt. While configuring Keycloak and WildFly on our local machines certainly gave us insight, we would have discovered that learning about WildFly and its subsequent installation may have been completely pointless depending on which configuration we decide on going forward.

Given our approach I found that the best work was done when we were collaborating together. I touched on this concept earlier when I was describing how – with the benefit of hindsight – our group ought to have approached the assignment, but synchronous communication and action taken towards configuration yielded drastically better results. It was during these sessions where the team was able to best overcome technical hurdles (such as versions of Docker mismatching) or discover some steps might be superfluous (such as installing and configuring WildFly when not using a local instance of Keycloak). It pains me to say it but it seems as though, of the work we got done, a very small portion of it ended up being useful and that our approach seemed to be driven more by how we could fit our work into the agile framework and not how the agile framework could best help us implement our work. This isn’t to say the framework is of no value or inherently a hindrance, nor is it an indictment of any particular person, but it seems as though our group was not able to mesh well with the framework to get results.

Individual improvements can mostly be derived from the same tired critiques in the vein of rugged individualism whereby things such as losing power, health problems, email harassment must not dampen one’s spirit and certainly, above all else, not their work ethic. Perhaps if I had instead made a measured effort to calculate how many hours of autodidacticism I could throw out so that I may stay in the low C range (as opposed to the upper range) of a non-major class, I may have been able to find more time to commit to exploring Keycloak. Is it unprofessional for a student like me to complain on an assignment for my personal blog? Perhaps. I would argue it’s at least as unprofessional for a teacher to underperform in their profession and that students should have to internalize that as an individual failing.

Links to work done on our team’s wiki:

This wiki entry is the reference page I accidentally wrote on the Authorization Services.

This wiki entry is the reference page I created for WildFly.

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

Sprint 1 Retrospective

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

This was easily accomplished by everyone. This was learning the issue board.

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

This was us choosing a Scrum master. We decided on Tim Drevitch.

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

This was our review of the LibreFoodPantry website which was to get an idea of LFP.

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

This was creating the requirements for the GuestInfo EventSystem, in which I linked resources and described the requirements.

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

This was the most time-intensive task. I linked multiple tutorials for Vue.js, all of which I completed. This encompassed most of the first two weeks of the sprint for me.

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

This is the repository I made which contains all of the simple examples we created for small Vue.js, Express, and MongoDB applications to pull from.

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

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

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

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

These 3 activities are encompassed in the GuestInfoSystem section of Thea’s Pantry. There is a repository for frontend and backend work. It has basic files for each which is taken from the WNE example.

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

This is created a sample Vue.js project, which is on the example work repository.

            Overall, I think we worked quite well as a group, and I would attribute a good deal of it to how well our sprint planning went. We were thorough in going through topics which we felt we needed to cover and created individual cards for everything so that all of our tasks were tangible. Furthermore, we were fair in our division of labor and honesty in what we wanted to do while still taking on enough responsibility as individuals to support the team as a whole. What worked well towards the end of the sprint was also when we focused on what we hadn’t yet finished and allotted the work evenly. Not only this, but we had also made enough progress that I found it to be helpful to have a sort of progress report session in class. We were going through with our Scrum meetings daily, but it was more in-depth, and we were able to articulate what we had done and where our progress was taking us. This was very helpful and perhaps we could incorporate this into our Scrum meetings, allowing us to have a better stream of communication.

            There weren’t many things that didn’t go well for us, but a few include some lacking communication at times and a lack of due dates. As I articulated previously, I was only able to notice any lacking communication when we did communicate better. It wasn’t that our communication was impeding our progress, but it definitely helped to have a clearer picture of the project as a whole when each of us was clearer about our individual progress. As far as a lack of due dates, we became a little rushed towards the end of the sprint since we spent a little too much time completing our learning tasks. If we set limits on these tasks, because they were more open ended, we could have gotten some of our more rushed late sprint activities done faster.

            As far as changes to be made as a team, I would focus on making the changes I stated previously. To get better communication, we should make better use of the cards on the GitLab issue board. Each card should have documentation of information learned and progress made it on it. This makes it much easier for everyone to read the cards instead of having to check Discord or wait for the in-class meetings. Also, we should start putting due dates on the cards for our own sake. This would keep us on track better.

            Individually, I should plan out my time more. I was feeling lost with Vue.js so I spent a lot of time on it. I got into stuff that, later on into the sprint, I found out that I didn’t even need. I need to be better at setting due dates and creating more incremental tasks. I took a couple longer tasks and rather than breaking them down, would try to accomplish a couple things at once which could have been subdivided. This, along with better documentation on the GitLab cards, should put me in a better spot for success in the next sprint.

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

Sprint 2 Retrospective

This past week was the end of our second Sprint for the Capstone class. It all went well, and I think we completed all out tasks successfully. I will write about my tasks and my overall impressions of this Sprint.

Tasks:                                                                                                                                                                

  1. Issue #25: Connection between Database and Rest API Backend
    https://gitlab.com/LibreFoodPantry/modules/visitmodule-tp/checkout/Plan/-/issues/25
    Creating a Rest API backend that talks to the Mongo Database with specified queries and retrieves total weight.
  2. Issue #2: Fix CI Setup
    https://gitlab.com/LibreFoodPantry/modules/visitmodule-tp/checkout/CheckoutService/-/issues/2
    As the name implies, fixing the CI/CD setup for GitLab pipelines, after copying from master it no longer worked.

What worked well?
This time around the Sprint and our lives in general were drastically changed due to ongoing COVID-19 outbreak and the implementations of federal emergency and stay at home orders. It all began normally we started this Sprint like we have before with everyone working on our tasks and meeting once a week for a group session to tackle the problems together. After the outbreak what worked well was very little. In my case finding time and just organizing anything due to my work switching to a “work from home” situation was extremely challenging. One thing that might be working in our favor is that due to most people not working we can call in an online meeting a lot easier since we are all at home. There will still be some time constraints of course.

What didn’t work well?

The social distancing order is a little challenging to work as a small group like this on a project. Before we were able to meet and collectively challenge some of the problems we were having. Scheduling some of the meetings got easier but the actual work time got drastically reduced and in my case just being able to perform some tasks is rather challenging.

What changes could be made to improve as a team?

As I have mentioned before, as a team we should work more on our comments and notes when it comes to working on GitLab and making sure that future participants will be able to trace our decisions and thought process, I believe we are simply not there yet and Corona Virus outbreak made that so much more challenging than before. We also should work on our problem descriptions, we need to be more specific and detail oriented, in my opinion we have only used more generic wording. We probably should have broken the bigger tasks into smaller sub-tasks to make them more approachable as a whole.

What changes could be made to improve as an individual?

During this sprint I have again felt that I have not contributed enough to the team, the tasks I have performed were not as hard as they seemed originally, only working on the API connection to the database took a significant time. As an individual I also think that I should work on my free time management and schedule conflicts. I work full time and often I have only certain time frames to work on school projects and homework and with the temporary adjustments to our living conditions that has gotten even worse. This time will be a real test for all of us, test of our self-control and patience.

From the blog #CS@Worcester – Pawel’s CS Experience by Pawel Stypulkowski and used with permission of the author. All other rights reserved by the author.

Sprint 1 – Retrospective

Sprint 1: 01/22/2020 – 02/19/2020

During the month, I started to work as part of the UpdateGuest time for the LibreFoodPantry project. The Sprint started with sharing and learning general knowledge about the project, what are the services to be offered, and some future perspective. As I learned the service that I and my team will be supporting, we began to fill the backlog with to-do tasks. We operated as a Scrum team, managing a Scrum board in GitLab, and separating stories based on requirements.

We started this sprint by learning new knowledge. As we decided to with the MEAN Stack, we needed to gain knowledge in all technologies that will be used: MongoDB, Express Framework, Angular, and Node.js. So we created stories to track our learning timeframe and weight the knowledge we gained.

During the Sprint I worked in multiple stories and supported the team in different topics:

  • #1– I created the Angular App, the Mock version of our UI service. I supported the team with discussions on how the App should be implemented and organized.
  • #2 – I supported to edit and fix an issue we had with .gitignore file. Together with the team, we discussed how to fix this issue and concluded with a good result.
  • #3 – I created the Document and designed the Frontend Architecture for out UpdateGuest. This document will support the implementation of the service. This document will be edited during Sprint 2
  • I supported the team with PR reviews, issue discussions, and research when we had knowledge gaps.

The end of the first Sprint consists of secure knowledge and the beginning of work with UpdateGuest service.

In this retrospective, I and my team need to reflect on these points:

  1. What we need to stop doing
  2. What we need to do less
  3. What we need to keep doing
  4. What we need to improve

1- What we need to stop doing

We should stop Approving PR by only one person. Each member of the team should approve a PR – so we know that we are all on the same page.

2- What we need to do less

We should be careful when we create new stories and check if there are no duplicates.

If there are duplicates, before closing the story we should let the creator of the story know first.

In the case of merging a PR, the creator of the PR should merge, or if another person do it, we should let the creator know first.

3- What we need to keep doing

We need to keep working with stories that we have on the Sprint backlog.

We need to discuss issues that we may have during the sprint and approve each other work.

We should keep reviewing each story before we mark them as DOne and close them.

We should keep solving debatable conversations and conclude in a good result that works for everyone.

4- What we need to improve 

We should have better communication for each story, issue or blocker during the sprint. Class meetings are not enough to solve issues. For each story, we all need to discuss and communicate with each other, and to consider all opinions before we conclude to a solution. Communication is the key to success for a team.

Conclusion

As a team, we successfully closed Sprint 1. We closed most of the stories in Sprint’s backlog and supported each other to move to the next sprint. We had a Sprint review for what we did, and a Sprint planning for Sprint 2, so we are prepared for the next step. So, let’s start implementing our ideas!

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

Sprint Retrospective 1

Completed tasks

I was worried about how well my team would work together at the start of the sprint. We are all rather quiet and I feared that would impact our project. Even Professor Wurst expressed some concern. While I feel our communication could use improvement, I think we did a fine job completing what we planned to do in this sprint.

We divided the sprint tasks amongst us and mostly worked on our tasks independently. All work that was completed was shared so that others could study and review the tasks they did not work on. While this worked for our first sprint, I am hesitant to repeat this method as I believe it can lead to confusion in the group. For our next sprint, I think we should try and assign tasks to multiple people so we can emphasize that the responsibility for the tasks fall on the entire group.

I feel we did a great job of sharing our work and resources. Most of our decisions are public on gitlab so that it is clear why we did what we did.

My primary focuses this sprint were learning how to set up a mongo database and how create a REST API for it. One thing I think I could improve on is the frequency of my updates. I generally completed a task before making my work public. It may be beneficial to update more often. Something I would like more from my team is feedback. While my work was reviewed, I have not felt like I have received any real criticism, constructive or otherwise.

By the end of this sprint, we had a good skeletal structure of the update module. We implemented test versions of the technologies we would use in our full stack application and completed a small MEAN stack, a full stack app using MongoDB, Express.js, Angular.js, Node.js. With what we completed in this sprint, I believe the coming sprint will be clearer in scope and better planned.

From the blog CS@Worcester – D’s Comp Sci Blog by dlivengood and used with permission of the author. All other rights reserved by the author.

Developing for LFP Again: First Sprint Retrospective

For over the past month I have been working as a member of the UpdateGuest team as part of developing for the LibreFoodPantry community. This blog post is a retrospective for the first sprint our team had. During this first sprint our team focused on setting up the UpdateGuest service and beginning the research into the tools we want to use to implement this service.

The issues that I was assigned to work on for this first sprint mostly focused on figuring out what we needed from other teams for the UpdateGuest service to function and what information the UpdateGuest service needs to store and to provide for other services under the VisitModule.

Specifically looking at the work I did this sprint:

The first issue I worked on was determining what data fields UpdateGuest would store, this was relatively simple and we decided that our service would mostly be using the fields the RegisterGuest team was storing since our service pulls guest data from theirs.

The second issue I worked on was a quick one creating a .gitignore file for one of our projects.

The third issue I worked on was determining the endpoints UpdateGuest needed from RegisterGuest to be able to get data from their service, this was solved quickly as the RegisterGuest team posted an issue where they listed all of the endpoints their service would have and this was all we needed.

The last issue I solved was what endpoints UpdateGuest needed to create for other services to use (along with our own), this became a discussion on many things, mostly with our team and the RegisterGuest team, to coordinate the endpoints and data they needed from us and how to format the endpoints and the data we are sending back and forth, but also how our service functions in general.

Finally, I helped to discuss and merge the creation of the Angular app for the UpdateGuestWebUI project.

I think that during this first sprint that our team did well. We successfully completed nearly all of the issues that we initially proposed to work on at the beginning of the sprint and even managed to create a couple of new ones and pull some additional issues from the backlog that were completed. Our pacing and completion of issues was mostly on track with the weighting system we used when creating the issues during sprint planning, although this might need some refining. We had good meetings in class where we all talked about what we were working on and we resolved any issues or questions that were ongoing with our work. We also used GitLab effectively to coordinate all of this work and document the different discussions and work as it was ongoing throughout the sprint.

I think that some things could be improved. I think that we could all try talking and communicating a bit more both in-class during our sprint meetings and outside of class either on issues on GitLab or on Discord. From Dr. Wurst’s suggestion I think we should establish some working policies for the rest of the semester’s sprints, especially about communication, but also when work should be done on the project. I think this is necessary so that others have time to contribute and interact on other group member’s issues and work before class meetings, so we are better prepared to discuss them in-class. I think specifically we need to define a team policy of replying to comments on GitLab or Discord when someone directly mentions an individual or the whole team asking for input that helps to solve or facilitate an issue.

Individually I think that I need to improve on my own communication skills and in helping facilitating team meetings in-class. Most importantly, I think that I need to get better at letting others talk and understanding the points they are making, especially if their opinions or solutions differ from my own, before I comment on them. Additionally, I think I need to get better at articulating my explanations of solutions and trying to not sound condescending while doing this. I also think that I could improve on my response time when directly mentioned on GitLab on issues.

Overall, I am excited to be working on a LibreFoodPantry project again and look forward to the remaining sprints as we continue developing our services this semester.

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

Retrospective #1

Now that Sprint 1 has come to an end, it is time for the retrospective blog. I will start by including everything I contributed to this sprint:

This link is a note in an issue where I have put a document discussing the Pros and Cons of whether we should be using a relational database or not. I put some examples of relational databases and non-relational databases for when I was making a decision along with links explaining a few of them.

This link is another comment on GitLab basically stating that we are using mySQL because of the simplicity and it is easy to look up information on it if needed.

This is the repository for our database currently, it is currently on a separate branch and not merged with the master due to a sudden change in database fields which will be implemented first thing in the next sprint.

This is another repository that holds the results of completing the Tour of Heroes Angular tutorial. This was the last thing completed for the current sprint to give me a refresher on Angular as I haven’t worked with Angular in a little over a year.

This was our first sprint so everything obviously wasn’t going to be perfect. However, I believe that we used GitLab very well considering this is my first time actually collaborating on a big project using GitLab. I think that we created issues that were specific enough to be considered issues. We utilized the boards well too. Our communication was mainly done through class and text message, but overall, I still think we communicated every issue that needed to be communicated.

Of course there were things that didn’t work well either considering it was the first sprint and this is most of our first experiences with Agile and sprints. While I mentioned that our GitLab use was very good. There were some faults with it as well. For example, my desktop didn’t let me push to GitLab which is an issue that still needs to be resolved. I specifically had trouble working with the separate branches because it was confusing at first. Our issues weren’t created the right way at first, and had to be restarted even though there were ways to just edit them without restarting. We had good communication, but I felt as though I wasn’t as involved as I should have been with the other team members work. I also think that there wasn’t enough communication between the other groups in the class as a whole.

Some of the changes that can be made as a team is more involvement in each others work. I think that we can all spend more class time looking at each others work rather than looking at it on our own time because this allows for more discussion. I also think that our team could start communicating with other teams more. Most of the teams came to us rather than us going over to the other teams to collaborate.

My individual changes that I need to make is talking more to my team members about what they have been working on rather than focusing on my own work. I could offer more solutions to the front end team about design. Probably my biggest issue would be my procrastination. I have to start working on my assignments earlier because that has an effect on how the rest of my team performs. I think that this next sprint will be much better now that we have been exposed to this more.

From the blog CS@Worcester – My Life in Comp Sci by Tyler Rego and used with permission of the author. All other rights reserved by the author.

Sprint 1 Retrospective

I think that the first sprint went well overall. My teammates and I completed all of the issues we assigned ourselves during the planning meeting, so the sprint was definitely a success. We accomplished this thanks to our effective use of the GitLab issue board. For the most part, our issues were clearly defined by their titles and labels, which helped us understand what needed to be done. Additionally, we assigned different team members to different issues, which made it easy to track our own issues and the progress of each other. The issue board also helped guide our in-class discussions, as the column-based structure allowed us to quickly select doing issues to discuss their progress and evaluate the needs review issues as a group before moving them to done. Finally, the board gave us a platform for discussion outside of class with each other and with other teams. We successfully used this to clarify what we needed from other teams and to answer questions among ourselves.

I think the main issue among the team during this sprint was communication. We did not always keep each other informed about our individual tasks, which sometimes made it difficult to resolve problems. During our class sessions, discussions frequently came to a stop after we reviewed our issues, leading us to silently work separately instead of collaborating. One major hinderance to our progress was an issue with our .gitignore file in the UpdateGuestWebUI repository. We had a branch where a mock Angular app was created, which had commits made before we finalized the .gitignore on the master branch. This caused unnecessary files to be committed, and we spent multiple weeks trying to find a way to remove them. We eventually found a simple solution that involved removing and recommitting every file after updating the .gitingore. It really shouldn’t have taken us that long to find such a simple solution, and I think we could have solved the problem quickly if we all worked together on it rather than focusing on our assigned issues independently.

I think there are several changes that can be made for future sprints, both for me individually and for the team as a whole. For myself, I think I could leave more comments on issues. I often made progress on my assigned issues or wanted to ask questions to my teammates, but I decided to wait until our class meetings to inform them about my progress and ask them my questions. Not only did this result in several of my contributions being undocumented on GitLab, but I also felt that it slowed the pace at which I could work. I also think that I need to work on communicating with the team in class more. During our meetings, I need to try listening better and making more contributions during discussions so that I can keep myself informed about the team’s progress and help my teammates resolve their problems more efficiently.

For the team as a whole, I think we can make some improvements to our usage of the GitLab issue board. I think we used it effectively overall, but there were some problems that caused confusion, such as an issue getting duplicated. We also exclusively used template descriptions for our issues, which sometimes made it unclear what we planned to do. I think we could better coordinate how we create and label our issues to avoid such confusion in the future. Additionally, I think the team could make improvements to communication. Instead of simply sitting in silence during class, we could explain to each other what we are working on in order to keep each other informed. Also, asking questions about issues and listening closely to comments from each other would undoubtedly help us avoid drawing problems out for too long. While this sprint was certainly an overall success, making these changes would help us work more efficiently and ultimately complete more of the project.

Links to My GitLab Contributions:

These are issues I was assigned to, where I made comments detailing my progress.

These are issues where I replied to comments from a teammate, acknowledging that their progress would help me with my assigned issues.

These are issues I opened, assigned weights and labels, and edited the descriptions of.

These are issues I moved across the board.

This is the duplicate issue that I closed.

This is the UpdateGuestWebUI repository I created and worked in. Note that the branch where I added the .gitignore and the Angular Mock branch where I resolved the .gitignore issue have since been merged into master.

From the blog CS@Worcester – Computer Science with Kyle Q by kylequad and used with permission of the author. All other rights reserved by the author.

First Sprint Retrospective

https://gitlab.com/LibreFoodPantry/modules/visitmodule-tp/approveguest/ApproveGuestWebUI created git repository for approve guest web ui.

https://gitlab.com/LibreFoodPantry/modules/visitmodule-tp/approveguest/isApprovedWebUI created isApproved web ui git repository.

https://gitlab.com/LibreFoodPantry/modules/visitmodule-tp/approveguest/ApproveGuestService created ApproveGuestService git repository.

https://gitlab.com/LibreFoodPantry/modules/visitmodule-tp/approveguest/ApproveGuestService/-/wikis/REST-API-design designed our rest API and created a wiki page for it.

https://gitlab.com/LibreFoodPantry/modules/visitmodule-tp/approveguest/ApproveGuestService/-/wikis/Database-Schema created and worked with registration to create a mock database design.

https://gitlab.com/LibreFoodPantry/modules/visitmodule-tp/approveguest/ApproveGuestService/-/wikis/Docker-Documentation got familiar with how docker works and how we can use it to complete this project.

https://gitlab.com/LibreFoodPantry/modules/visitmodule-tp/approveguest/ApproveGuestService/-/wikis/mySQL-with-Docker found more information on docker and how to connect it to MySQL.

https://gitlab.com/LibreFoodPantry/modules/visitmodule-tp/approveguest/ApproveGuestService/-/tree/feature/initialize_rest_api Initialized and set up the base code that will be changed for the rest api.

https://gitlab.com/LibreFoodPantry/modules/visitmodule-tp/approveguest/mockprojects/AngularTodoList created a mock angular project to test and better understand how angular works and what it can do.

Things that worked well was letting people work at their own paces and at their own times in order to maximize work done. This laid back style that we used helped the members to not stress on what was done or what needed to be done by a certain time and allowed us to focus on the tasks at hand. Our team was very focused on each task and for the most part knew what we could accomplish. things that didn’t work were people calling different issues before they finished the one that they were working on which left other members trying to figure out what more they could do to be useful to the team. All of our reviews were done at the end of the sprint which made the quality of those review less than what they would normally be.
Since it was our first sprint, we were unsure of how much work was enough work and had a lot of free time to work on other issues because we finished the others early. As a team we could do reviews on Tuesdays and Thursdays to lessen the reviews needed at the end and allow for more time and consideration when reviewing each issue. We also need to only take one issue at a time and avoid planning out the work course for our whole sprint and instead only pick up the next issue when we finish the one we are working on. We should also set up schedule days to meet up and work together outside of class to be able to finish more and help one another with issues and problems that we might be facing. I want to work on making more time outside of classes to work on the sprint issues and work on more difficult tasks but since this sprint was just a set up sprint, I’m sure that I will be faced with more difficult/time consuming tasks. I also want to make sure that I add/write my ideas/communicate on gitlab so that it appears and if someone continues this project in the future they can understand my thought process.

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