Category Archives: Sprint-1

If At First You Don’t Succeed… Sprint, Sprint Again! (Sprint 1 Retrospective)

INTRODUCTION: Looking back on this sprint, I can say that our group has performed quite well. better than expected, honestly. Perhaps I have an irrational fear of “events always going haywire”, but at least this phobia keeps me well aware of the situation (“on my toes”, you might say).

Considering the activity found on our group’s gitlab project, we can see that this sprint has consisted mainly of research write-ups, alongside some minor work for the frontend, backend and API of the IAMS.

POSITIVE FACTORS: Here are some factors of the sprint that I believe went well:

  • Our group had satisfactory distribution of work.
  • The group was able to present a “proof of concept” demo that met specifications for the current sprint. Examples include a basic frontend/backend/API system.
  • A lot of research was done during this sprint; our group was able to learn a bit about Kubernetes, VUE, Node.js and other software that is crucial for the IAMS.
  • Keycloak has not been set up, but a plan has been made to get it running by the end of the second sprint.

NEGATIVE FACTORS: Here are some factors that I believe can be worked upon:

  • The group seemed to struggle with suggestion a proper amount of weight for each issue. Specifically, we seemed to “underestimate” the difficulty of certain issues (such as setting up a Kubernetes distribution). In short, the group often weighted issues as easier than they actually were.
  • I feel as though having “more concentrated roles” within the team would be beneficial. While we had two teams (coding and research) led by a scrum master, I feel as though we can have “individual” roles. Applying roles such as “Quality Assurance”, “Presentation Director” and “Merge Coordinator” would help make a better team.

TEAM IMRPOVEMENT SUGGESTIONS: In order for the team to improve, some suggestions that I would improvise include:

  • More communication. While our group had used discord and gitlab to an impressive extent, I feel as though there can always be improvement. Additional communication can give us a better idea of our current position in the project, as well as create solutions for the next steps forward.
  • Enforcing the “Scrum Structure” more properly. This is an extension of the previous criticism (“More Communication”). In addition to standup meetings, the group should be engaging in a “Daily Scrum” meeting every day, (regardless of class)

SOLO IMPROVEMENT SUGGESTIONS: Personally, I feel as though my team worked spectacularly. If anything, I believe that I was the worst one on my team (following the Apprenticeship Pattern: “Be the Worst”). In order to improve upon my own performance, I believe that I should look at the following shortcomings:

  • Dedicate more time to the work. Unfortunately, while I am busy with other factors (such as work, other classes, and so on), this is not an excuse. This project is meant to be treated as though it is a paid job; the performance delivered should reflect a similar quality.
  • I would also like to reach out to LibreFoodPantry staff, as well as other groups, more often. Communication and cooperation are key factors to creating this massive project; each group creates their “piece of the puzzle”, and then it will all be fit together towards the end.
  • Finally, having a greater understanding of my role (such as “Coder”, “Quality Assurance”, and so on) would be crucial to future work. As of this sprint, I seemed to dabble on various topics without concentrating on anything in particular; this can lead to messy, unfinished work.

Most importantly, I would like to point out that this retrospective blog was posted late (it was meant to be done before the start of Sprint 2). This, in itself, is an error that needs to be rectified in future sprints – timeliness and containing work within the sprints is essential in order to keep the project from falling apart. It’s okay if work carries over to another sprint, but that usually needs to be planned from the get-go.

All in all, the first sprint never goes perfect. No matter how hard one tries to make it go right, something always goes wrong. The point of this lesson (and by extension, this class) is to ensure that we look back on these errors; we then perform research on them so we can modify our work habits. All of this is done to ensure that the mistakes don’t occur again in future sprints. As I look forward, I will do my best to enforce these new policies.

From the blog CS@Worcester – mpekim.code by Mike Morley (mpekim) and used with permission of the author. All other rights reserved by the author.

Sprint Retrospective 1

To be honest, I think this first round of figuring everything out went as well as it could have. To start with what could be improved, I’d definitely have to say our team should establish much more concrete issues to deal with the specifics of what we prioritize for getting done. While we certainly got the gist of it as we were progressing, I was feeling quite lost in organizing epics and issues to be more to the point. A second thing that I specifically didn’t do well with was communication with the team. While in class we had no problems (in my opinion) and we get along quite well, but out of class I am egregiously bad at keeping up with messages. Thankfully, I don’t think it interfered too much with the work flow, but it certainly remains an important thing I have to remedy as I owe it to my teammates. In addition, I think the Scrum Master position was a little up in the air, as most of us were looking at each other for help with direction in our sprint. As a result, we all sort of pitched in where we could, and hopefully in coming sprints the role will solidify into a more acute position with specific responsibilities.

