With the end of my first ever sprint experience, I would like to reflect back on what worked, what didn’t work, and what changes could be made. To be honest, I felt like we were kind of just thrown into the first sprint with little time to prepare, but as the sprint progressed, my team ended up getting the hang of it. As a team we managed to create enough issues to work on throughout the sprint and everyone took up different issues to work on. We were swift to approve merge requests and review other members’ changes, so I think we worked efficiently on that part. 

As for me individually, I took on three issues, all of them involving the rearrangement of the file structure for each of the frontends. Issue #3 involved refactoring the file structure of checkInventoryFrontend where I based it off the MicroServices example. Issue #4 involved refactoring the file structure of addInventoryFrontend where I based it off the MicroServices example. Issue #6 involved refactoring the file structure for CheckoutGuestFrontend where I based it off the MicroServices example. I didn’t have much of a problem with them, as they were not complicated to complete.

As for what didn’t work well, overall, I think we as a team spent a lot of time trying to understand what everything was supposed to do. From each of the frontend to the backend, there was basically nothing implemented nor functional. I think because there was the daunting task of having to create the inventory system from the ground up, I had trouble actually picking out what needed to be done for this sprint. That aside, we managed to dedicate this sprint to preparing the files for implementation so that we would be able to start working in the next sprint.

As a team, I think we were able to come together and get work done. Some of the members of my team are people I have yet to work with, but there was no issue there. I am happy that I was able to help a fellow teammate resolve an issue they were having with the API. Aside from that, there was not much else communication between teammates during work periods as everyone was focusing on more individual tasks. This first sprint was more focused on the housekeeping tasks so there wasn’t much need for collaboration in the first place. I think in the next sprint, we will be able to greatly benefit from more communication and asking for help when needed. 

What I can improve on individually is to come up with more meaningful issues. This last sprint, I only created a handful of issues, all of them involved creating or moving files around. Now that this coming sprint will be more hands-on, it will give me a chance to come up with more specific issues, focusing on parts of the project that need to be implemented. I would like to work more efficiently, finishing issues within their estimated weight time. Overall, I am looking forward to the next sprint now that I have an idea of how the entire sprint process goes.

From the blog CS@Worcester – Null Pointer by vrotimmy and used with permission of the author. All other rights reserved by the author.

Overall, with my work on the issues listed below, I think that the methodology of using the GitLab boards worked really well for us as a team, allowing us to pick which issues we personally wanted to tackle and notify everyone of what was currently being worked on. I also think that the methodology that we figured out as a group of requesting someone to check over our commits before we merged the branches worked really well.

Overall, I just don’t think we had a handle on the project when we made the first set of issues, so a lot of them were undefined and others really had no purpose. Our first sprint had no real direction and was just a bunch of random issues that we thought we had based on random comments in the code and what we thought should be done. This lack of direction, I feel, really hurt our productivity as we were focusing on things that had very little to do with each other and were just in there as things that could be done to grab some extra time units that it seemed like we needed. I also don’t think we communicated enough over the course of the sprint as to what everyone had done, which caused a bit of confusion. I also felt like I personally didn’t do as much as I would’ve liked, as some of my issues fell flat and left me feeling like I hadn’t contributed as much as I would’ve liked. The biggest issue we ran into on the technical end was the fact that our backend had almost no functionality at all, and needing a backend in order to properly try out and work on frontend behavior really put a damper on the amount of progress that was possible for us.

To improve our team issues I think we just need to flesh out what we need to do as a group, in order to fully grasp the scope of our sprint and what functionality the project needs as a whole. We also need to flesh out how we want to handle organization in terms of the file hierarchy and structure within the repos, as well as a proper naming system. These issues would be easily possible with a refactor I think. This first sprint was really a trial run, in my opinion. We are slowly figuring out and narrowing in on what needs to be done to get this thing working and finding examples to go off of to start to create some real functionality.

