Category Archives: Sprint-1

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.

Sprint Retrospective 1

What we did as group for sprint

Our first sprint we planned out what are the things we need to work on during the sprint and how long would it take. We assigned each other to what their tasks will be, whoever was comfortable in doing took the tasks and started working on it and whoever was unaware or was not sure everyone in the group made sure that the member has enough info to cover the task. 

After agreeing and planning out the sprint, we all started to work on the project. We started by creating two black angular apps for is register and register guest and one black rest server. We created classes and used java language for the rest API, HTML and TypeScript for Angular App.

One of the challenges that we faced during this sprint was working on the database. We decided to choose MySQL for our database.

Overview of what we did:

  • Designing: endpoints, front ends
  • Choosing the database program to run the server to match with Angular App
  • Designing wireframes
  • Coding backend
  • Coding frontend

What i did for sprint

I volunteered to do the front end for the isRegistered. Shams and I discussed  what the layout of the page should look like. Before starting the code I made sure that the other team members agreed on the layout and language that I thought of using. To keep it simple, I used HTML and CSS and webstorm as the tool to write the code for the frontend.

What caught my attention was the Docker. I researched more on the docker whiel working on the frontend. I’ve never worked with a docker before and was curious in know how it works. I researched and shred whichever information I found helpful in understanding the  docker to the team.

Reflection on what worked well?

What worked well was frontend. I enjoyed my time coding and exploring more in designing the layout. It came out quite nice.

Reflection on what didn’t work well?

What didn’t work well for me was being consistent with the issues that were assigned. It was helpful in knowing the issues and working on it. But I rarely did a few because of figuring and working on the frontend. I would be aware of the next sprint.

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

I feel like not everyone was on the same boat. There should be roles assigned, such as who is the manager, which keeps everyone on check. I do feel confused about what else we would be doing in the project. I recommend planning out and having everyone on check.

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

     More material the better the understanding of the task. I should research and discuss what/how my team members are doing. Knowing it would also enhance my knowledge on the project and I might be able to help them as well.

Links:

    Whole project : https://gitlab.com/LibreFoodPantry/modules/visitmodule-tp/registerguest 

    Issue board: https://gitlab.com/LibreFoodPantry/modules/visitmodule-tp/registerguest/Plan/-/boards

From the blog CS@Worcester – Tech a Talk -Arisha Khan by ajahan22 and used with permission of the author. All other rights reserved by the author.

Sprint Retrospective 1

For the first sprint we did a lot of setup tasks as well as the designing of the architecture. In addition to some of the programming. The first thing we did was talk about the architectural design of the service. Once that was settled a group member created the wireframe for the “register” user interface. A group member also created the wireframe for the “is registered” user interface. The next thing we did was create the blank projects on gitlab. After this we initialized two blank angular apps in the user interface projects. We also created the blank rest server. While this one going on a group member was working the database understanding it and creating one that the architectural design specified. At the same time we created the class the design specified in the rest api and created the endpoints. We also connected the endpoints to a run-time database to test the rest server. In Addition we put in a template to learn how to make scheduled calls in a rest server. At the same time we also started coding the wireframe designs in HTML pages. That basically all we did for the sprint.

For the sprint I personally first created the main documentation issue and kept  it updated. I did this after the meetings or after consulting with the rest of the team and coming to a consensus with them. I also did several of the issues. First I did the issues for creating the 4 projects and initializing them. I also did the issue for designing the endpoints. I also did the issue for creating the object classes for the rest server. In addition i did the issues for creating the endpoints and finishing the rest server with a fakes database implementation. The last issue I did was researching how to make a scheduled method call in a rest server.

For the sprint I personally first created the main documentation issue and kept  it updated. I did this after the meetings or after consulting with the rest of the team and coming to a consensus with them. I also did several of the issues. First I did the issues for creating the 4 projects and initializing them. I also did the issue for designing the endpoints. I also did the issue for creating the object classes for the rest server. In addition i did the issues for creating the endpoints and finishing the rest server with a fakes database implementation. The last issue I did was researching how to make a scheduled method call in a rest server.

I thought the sprint went mostly well. I thought we did using the issue to break the work of the project up into smaller pieces for us to do. I also thought we did a good job of assigning issues to different people to make sure everyone had something to do. Lastly, I thought the documation issue worked well to keep the whole team on the same page as far as what the current plan was.

    Even though the sprint went well there were still some things we needed to improve on. I feel like there should have been more time spent planning before we started. Since a lot of  the first half of the sprint was spent changing our mind on the design and having to start over and this was inefficient. In addition before the working documentation issue was made we were not really telling each other what the plan was or when we changed it. We also could have had better communication overall especially at the start. We got much better later on though.