As for what went well, I think the team’s communication was much better than I was expecting. In some areas there was a bit of tension when it came to explaining a concept, or deciding what should get done first, but it was amicably resolved with no real issues. I personally enjoy working with everyone in the team, as everyone was ready to come to the table and pitch in. The only area of improvement I can really pinpoint is staying in contact with what each of us may be specifically working on at the moment. At one point me and a team member began to overlap what we were working on, which went on for a little longer than it needed to.  However, I don’t have much to say on this, as I think on the whole it went smoothly. The things that might need to improve I believe will just come with time as we continue to work on the project. 

As for myself, I think some members may not like me as much, as my participation could for sure improve, but that’s neither here nor there; I only say that to remind myself I need to be better. Another place I may need improvement in is with my explanations. I can be quite ramble-y with some assumptions about what others may believe, or already know. I don’t think in a condescending way, but only insofar that the gap in understanding of communication doesn’t help me to get my point across.  

As for some of my contributions, they are as follows:

https://gitlab.com/LibreFoodPantry/client-solutions/nest/guest-information-system/api/-/commit/8303274a7264a636ee71a2bc10ae57e4578b6806

Here is when I added a few schemas to the API repository.

https://gitlab.com/LibreFoodPantry/client-solutions/nest/guest-information-system/api/-/commit/9fe22f78eaa34a46c3cb32eedb7080bfe33b9bd5

https://gitlab.com/LibreFoodPantry/client-solutions/nest/guest-information-system/api/-/commit/71d797e318075cba6f1ded1bb31ceb0c4fcb7dd5

Here are a couple examples of when I added some basic files to get the API repository updated; I believe there are about 12 similar creations of basic files, but it would be repetitive to include them.

https://gitlab.com/LibreFoodPantry/client-solutions/nest/guest-information-system/api/-/commit/9412a5433a4e8adb9f617d0f892e5a879d1b2455

And finally, here’s an example of me updating a basic attribute file in the repository.

From the blog CS@worcester – Dummies that Code by howbrash and used with permission of the author. All other rights reserved by the author.

Sprint 1 Retrospective Blog Post

This sprint I feel we all did pretty well all around, and were able to accomplish almost all of what we set out to do. The workload felt very balanced throughout the sprint, not too heavy, but not too light either. My contributions to the sprint were adding files to our Documentation Repository, researched Ingress & Gateway, & researched RabbitMQ.

https://gitlab.com/LibreFoodPantry/common-services/aws-deployment/general/-/issues/3

https://gitlab.com/LibreFoodPantry/common-services/aws-deployment/documentation

The above links will take you to the issue to add the files to the repository, along with the repository with the files added to it.

https://gitlab.com/LibreFoodPantry/common-services/aws-deployment/general/-/issues/11

Here is the issue to research Gateway & Ingress, what they do and how we can take advantage of them.

https://gitlab.com/LibreFoodPantry/common-services/aws-deployment/general/-/issues/5

Lastly, I researched RabbitMQ and what it does and how we could use it.

I cannot think of much to add with regards to change, maybe add a bit more detail to my research posts, but otherwise I think everything was solid.

From the blog CS@Worcester – Erockwood Blog by erockwood and used with permission of the author. All other rights reserved by the author.

Sprint 1 Retrospective

For our first sprint, our goal was to familiarize ourselves with the different components of a system that we need to work with and that we don’t know. Most of the issues present in our first sprint dealt with researching these aforementioned components, for instance, RabbitMQ, EKS, and Kubernetes. As such, most of our issues were researching the anatomy of what we’d be working with via AWS EKS. I believe our main difficulty was determining what we needed to research, and what was useful or not.

To get what did not work best out of the way first, some team members, myself included, missed the deadline on some of the issues. In my case, this was due to the fact that we are unfamiliar with much of what we’re researching, thus, the issue I dealt that I’m referencing with was denser than I expected it to be because it’s difficult to project precisely how long each issue would take, or if we need to split it up into several smaller issues1. 

