As the first sprint of the Naturalization Interview Confidence Environment project I have been assigned to work on has finally come to an end, I think that it is time for me to look back on what my team and I managed to achieve, as well as reflect on what I think went right, what went wrong, as well as which of my actions I believe may need to be adjusted before the upcoming sprint begins. Initially, I was somewhat fearful that we would be off to a very rocky start, given how the project itself was borderline non-existent due to the lack of code or repositories from the get-go, meaning that we as a group started work from square one. However, such fearful sentiment had soon dissipated as the sprint went on and more work began to be done. That is to say that, for such circumstances, I believe that this first sprint was an overall positive experience, given the people that I was assigned to work with in my current group.

               In this sprint, my team began working on 40 issues across 8 epics, with around 29 of them being resolved by the end of the sprint. Though everyone was assigned issues to create and populate needed repositories, everyone’s main focus included looking for and learning what Native development framework should be used for the project, in which case I was involved with Ionic Angular. I was involved in the following issues (not including duplicated issues):

• Scope for the Ionic framework: The goal of this issue was to begin learning more about Ionic and Ionic Angular by reading documentations and working on tutorials, as well as configure the development environment.
• Create demo app in Ionic Framework : The goal of this issue was to create a spike solution as a means to demonstrate the capabilities of Ionic Angular.
• Add a CODE_OF_CONDUCT.md file to the “Documentation” repository: Populated the Documentation directory with the CODE_OF_CONDUCT.md file.
• General Resource Collection: A perpetually open issue that serves as an archive of potentially useful resources related to the project.

               As I mentioned previously, the first sprint overall went fairly well. Given how our main focus was to choose one of the three recommended frameworks that we had found (React Native, Flutter, and Ionic React), we were divided into three sub-teams of two members, with each sub-team studying a specified framework. Such dividing tactic worked very well for us, as each team could learn one framework and communicate their findings, such as what they believed would work well for the project. Overall, our method of dividing work among individual group members or sub-teams seemed to work very well for us, especially evident on the topic of choosing a framework because everyone was great at communicating their perspectives. This is also due to the fact that, even though we may have not worked with each other before, we still had some very good chemistry that made communication much easier and more productive.

               However, what did not work well for this sprint was the fact that we, as a group, were lacking on the aspect of properly documenting what takes place during meetings. Though our meetings in class were productive, we do not have any records of what was done or said during the meeting except for some issues posted on the issue boards, and this lack of documentation may bring some difficulties to people who may work on this project in the future. As for myself, I admittedly felt like my time management skills for this sprint were not exceptionally great, given how I devoted disproportionate amount of time and effort into learning Ionic Angular in a somewhat selfish manner, as if I wanted to learn this framework as part of a hobby rather than as part of the project.

               Regardless, this first sprint was off to a very good start, all things considered. Of course, there are some aspects that we have all agreed that we need to really work on as a group, namely the aforementioned lack of documentation of our meetings. Thus, we may need to develop a strategy that can help us keep a proper record of each meeting without breaking the flow in a distracting manner. As for myself, I will definitely need to improve on my time management skills and learn to devote the appropriate amount of time on tasks that need to be done and further learning of React Native.

Direct links to issues:

1. Scope for the Ionic framework: https://gitlab.com/worcester/cs/naturalization-interview-confidence-environment/General/-/issues/12
2. Create demo app in Ionic Framework: https://gitlab.com/worcester/cs/naturalization-interview-confidence-environment/General/-/issues/3
3. Add a CODE_OF_CONDUCT.md file to the “Documentation” repository: https://gitlab.com/worcester/cs/naturalization-interview-confidence-environment/documentation/-/issues/8
4. General Resource Collection: https://gitlab.com/worcester/cs/naturalization-interview-confidence-environment/documentation/-/issues/2

From the blog CS@Worcester – CompSci Log by sohoda and used with permission of the author. All other rights reserved by the author.

Our team is in the process of developing an OpenAPI specification to connect the NEST android application to a remote MongoDB database. It currently uses a local SQLite database to store its Guest Information System data. There are 5 developers in our scrum team. Our sprints are 3 weeks long, with each developer being allotted 6 hours’ worth of work in a week, over and about the 3 hours per week we are using for class time and scrum meetings.

