For our first sprint, I think our group did some things fairly well and had some things that we need to work on. From the first day of Sprint planning, our group got along very well and that made it easier for us to work together. We got straight to work on most days but there were also some days where we all got sidetracked for a while and needed to get railed back in. What I think worked well in the group was we were always asking questions. There were definitely points in the project where we were not sure about what were supposed to be doing and rather stumbling in the dark, we asked each other questions so that everyone in the group was up to speed and knew what to do and what was expected from each other and the project. Another thing that I think worked very well for the group was how open-minded everyone in the group was. We found out very early on in the project that most of us in the group had no experience working with mobile apps. Since we did not know where to start, we all decided to research what frameworks were out for creating apps. This led to the group creating separate issues for each of the frameworks (Ionic, Flutter, React Native). Even though some people in the group already had an inkling feeling that React Native would be the best fit for our project, we still decided to investigate all three frameworks to cover all of our bases. One thing that I think my group fairly well but also poorly was communication. When we were investigating the frameworks, our group of six broke up into three pairs. While we were in pairs, I think we did an okay job communicating with our partners. For example, when I was working on Flutter with Emmanuel, we forwarded resources to another one and let each other know our availability using Discord. So, we kept our partners well informed on what we were working on and when. This is where I think communication is something we need to work on during the next Sprint. Sometimes resources we forward to each through Discord do not end up on GitLab. Discord direct messages is not public information so there was sometimes no public record of what me and Emmanuel were working on. While I think we did a good job communicating with our partners, I think we could have done a better job informing the rest of the group as to what we were working on sometimes. I think as a group we did not do a very good job making sure everything that we did was documented and ended up on GitLab. This is something that I think we need to work on during the second sprint.

As an individual, I think I need to work getting more consistent results. I have a tendency of doing everything all at once so sometimes throughout the week, I don’t think I contribute a lot to the group or the project and then seemingly out of nowhere over the weekend I may contribute a lot to the group whether it be links to resources that I think would be valuable, comments on issues and/or code snippets to mini programs on what we were talking about in class. One thing that I need to work on in class and I am very aware of this issue, is I need to work on listening more to my group. When I work, I tend to become absorbed in my work and ignore the people around me. So, during the next sprint I think I need to work on knowing when to pause my work so that I do a better job listening to my group.  

From the blog CS@Worcester – Just a Guy Passing By by Eric Nguyen and used with permission of the author. All other rights reserved by the author.

My group for this sprint was team 3, and we worked on the FoodKeeper for LibreFoodPantry, and at the end of our first sprint, we have made a pretty good amount of progress. A lot of work has been done to the API for its schemas, paths, and responses, and we have done some work on the backend too with its endpoints.

We have worked well as a team so far by staying communicated with each other and everyone had a roughly even amount of weight and work. We were assigning issues to different people and learned quickly not to have multiple issues assigned to a person at a time because the work would be unbalanced and/or other people would be left without things to do. Each person had an issue either done or mostly done by the next meeting, and they had their next issue assigned after resolving any problems. Everyone was involved in the in person discussions.

Our main area of improvement is communication on gitlab, because for our first sprint, the majority of our discussions were in person or on discord. Because of this, there was not much discussion on gitlab in the comments of epics, issues, and merge requests. This can make it look like we are not having these discussions when people look at the project and go through the work done for it because they can’t see our discussions on discord or in person, so we will using gitlab for our discussions and questions more often. The two other areas that were talked about were how we handled our standup meetings and merge requests. Our stand up meetings would go a little longer than intended because we would have minor discussions when talking about what was worked on, and we agreed to wait until everyone talked about what they did, what they plan to do, and what is stopping them, before we go into our questions and discussion. With our merge requests, we thought it would be a good idea for a few people to check and approve requests before the meetings, so less time is used on reviewing the requests.

As an individual, I think I was doing a good job on the issues I worked on, and I was involved in the in person discussions. However, I was not talking that much on discord because I wanted to wait until I was in person with the group to ask any questions I had. We are focusing more on having discussions on gitlab instead of discord, so I want to be more involved on there than I was on discord for the next sprint.

Gitlab links :

https://gitlab.com/LibreFoodPantry/common-services/foodkeeper/foodkeeperapi/-/merge_requests/13

The schema for modelandview, I originally made it as a .js file and had to change it to a .yaml file.

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

The paths for the category object that includes getAllCategories.yaml and getCategoryID.yaml.

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

The endpoints for the category object that include getAllCategories.js and getCategoryID.yaml.

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

The product endpoints that includes getAllProducts.js, getProductWithID.js, getProductIDName.js, and getProductCategoryID.js.

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

https://gitlab.com/LibreFoodPantry/common-services/foodkeeper/foodkeeperapi/-/blob/main/src/paths/index.yaml

The index.yaml file that covers the paths for the api, the put methods from the first request were meant to be get methods, which has been fixed in the file itself.

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

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.