Category Archives: Sprint 2

Retrospective #2

There is one month left in the semester and it is already time for the second retrospective blog. This was certainly an interesting sprint due to the unprecedented pandemic that took the world by storm. Luckily, it doesn’t hinder us too much as technology exists enough to where we can still collaborate with our partners and other teams thanks to discord, Zoom, Gitlab, etc. To begin this post, I’ll be posting links to the progress I made this sprint.

This is thew link to our database repository because I had to modify it to reflect the new changes that were made after our meeting with Joanne. I am also using this link to show that the branches have been merged because I am no longer testing it.

This is a link to another one of my closed issues. This issue pertains to connecting the database to the server. While, I haven’t figured it out quite yet, there is a link in this issue with a tutorial that I have been using to experiment connecting servers with databases.

There wasn’t a large amount done by me on this sprint due to the COVID-19 outbreak which caused us to have a whole extra week off of school, and completely shifted us to online learning. However, there was a large improvement from the last sprint. Our Gitlab use improved immensely between sprint 1 and sprint 2. We started using the “blocked by” features to make sure issues were getting done in the order that they had to be. We also started commenting more on our issues, so everyone can see our progress rather than just our group knowing what we did. Also, I feel like our communication worked better compared to last sprint, but it could definitely still be improved.

As for what didn’t work well, I think that I could have gotten more work done for this sprint seeing that I only worked on database stuff for this sprint. I also feel like were still only involved in our each individual part of the project when we need to be more involved in each others parts. I also believe our communication with other teams could still use some work especially for this upcoming sprint because if we have time, we need to work on the aesthetic of our web application.

When it comes down to improvements, I know that I can try to work on a little more for this upcoming sprint. Once I figure out how to connect the database to the server, I can then move on to starting my work on Docker and helping everyone else with what they have to do, and hopefully we’ll be able to get to aesthetic because I feel like I would be helpful on that front. As for the team improvements, I still think that our communication with each other could be improved. For example, we can have more zoom meetings with each other and show each other our work. I also think we should talk to the other teams as well because they might be able to help us with things that we are stuck with. Besides that, I think our team is in great shape for the last sprint.

 

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 2: Retrospective

It’s time for another sprint retrospective. Last sprint, our team focused on researching needed technologies and structure of our micro-service. This sprint, our team focused on implementation.

We started with deciding coding standards and preparing for the visit with pantry staff. We decided to follow the principles of the first five chapters of Clean Code: A Handbook of Agile Software Craftmanship by Robert C. Martin. Lucky for me, I was reading these chapters for my software process management class. We also decided our code formatting standards, so collaborative work does not get reformatted constantly. After these issues were completed, it was spring break and I started focusing on solo work.

Last sprint, I learned how to implement and test a Mongo database with a schema defined by the Node.js package called mongoose. With this knowledge, I started implementing our micro-service’s database requirements. I designed a guest schema with all the data fields from the register team. Due to the nature of our update service, our schema does not require any data field except for the guest id. I also added an additional date field for when the update was made that is automatically added. I then wrote tests for checking the schema and the interaction with the database using mocha. At this point I decided to wait for my work to be reviewed by my team and started work on implementing our endpoints.

Our service only needed a few endpoints, a POST for new updates, a GET for obtaining an array of updates from a range of dates, and possibly a DELETE. I managed to get a couple endpoints started before my previous work was reviewed. After the review I had to focus on the guest schema again. While I did not focus on the endpoints after this, I did manage to fix up the incomplete GET endpoint when I had the time.

My focus for the rest of the sprint was getting the schema work ready to be merged. The review process was much longer than I had anticipated. With my merge requested branch bringing a lot of changes, the issues I needed to fix were diverse and plentiful. The issues ranged from simple oversights, to writing documentation. At this point, the schema branch has been through many changes and is nearly completed.

The rest of the work I did was reviewing my team’s work and familiarizing myself with it. The rest of my team worked on the front-end, implementing our UI and how to test it. At this point, our team has the UI design completed or nearly so.

