This first sprint could have went better but it is to be expected as it is the first time for most people to work like this. There group so far seems to have congealed well and can communicate well with each other. We were able to obtain the necessary information for helping build the project and now we should start to move at a faster pace to get the project done.

There hasn’t been much to critique so far since we haven’t quite starting working on coding yet but some of the issues that have come up so far would be with the way this group has been going . This process is still new to everybody so people are still taking the time of getting used to working on these different issues. There is the issue of the communication of the team so far. The way that the team is going to work isn’t quite clear and the path we are taking needs meeting time to figure out so that . The team could improve by communicating more with each other more, especially when the team tries to set up meetings outside of class and part of the team does not respond or does not make it clear if they are going to show up.

Then for me personally, I don’t think that I have made much of a considerable impact so far as the team just recently has the means to move forward with the project. I have contributed in discussions in the team and helped set up tools to use for the project later on. I could improve as an individual by contributing more in the discussions and think of more ideas on what we should be doing in the project. I also could have done more on GitLab as so far while most of the stuff added was nothing new and mostly mimicking what we have already done in the past, I probably could have taken the initiative to add some work into GitLab instead of another person doing it.

The majority of the time spent on the first sprint was getting our bearings together and figure out what exactly we were supposed to do in this sprint. At first, there were hopes of getting the API up and running by this first sprint ends but that was later put down due to confusion on what the specs and information was needed from other people. It took quite a bit of time to get this information as it was obtained at the end of the sprint which means that the coding will haver to wait until the 2nd sprint. There was also work that we had placed into the sprint backlog that should have been saved for later sprints as they required information and buildup that we did not have at the time. This fuss over issues like these had costed us time that could have been used elsewhere.

https://gitlab.com/LibreFoodPantry/client-solutions/nest/guest-information-system/sprint1-epics/-/commit/2645e65c3cc2c2346b808547cf71c41015d36f15
I added the tools necessary to the backend devcontainer and helped some team members on running the tools.

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

               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.