Category Archives: Sprint2

Sprint #2 Retrospective

Issues Evidence

Issue:: backend: look at all lose files in backend/ and determine what is needed and keep them if so.

This issue was worked out in different layers. I wanted to be careful to maintain integrity while modifying the code.

https://gitlab.com/LibreFoodPantry/client-solutions/nest/guest-information-system/backend/-/issues/11

Issue:: backend: in source/data create .js files for methods to be used.

In this issue we have decided after reviewing the code from last semester’s software architecture class that we would reuse it because it served the purpose of the project. Much of the code had to be changed and reformatted to meet our needs.

https://gitlab.com/LibreFoodPantry/client-solutions/nest/guest-information-system/backend/-/issues/5

Issue:: backend: source/ figure out index.js

This file initialized the objects that are important for the operations across the various actions the backend is responsible for. My idea was to explore and find out more about the JavaScript syntax and methods and modules handling as well as behaviors.

https://gitlab.com/LibreFoodPantry/client-solutions/nest/guest-information-system/backend/-/issues/7

Issue:: all: setup semantic release.

This was commission by Dr. Wurst, my colleague Robin and I had already worked through the process of factoring the steps needed to set up the continuous integration GitLab environment. Even though the steps were clear, I took longer than expected some failures along the way actually helped me look deeper into the settings of the continuous integration environment and experiment on them to find out the innerworkings of GitLab’s continuous integration tool and its security.

https://gitlab.com/LibreFoodPantry/client-solutions/nest/guest-information-system/general-repository/-/issues/10

  •   Reflection on what worked well

In this sprint we tried to work out the issues we had on the first. The idea was to not repeat the mistakes already made and if mistakes were made, we would want them to at least be new ones. In that sense our sprint was successful we were able to identify and adjust expectations. One of the important things that we worked on was to be more specific on the issues and to delineate a better definition of done. In this sprint we were able to connect our different projects and also able to identify points where modifications need to be made in order to work properly.

  •   Reflection on what didn’t work well

Our team suffered from the short absence of some members due to personal unforeseen reasons. The team adapted and the absentee members put back in their missing share and we were able to still have our goals completed. We communicated well as a team but sometimes we would put in too much work leaving little to share. Thankfully the work done individually was hardly final and the trouble shooting, and integration made sure everyone had a part to play. We also had trouble with issue artifacts from the last spring. The names didn’t help us make much sense of what we needed then and moving them around got us a bit lost on planning for the last sprint.

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

To improve as a team, I think communication is definitely key. We should have more meetings outside class and maybe work on issues within these meetings. I see that sometimes we do work during class, but I think these one-on-one meetings would be better utilized for higher level organization, like adjusting tasks, trouble shooting, cleaning up the repo and other tasks. Reaching out is also a good idea if anyone is stuck. It not only helps the person trying to solve the problem but also whoever is there to help. It reinforces what they know and build confidence at the team level.

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

I personally think that I could have done more if I have not obsessed over an issue or another. I actually have found myself paralyzed by over planning. I have so many things to get done that organizing how to do them take longer than it is worth. I increasingly found that a generic schedule with cut off set times to switch from one activity to the next can help but a lot of times I freeze when stuck and enter a brute force infinite loop. This account for most of my wasted time that is when I believe that productivity not only flattens but drops so sharply that even if I moved forward, I still feel like I am stepping backwards. Shuffling tasks is truly the best way to succeed in not all but most so ill try to be better at that.  

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

Sprint 2 Retrospective

In Sprint 2 we didn’t exactly have tasks to work on or complete. The issue with this is we didn’t really know where to focus our attention. A lot of our spare time was researching testing, and making sure everyone’s servers were working. Once we had the servers working we had no additional reasons to… Continue Reading →

From the blog CS@Worcester – Computing Finn by computingfinn and used with permission of the author. All other rights reserved by the author.

Sprint Retrospective 2

Another sprint ended for our capstone class and we are starting to be more familiar with the EMRS source code, and the testing ways using Karma. Testing with Karma is a must have knowledge for all Angular programmers. As we started the second sprint with zero knowledge in this area, everyone on the team had … Continue reading Sprint Retrospective 2 →

From the blog cs-wsu – Kristi Pina's Blog by kpina23 and used with permission of the author. All other rights reserved by the author.

Sprint Review Blog #2

Hello and welcome back to Benderson’s blog, this week I am going to talk about the conclusion of my second sprint with my team in my Computer Science class at Worcester State. My team and I are working on creating an application for the food pantry that just opened on campus that will help them have a fluent and easily done job without having to do things manually like keeping track of inventory and who is coming and going at the food pantry. During the recent sprint we just had we were doing more and more research on food pantries and exactly what they need to succeed in this environment. We had a couple members try to figure out how to make the back end API for the food pantry where we can read the information they gave us in a JSON file. We are all working hard on getting this project rolling on a constant steady pace so we can provide the food pantry workers with what they want.

About two weeks ago from this post, a worker from the food pantry came to our classroom and explained what is going on at the food pantry and what they will need to succeed. She brought in a sheet that explained what people need to provide so they can have a membership at the food pantry and that they can take out food. Some of the rules of the food pantry is that you can only come once a week and only take a certain amount of food out at a time. Some of the information you have to fill out before you can take the food are: Your student ID number from Worcester State, check if you have any of the following supplemental services, assistance in applying for SNAP, current housing situation and income/number of household members. Our group is confident in our ability of taking all these variable and putting them into an application for the food pantry to use. Also another thing they said they do is they don’t keep track of inventory by item but they keep track of inventory by the weight of everything in there, they gave us their current weight that they have and told us if people take out stuff they weigh it and subtract it from the current total and that is how they have been keeping track of the inventory.

The meeting with the food pantry worker was very informative and was able to propel our productivity by a lot because before then we were just working on basic set up stuff but now we have actual tasks to do for this project. One of my fellow teammates is working on the design of the interface they would use for the food pantry which will be good to have for a basis. Once we have a base product working, we will reach out to the food pantry workers and see if this would be something they would like and if not, we will go back to the drawing board and keep working on it. Another thing my group and I want to do is actually go to the food pantry and see what it looks like, maybe get some more ideas and ask them if certain things would be easier if we did things in a different way. Just some small things to consider for when we do the final product and show it to them and their needs. Well that concludes this week of Benderson’s blog, join back next week for some more information about sprints.

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