What worked well was our team’s communication with each other in class, and in some of the issues. It took a few classes to warm up to each other. I think the descriptions and how we formatted our research also worked well. In general, we used markdown to break down our research into more digestible sections that made it easier to understand2. Another thing I thought worked well was the description of what we may be looking for in the issue descriptions. While difficult to be too specific, it helped as a starting point for the other team members to begin once they finally started on the issue3. 

As an individual, I think I could improve on meeting issue deadlines in a more timely manner. While I mentioned earlier that the issue was denser than I thought it would be, I also should’ve managed my time better, and started working on this earlier to fully understand the time it would take, so that I might’ve been able to mention it in the next class. I also think that I should’ve talked more through the GitLab Issues / Epics rather than other means. While I did communicate using the aforementioned means, it may be better to discuss more, especially as our future sprints will more than likely demand it.

As a team, I think we should institute a better application of rules throughout the issues. While writing this, I realized the issues implement markdown format differently than others4 5. I don’t think this is a big deal, but it may be better to implement some form of standard across the issues. I also think that we may need to communicate a little more via the GitLab Issues / Epics. In this first sprint, most of the issues were independent research that usually didn’t cross over into other issues very much, hence there was little need for communication between team members. However, given that the second and third sprints will involve deployment, it is both required and vital that we communicate on GitLab.

Evidence:

  1. https://gitlab.com/LibreFoodPantry/common-services/aws-deployment/general/-/issues/13#note_848604859 – A note left by me explaining why it took extra time.
  1. https://gitlab.com/LibreFoodPantry/common-services/aws-deployment/general/-/issues/14 – An example of research using markdown to partition the different parts of research as mentioned above.
  1. https://gitlab.com/LibreFoodPantry/common-services/aws-deployment/general/-/issues/4 – Example of an issue’s description that includes a brief description and several points of interest.
  1. https://gitlab.com/LibreFoodPantry/common-services/aws-deployment/general/-/issues/11 – An issue description using spacing to separate sections.

5. https://gitlab.com/LibreFoodPantry/common-services/aws-deployment/general/-/issues/15 – An issue using titles in markdown to separate sections.

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

Sprint 1 Retrospective

As my team moves on to our second sprint, I am reflecting on our progress so far. Our project, deploying LibreFoodPantry to AWS EKS, is new this semester. My group is essentially starting from scratch. As such, we spent most of our first sprint researching and compiling information about AWS EKS, Kubernetes, and other relevant tools.

Overall, I think my group did a very good job during our first sprint. Since it was mostly research, I think it was easy for our team to excel. We were able to complete all of the work we had laid out at the beginning of the sprint and now have a better idea of where our second sprint will lead. Everyone was very efficient and got their work done in a reasonable time. It felt like everyone was doing an equal amount of work; it didn’t feel like one person was doing the bulk of it. We all worked well together and were able to communicate when we needed to.

My team did struggle initially trying to break down the work we needed to do into smaller issues, and I can see this may be a problem going forward. No one on our team has extensive experience with AWS EKS, so it can be hard to tell what needs to be done and what is worth researching. I think this will get easier as we become more familiar with our project and how we want it to progress. But this did make it difficult to plan our first sprint.

Something I think my team could improve upon is communication, especially on Gitlab. Most of our conversations about our project were held either on Discord or in person. This sometimes makes it difficult to review what we had talked about afterward, and I imagine it will make it difficult for the group that takes over this project next to understand what we did. It would probably be more useful to have these conversations in the comments of a relevant Gitlab issue.

In addition to communicating more on Gitlab, something I feel that I personally could improve on is time management. I was still able to get my work done in a timely manner, I would not plan out my time well. I am not good at predicting how long a task will take me to complete. I would underestimate how much time a task would take and leave it until the last minute, or I would overestimate the amount of time it would take and wind up with nothing left to do. I want to plan my time more efficiently for the next sprint.

Contributions:

Look into how to set up AWS access for us – I worked on this issue to get our team access to an AWS account so that we could start learning the tool.

Research AWS EKS – This issue provides a set of resources for someone looking to familiarize themself broadly with AWS EKS.

Research and report best practices for Kubernetes – This is a listing of some best practices to keep in mind as our team begins to work with Kubernetes.

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

Sprint 1 Retrospective

The first sprint for Software development capstone class was believed to a successful event. Our objective was based upon the epics given to us and broken down to smaller issues to tackle the epics. Our team’s goal is to create new repositories for the backend and API. The nature of this sprint was to make sure the backend and API were setup with their schemas, endpoints, and dev containers to be running toward our next sprint we going to formulate.  Throughout the sprint we did a successful job at setting up the infrastructure and revisiting the previous semester assignment from Software architecture was a major help to us to progress at a steady rate.