Overall, I feel good about the work that was completed even though it took longer than expected. I think we have improved our teamwork since last sprint. The main lesson to learn from this sprint for me was to expect a lot of editing and to assume issues will take longer than I initially guess. Something we could improve on is the scope of our issues. Many of our issues could have been broken down into smaller issues that would be quicker to complete. After last sprint, we gave a work-in-progress limit to our review column to try and force reviews, but it ended up getting clogged by wide scope issues with a lot of work to review. I believe our team will be able to continue work on our micro-service and hopefully be able to have some functional software after next sprint.

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.

Second Sprint Retrospective

This week concluded the second sprint with my work on the UpdateGuest team developing for LibreFoodPantry. This sprint was exciting as we began creating the implementation of our service.

One of the first issues I helped work on this sprint was coming up with questions for the Thea’s Pantry staff member for when they came to our class.

During this sprint our team also focused on improving working together as a team as were beginning to implement our service.

An issue directly related to this included standardizing our IDEs as we prepared to code together on this project.

Secondly, as part of learning to code as a team I also re-read the first five chapters of Clean Code by Robert C. Martin to review best coding practices.

Additionally during this sprint I helped to implement the web interface for our frontend service where I began to learn how to use Angular again and also learned how to use Angular Material. This issue has two merge requests associated with it, one mainly adding Angular Material to the project, and another adding the implementation of the Web UI.

During this sprint I also reviewed and commented on two different merge requests. The first merge request was for implementing MongoDb for our backend service. The second was for the front end architecture document.

Individually, I think I am getting better at becoming a Scrum Master and learning to listen to other people during our meetings as I help to facilitate them. Although I have found it harder to do this when we switched to online meetings as sometimes it is harder to hear people talk than in-person. During the final sprint I would still like to improve on my ability to listen to other people’s suggestions, both during meetings and on GitLab.

I do think I need to get better at being patient with the rate that changes are made. This issue specifically occurred with a merge request when I directly made changes to a branch without asking first (even though I figured I should) as I thought it would be quicker than submitting another review for it. I do regret doing this as it led to a small conflict. We did resolve this issue and as a team we have made a new working policy that helps address this issue, so each developer only works on their branch individually to help avoid merge conflicts, in addition to helping with this issue.

As a team I think we did good this sprint. We finished several issues early on in the sprint and I am particularly happy with the work that was accomplished for the backend service and the web UI. I think that our team was also better at communicating this sprint and that we have improved our communication on issues and our use of GitLab to coordinate and communicate with each other. I also think we had some great collaboration this sprint with reviewing each other’s work, discussing and implementing suggestions, and even having multiple people working on the same branch.

I also think there is further room for improvement with our communication over GitLab and in meetings. Improving GitLab communication is especially important since we no longer have face-to-face meetings, and GitLab is where most of the remaining time discussing issues and work will be spent in the upcoming final sprint.

I do wish we were able to finish all of the issues we planned on doing for this sprint, but I understand that given the many different events over the past month that other things just got in the way of this. Part of this issue also has to do with the weights issues were assigned during planning. I personally think I need to improve my weighting estimates for issues as this seemed way off for this sprint. I think this was part of the reason we were unable to finish all of our issues as issues became more involved and took longer than was originally anticipated when planning for the sprint. Additionally, I think as a team we need to break issues into both smaller and more defined tasks, that way the work is more defined and the issue weight can be estimated more clearly. These factors are something I have been trying to take into account for while planning for the last sprint.

Overall, I am looking forward to our upcoming final sprint and I am excited to see if we can finish the UpdateGuest service.

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.

Sprint 2 Retrospective

