INTRODUCTION: As the final Sprint of my team’s Software Development Capstone project introduces its conclusion, I feel as though it is a good time to reflect on the results of this sprint. Going further, some aspects of this blog (specifically the conclusion) will involve reflection of the project in its entirety. To start, I believe that this sprint may have been weaker than previous ones. Factors supporting this argument include the idea that we now have experience from the previous sprints and that we should be more prepared; factors against the argument include non-work related considerations (such as future semester set-up).

POSITIVE FACTORS: During the final sprint, these favorable events had occurred:

• Our team had made progress on getting Keycloak into a Docker container. Hopefully, futures semesters will be able to complete the project for us (allowing connection to the AWS Team, and other teams in general).
• Speaking of progress, our Product Owner (our Instructor/Professor) has mentioned that the team has made an impressive amount of progress in general. Factors involved with the amount of progress include comparisons to previous semesters’ work, and consideration of the fact that our team had quite literally started this project from scratch.

NEGATIVE FACTORS: As much as the team has improved, there were still some bumps in the project’s road. These bumps include:

• To contrast the statement in the “Positive Factors” section, work on the Keycloak Docker container has been completed, but we do not have a final product yet. However, in our defense: part of this sprint was spent setting up the project for the teams that will work on it in the future.
• As mentioned in the “Self-Improvement Suggestions” section below, this team has done quite well during this sprint (considering the fact that the Scrum Master was not as involved as previous sprints). I understand that Scrum Masters do not have a drastic amount of authority over the rest of the team; at the same time, too little involvement with the team’s work essentially makes them a facilitator “in name only”.

TEAM IMPROVEMENT SUGGESTIONS: Even though we have no more sprints left for the project, it is still a valuable form of criticism to discuss where the team can improve. Factors involve:

• I believe that additional dedication to Sprint Planning would be beneficial for the team. While our first two sprints involved research of our issues (in other words, we didn’t know what we needed to do), having a clear idea of the end goal will make for more efficient work. This is opposed to issues being brainstormed and abandoned like darts thrown at a board.
• In addition to Sprint Planning, having a better structure for our Sprint Review/Demo classes can help. While we get our work done, it’s also important to know how to present it in a neat, organized manner that is easy for the Product Owner to interpret.

SELF-IMPROVEMENT SUGGESTIONS: In addition to team improvement, there is always room for self-improvement. Some ideas for my own improvement are:

• Since I was the Scrum Master for this sprint, I must say that I was not as involved with the role as I would have liked to have been. In future projects, I would like to dedicate more time to the role; hopefully, outside commitments won’t weigh me down like they did during this semester.
• In future Scrum work, I would also like to be more involved with Gitlab issue board work (this factor ties into my criticism of my Scrum Master performance). I feel as though reviewing and commenting on issues isn’t enough; taking the initiative and creating issues is a key factor of being a leader on the team.

Considering the project (and its semester) as a whole, I will say that I appreciate my teammates and the work that they have done. We have all made this Capstone project a pleasure to be involved with; in fact, due to how pleasant the overall experience was, I have shown interest in working with the LibreFoodPantry software outside of the class. To be honest, there’s no reason not to be involved – working with LFP has varying levels of commitment. Regardless of the commitment level, the work is a great way of acquiring work experience and keeping Software Development skills fresh.

LINKS TO GITLAB ACTIVITY:

• https://gitlab.com/LibreFoodPantry/common-services/identity-and-access-management-system/keycloak-research/-/blob/KeycloakWithoutDocker/README.md (Images added to guides for future semesters).
• https://gitlab.com/LibreFoodPantry/common-services/identity-and-access-management-system/general/-/blob/main/.gitlab-ci.yml (CommitLint Setup for commit structure)
• https://gitlab.com/LibreFoodPantry/common-services/identity-and-access-management-system/documentation/-/blob/main/History.md (History log, for future semesters)

From the blog CS@Worcester – mpekim.code by Mike Morley (mpekim) and used with permission of the author. All other rights reserved by the author.

INTRODUCTION: Compared to the first sprint, “Sprint 2” has gone better in some ways. However, in other ways. we definitely have dropped in performance a bit. It’s no one’s fault; part of working within these sprints is figuring out what needs to get done now, and what can be done later.
POSTIVE FACTORS: Here are the following improvements since the last sprint…