There were some issues that our team that we came across our sprint that we struggled and affected our productivity and time management. First, whenever we conduct our standup meetings, we tend to get sidetracked and off topic, one person over speaks another person and bot waited till the end of the meeting thus making us waste our meetings and lose track of time. Second, as we learn more on GitLab and its functions we had many problems with repositories and understanding the merge requests as well as its purpose. The team was stuck upon making the appropriate comments to make a record of what we have discussed during the standup meetings or in general if needed for the next team to look through. Third, making unnecessary repositories, this is what we really struggled with because once we were working the API and we made a repository to accommodate each issue we had, sometimes we accidently work on each other repositories and created a workflow mess and had to revert the commit we made to detangle the situations that occurred.

To be sure we don’t have these issues reoccur, we had made an understand on the major conflicts we have faced to be squashed towards our future sprints. We agreed that for our standup meetings is to be respectful and allow the person to finish speaking their side and wait for all questions till we are finished. To make our own repositories in general to reduce confusion when we are working on our own issues and committing them to the correct repositories. Applying up to date comments in the issues we create and after our discussions to keep a record. 

Other than my team’s performance, there are improvements I want to make towards myself. When I was making one of the schemas for the API repositories, I had trouble on making one myself and had to ask a teammate and do research on a detailed explanation of it and to compose one. An issue like this one could’ve been done in a class period, but it took me two because of it. Backend is a weak point for me and to squash this fear is to resort to the previous classwork and material. As well as do massive amounts of online research to completely understand how to about be implementing the backend which is required for the next two sprints. Another improvement I can make is that for the issues I create are too broad and vague to understand, had some of them revised to be more meaningful. 

Sprint 1 Issues

From the blog cs@worcester – Dahwal Dev by Dahwal Charles and used with permission of the author. All other rights reserved by the author.

Sprint Retrospective 1

The AWS deployment project was very surprising to me as it was not among my first choices. But with time, I am very confident with the evolution of the project and what the final product will look like. The god thing about our project is that we are all learning what to do. There is no sense of feeling behind or being ahead of others in the team as we are all new to most areas of the project. I believe this has allowed our team to be very open minded to any idea and to accept each other’s participation without any previous knowledge of what could be wrong or right. I appreciate the team workflow in the project and the trust we had in one another to get things done. The professor has been a great source of reassurance when we had couple of blockages (especially with the AWS) website. I believe that the accesses we have been given so far will be enough to get us started however, having worked with AWS website before, knowing how complex it can be, we might always need something more. Overall, we are a great team, out scrum master did a great job keeping the team together and maintaining respect and work ethics.

Improvements as a team

I have always been skeptical when it comes to working as a team. The reservations and worries about whether the work will get done, whether everyone will be involved, and the quality of the work reflected on our grades has been inevitable for me in the past. However, in this class, I feel very confident in the way we work as team and the way the professor assists us regularly to make sure we are involved and progressing. During our first sprint, we needed to make a lot of research to familiarize ourselves with the project. We didn’t find the need to meet outside of our stand-up meetings. That resulted in us not really communicating on the discord server, or any other platform outside of the classroom. In the future, as we will get more in depth in our project, I expect to improve this area and communicate more outside class for better planning and understanding among the team.

Improvements as an individual

As an Individual, I believe I did a good job on providing ideas, communicating with the entire team. I believe I specifically played the role of the reflector. The scrum master did a great job, but I was always willing to keep everyone on track when it was necessary. One area I could work on in the future is help improving the efficiency of our stand-up meetings. I noticed that my team is a quiet team which is not necessarily a bad thing. However, more common, and altogether conversations and unified ideas can be a good thing for the development of our team. Another thing I am planning on focusing more on the future is provide more in-depth reports on GitLab of the research we make. Our project is definitely a very interesting one and it would be great to share as many details as possible. The third area of improvement is to merge with the Identity and Access Management System(IAM) team regarding our project. We know for sure that keycloak will be a crucial part in our project. Meeting regularly with the IAM team to work together will make it easier for the two teams to move faster and not slow down each other on other things we could separately work on.

Evidence of GitLab activities

I did add the files in the General repository

https://gitlab.com/LibreFoodPantry/common-services/aws-deployment/general/-/issues/1