Overall, I think the second sprint was somewhat less effective than the first for my group. Unlike the previous sprint, we had some problems that prevented us from completing everything we expected to. I think the main issue we had was a lack of clarity regarding our goals for each issue. We have not been declaring a ‘definition of done’ for our issues, so we didn’t always know what we were working towards. The biggest example of this was the “Design frontend architecture” issue. We never had a plan for what our design needed to include or how it should be made, which caused this issue to get stuck in the ‘needs review’ column for most of the sprint as we tried to work out the confusion surrounding it. Additionally, I think many of our issues were too broad. For example, we had single issues for creating a database and implementing our UI which could probably have been broken into more specific tasks. We definitely underestimated the complexity of these issues and the time they would take, which made them difficult to complete during the sprint.

Despite the problems, there were some aspects of the sprint that worked well. I think our communication has started to improve since the last sprint. GitLab was used for discussion outside meetings more often, especially on the merge requests. I also thought that our in-class discussions were more effective. We did a better job using our time together to discuss specific problems instead of working on our own, especially after the transition to online meetings. Although the lack of clarity in our issues made the sprint difficult, it forced us to communicate more effectively so that we could help each other understand what needed to be done.

To improve as a team, we definitely need to be more specific with our issues. This would involve splitting broad issues into more specific tasks and creating a ‘definition of done’ for each issue so that we all know what to work towards. We should all look over our proposed issues to make sure they are small enough tasks, and we should add a definition of done that we all agree on to each issue. Ideally, this would be done during the planning meeting, though we can surely continue to fine-tune our issues during the sprint. If we are able to accomplish this while maintaining effective communication, I think our final sprint will be far more effective.

Individually, the main improvement I think I need to make is to keep better track of my teammates’ progress on their issues. So far, I have been completely focused on completing my assigned issues. As a result, I could never get around to familiarizing myself with the work completed by my teammates. This prevented me from reviewing their issues and approving their merge requests. It has also made me generally uninformed about the state of the overall project and where it is heading. I feel like I have not been contributing enough to the team, since I have been so focused on my own work. For the last sprint, I hope to participate more in reviewing my teammates work to both help the project progress and to keep myself informed. I think that making our issues more specific will immensely help with this. Having more manageable and specific goals would likely reduce my anxiety about completing my issues and allow me to spend more time assisting my teammates.

Links to my GitLab Contributions:

This is the main issue I worked on, where I learned about Angular testing. I left several comments informing the group of my progress and providing links to useful resources I found.

This is a repository I made to share my project where I experimented with Angular testing with the team.

These are issues that the entire team worked on. I left comments on some and moved some across the board.

I left a comment on this issue to inform the group of a meeting I had with the other teams in class.

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.

SPRINT RETROSPECTIVE #2

In the past few weeks a lot changed in our lives. With all the global epidemic we lost a week worth of work for the semester, and with all responsibilities that all of us have, everything else pushed to the second degree of priorities. With that being said we as a team supported each other … Continue reading SPRINT RETROSPECTIVE #2 →

From the blog CS@Worcester – Shams's Bits and Bytes by Shams Al Farees and used with permission of the author. All other rights reserved by the author.

Sprint Retrospective 2

For the first sprint we did most of the programming of the individual parts of the service. The first thing we did was update the working documentation with the new information from the meeting with the food pantry. Also in the working documentation we Changed the zip code and id to string in the working documentation since they can start with zero. This was pointed out by another team. The next thing we did was to update the REST server with the new information from the meeting with the food pantry. We also updated the register application with the new information from the meeting with the food pantry. The last thing we updated with new food pantry information was the database. Also in the database we looked into how to connect the database to the REST server. Next we created a new angular project with all the different types of inputs the angular applications would need to run. This was done to help the people writing the angular applications. After that we added a register class to the register application to send over the register endpoint. We also added an error checking method to the register application so that a bad registration cant be sent to the REST server. Next we added all the input elements to the register application and connected them to variables in the typescript file. The last thing we did with the register application was to connect it to the register endpoint from the REST server. We also added all the input elements to the is registered application and connected them to variables in the typescript file. The last thing we did with the is registered application was to connect it to the register endpoint from the REST server. This was all everything we did for the sprint.

What i did for sprint

Update the working documentation  with the new information from the meeting with the food pantry

Changed the zip code and id to string in the working documentation since they can start with zero.