The project started out with 4 Epics, which we broke up into 18 issues initially. The 2 primary epics were API and Backend. Given that the backend work couldn’t be specified until the API was defined, we had to be creative in how we distributed the work. Since the team members were not that familiar with the specific skillsets of the other members, it was difficult at times to determine who would be assigned to which tasks.

I acted as the scrum master for this sprint, which was surprisingly difficult to manage. The majority of my time was spent trying to figure out the API and adding a basic framework to our docker API project. Other members of the team developed container shells for the API and Backend, as well as adding documentation to our general and documentation repositories.

We ran into issues where issues were designed too vaguely, resulting in some tasks being defined twice. The team did a good job of giving weights to tasks, but we could use more effort in knowing the status of each individual.

This may have been an error on my part, but the scrum meeting task of each developer telling (1) what they have done, (2) what they now will do, and (3) if they had any questions turned into longer discussions, therefore not giving enough time to other team members to communicate enough.

I communicated with Professor Budge from Nassau Community College, who teaches an Android class at that school, and is a key contributor to the LibreFoodPantry product. Since our correspondence took 10 days to solidify a general design, I had jumped the gun on the task of developing the OpenAPI by assuming the full contents of the SQLite database were to be stored in our database, as a result, I developed a plantuml design for 8 tables that were not ours!! https://gitlab.com/LibreFoodPantry/client-solutions/nest/guest-information-system/api/-/tree/main/bundles

I also produced a yaml bundle of the Product table. We decided during sprint 1 review that this work should be offered to the FoodKeeper team, another subgroup of our Capstone class.

During the last week, Dr. Budge, after a series of emails, led me down the right path for what we will need to do over the next 2 springs. We are responsible for the data in 2 tables (collections on MongoDB), QuestionnaireSubmission, and GuestRepositoryEntry.

Our sprint’s work should probably have been more focused on design than it was. With people new to Agile/Scrum and some of the underlying technologies we are using, in retrospect, it is clear there were mistakes in our process we will learn from. I think the main message is that until a design is cast in stone, then any technical efforts afforded to the project before the design is solidified should be considered as disposable.  

As a team, we spent a lot of time considering our methods for testing what will be written. At first, it seemed that best approach was to use swagger preview to test the API, given that the backend wouldn’t be in place yet to test with actual “curl HTTP … “calls.

It has now become clear that we really need a new Epic to fully system test the project. W\Three members of the group have built Android Studio and/or Visual Studio Code version of the NEST application itself. The new Epic could outline the work necessary to make a test version of the NEST app to do the actual calls. This will dramatically help the team that will be working on the NEST app next fall.

I have decided that I will relinquish my role as scrum master for sprint 2, which will give another team member a chance to gain experience with this job.

From the blog cs@worcester – (Twinstar Blogland) by Joe Barry and used with permission of the author. All other rights reserved by the author.

Christian Shadis

2/26/2022

This past week, my development team in my Software Development capstone completed our first Scrum sprint for the semester and recently had our Sprint Retrospective meeting. This was my first exposure to an Agile development environment, and thus I have many thoughts about the experience. In this post I will review my own contributions to the project, reflect on the team dynamics, and critique my own contributions and suggest strategies to improve my work in the next sprint.

The sprint got off to a rocky start since none of the six of us had worked in a Scrum environment, nor worked with Gitlab issues and boards, but we settled in quickly enough to complete nearly all the work we set out to for the three-week period. The most difficulty we had as a team was with the process of branching and merging – we had multiple instances of changes being made on main instead of in the branch and had a surplus of merge conflicts to deal with due to pushing outdated code to the main branch. Our difficulties can be attributed to lack of experience, but as a team we were able to overcome these difficulties quickly, and by the end of the semester had a much smoother process in place for merging code into the main branch.

As a team we communicated efficiently and were able to help each other with issues when needed. We divided work evenly such that no team member worked significantly more or less than any other member. We were also effective in the work itself, as nearly every issue agreed upon during the Sprint Planning meeting was completed.