As an individual, I think I need to communicate more with the group and see if anyone else needs help, I guess so far I haven’t felt like as much of an active member as I would have liked. I also need to be less rigid about issues and not feel like I can add them as they come up because sometimes I feel like I shouldn’t add things to a sprint that is underway because of the seeming rigidity of SCRUM. There are things that can be done and issues that can be added or modified over the course of the sprint, at least I think there should be. I just need to let go of my personal hangups with SCRUM in order to work more effectively with the team. That and manage my time better, as this sprint, I kind of dropped the ball.

Issue #17 This issue represents work done by Sebastian and I trying to figure out how the backend worked, and our conclusion that it needed to be completely rewritten

Issue #62 I added dev containers to each of the repos of the project, however they may need to be updated as we go.

Issue #16 This was abandoned after figuring out that the file the comment was part of was just copy-pasted as a placeholder.

Issue #15 This was also based on a comment about a file being used as a test, I moved it to its own folder but have determined it has no functionality, but we will keep it around just in case we need some of the code.

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

During this past sprint session my team and I worked on the LibreFood Pantry Identity and Access Management System. Our goals in this sprint were getting a KeyCloak implementation going and building a small API to work with keycloak and LibreFood Pantry. The first issue I created was designing our API (what endpoints should it have and what basic structure should it have). This issue had a weight of one and I was able to complete it between class on Wednesday and the following class on Monday. This involved creating the LibreAPI/src folder and using NPM to initialize the folder with a package.json file and manually add the folders. The next issue I created was to begin creating the API and writing code. This step involved watching a lot of videos and reading tutorials on how to implement a simple API. The API has two basic functions: Post a string and get an array of all the strings. Two YAML files were created in order to service the endpoints using OpenAPI implementation. I also created an issue on linking KeyCloak with our API and put in in the backlog until there was more research available and I would be able to have the other team mates catch me up on their KeyCloak information. 

Our team divided into two sections: I would work on the API, Mike would start with frontend and backend files then join me in API development, George (our scrum master) handled creating all the legal documents and licensing/documentation, Andrew and Gracia did research on KeyCloak set up and implementation. The research documents were very helpful when it came to better understanding KeyCloak’s structure, function, and how we could link it using a JavaScript adapter. Overall, the division of team labor felt fair when allocating individual team tasks. Having two students focus on development (Mike and I) and the rest of the team handle KeyCloak kickstart (George, Andrew and Gracia). KeyCloak is a very large system and there was a lot of research that needed to be done before we could begin a simple implementation. 

As an Individual I want to improve the way I communicate with my team and try to keep my focus narrowed in. During group meetings, I would find myself asking questions to the research team about KeyCloak that are very off topic from the current discussion. In reflection, I think this may sometimes throw off the group discussion and put my teammates “on the spot” to mentally shift gears to what I’m asking to try and best answer my question. I think this throws off the workflow and next sprint I plan on writing down questions that come to mind as I am working and near the start of the meeting (possibly during my stand up) and chip away at questions during that time, or bring questions up when they are relevant. 

As a team I believe we worked very well together. We all have a true interest in this project and put in a lot of time outside of class to get things done. For this next sprint, we plan on all focusing on getting keycloak up and running and will revisit the code we worked on once we get past our current roadblock which is getting one instance of keycloak to work and use that as the basis for our project. One way we can improve as a team is to communicate more outside of class via discord channels and also communicate with other teams.  We are in the same classroom as other teams working on LibreFood Pantry and our project needs to be linked together with everyone else’s work by the end of the semester. This means we need to take more time to talk with other teams during class or via discord voice channels. 

From the blog CS@Worcester – Site Title by lenagviaz and used with permission of the author. All other rights reserved by the author.

The outcome of the sprint was excellent. We wanted to get a working frontend and a working backend, and we had to familiarize ourselves with the code from last semester. The state of the project did not have a fully functioning frontend, and the backend was not working at all. The goal of this sprint was to clean up the existing code and make the current features work as they should. The nature of this sprint was to set up the GuestInfoSystem front end and back end, and we did well on that. We added several features, but a majority of it was refactoring existing code.