There are a few we could do better for the next sprint. I don’t think there is much however as we fixed most of the problems by the end of this sprint. The most important thing is to have a better planning meeting. We could be more communicative with each other on what we are doing. Lastly i guess the communication we do have could be better quality and more informative.

I could do a better job individually too. For the next sprint I need to do a better job of explaining why I am making the decisions i am making. I could also do a better job keeping the team updated on what I am doing and my progress. Lastly I could do a better job with the overall documentation of my issues. That being said, I don’t think me or anyone else in the team really needs to be better individually to much.  I think the biggest problem was the poor planning meeting at the beginning.

GITLAB LINKS:

  1. https://gitlab.com/LibreFoodPantry/modules/visitmodule-tp/registerguest
    1. This is the whole project.
  2. https://gitlab.com/LibreFoodPantry/modules/visitmodule-tp/registerguest/register-guest-service
    1. This is the rest server project i was working on.
  3. https://gitlab.com/LibreFoodPantry/modules/visitmodule-tp/registerguest/Plan/-/boards
    1. This is the issue board for all our issues.
  4. https://gitlab.com/LibreFoodPantry/modules/visitmodule-tp/registerguest/Plan/issues/16
    1. This is the working documentation issue that has the current plan for the project.

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

Sprint Retrospective

https://gitlab.com/LibreFoodPantry/modules/visitmodule-tp/approveguest/Plan/issues/9

Here I am finding out about docker, posted resources to videos for the team.

https://gitlab.com/LibreFoodPantry/modules/visitmodule-tp/approveguest/ApproveGuestService/-/wikis/Docker-Documentation

Created a document that highlighted the key commands that would be used for docker containers and images.

https://gitlab.com/LibreFoodPantry/modules/visitmodule-tp/approveguest/Plan/issues/28

https://gitlab.com/LibreFoodPantry/modules/visitmodule-tp/approveguest/Plan/issues/27

https://gitlab.com/LibreFoodPantry/modules/visitmodule-tp/approveguest/Plan/issues/23

https://gitlab.com/LibreFoodPantry/modules/visitmodule-tp/approveguest/Plan/issues/26

These are the endpoints that I reviewed and moved to done.

From the very beginning of the spring we had assigned everyone an issue of what they needed to start on. From there each respective person worked individually on their assigned task until moving onto the next one. This was working well for our team in the beginning and for me, because I had a higher weight task, because everyone had something to work on. However, once I thought I was done researching docker and creating the wiki for the docker commands, I had run short of things to do with docker. My main task was familiarizing myself with docker but since we were not going to be using docker until at least the next sprint, there was little to do with everything I had just learned.

Another tough issue was the actual design of our endpoints. Our teams had not yet gotten the documentation of what would be stored for information on each person. For our initial design we made simple variables that could be replaced once the correct information was present. Eventually we were able to change into the correct variables with proper documentation.

Our team was very good at coordinating with the others when it came to work on our endpoints. We had originally designed them each with base variables as described before. After the documentation was given, the main problem that arose was the communication between other teams. We needed to understand what we were pulling from other teams and what they would be pulling from us. Our team did well to communicate and document the interaction and solutions on GitLab.

I think something that our team could do better in the division of tasks. For next sprint, as mentioned in class, we will be waiting to assign the next task once someone has completed theirs. I believe this will allow for a smoother distribution of work. Another team improvement, we could have better documentation when working through GitLab. When different people were working on different task, it was easy for the work completed to be missed. It can also cause a lack of understanding through the team if there is not much to go off of.

An improvement I could make would to be to take on a greater responsibility. I need to communicate to my teammates that I need to take on more work than previously because I felt a lot of time was wasted. I have to be better at involving myself in the ongoing process of something new in order to immerse myself, even if it is just to help push someone to the end of their goal. Another change I will make going into the next spring will be better documentation. I posted a document in the wiki for reference, but should be in markdown on the page for everyone to see easily.

From the blog CS@Worcester – Journey Through Technology by krothermich and used with permission of the author. All other rights reserved by the author.

Sprint 1 Retrospective: Trial by Fire

Last week our team concluded our first sprint working on the Approve Guest module for the LibreFoodPantry project. This project is part of my Software Development Capstone and has us working on an open source project using Agile principles and the Scrum framework for software development. While I think the project has been going well, there are definitely aspects of our workflow that can be refactored in order to increase our productivity.