The team has agreed to implement numerous changes in our workflow for the upcoming sprint. We have re-structured our merging process to make updating the main branch as seamless as possible: instead of approving changes to the code during class time, we will instead transition to having two team members approve any merge request before merging it. This will help prevent logjams of merge requests and will allow us to better utilize our in-class meetings. We also agreed to work on improving the efficiency of our standup meetings. In the previous sprint, we would often get sidetracked during the standup meetings and talk about code that was written or have discussion about implementation – we have resolved to instead keep the standup meeting as concise and focused as possible and hold all other discussions afterward.

I contributed to the team by creating the Documentation repository in the Foodkeeper group and populating it with the necessary files (https://gitlab.com/LibreFoodPantry/common-services/foodkeeper/food-keeper-backend/-/issues/1), by creating the index file in the API repository (https://gitlab.com/LibreFoodPantry/common-services/foodkeeper/food-keeper-backend/-/issues/24), and by creating the schema for the Category of a data point (https://gitlab.com/LibreFoodPantry/common-services/foodkeeper/food-keeper-backend/-/issues/6). I also wrote several files of code for Issue 17, which wound up not being implemented (see below for further explanation).

There are several improvements I can make as an individual as well. I noticed my shortcomings in keeping the issue boards organized: I often forgot to move issues between labels, and at one point unassigned myself to an issue I had already completed yet not merged (Issue 17 mentioned above), causing a waste of time when another team member picked up and re-completed the issue. Keeping my own issues organized, properly labeled, and assigned is important to the overall function of the team.

I would consider the sprint successful overall. We had some rough patches in the beginning, but our team excelled at addressing problems as they came up. We are also producing work that all of us can be proud of. I am looking forward to the next sprint and further improving my capability of working in an agile development team.

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

During this sprint, team one performed extremely well. Despite being a new team that is completely new to this project, everybody did their best to be as productive and cooperative as possible. I thought that the team operated efficiently and worked as a unit. We were able to come up with great methods to communicate, find issues, divide the labor, as well as a method to review and approve completed tasks. In the end we managed to finish the vast majority of our tasks and we are already preparing for the next sprint. Personally, I thought I did well during this sprint as well. I completed all of the tasks that I assigned myself, and I found the time afterwards to help my teammates with any issues that they were having with their tasks.

With that being said, we did struggle as a team trying to understand what the project was about. Most of the files in the project had little to no functionality, and the backend was basically missing. The backend was only a skeleton with placeholder files. The only things were able to do during this sprint was moving files around for organization purposes as well as spend time trying to understand this project. I personally had issues trying to understand how the architecture works as well as what some things do like RabbitMQ for example. I also thought that spent too much time with my tasks than I should have especially when considering how easy they were. Most of my tasks were just creating new folders and moving files into them.

I think our team has a lot of room for improvement. For starters, I think we need to spend more time during the planning phase of our sprints to fully flush out what we want to do and how we want to do it. For this sprint, we all had an idea of what we were doing, but I felt like we did not use Gitlab or Discord effectively to plan or communicate as we could have. Another area that I think the team could improve on is appropriately allocating the amount of time it takes. I did the most the tasks during this sprint, however, all my tasks combined took less time than some of the issues that my teammates were working on despite their issues having the same amount allocated to them as any of my issues.

I also had a lot of room to improve as an individual. For example, I could have spent more time outside of class trying to understand the project. For the future, I’m going to put in way more time outside of class trying to make sure that I am prepared. Another area that I would like to see myself improve is coming up with as well as creating better issues. I thought that the tasks that I came up with and created were too repetitive and minor. For the next sprint, I want to create and work bigger, more relevant tasks. Other than that, I thought that this sprint went well, and I look forward to the next one.

List of issues that I worked on:

Issue Community#59: I created the Documentation repository

Issue Community#60: I moved files from general to the Documentation repository.

Issue backend#3: I created src/endpoints folder in the backend.

Issue backend#4: I created src/data folder in the backend.

Issue backend#5: I created src/lib folder in the backend.

Issue backend#6: I move items.js into src/data in the backend.

Issue backend#7: I move endpoints.js into src/endpoints in the backend.

Issue backend#8: I move config.js into src/lib in the backend.

Issue backend#9: I move database.js into src/lib in the backend.

Issue backend#10: I move logger.js into src/lib in the backend.

Issue checkoutguestfrontend#3: I created src/id-input-field/assets and src/id-input-field/components folder to aid with organization.

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

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.