One of the workflows we struggled with was managing branches while we programmed. Because there were three people on the front end and three people on the backend, multiple people worked on the same area of code. The workflow that emerged, especially on the backend, was creating many branches from other branches. The effect of this was that we had a diverging codebase that was difficult to merge and maintain coherence. For example, a branch created from the main branch was to add JSDoc. Then we needed to update an API path, and a branch was created from JSDoc. An individual continued to work on the JSDoc branch while someone else worked on a new branch from this one. Creating a new branches from an existing branchx continued a few times, and updates to the code were scattered. New code was mixed with old code in each different branch.

To not have this issue reoccur, we will be changing our workflow for managing branches. What we will do for the next sprint is make a single branch for each issue and merge it into the main branch following it has been reviewed. If a significant feature needs adding, we will create a branch for this, and multiple people can work on it at once. If there are multiple active branches, we will ensure that one branch does not modify the area of code in another branch. By working on small features and performing common merging, we will make sure code is not lost and each member is working on the most up-to-date code at all times. It was difficult to do this during our initial sprint due to the amount of code that needed to be rewritten to get the backend working. In the next sprint, we will follow this improved workflow.

A change that I will make in the next sprint is to improve the issue creation process. The issues that I made for this sprint were overly broad, and the weight did not fully capture the issue’s headline. For example, ‘Add JSDoc’ has a weight of three, but it sounds like something that could be done in one class period. This issue actually required defining the type for each variable used in the backend, defining function input and output types, and creating object types for each object in the backend. This process involves studying the code, assessing the proper type for each instance, typing each file, and ensuring the types selected do not throw errors between files. What I could have done to improve my issues by creating smaller issues for each of these steps. Each one of these issues could have been done in the same JSDoc branch, but each small issue clearly defines what is being worked on. Following the closure of JSDoc related issues, the branch could be merged into main.

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

Today I’m taking a break from writing about software apprenticeship to post a quick overview of my progress in the first of three sprints I’m doing as part of a scrum team working on the Thea’s Pantry reporting system. This is my first time on a scrum team as well as my first time working with most of the tech stack involved here, so if it seems sort of unfocused, that’s why.

Here are the links to the commits I wrote during the last sprint:

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/reportingsystem/reportingdocumentation/-/commit/fd8292deb31063912468f51b2fd343218a155b48

Here I fixed a typo. I also made the repo and wrote a very bare bones readme file that this commit was addressing.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/reportingsystem/generatewcfbreportfrontend/-/commit/b9696c0951535f3200c49d8fce7de2dcd4c70929

Here I copied some boilerplate from an example project.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/reportingsystem/generatewcfbreportfrontend/-/commit/b55ec4d296b4159258d51279a5ae0aee678ea2f2

Here I added scripts that make it easier to use docker-compose.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/reportingsystem/generatewcfbreportfrontend/-/commit/7916ee242ca4cff7ff645f455986fd564ab68c52

I copied some things from an example readme to the frontend readme.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/reportingsystem/generatewcfbreportfrontend/-/commit/3cdc0c6a7b049b2a1d1462bb28991487954a4861

I went back and changed the title of that readme to actually be relevant to the project.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/reportingsystem/reportingbackend/-/commit/aac29a2161460b7ef832387c50d144221ae3a23b

I deleted a random file that I think someone was using for testing purposes.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/reportingsystem/reportingbackend/-/commit/251b4a5088f3998de0bda28ef4f83c68ca69e9bd

This commit contains the bulk of the actual work I did. That being said, I didn’t really know what I was doing, and mostly just thoughtlessly copied stuff over for the sake of getting something out there. I noticed there were dependencies at the top of the file, and that they needed to be either removed from the file or added to the project in order for the code to actually work, although for the sake of time and for the sake of keeping the history clear I decided to just leave them in as they were. After the retrospective meeting, I think there’s really no good reason to keep the validator around when NPM serves the same purpose, although we might still put the logger to use.