• We have set up a form of “login” based on Keycloak software. This Keycloak login has also been set up via JavaScript to act as a “re-direct” from the barebones frontend that we had created during the first sprint. I often refer to this “connected demo” as a HTML/Keycloak/VUE App or project. This is because that’s exactly what happens with the current demo: a user will start in the HTML index file, and then click on a button that redirects to a Keycloak login. Once credentials are entered, the Keycloak login will take the user to the VUE App.
• The group has figured out how to work with Keycloak – in particular, we understand how to create users, set up privileges for users, and group them within a “realm”. We also understand the hashing algorithms used to make JWT Tokens, alongside the structure of a token when de-coded.

NEGATIVE FACTORS: The following factors, as of this sprint, should be worked on…

• The group has reached out to other groups, as well as LibreFoodPantry staff. Still, I feel as though communication is key; the more communication that our group can make with other staff, the better.
• Our team’s organization of the Sprint board could have been better. Specifically, I feel as though moving issues to the “Needs Review” section as they are completed would be preferable to moving them all at once.

TEAM IMPROVEMENT SUGGESTIONS: Here are some ways that the team can improve for the third, final sprint…

• I have made the suggestion that the team could benefit from “POGIL-Style” roles, where each team member performs a specific task for the group. As emphasized throughout this blog, the role that comes to mind is “communications”; while not very “programming-heavy”, this role involves reaching out to other teams and staff. This keeps everyone “in the loop” so that they can plan their sprint work accordingly for the eventual project integration.
• Similar to my discussion within the self-improvement section below, I feel as though the group can benefit from work that is focused towards issue/epic progression. While we are making progress, it seems as though we have to scramble to figure out exactly what is done during our sprint review.

SELF-IMPROVEMENT SUGGESTIONS: As for myself, here are some factors that I need to work on for the future…

• I need to dedicate more time to this project. I have made this issue clear in the last retrospective blog, but failed to work on it. This project, and this class, are extremely important for my professional reputation. Having “outside factors” as a reason for why work isn’t done can only be justified for so long. Eventually, one side has to give: either the outside factors, or the project.
• I feel as though “issue-focused” work would be better for long-term progress. While it’s great that I seem to be making progress with Keycloak, my work is scattered. This issue reflects itself in the progress made on the gitlab issue board.

When creating this blog, I took a quick look back at my first Sprint Retrospective blog; I wanted to make comparisons on mistakes that have been amended during the first sprint. Unfortunately, having this blog posted on time is not one of those amended mistakes. Looking on the brighter side, I feel as though focusing on these blogs is not as important as I make it out to be (this was a mistake that I made during Software Architecture).

LINKS TO GITLAB ACTIVITY

• https://gitlab.com/LibreFoodPantry/common-services/identity-and-access-management-system/keycloak-research/-/tree/KeycloakWithoutDocker (Keycloak Software and Guide)
• https://gitlab.com/LibreFoodPantry/common-services/identity-and-access-management-system/keycloak-research/-/blob/main/npm_review.md (Example of file converted to .md format)
• https://gitlab.com/LibreFoodPantry/common-services/identity-and-access-management-system/keycloak-research/-/blob/main/Keycloak-Guide.md (Keycloak Guide)
• https://gitlab.com/LibreFoodPantry/common-services/identity-and-access-management-system/general/-/tree/APIDev/Libre_Frontend (Repository of Working Frontend Demo – HTML/Keycloak/VUE Connection)

From the blog CS@Worcester – mpekim.code by Mike Morley (mpekim) and used with permission of the author. All other rights reserved by the author.

My third and final sprint for my software development capstone has come to an end. Here is what I did, and my thoughts on it.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/reportingsystem/reportingbackend/-/issues/6#note_911958619

This represents my thoughts on this file after looking it over. There’s probably still room for improvement but I didn’t think it was the best use of our time.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/reportingsystem/reportingapi/-/commit/81ce29d85af035a51e668fe6c4c80267c0d72d08

Changed the API to swap out json for plain text, since we want to return a .csv file.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/reportingsystem/reportingapi/-/commit/aa518b6d2f14ddce9deda38ce77fcedf752af03c

Removed this because the previous commit made it unnecessary.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/reportingsystem/reportingapi/-/commit/f671ce8d8de2af3282d8a402945964b6a4a38b24

Some minor restructuring of the API.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/reportingsystem/reportingapi/-/commit/7c1489a9f4ed45e58e7a6949231f1c40488c7095

Fixed a typo in the filename of the .yaml file mentioned above.

I think everyone had a pretty good work ethic. While individually we may have struggled, we collectively knew what we were doing.

As far as things that didn’t go well, I think we’re still struggling with assigning correct weight point values and issue granularity. Most things I did felt either too easy or too hard for their given point values, mainly the former.

