In our final sprint, our team focused primarily on finishing our demo, communicating with other teams about their projects and how they will fit into the cluster, and creating a schematic of the final cluster. I think our final sprint went really well. While we did not finish everything we set out to, we were able to get a significant amount of work done, and I think we have left the project in a good place for whoever will be picking it up next.

I think a lot of things went well in this sprint. Similar to our second sprint, we had a much clearer understanding of what we wanted to accomplish in this sprint, and that made it much easier to divide work into manageable tasks. Unlike the last sprint, much of this work could happen concurrently, so team members were blocked less often by the issues other team members were working on. Additionally, I think we were all much more comfortable communicating with each other, and this allowed our work to go much more smoothly.

The only thing that didn’t go well was how much work we wound up getting done by the end of the sprint. We initially planned for thirty points of work, and by the time the sprint had officially ended we only got through about half of that. I think we underestimated how long some of our issues would take to complete and wound up falling behind. Regardless, I feel that we got a substantial amount of work done.

Our team worked very well during this sprint, but there is always room for improvement. I think we could improve on our time management a little bit. We spent a lot of time discussing how we would like the sprint to go, and this left less time to actually work on our issues. Still, I don’t think this impacted us too heavily; I am happy with the work we did get done.

Personally, I think I could improve on the way I write documentation, especially summaries of research I’ve done. I tend to get overwhelmed by whatever information I’m reading and will forgo some details in my retelling. I want to be able to write more detailed documentation since that would be more beneficial for my team members.

Contributions:

Research Helm – I spent time looking into Helm, which is a package manager for Kubernetes. I researched what it is, how it works, and whether it would be worth using in the final cluster for Thea’s Food Pantry.

Communicate with Team 1: Inventory System – I informed the Inventory System team about our work, and I made sure we understood how their project is structured.

Communicate with Team 3: Food Keeper – This is similar to the previous issue. I informed the Food Keeper team about our work, and I made sure we understood how their project is structured.

Communicate with Team 4: nest Guest Info – This is similar to the previous two issues. I informed the Nest Guest Info System team about our work, and I made sure we understood how their project is structured.

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

Our third sprint was definitely the toughest, and we ran into some issues throughout the sprint that really slowed us down. We started out at fixing problems for the project from the end of the previous sprint, then moved on to the last issues we put in the backlog. One issue in particular would take a lot of time to solve and prevented some of the other issues from being completed.

Starting with what worked well, we were doing better at communicating with each other and finished with enough weight for the review. When we were having problems with the issues, we were keeping in touch with each other, and most of us were working together on the main issue that was holding us back. Some of us were having more success than others, but it was eventually completed and the other issues that were relying on it were being finished too. We were also able to finish the presentation on time, and had a plan for putting the presentation together with slides and an outline that we put together.

Our main problem for this sprint wasn’t a problem with the team, but with one of the issues we were working on, which had to do with building the backend server and getting it working for everyone. Along with getting the server working, some of us had different issues that others weren’t getting. We spent a lot of time working on this issue, and had to rush through the last issues in the last week. Aside from that, we were still trying to improving on keeping up the merge requests up to date. We managed to get all the merge requests done in time, the requests would just build up over a few days. Aside from that we had some days where team members would not be there in person, but they would join online and were able to join in the in-person discussions through the discord chat.

I think I did well at continuing with the improvements I was making as a team member by communicating with the team when working on the project and the presentation, but there were a couple times when working on the presentation that I missed out on some discussion. I would later join in the discussions, catch up on what I missed, and do my part in recording for the presentation. When waiting on the backend server issue being completed, I had the idea of setting the api tests up with a template for the test files, so that they would be mostly done by the time we are able to use the api. That way, the issues could still be completed while dealing with the backend server. I got this idea from a template file that we had made in the previous sprint for the data files, and a template file for api testing that was created during this sprint, and figured we could have something similar for the api testing methods while waiting. In the endpoint api templates, the testing methods were set up for the api to accept sample valid and invalid calls that worked for samples we had, so when we would be able to use the api for the testing, we could just make new calls to put in those positions and then adjust based on testing results.

https://gitlab.com/LibreFoodPantry/common-services/foodkeeper/foodkeeper-newbackend/-/merge_requests/28

Resolving the problems with the category test file so all tests passed.

https://gitlab.com/LibreFoodPantry/common-services/foodkeeper/foodkeeper-newbackend/-/merge_requests/33

Template for the category api testing that was created while waiting for the backend server.

https://gitlab.com/LibreFoodPantry/common-services/foodkeeper/foodkeeper-newbackend/-/merge_requests/36

Template for the product api testing that was created while waiting for the backend server.

From the blog Jeffery Neal's Blog by jneal44 and used with permission of the author. All other rights reserved by the author.

Our third and final sprint for the semester was our strongest sprint to date. Everyone in the team could feel that we were really hitting our stride and solving issues as they were being created. We were able to look at what went wrong in our prior sprints and not get trapped in the same pitfalls that we encountered early in the project.

The Good

We were laser focused on what we needed to do. Our productivity and communication levels were at an all-time high which really helped in the amount of work we were able to produce. We were also able to realize when an issue was more than a bite-sized problem and successfully broke them up into smaller issues as needed. We had a clearer vision of the direction we wanted to take the application in and for the most part we met the expectation we set for ourselves this sprint: A demo application that highlights its main functionality.

The Bad

I mean… There wasn’t too much that really went wrong with our workflow during this sprint. I think the feeling that we performed very well was very tangible to anyone watching us operate as a team or looking at our team’s activity on the project repository. The only bad thing that would come as a result of this sprint is that we are concluding our work on our application that we witnessed grow from inception.

What could we have done better?

I feel like the only thing we could’ve done better was perhaps having a longer discussion on how we envision the app to look in the future. Leaving better instructions for the next team of students who will work on this project is the only thing that comes to mind when I think about anything we might have lacked in.

Contributions that I added to the application include

Writing Portion:

Create a writing page for an examinee to record the prompt they heard from the proctor. They will type out what they heard instead of using their finger or a stylus to write it out. The current version of this feature is a temporary solution until a way to implement the correct functionality is discovered.

Create a page that holds all the prompts the test proctor will ask the examinee to write(type) in English. A .csv file named “sentences” was added into the projects assets folder. The Prompts.js file reads from and parses the sentences from the file into a list which is then displayed in a ScrollView on the page.

Adding React Native Paper styling to Writing and Prompt pages. We decided to use React Native Paper styles throughout our application. In order to remain consistent with the application design, I added card features for the elements on each page.

Merging of Writing page and Prompt pages. After the pages were created a teammate suggested that we merge the pages instead of having to navigate too much. This was a great idea because it was much easier to implement than having to move from page to page as well as improving the UI.

Reading portion:

While working on my own issues, I aided my teammates in working with our app’s counterpart to the writing portion. The bug we encountered involved displaying a question from a list of questions on a separate page. While we couldn’t resolve the bug itself, we were able to verify that it is possible to display another question successfully on a “new page” but do not have the means to display the correct one at the moment.

From the blog CS@Worcester – You have reached the upper bound by cloudtech360 and used with permission of the author. All other rights reserved by the author.

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.

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.