So, the problem that has been burning in my mind the most was that I just kind of threw things together, being so unfamiliar with the system that I really didn’t even test to see whether my code worked. A big part of that is that we don’t really have anything functioning yet, but it’s also because in the specific area I was working on (the backend) I actually was a little rusty on how. I am from a background where I’m used to just having an executable file with a call stack that I can look at at any time, and the way this project is spread across multiple machines is something I find somewhat confusing.

We also didn’t take creating issues as seriously as we should have, in my opinion. We kind of threw it all on a few people. We should probably have discussed them for more than just the one class session, and the discussion should have been put in writing on GitLab so that there would be evidence of everyone having participated (a lesson I learned the hard way).

I think many issues were too granular. Many of the above commits were two-weight issues, which our department is using to mean that the task should take about one week. I did most of them back to back in one session, except for the last one, which took another session (in other words, it all added up to one single two-weight issue).

I feel like as a team we’re pretty good at putting the effort in, which is in my opinion the hardest part of anything. I think our biggest struggle is in communication, and I think that’s due in part to unfamiliarity with the project. Something we could try as a team is to pick five areas to research and assign one to each person. Something I could do personally is see if I can get the whole system running so that I can test it out and know what everything is for and what everything is supposed to do.

One final thing I’m going to do is proofread everything I write in this project, because a pretty significant number of commits up there are just fixing typos. I actually noticed another one as I was writing this post, which I’ll probably fix as soon as I post this. I don’t really understand why I made all these errors, since it’s not something I usually do. I suspect it may be because I was panicking when I did most of the work here. That’s definitely something to avoid in the future, since I feel it’s not conducive to programming.

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.

For the first sprint, our team, team 1, have focused on working with 4 projects which are ReportingDocumentation, ReportingBackend, GenerateWCFBReportFrontend, and ReportingAPI. ReportingAPI and ReportingDocumentation are the two new projects created in this sprint. For ReportingDocumentation, we based on the description of the epic called “Create Documentation repository” to add all the necessary files and write the README.md to describe about the ReportingSytem in detail. In README.md, we depicted the role of each project created in the ReportingSytem; we also added the user story, the architecture, and technology sections related to Reporting system from Theas Pantry’s Documentation. ReportingDocumentation is completed as we expected in the first sprint, but we will update more information about each project in the Reporting System if any changes are made in the next sprint.

For the ReportingAPI, we separated the given API from the ReportingBackend into its own repository just like the example API that we have learned from last semester. Based on the example API, we added all the required files to the ReportingAPI. The src folder which includes the paths, responses, schemas, and index.yaml is the only folder that we have edited to create API for the ReportingSystem. This is a simple API, so we finished the ReportingAPI repository in the first sprint without any issues.

The API is similar to the blueprint for ReportingSystem which tells us what should be done in the backend. Based on the API, we know that Get /WCFB/report is the only request that needs to be implemented in the backend. However, the backend of ReportingSystem was made by another group with no instructions for running it. We tried many ways to test the backend and found some bugs in docker-compos.yaml that caused the images and containers to be built incorrectly. Although we fixed those, the backend was not working as expected. We also tried to refactor some of the .js files in the backend to make them look more understandable with the new style. However, since we still have not found a way to check if the old code is working correctly, we got confused when we refactored the backend. So, I think those missions should be redone in the next sprint. For this sprint, our team has not finished the backend yet, we just tried to test the old code of the backend, but we failed many times. So, the backend will be the only project we will focus to work on in the next sprint.

For the frontend, GenerateWCFBReportFrontend, we also based on the example frontend that we have learned from previous semester to create a similar frontend. We added all necessary files like the example; and the src folder is the only folder that we have edited to create the frontend for ReportingSystem. The frontend is still in progress as it is waiting for the backend to be completed. When we finish the backend, we will attach the http request to the method section in the getReport.vue to complete the frontend.