I did make research on Keycloak and worked a little bit with the IAM team. Keycloak is an open-source software product to allow single sign-on with Identity and Access Management aimed at modern applications and services. It helps securing applications. It is a reliable tool to help manage users identity and accesses.

https://gitlab.com/LibreFoodPantry/common-services/aws-deployment/general/-/issues/10

I did the Research on the best practices regarding the AWS EKS. Some of the best and important practices are the security, reliability, cluster autoscaling and running containers.

https://gitlab.com/LibreFoodPantry/common-services/aws-deployment/general/-/issues/8

From the blog CS@Worcester – Software Intellect by rkitenge91 and used with permission of the author. All other rights reserved by the author.

Sprint 1 – Retrospective.

What worked well

As a team: 

We did a good job reviewing each other’s work. Merge requests were approved pretty quickly and we did a good job jumping in to help as soon as there was an issue.

Most of us did not remember scrum techniques and rules at first. However, we managed to catch up and follow the “rules”. We kept up with standup meetings and updating the scrum board. I also appreciated how every team member effectively reported on their work regardless of its state (in-progress, done, needs review, not-progressing,…)

Personally:

I think I did a good job being the scrum master. I had to brush up on scrum concepts a little bit but after that it went smoothly. I led all the standup meetings and took important notes for the group whenever we discussed our tasks.

As far as the project went, I worked on moving the api to its own repository. It was pretty straightforward. I created the folders and sub-folders and filled them up. I referred to the API repo we used last semester for the Microservices examples. I then added two JSON packages, some documentation and a development container.

What didn’t work well

As a team:

The biggest struggle we had was figuring out meaningful issues for our epics. We started off with not enough issues but then ended up adjusting the weights to reach the appropriate weights. At the end of the sprint, we realized that we actually underestimated the weights for a couple issues because we did a lot of “figuring out”, researching and that took some time that was not reflect in the board of issues.

Personally:

I feel like I could have done a better job looking at issues other than mines. I was so focused on doing the API that I didn’t have the time to look inside backend and the 3 front ends to sort of have an idea of what the others were doing. Consequently, at certain stand-up meetings, I would hear team members talk about specific blocks in the issues, but would have no idea what they were referring to. Another issue I had was with the GitLab pipeline failing in the API inventory. 

Changes to be made

As a team:

As a team, we need to do a better job creating issues. We also need to add more communication, discussion, and recording of decisions taking place under the GitLab issues and epics. We are looking forward to this sprint because we will most likely all work on the backend for a while so there will hopefully be a lot more to communicate on GitLab

Personally:

I will make an effort to look over the issues that are not assigned to me. I will also be a little more prompt to approve merge requests. I barely approved any last sprint and I want to make sure I review some of my teammates’ work because it will help me be in touch with how the project is going.  

Links to some issues:

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/backend/-/issues/1

Create structure of API Directory

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/backend/-/issues/12

Split openapi.yaml into paths folder

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/backend/-/issues/14

Create schema folder and add content from openapi.yaml

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/community/-/issues/64

Add hrefs to API directory

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

Sprint Retro 1

With the end of our groups first Sprint, overall, I would say we did well as a team. This being the first time any of us were in a group, scrum team, working with Kanban boards, etc. With my group I gave them some reading material on roles/responsibilities of a scrum teams and scrum master. I figured with extra material; we will be able to create a solid plan for this Sprint. For this Sprint, I think we were a little everywhere in the beginning but were able to finally divide the tickets in the backlog with each member taking on 5 per sprint. We were able to get many of the tickets done and then go over what we had done or any impediments that we me have.

I was responsible for the following task:

Create “General” repository: The General repository needed the .gitattributes, CODE_OF_CONDUCT.md, DCO.txt, LICENSE.md, LICENSE_FOR_CONTENT.md, and README.md filles needed to be added. I went ahead and transfer all files over to the Guest Information Systems.

Create “Documentation” repository: The Documentation repository needed the .gitattributes, CODE_OF_CONDUCT.md, DCO.txt, LICENSE.md, LICENSE_FOR_CONTENT.md, and README.md filles needed to be added. I went ahead and transfer all files over to the Guest Information Systems.

check the database format to create our schema: Upon reviewing this task both my teammate Joe and I found that this task was completed before we realized that it wasn’t necessary. The correct tables that we needed are now documented in the documentation repository.