Update the rest API with the new information from the meeting with the food pantry

Changed the zip code and id to string in the rest API since they can start with zero.

Create an angular project with examples of the different inputs

Added register class to register application

Added error checking method to register application

Reflection on what worked well?

Planning was much better than last time

Used the boards better

Added relations to the issues

Ordered issues better

Reflection on what didn’t work well?

Did Not communicate enough during sprint

Didn’t talk to each other during two week break at all

Didn’t finish everything

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

Try to keep each other updated on our progress during sprint better

Finish everything

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

Try to tell other people what i am doing more

Ask other people option more

Links to evidence of activity on GitLab with one sentence description for each

https://gitlab.com/LibreFoodPantry/modules/visitmodule-tp/registerguest/input-examples

  • The input example project

https://gitlab.com/LibreFoodPantry/modules/visitmodule-tp/registerguest/is-registered-web-ui

  • The is registered application

https://gitlab.com/LibreFoodPantry/modules/visitmodule-tp/registerguest/register-web-ui

  • The register application

https://gitlab.com/LibreFoodPantry/modules/visitmodule-tp/registerguest/register-guest-service

  • The rest server

https://gitlab.com/LibreFoodPantry/modules/visitmodule-tp/registerguest/register-guest-data-base/-/tree/master

  • The database

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 2

We are on our second sprint. Couple of things and changes we as a team did. We reflected on our last sprint and tried to be more organized and complete tasks on time. We updated the working documentation, changed zip code and id string to working documentation, looked into how to connect databases with new information, created an angular project with examples of different inputs, added buttons to register applications, connected buttons in the register application to variables and added an error checking method to register applications. We all tried to communicate with each other on how things are going, if someone needs help and communicated on what each member is working on.

I tried to give my best effort in helping the team. I pushed my code in branch-working, instead of master. I plan to work on connecting the endpoint with help of my teammates. I did some more research on Docker and tried to learn more on connecting the endpoint. I needed to understand what why and how I will be doing it because it is an important connection in the project.. Nothing at the moment is blocking my progress. I am trying to learn and research more on connecting the endpoint. After researching and getting some feedback from my teammates. I created the endpoints in isregister and modified the app design.

Overall, everything went well, I learned new skills and gained more knowledge. What didn’t work well was the communication. Due to lack of communication we weren’t able to complete some of the work.

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.

Second Sprint Retrospective

https://gitlab.com/LibreFoodPantry/modules/visitmodule-tp/approveguest/Plan/-/issues/25 got familiar with NGINX

https://gitlab.com/LibreFoodPantry/modules/visitmodule-tp/approveguest/Plan/-/issues/41 Made program read MySQL login info for rest api

https://gitlab.com/LibreFoodPantry/modules/visitmodule-tp/approveguest/Plan/-/issues/21 Implement Endpoint /needsApprove/between

https://gitlab.com/LibreFoodPantry/modules/visitmodule-tp/approveguest/Plan/-/issues/46 Design /approveUpdate

https://gitlab.com/LibreFoodPantry/modules/visitmodule-tp/approveguest/Plan/-/issues/22 Implement Endpoint /Approve/all

https://gitlab.com/LibreFoodPantry/modules/visitmodule-tp/approveguest/Plan/-/issues/37 Implement guest-info Component ApproveGuestWebUI

https://gitlab.com/LibreFoodPantry/modules/visitmodule-tp/approveguest/Plan/-/issues/20 Implement Endpoint /getGuestInfo/{id}

https://gitlab.com/LibreFoodPantry/modules/visitmodule-tp/approveguest/Plan/-/issues/30 Create connection between database and Rest API

https://gitlab.com/LibreFoodPantry/modules/visitmodule-tp/approveguest/Plan/-/issues/40 Create and Link Epics

https://gitlab.com/LibreFoodPantry/modules/visitmodule-tp/approveguest/Plan/-/issues/5 Create mock database in mySQL

https://gitlab.com/LibreFoodPantry/modules/visitmodule-tp/approveguest/Plan/-/issues/19 Implement Endpoint /isApproved/{id}