In summary, for the first sprint, we worked with the 4 projects in the ReportingSystem which are ReportingDocumentation, ReportingBackend, GenerateWCFBReportFrontend, and ReportingAPI. We have completed the ReportingAPI and ReportingDocumentation, but we will keep track on and update these two projects if there are any changes in other subsequent sprints. The ReportingBackend and GenerateWCFBReportFrontend are still in progress, but they are planned to be finished in the next sprint.

For the teamwork, I think we worked well as a team but the only change that I would suggest for the next sprint is that we should focus on solving the issues established in the sprint backlog before focusing on anything else. Our team focused too much on working with the backend, which consumed a lot of time with no results, and forgot what should have been done in this sprint. Although we completed all issues in the sprint backlog of the first sprint in time, the work was not evenly distributed among the team members. So, I think that is the point we need to notice to improve for the next sprint. On the other hand, as a member of group 1, I think I should communicate more with the whole team to figure out how to work as a team more effectively.

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

For the first sprint of the semester, I individually didn’t get as much done as I hoped to. I did help others, and collectively as a team we got a good amount done,  but I hoped to get more done individually. For this first sprint, I spent a lot of time looking through the project and the different repositories to find out about each component, how it worked, and how it interacted with the other components. Due to this, I feel that I learned a lot about how the project currently works, how it’s supposed to work, and what systems currently function or do not function. However, this also means that I didn’t have a lot of completed tasks.

The only issue that I had assigned myself on GitLab was the one to rename the subprocess files in the Reporting Backend. We felt that the names ‘send.js’ and ‘receive.js’ weren’t very descriptive, and in order for them to properly reflect what they were for, they would need to be renamed to something more descriptive. This sent me down a rabbit hole of looking through the project files to see everywhere the files were referenced so that nothing would be broken by renaming them, and also to be able to update the names in any documentation in which they were referenced. This led me to discovering that many things in the project were pulled from an old version of the backend, and that many things would have to be redone in order for it to pull new changes and build the image from the new repository. Additionally, I noticed that there were two sets of send and receive files, one in the subprocess folder of the backend, and one in the RabbitMQ folder. This had me very confused, as I at first didn’t know what the send file was for because our module wouldn’t need to send any information through the queue system, but then I discovered that it was simply to insert dummy test data into the queue for it to be received by the backend. I still don’t fully understand why there are two sets of these files, but I now understand what they’re for and will be able to modify and use them.

What worked well within our team was everyone being individually proficient, as well as being proficient in certain areas that others were not. Everyone on the team had their own strengths and weaknesses, and we were able to coordinate so that people’s strengths complimented each other, working towards a more cohesive whole. For example, I am more knowledgeable about the backend systems more so than the frontend systems, so I know more about how the docker containers work and some JavaScript, whereas others know more about Vue and the design of the frontend and are much more proficient than me in JavaScript.

What didn’t  work very well was our team communication. We communicated mostly only in class, and only minimally out of class such as on Discord. Given that we were all individually proficient, we had less of a problem completing tasks individually, meaning we had less of a reason to communicate what we were doing and what progress was being made. I think that sharing more information with other team members periodically, such as what progress has been made, what you’re working on, and what still needs to be done, outside of the scheduled times, could have been very productive and helpful for the team.

To improve upon this, we could have scheduled times for meetings outside of class via Discord, where we could discuss the details of what each of us is currently doing and ask others if they need help or if we need help. This way, we could more immediately resolve an issue that someone is facing, rather than having to wait until the next class to discuss the issue with the other team members. Additionally, the extra time spent as a team could help us to figure out each other’s strengths and weaknesses, and to discuss how we could work better as a team.

Individually, I could have improved upon a few things. First, I should have focused more on completing certain tasks, rather than exploring the project independently of any tasks. I could have learned everything I did about the project while completing tasks, rather than without completing tasks. Second, I could have better shared what I learned about the project with other team members.

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