Contact the IAM team to determine security key format: This task was a joint task between myself and Jefferson. We contacted the IAM team, and we are currently waiting on the security key. We will keep open communication with IAM to further pursue future task. We met with Dr. Burdge and determined the two (2) tables and eight (8) API calls we will need for building the API yaml bundle. Currently, that is the only impediment that we are facing.

Study Nest api calls to define our own: RestAPI contained the tables that FoodKeeper needs to implement. After further investigation and the completion of the previous task of contacting IAM team, we were able to determine the correct tables needed. We also developed a plantuml file showing the 8 tables, and created a yaml bundle for the product table, but are now deprecated.

During this Sprint, we really were trying to get to know one another to get a feel of each other’s work ethic. However, we still were not able to showcase each other’s skills or strengths. A good majority of the tickets we had were coping and pasting things over or information gathering. Now, these tickets were and are essential for our next Sprint where we will be able to do actual coding. I think there we will be able to see our strengths and weakness as an individual and as a group to then grow from there.

I think going forward to the next Sprint, we will need more leadership and what we need to get done and keeping a timeframe on that. This past Sprint just felt unorganized, not everyone was being heard and just not as conducive as it should have been. Also, I think clarity from all members of the group is also helpful. Having some members not knowing what is going on can lead to the team not completing their task.

As for personal improvement, I think for me I need to give more input on what we should do as a team. I also think I will take on harder task to help the team move along, with assistance from other members as well. I think working more in a team dynamic to help each other out and complete task in a more sufficient and timely manner. 

From the blog CS@Worcester – The Dive by gonzalezwsu22 and used with permission of the author. All other rights reserved by the author.

Sprint 1 RetroSpective

Working in a SCRUM team has proven to be a task to say the least. For our first sprint, I was our team’s assigned SCRUM master. Our project? To create a mobile application that runs on android and apple devices to help aspiring U.S. citizens prepare for their citizenship exam. Our project was the only one out of the 8 that had no prior work done before it was assigned to us… aka we were starting from scratch.

The Bad

Before this semester, I wasn’t a stranger to working in a team to complete a project. Despite this fact, working in a SCRUM team felt a bit different. Collectively, we were working together as a team but at the same time we were working independently. At points during this sprint, there were times where we didn’t have great communication. A lot of the same questions kept reemerging after they had already been answered. I feel like we were slower to realize how important effective communication and active listening is. While we did conduct our daily standups, I feel like we only did them for ritual’s sake. Also, I felt the sense of everyone wanting to take the project in different directions because it reflected in how we had our conversations.

The Good

Although I had feelings of stagnation within our team, I do not fault anyone in the group because developing an application while beginning to learn many new things about getting it started is a lot, especially since it’s everyone’s first time. This feeling of stagnation is everything but. Our team’s progress had never stopped moving forward, even if it was moving slowly and that is an amazing display of my teammates willingness to finding solutions in new and unfamiliar territory. During our retrospective meeting we all came to realize that we got all the essential tasks for Sprint 1 project setup completed. I am also hopeful because I feel like my teammates are going to be great to work with once we all learn how to work with one another.

Improvements?

I think as a team we need to put more value into the daily standup meetings. Although they’re short in comparison to the work we’re doing during the rest of our meetings, they are super important in terms of our success. Making sure that everyone is active in the meeting whether speaking or listening is something we can improve upon. Another improvement we can make is being comfortable with having our ideas challenged. Instead of just blindly agreeing with an idea one of us has, we should be able to hold respectable debates on why something may not be great for our project and be alright with the outcomes of the debate.

How Did I Contribute?

Much of the early part of the sprint was dedicated to figuring out which framework we would use to create our application. We broke into three teams of two. Eric and I were assigned to investigate what the Flutter framework would bring in its arsenal to help us complete our project. A few of the things I spent my time researching include:

  • Learning about what type of application Flutter is.

https://gitlab.com/worcester/cs/naturalization-interview-confidence-environment/demo-react/-/issues/6

  • Creating a sample “Hello World” -like application in Flutter.

https://gitlab.com/worcester/cs/naturalization-interview-confidence-environment/General/-/issues/2

  • Making the decision to install Flutter locally on our system or use docker containers.

https://gitlab.com/worcester/cs/naturalization-interview-confidence-environment/General/-/issues/2

Once we decided that Flutter was not going to be the route we were going to take, I used the rest of my time during the sprint to work on the writing portion of our application.

https://gitlab.com/worcester/cs/naturalization-interview-confidence-environment/demo-react/-/issues/18

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