https://gitlab.com/LibreFoodPantry/modules/visitmodule-tp/approveguest/Plan/-/issues/47 implement /approveUpdate

https://gitlab.com/LibreFoodPantry/modules/visitmodule-tp/approveguest/Plan/-/issues/51 Install Angular Material in ApproveGuestWebUI Project

https://gitlab.com/LibreFoodPantry/modules/visitmodule-tp/approveguest/Plan/-/issues/32 Create UI Design for ApproveGuestWebUI

https://gitlab.com/LibreFoodPantry/modules/visitmodule-tp/approveguest/Plan/-/issues/45 Implementing CI/CD for IsApprovedWebUI

https://gitlab.com/LibreFoodPantry/modules/visitmodule-tp/approveguest/Plan/-/issues/44 Implementing CI/CD for ApproveGuestService

https://gitlab.com/LibreFoodPantry/modules/visitmodule-tp/approveguest/Plan/-/issues/49 Questions to ask Joanne from Thea’s Pantry

I believe the thing that worked well for us in this sprint was constant communication and trying to help each other with issues that we were facing or that were related to one another. I think our team did a good job on staying on task and completing things at a good pace and each member was actively involved with each person’s code since we needed another person to review our code and approve it for it to be merged with the master branch. Due to the situation going on in the world around us the sprint was hindered due to the extra week of spring break and our group got a little too comfortable during the break and neglected our work. I think we had a lot of great things that we should have weighted a little differently and we had no idea that the weight of an issue can be changed during the sprint as well, so had we known that we would have readjusted a few of the weights to be more reasonable for the amount of work that was required to complete the issue. As a team we could benefit from meeting at least once more outside of the regularly schedule class period during the week to be able to complete more work and have more opportunities to figure out what works and what doesn’t. I feel that I got too complacent during the break and neglected this sprint’s work toward the end, so in the future I hope to be more focused and on task even during things like a two week spring break. I should have also spoken up more when I felt that an issue was not the correct weight, but I wasn’t fully sure since the last sprint we had, we finished all of the issues way before the end of the sprint.

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 Two Retrospective

If the first sprint was crawling, then this sprint we moved straight to running. When considering the shorter length of the first sprint we appropriately stuck to smaller “set-up” or preparatory goals. This time, we began actually building our site in earnest. My focus, as evident from the list above, is web design and development for the UI/UX. At the beginning of this sprint, while planning, I was at a loss to quantify what exactly needed to be done. One may notice that many of these issues were posted within the last few days of this sprint. Considering I haven’t built that many websites, and none with so specific of a purpose, my thought was that I didn’t know what I needed until I had it: I would simply figure things out as I built them. This flies in the face of any good practice, and I will of course avoid such practices moving forward, but given my inexperience I had to lay the tracks in front of us as we steamed on. This manifested as an incredibly broad task, “Implement the UI from the wireframe”, with us then filling in the gaps after.

This worked, but not terribly well. It has given us a working front, albeit with some missing or broken features, but a code base desperate for refactoring. As with last semester, I often would end up learning about a useful feature after I had already beat my head against the problem and found a roundabout way of solving it. For instance, despite implementing a new directive, I did not know that services could be split off as well and shared by all components. The list of all Guest IDs, for example, would be best shared by all components instead of how it currently is implemented, which is a hodgepodge of emitters with no “real” persistence between components. It can currently pass guest IDs effectively between them, but this could be done, presumably, much easier using a service. I’m not completely certain either, it will be another instance of a new technique we’ll have to learn as we implement it, but I would have liked to have started here rather than arrive here after what will become somewhat wasted effort.