The issues we made mostly felt to me like they were too specific. Sometimes this meant they were too easy, but not necessarily. I think it caused unnecessary confusion, since what should be one task might get split up into three, done by three different people. There’d then be no way for any of them individually to check their work.

There’s the possibility of coordinating the issues so that it’s clear they’re dependent on each other, but I think it would be simpler to just have them all be the same thing. I wouldn’t coordinate issues in this way unless they were clearly separate tasks, but still related.

One thing I think we could have done as a team is coordinate more. I think communication was our biggest weakness. I always felt like no matter what I was doing, I was always kind of going off on my own. At the start of the semester, we agreed to take turns being the scrum master, but as it went on we focused less and less on procedural concerns. I think we could have benefited a lot if someone had stepped up to be the team leader.

As far as things I could have done to improve, I could research more. My biggest roadblock was not really understanding how all the moving parts fit together. I think I overestimated my skills a lot. Also, in the context of a college class, there’s a strong incentive to just do the bare minimum to pass, with any independent study taking away from other classes and out of school activities. I did manage to get a little bit of independent study about the tools we were using in, but not nearly as much as I’d have liked.

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

With this being our last Sprint for the semester, it couldn’t have ended on a better note. Cooperation between the team members and communication continued to be effective. Everyone seemed stepped up and the work ethic was beyond that I could imagine. Comparing to other team/group projects I have been on in the past.

During this sprint, I worked on creating a key for the endpoint authentication. We were still waiting on the actual key from the IAM team so in the meantime, I created a code that will give authorized individuals in the LibreFoodPantry access to their sites. Such has if a guest has access to the LibreFoodPantry portal, once they put in their login credentials, they will either be authorized or unauthorized. This was by request of the client.

Some of the issues that we faced was the getRange API calls. This method required additional coding to the NestTester, API and the backend. Once that was completed, we were able to move on from this project.

I think over the past two sprints, our usage and knowledge of GitLab Epics and Issues board just continued to improve. One issue we faced in the beginning was apply the proper weight to each ticket. As the sprints continued, our distribution of the weight continued to get better. We ended having a better workflow and a more balanced and shared workload.

With a good portion of our task completed, we mostly spent this sprint communication with the IAM team to get a better understanding of when they need to integrate security mechanisms into our remote function calls. We concluded that this will not be complete this semester and will have to be pushed to next years Capstone class.

We were giving the option to continue to work on this the rest of the summer to better improve the progress that we have. This is not a bad option since technically this is for a real work client that is expecting some type of prototype. Joe has decided to stay on and continue to work on this while myself, I have opted not to. With this being my last year, I have other opportunities that I will be pursuing to better myself in this field.

As the conclusion to this spring, the group decided that each member will record a portion of the project and prepare a video presentation. I’m overseeing the consolidation all the recordings and preparing a video presentation for Dr. Wurst. We broke down what needs to be discussed and each member will pick what they would like to talk about. I will take what’s left over to check off all the topics that we would like to discuss/present.

The capstone was a good experience and helped be become a better team member. Being able to see each member grow from the first sprint till now is always something that I am proud of because I know they each learned and took something away from this class. Not all was smooth, and we definitely had some bumps along the way but in a real world scenario, that is what happens and you have to learn how to adjust and get over those bumps. Theirs always a solution to any problem, isn’t that was coding is, solving problems.

From the blog CS@Worcester – The Dive by gonzalezwsu22 and used with permission of the author. All other rights reserved by the author.

For the end of Sprint 2, I would say the team really came together to help each other out. We were able to see each other’s skills and start coding. The communication seemed to improve throughout, and the group decided to let Joe continue to be the scrum master for the rest of the semester since the first Sprint he couldn’t really apply scrum master duties. This time around we were more focused and ready to tackle this sprint and give our best work. For this sprint, we assigned fewer task to people with higher weights because we knew it was going to take up some time to build the backend. We were able to produce an OpenAPI for the requested endpoints. We used the yaml file provided that helped us write, build and then test the endpoints in our backend. Then these methods were tested using Visual Code Studio to launch the HTTP request from the guest.http and the qs.http.

During this sprint, while building the backend, we ran into some issues on how to get the calls. http POST, GET, PUT to work for our guest information code. First, we assigned each call to a member in the group. I oversaw creating the get DELETE which was giving us some issues. The error ended up being just minor coding grammar on my end that was easily fixed. Unfortunately, I was operating under a different branch so every code that I sent or corrections to the code that I made, was being pushed to another section of the LibreFoodPantry. Once that was corrected, I was able to continue to help my team. Another issue that we ran into was our Questionnaire call. The reason we were having issues is because Mongold gets created and returned on a post. Any record access after that must pass with a key for that item. Another issue we faced were that the Android app was producing a Timeout Error which we sought counsel from Dr. Wurst on how to correct that in the next sprint.