What I Completed This Sprint:

For this sprint I took the role of Scrum Master for my team of four. I felt like this would be a great way to put my knowledge of the Scrum framework into practice. While I tried to make sure I was available to the team to answer any questions about Scrum, I feel like I didn’t emphasize the importance of following the scrum framework as well as I could have. I facilitated the stand-ups at the beginning of each class period as well as planning and review meetings. Our team did a good job of explaining what they had done prior to the stand-up and what they were going to work on, but the stand-ups were never used to raise questions about logistics or talk about progress towards meeting our Sprint goal. I feel this is because much of the Sprint was used for getting adjusted to the slightly more structured workflow that we are working with. If I continue to be Scrum Master for our team I will make sure that we utilize class time to the fullest in order to have open discussion about what we need to complete and how we can deliver working software as fast as possible while doing only the minimal amount of work necessary.

I think its important that, as a group, we start to utilize GitLab and our issue board to a greater extant than we did this Sprint. In the beginning of the Sprint we were having trouble coming up with what issues to work on because we didn’t have much information about exactly what it was we are building. I feel like not only our team, but all teams were very concerned with granular aspects of the project such as, what attributes should we be storing in our databases and what style guidelines should our applications use. All of the information that was up in the air was making it difficult for us to feel like we can start developing since everything is subject to change, but it is important for us to remember the Agile principle, “Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage”. We should be building this expecting requirements to change, rather than feeling the need to wait until requirements are finalized to start working. Also, I feel like even though our communication with each other and the other teams improved greatly from the start of the Sprint, we should be communicating as much as possible in order to maximize our productivity. We had good discussion with other teams but left minimal evidence of this on GitLab, which is something that we will need to be more vigilant about in the future.

We were able to finish all issues in the Sprint before the end, which is a sign that we gave ourselves too little to work on. I think as a team we made an acceptable amount of progress this Sprint as it was our first ever sprint working as a team. Going forward we can more accurately gauge how long each issue will take us to complete and make sure each member of the team delivers a reasonable amount of work by the end of the Sprint. Reflecting on what I delivered this Sprint I know for a fact that next Sprint I will need to give myself more issues to work on. I wanted to start working on our actual web applications, but the fact that our requirements were vague made me decide maybe we could leave that for the next sprint. I think my own fear of the unknown had me making many spike issues, when we could have made greater progress on the application itself.

“Working software is the primary measure of progress.”

 

From the blog CS@Worcester – Creative Coding by John Pacheco and used with permission of the author. All other rights reserved by the author.

Sprint 1 Retrospective

This past week was the end of our first 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 #21: Define Database Schema
    https://gitlab.com/LibreFoodPantry/modules/visitmodule-tp/checkout/Plan/issues/21#
    Creating a small UML diagram of possible database schema, open for further revisions later.
  2. Issue #6: Create UML Diagram for REST API Structure
    https://gitlab.com/LibreFoodPantry/modules/visitmodule-tp/checkout/Plan/issues/6
    As the name implies, creating a UML diagram for REST API structure for our project, open for further revisions later.
  3. Setup production Database
    https://gitlab.com/LibreFoodPantry/modules/visitmodule-tp/checkout/Plan/issues/11
    After deciding what our team will use as a database for the project we have made some preparations to make sure it is working correctly and we can do necessary operations with it.

What worked well?
In my opinion pretty much everything our group (BZPJ’s) planned on doing ended up fine and on time, when it comes to my tasks they were somewhat easy for now and not necessarily required a lot of time, in my opinion being able to use some of the knowledge from previously taken classes was a very good example that what we learn is useful in the “field” application. What I am also very grateful and happy about is the way our team was able to find time and place to meet regularly to be able to work on these tasks. With my busy schedule it was always challenging to have a team able to work within my time constraints.

What didn’t work well?

Comments. I think as a team we were not quite there yet when it came to work on this big group project that others will take over eventually. I also believe that some of my contributions to the team could be more, after this Sprint I’m not sure I have done enough.

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 but with some minor adjustments it will be ok. 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.

What changes could be made to improve as an individual?

During this sprint I have felt that I have not contributed enough to the team, what I had to make were some diagrams, only the work on the database was somewhat challenging, even though most of it was handled by my teammate and I only helped with some of the parts. 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, but to be honest I also waste some of that time. Another thing I should probably work on more is to do more research on topics assigned to me, not only finding enough to get my portion completed. As my previous post said I need to Dig Deeper.

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.