I say somewhat wasted, but in reality, it doesn’t hurt to know how to approach problems in many different ways. I believe using emitters is a valuable skill to have. Additionally, I now know at least three different ways to embed svg into a web page, with each successive one being more effective than the last but with all having their uses. I feel that I am certainly improving as a web developer, with each new misstep putting me in the direction of a better solution. However, I have a lot to learn in regard to version control systems. I caused a few headaches for poor James, who kindly walked me through all my poor practices. I know now never to push directly to the master branch for a new feature and utilize merge requests effectively. Also, never copy paste anything, because they are treated as new files even if they have the same exact content and will cause innumerable conflicts. In addition, Pawel and I ended up both independently working on the same issues, but we have discussed ways to avoid these situations moving forward. Even with all the growing pains mentioned and those involved in moving everything online, I believe we have found ways to be an effective team as well.

For this next sprint, our tasks already look much better, each containing the fine detail of work that needs to be done in order to reach our next project iteration. There are considerably more tasks, and none that are as horribly broad as many of those in this sprint. We possess a better sense of what needs to be done, and we can act upon it. By applying all the lessons learned thus far I believe we are closer and closer to something that can actually be used by the food pantry and should all be proud of that fact.

From the blog CS@Worcester – Press Here for Worms by wurmpress and used with permission of the author. All other rights reserved by the author.

Capstone Sprint 2 Retrospective

This second sprint brought with it some challenges in moving to online classes for the ongoing epidemic, but with it a stronger grasp on communication and documentation using GitLab and Discord, both out of necessity and intentional effort. We have learned to better work with LibreFoodPantry workflow and are ready to go into our next sprint with our REST API, Database, and Frontend all working in isolation.

My contributions

Create file with definition of done.

Change to default .gitignore file for Spring and remove unnecessary tracked files from before we added the .gitignore,

Research internationalization support and decide that it is better to be saved once a more-final version of the front-end is complete.

Research Angular Testing and create a Spike project that covers most cases we will encounter.

Integrate ID scanner to get Student ID with an Angular component and create tests to have 100% code coverage.

Retrospective

For the first half of the sprint, we were still having weekly meetings to work together. One of our troubles last sprint was that we were discussing things in person and not doing well documenting the reasons for decisions we made. We improved on this even while having in-person meetings. By the second half, although we were all coping with changes brought on by moving to online classes, we did well in keeping each other updated and communicating through GitLab. In hindsight, it’s probably a good experience to be forced to do this. Especially if this epidemic inspires more software companies to promote working from home.

The biggest issue we had as a team was working with merge requests. There were a couple cases where code on a feature branch was not kept up to date with the master branch. As a result, there were a lot of merge conflicts to work together on resolving as a team. Overall, working through these together as a team was a good experience, because this is bound to happen when working in tandem with version control. However, now we will be reminding ourselves to pull changes from origin/master as we are working on our local branches.

We also improved with creating merge requests for each individual features, although this took a few weeks for us to all do efficiently. GitLab has a great feature where you can tightly-bind an issue to a merge request, but this caused a couple of problems for me. When the merge request is accepted, the issue is automatically closed. This messes with our workflow, because we want the issues in the “done” column, only to be closed by the product owner. Moving forward, the issues should be linked with their merge request but we will have to take care that the description doesn’t include a “Closes issue” tag.

Furthermore, when a branch is automatically made in GitLab, it creates a very verbose branch name, which is simply annoying if your Git isn’t configured to autocomplete branch names when pressing “tab”. In the future, I will create a new merge request and manually select my already-created branch. Then I will manually link the issue.

The team’s willingness to quickly meet over Discord about an issue we were having was the best thing about this sprint. In the few cases where something occurred outside of class time that required all of us, we were able to set up a time the same day or the next day and resolve the problem. This flexibility to schedule work within the sprint is what helped us get as much work done as we did.

The next sprint will involve combining our individual pieces into a working product that is capable of storing actual checkout transactions. There is a still a lot to learn and to do, but we are well on our way to finishing a viable product that we are proud of, albeit with much room to grow in the future. We will have to pay close attention in the next sprint to creating well-written documentation as we combine our API, database, and front end so that future developers can easily recreate what we’ve done and get it running.

From the blog CS@Worcester – Inquiries and Queries by James Young and used with permission of the author. All other rights reserved by the author.