Overall, I was really impressed with my team since we accomplished two of the major goals that we had. First, was to improve the skill-set of the team members. The first sprint was all copy and pasting documentations. This sprint we all had to show our coding abilities and was able to learn from one another if was lost. Second, was that we were able to help the general progression of the LibreFoodPantry.

For the next sprint, I believe we are starting off on a good start. We were able to fix all the errors that had with our backend, all of our calls are now working with no errors and has a team we have better communication and organization. Joe has really stepped up and lead us to a good position.

Links to my tickets:

API: add endpoint to return current version (#21) · Issues · LibreFoodPantry / Client Solutions / NEST / Guest Information System / API · GitLab

HTTP Get Range of Questionaire Submissions (#19) · Issues · LibreFoodPantry / Client Solutions / NEST / Guest Information System / API · GitLab

backend: set up devcontainer.json for extra tools needed (#2) · Issues · LibreFoodPantry / Client Solutions / NEST / Guest Information System / Backend · GitLab

From the blog CS@Worcester – The Dive by gonzalezwsu22 and used with permission of the author. All other rights reserved by the author.

Oddly enough, I found this sprint to be a tad more challenging than both the first and second. I’d say this is primarily because we were nearing the end of our project, and the team had some difficulty accurately choosing and weighting our epics and issues. I’m unsure if the rest of the team would agree with this sentiment, but it’s certainly something I felt at the beginning of the sprint. We all eventually found worthwhile contributions to work through, but the lack of cohesion or agreement at the beginning was a little jarring. 

Despite this, I’d say the team got some of the harder pieces of work done near the end of the sprint. I certainly remember the getRange file for the API being a huge hurdle to get functioning, but with Jeff and Kenny working together they made it work in the end. Personally, I felt a little stuck after implementing a few new schemas in the API, as I had elected to work on the key validation from the other groups’ projects. I thought I’d give it a shot, as encryption has always been pretty fascinating to me with all the different types of encoding techniques that exist. However, I soon found I was quite far out of my depth; I ended up staring at StackOverload and random forums trying to get the verification working for a lot of class time. There were a few times I thought I had cracked it, but unfortunately it broke the code every time I pushed it into our repository.

In the future and during my career, it’s pretty crucial I learn to reach out or actually post something on one of these forums for help. I’m sure during the process of an actual situation my seniors will be vastly more knowledgeable than me on basically everything, so this is a skill that should hopefully develop naturally. Of course it’s important not to be an incessant pest, but with my genuine willingness to improve I’m sure I’ll be fine.  

Overall, I was still really satisfied with the team this sprint. I think we all found our roles and niches in the project to work on, and were more than willing to answer questions and help out whenever it was needed. I found the capstone to be a great introduction to my future career opportunities, and the familiarity I garnered over the semester should boost my competency level pretty far beyond what it would have been otherwise. I also look forward to working on a team with a dedicated scrum leader who I can look to for some direction if I feel lost.

One thing that I do think the team could have communicated better on was our presentation. I know it’s pretty separate from the actual work we were doing, but for a good amount of time I had no idea what I was supposed to be covering in the video. I defaulted to whatever the team didn’t initially choose, as I wanted them to be more interested in what they were presenting. Unfortunately, it was difficult to glean my responsibilities as some members were quick to post what they preferred, while others didn’t accurately mention their coverage. In the end I just went over the API, and I hope I didn’t overlap all too much with the others’ videos. Regardless, that’s a minor gripe, and I don’t blame anyone because it’s the end of the semester. 

As for some contributions, I added these pretty minor things to the API over the sprint.

https://gitlab.com/LibreFoodPantry/client-solutions/nest/guest-information-system/api/-/blob/main/src/schemas/GREkeyValidation.yaml

https://gitlab.com/LibreFoodPantry/client-solutions/nest/guest-information-system/api/-/blob/main/src/paths/invalidKey.yaml

https://gitlab.com/LibreFoodPantry/client-solutions/nest/guest-information-system/api/-/blob/main/src/paths/validKey.yaml

I also helped out a bit on the getRange before I started working on the backend key validation. It starts on line 56 of this link. 

https://gitlab.com/LibreFoodPantry/client-solutions/nest/guest-information-system/backend/-/blob/main/src/data/questionaire.js

From the blog CS@worcester – Dummies that Code by howbrash and used with permission of the author. All other rights reserved by the author.