Monthly Archives: April 2022

Sprint Retrospecitve Blog 2

We have made good progress in the second sprint, which was our objective to build on top of what we already did in the previous sprint. We have seen some results, but it could have been a lot better if we had changed some of the methods. 

  1. Plan in advance what to discuss for the future sprint discuss
  2. The detailed plans for every issue,
  3. Better communication in general 
  4. Think about the big picture 
  5. Break issues into small pieces
  6. Daily stand up to need to be more prepare
  7. Documentation needs to be clear and sample.
  8. How do we use time in class more efficiently 
  9. Go to detail and ask questions related to the issues and find the solutions. 

Since we’ve agreed that we need to improve what we do and how we do it, I’ve decided to narrow it down and be more specific about what we need to do to achieve the results we want. 

This sprint focused on the effectiveness of our abilities to work as a team. Since we already had a good idea about how we wanted our platform, we wanted to focus on the mechanisms of the way to work as a team. We had so much overlapped work between one another. For example, duplicates, comments, and misdirections to interpret others’ ideas caused a massive delay, which impacted us from making meaningful progress. Identifying the cause of the problem will help us prepare for the future. There is a list of the things that we think should be implemented to make the team more efficient. 

First, clarify the vision: You must first understand what you are trying to achieve before deciding how to solve a problem. Clarification is essential for teamwork to be successful. For this reason, we should write down our vision for each sprint. Detailing the issues will help us weigh the issues properly and break them down if necessary. We will be able to tell if the steps you’re taking will help us achieve our vision and if our problem-solving efforts were successful if we write down our vision. This step will be a great advantage in resolving the issues.

Second, Define the issue. Writing a vision statement gives everyone a basic understanding of what needs to be done. but it’s more concerned with what happens after the problem is solved than with the problem itself. That’s why it’s critical to write an issue statement that clearly defines the problem. We have seen issues that had nested issues, this should be a brief statement that describes the problem and explains why it is important to solve the problem. After all, how can we solve a problem if you don’t know what it is? 

Third, defying the context of the issues. Consider whether a business problem affects multiple individuals or functions within our project as a team, or if it only affects specific issue lines that we are working on. To be able to identify how to increase the performance of our work will help us to determine the best course of action. We felt that we need to better in this type of context. Learn how to write proper issues and better execution as a team.

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

Apprenticeship Pattern: Record What You Learn

The pattern I decided to read is titled “Record What You Learn” from chapter 5 of Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman by Dave Hoover and Adewale Oshineye. This pattern starts out by giving context of a situation I know I have found myself in multiple times. This situation is one where I am relearning the same technical lessons over and over again. The proposed solution to this problem is to keep a chronological record of the lessons I’ve learned. This record can be made in the format of a blog or wiki, to name a few options. Additionally, these kinds of records can be made public or private. Public records are good for building connections since others can read them and private records are good for being painfully honest with yourself about your progress. The last section of the solution ends on discussing how your record keeping tool can be an example of a Breakable Toy and how this Breakable Toy can help you extract lessons from it as one grows from a novice to a more experienced developer. The actionable item this excerpt ends with is encouraging its readers to start immediately because these entries can become the basis for books, magazines, and blog posts in the future.

In response to the question, “Will this pattern cause you to change the way you will work?”, my answer is a resounding yes. I’ve read this pattern multiple times before writing this blog post and have slowly been successfully developing my own personal journal/“Breakable toy”. I think one of the reasons why this has been so effective for me has to do with the following line I found interesting while reading this pattern, “The private record allows you to be painfully honest with yourself about the progress you are making”. In my journal, I get to reflect on how well I truly know certain technologies and what I still want to learn. And whenever I learn something new, I write about it in a way that is meaningful to me (as opposed to doing work for a class deadline). Therefore, I completely agree with the information in this pattern. It has been a super beneficial process for me so far and it is rewarding to physically see the evidence of what I’ve been learning in one localized place. I’m happy that if I have taken anything from this book, it is a journal/“Breakable Toy” I can continue using in my career and life.

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

Sprint #2 Retrospective

Issues Evidence

Issue:: backend: look at all lose files in backend/ and determine what is needed and keep them if so.

This issue was worked out in different layers. I wanted to be careful to maintain integrity while modifying the code.

https://gitlab.com/LibreFoodPantry/client-solutions/nest/guest-information-system/backend/-/issues/11

Issue:: backend: in source/data create .js files for methods to be used.

In this issue we have decided after reviewing the code from last semester’s software architecture class that we would reuse it because it served the purpose of the project. Much of the code had to be changed and reformatted to meet our needs.

https://gitlab.com/LibreFoodPantry/client-solutions/nest/guest-information-system/backend/-/issues/5

Issue:: backend: source/ figure out index.js

This file initialized the objects that are important for the operations across the various actions the backend is responsible for. My idea was to explore and find out more about the JavaScript syntax and methods and modules handling as well as behaviors.

https://gitlab.com/LibreFoodPantry/client-solutions/nest/guest-information-system/backend/-/issues/7

Issue:: all: setup semantic release.

This was commission by Dr. Wurst, my colleague Robin and I had already worked through the process of factoring the steps needed to set up the continuous integration GitLab environment. Even though the steps were clear, I took longer than expected some failures along the way actually helped me look deeper into the settings of the continuous integration environment and experiment on them to find out the innerworkings of GitLab’s continuous integration tool and its security.

https://gitlab.com/LibreFoodPantry/client-solutions/nest/guest-information-system/general-repository/-/issues/10

  •   Reflection on what worked well

In this sprint we tried to work out the issues we had on the first. The idea was to not repeat the mistakes already made and if mistakes were made, we would want them to at least be new ones. In that sense our sprint was successful we were able to identify and adjust expectations. One of the important things that we worked on was to be more specific on the issues and to delineate a better definition of done. In this sprint we were able to connect our different projects and also able to identify points where modifications need to be made in order to work properly.

  •   Reflection on what didn’t work well

Our team suffered from the short absence of some members due to personal unforeseen reasons. The team adapted and the absentee members put back in their missing share and we were able to still have our goals completed. We communicated well as a team but sometimes we would put in too much work leaving little to share. Thankfully the work done individually was hardly final and the trouble shooting, and integration made sure everyone had a part to play. We also had trouble with issue artifacts from the last spring. The names didn’t help us make much sense of what we needed then and moving them around got us a bit lost on planning for the last sprint.

  • Reflection on what changes could be made to improve as a team

To improve as a team, I think communication is definitely key. We should have more meetings outside class and maybe work on issues within these meetings. I see that sometimes we do work during class, but I think these one-on-one meetings would be better utilized for higher level organization, like adjusting tasks, trouble shooting, cleaning up the repo and other tasks. Reaching out is also a good idea if anyone is stuck. It not only helps the person trying to solve the problem but also whoever is there to help. It reinforces what they know and build confidence at the team level.

  •   Reflection on what changes could be made to improve as an individual

I personally think that I could have done more if I have not obsessed over an issue or another. I actually have found myself paralyzed by over planning. I have so many things to get done that organizing how to do them take longer than it is worth. I increasingly found that a generic schedule with cut off set times to switch from one activity to the next can help but a lot of times I freeze when stuck and enter a brute force infinite loop. This account for most of my wasted time that is when I believe that productivity not only flattens but drops so sharply that even if I moved forward, I still feel like I am stepping backwards. Shuffling tasks is truly the best way to succeed in not all but most so ill try to be better at that.  

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

Sprint 2 Retrospective

My team is about to move on to our third sprint, so I want to spend some time reflecting on how our second sprint went. Our plan for this sprint was to build a working demo of a Kubernetes cluster that we could deploy to AWS EKS. While we did not get everything done that we wanted, I am happy with the progress we made during this sprint. We got very close to deploying our cluster; the cluster is nearly set up, and AWS EKS has been configured for it. We are prepared to finish our demo at the beginning of our third sprint.

I think for this sprint, we had a much stronger idea about what we actually wanted to accomplish. Compared to our first sprint, this second sprint was much focused more on creating something than on research. It was easier to divide tasks into manageable issues, and it was clear what had to be completed with each issue. Not that the research we focused on wasn’t important, but it was satisfying to be able to apply that research to an actual demo.

In the same vein as the above discussion, having a more streamlined idea of what needed to get done did make it a little more difficult to work. A lot of the issues we decided on depended on the completion of others. It was difficult deciding which issues to take on individually; I felt bad doing nothing while waiting for whatever issues needed to be completed first got done, but in some cases it was necessary. As we complete our demo and move on to focus on communicating with other teams about our project, however, I think this will be less of an issue.

As a team, I think we could still improve our use of Gitlab for communication. I think we were definitely better about it during our second sprint, but our communication was largely remained on Discord, Zoom, or in person. It would be nice to have a more permanent record of our discussions, especially when those discussions are about the work we’re doing and the direction that work should be leading us.

As an individual, I want to take on more challenging work. The issues I worked on during this sprint were pretty simple, and two of the three of them were very easy to complete. I think it would be a better learning experience for myself if I tried to focus on more complicated issues. I also want to get better at communicating with my team. I think I should be talking more to my team members about my progress on whatever I am working on.

Contributions:

Add commitlint to gitlab-ci.yml to demo repository – I added a gitlab-ci.yml file to the repository that will host our demo.

Look into IAM Roles for EKS – In order to deploy a Kubernetes cluster to EKS, it (along with its nodes) must be assigned an IAM role. This post details the roles Amazon recommends using, and it has links to instructions on setting them up properly.

Determine what projects we are using for the demo – We decided to use a simplified version of a frontend/backend/API project for our demo.

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 2 Retrospective

Now for sprint 2, much has changed in which the direction, work, communication and more has changed from the previous sprint. There seems to be more communication and a better direction of where we are going and a more complete vision based on the project. There are still questions on what to do and where exactly we are going to end up by the end of the project but hopefully that can be figured out in to coming days. There is also the collaboration between other groups that need to be sorted out.

On what has worked well, we have made good progress on building the API and backend in that there are functioning pieces of code we can work with. The NestAPIMap Joe had obtained from the previous sprint had provided a good starting point for the sprint. The http calls are functioning as they should be and the overall structure of the project seems sound. There was a lot of functionality added to which the API and the backend actually works when previously we didn’t quite have much working at all which is nice. The changes made to the project are numerous and a good sign of work getting done.

On what has not worked well, there is still a feeling of misdirection as we are still new to this kind of work so it shouldn’t be surprising that this is happening. There are parts where people work on different parts on their own and later on do different things than intended in which other people who are working on the same issue don’t know that it has already been finished. The flow of issues from being worked on to done wasn’t quite as fluid as the last sprint as most of them just stayed in process section till the last day in which we sorted them out there.

We could improve as a team by communicating better on the work being done and what is free to do so that way the work could have been more evenly distributed. It felt like some people did more work than what was originally intended/different from what was thought of. There was a lack of usage of the issue board on GitLab which contributed to this problem and that it would be beneficial to have a better flow of finishing issues so that way we know better on what to do or not to do and that there isn’t a backlog of issues all waiting to be sorted until the last day.

I could improve as personally I was also part of the problem of communicating between others on what issues were being done and didn’t quite contribute as much as I could’ve to the project. I feel like I could’ve done quite a bit more contribution work to the backend with the calls and hopefully in the next sprint I dive into some issues and get more meaningful work done. There is the issue of all the other classes I am taking starting to reach their end so I will have to watch for that.

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

Sprint Retrospective #2

Now that the second  sprint of the Naturalization Interview Confidence Environment project has ended, it is time to yet again reflect on the progress that my team and myself as this sprint’s Scrum Master have made thus far. Moreover, it is also time to reflect on what went right on wrong during this sprint, both in regard to what we as a team decided to improve upon based on what we discussed during our first retrospective, as well as what new obstacles may have shown up during the second sprint. It is important to note that in this sprint, unlike the first, the team had a sense of direction as to what needed to be done. For comparison, during the first sprint we were more concerned with determining what development framework we would need to use for the project while in the second sprint we had somewhat begun the development process of the project as well as creating the infrastructure for development. Though some progress may have been made, this sprint did not prove to be as fruitful as the last.

In this sprint, we as a team had planned on working on 36 issues across 5 epics. Moreover, for this sprint, the main team was separated into two sub-groups with one working on creating the application itself while the other worked on creating the Docker development infrastructure needed for future development. The application development group, of which I was a part, was tasked with implementing the following functionalities:

as well as other functionalities that would be necessary, such as ways to navigate between the aforementioned functionalities. I was primarily tasked with implementing the reading portion of the application (as linked above), meaning I needed to implement the necessary functionality for a user to be able to see previews of the questions that are to be included in the application, as well as interact with each question separately. Though I was tasked to implement a specific functionality, I was still expected to help my teammates of the application team in the case they needed assistance with their own task, as well as provide support to the Docker infrastructure team.

          Though, admittedly, the breaks that occurred during the sprint contributed to hindering the structure of our productivity, as well as certain tasks taking much longer to work on than we had anticipated, there was still some progress regarding the infrastructure aspect of the project which continues to be worked on and improved by the responsible team members. Some problems that we had noticed in retrospect are mostly related to our management of time both during and outside meetings. As a scrum leader I still had issues managing our time during meetings such that there was a balance between allowing all team members to express themselves fully as well as using the meetings to outline what progress has been made and what progress needs to be made. Moreover, though we as a group acknowledged that documentation is extremely important, there was still lack of proper documentation and clarity in issues, which contributed to the improper time management of our meetings since there was more focus discussing what each new issue actually meant, thus meeting discussions wound up being somewhat disorganized. On a positive note, however, our approach of “Divide-and-conquer” from last sprint was crucial in helping the team establish who would do what tasks, either regarding the application or the infrastructure. Moreover, there has been substantial improvement regarding documenting what is being discussed during meetings, with certain issues having the appropriate context needed to ensure proper communication of our goals and progress between team members.

          As detailed above, while this sprint had its flaws regarding productivity and time management, there was still some progress made regarding development and infrastructure. While we all, as a team, acknowledge that some mistakes from the first sprint were still present in the second sprint, we are all still willing to learn from such mistakes and improve our own productivity and communication.

Direct links to issues:
1) Build a page that shows previews of the questions for the interview: https://gitlab.com/worcester/cs/naturalization-interview-confidence-environment/demo-react/-/issues/28
2) Learn how to use commitlint/conventional commits for the Application source code: https://gitlab.com/worcester/cs/naturalization-interview-confidence-environment/General/-/issues/13

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

Sprint Retrospective #2

For our second sprint, I think our group had a lot of ups and downs. At the start of the spring (before Spring Break), our group was very productive. Before break, we divided our group into two subgroups, three people working on the programming portion of the project (Sofia, Emmanuel, and I) and three people working on constructing a Docker container (Pernesso, Joao and Dylan). Early on, Dylan was able to get a Docker image and container working for our project. So, the Sprint was off to a strong start. During the last class before break, Sofia, Emmanuel, and I managed to break up the programming portion of the project into separate parts and assigned each part to a different person. So, each one of us knew what we had to work on over and after break. Some of us in the group had made plans to meet up over break using Discord to work on the project over break, but things came up and not everyone was able to meet. Sophia and I managed to work over Discord during break and I think we got a lot done. We did a mix between going over issues on our issue board and actually programming. For example, one of the issues I was going to work on over break was the Oath of Allegiance page and Personal Information page.

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

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

Originally, we had these issues as one issue which we decided did not really make sense because we were building two different screens. After an extensively discussion with Sophia, we also decided that the Personal Information page should go into our product backlog because if the purpose of our application was to just let people practice before taking the exam, then adding a Personal Information page does not really much to the functionality of our application. If the application was to simulate the exam, then adding a Personal Information page would make a lot more sense. So, we decided adding a Personal Information page was more of a luxury item that we could implement in a later Sprint if we have time. After our meet up, both Sophia and I documented what happened and our decisions on GitLab. So, in the beginning of the Sprint, we had decent documentation. It was what happened that everything kind of went south.

While I think our documentation was fine before and during break, I think documentation was one of the areas that fell apart the most after break. After we came back from break, we never followed up with one another on what we worked on during break or the week after break and so it was difficult to what was or wasn’t getting worked on or even what already done. Another issue that we had was we did not adjust the weights accordingly. When we initially made the issues in class before break, one of the things that we talked about was how for some of the issues, we did not know how to give it a weight because the issue may have been too broad, or we don’t know how to break up that specific issue. So, we were going to break some of those issues over time during the Sprint. This did not end up happening and our weights were off.

What I really to work on as an individual is working on a team. During this second sprint, I talked to my teammates a lot less than I did during the first Sprint. I just worked on the issues that I was assigned to and did not check in with anyone from the group unless I needed their feedback. For example, another issue that I worked during this Sprint was creating a UML diagram.

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

This was one of the few times I checked in with my group. I made two different diagrams. One simple diagram and one where I was trying something new and wanted my group’s feedback. So I feel like I need to work on checking in with my group more to see what they are working on and let them know what I am working on.

Another thing that I need to work on is writing issues as they come. Sometimes when I am working on an issue, I encounter more issues and I wait until the end of the sprint to put those issues on the issue board and forget about it until I talk to someone about it.

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.

“N.I.C.E” Sprint 2 Retrospective

During our second sprint we finally began setting up what we wanted for our application. We discussed the features that we wanted as well as how we wanted to be able to set up the environment for future students. What I was tasked with was trying to develop a docker container that would be able to run react and expo so that others would not need to require to download anything in order to run it. The docker team was not well versed with docker but we managed to figure out how to successfully create one. It was a lot of trial and error, but in the end, we overcame one of our weaknesses. The next order of business was then work with the React team to include all of their dependencies in the docker container so that everyone would have no trouble using their code.

The react team in parallel of the docker team was working on developing the features of the app that we wanted to include. They created the base of the cards with questions as well as the writing portion of the app. Unfortunately, the code provided by one of our referenced sources seemed to be unviable and the writing portion is being put aside for now. With that we are now putting our focus into creating the other portions of our application.

As a team we work well with trying to help one another succeed and adding on to one another’s ideas. Our communication is one of our strongest points as a group and it allows for us to express how we feel about areas we are weak in without the worry of any backlash. There were many times where some of us felt stuck in what we were doing, and we tried to help pick each other up.

One of the biggest issues we faced was not being able to create the proper issues that we needed to. We would have general ideas about what we wanted to do and how to do them but as a result of creating those issues, we would have other smaller issues that would pop up along the way. Although smaller issues would come up, we didn’t realize that we could add those to our issue board as well and it felt like we were not making much of a dent in the work that we wanted to do.

Individually I felt like I was a lost at times and did not know what to do. It was difficult working on things that I did not know much about and trying to teach myself was one of the hardest parts. Docker was one are where I felt as though I knew nothing but took it upon myself to try and learn what I was weakest at. It taught we that with time and hard work that I can achieve anything, but it would have been nice to have someone who was well versed to push me in the right direction because it would’ve saved a lot of time and I also wanted to help the other team as well. I also realized that I do like to work independently most of the time and that might take away from others learning and finding a cohesive solution together.

From the blog CS@Worcester – Life as a CS Student by Dylan Nguyen and used with permission of the author. All other rights reserved by the author.

Second Sprint Retrospective

Reflection on what worked well and didn’t work well
After having the Sprint Retrospective meeting with my group overall, I would say that the project is progressing very well. The workflow of the group was the same of how everyone worked by themselves and together. Both the frontend and backend development teams were able to make a lot of progress towards the project. Overall, we were able to get everything done besides a few minor things. We didn’t have any real issues in the programming itself. Towards the end, after looking back at what we did, we were able to see how we are able to make it easier to start the servers, which will be part of our next Sprint. From the last Sprint, we made too many branches, but we were able to clean up the branches and really became organized for the second sprint. The backend is pretty much all set besides integrating it with the frontend and possibly cleaning up the code so it may run even smoother.

Reflection on what changes could be made to improve as a team
The team worked pretty well. We still had everyone in their original development team. Those who were on the backend stayed on the backend and the same goes for the frontend. The backend team however started to run out of things to do so we would hop on over to the frontend to see what they may need help with and to give a different perspective. From how the meeting went, everyone was able to communicate any problems they had with one another, and no one was ever afraid to ask questions when they needed help. I mentioned this before but something the team could work better on is being vocal. This Sprint was much better because it seems that everyone was more comfortable with speaking up. During our daily meetings, they were much better because everyone was able to elaborate on what they did instead of “I did this”.

Reflection on what changes could be made to improve as an individual
From my perspective, the sprint went really well. I was able to do a lot more work this Sprint and even learn a little bit about how RabbitMQ works. I will attach the work I did on the project at the end with a description. I also worked alongside colleagues Jared and Vien to clean up the backend. At the same time, we were able to learn some new things and teach each other a little bit. Last Sprint I mentioned how I needed to be more active, and I can say with confidence that’s what I did this Sprint. I don’t think I have much to improve on than learning and improving my programming skills. It was a very successful Sprint in my opinion.  

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

Sprint 2 Retrospective Reflection

In this blog post, I will reflect on the second sprint of my capstone project. I will discuss what worked well, what didn’t work well, changes we can make to improve as a team, changes I can make to improve as an individual, and I will end by listing links to the work I have done with descriptions.

To start off discussing what worked well, one of our biggest accomplishments, if not our biggest accomplishment (in my opinion) was successfully creating a functioning docker image that we were all able to pull and use on our individual laptops. This was a big milestone for us because during sprint 1 we were running into compatibility issues and had no standardized way of creating and sharing code with one another.

For things that didn’t work that well, I would like to bring up something that was a common theme in our retrospective meeting: our lack of regularly documenting our work. I think this was something that we started off on the right track at the beginning of our sprint after having discussed this as an important thing to do in our first retrospective meeting. But with spring break, the week we had off from class, we fell back into the habit of doing work without documenting as we go along. Another thing I would like to mention for this category were the issues we created that started with “Learn to…”. By creating these kinds of issues, it made it difficult to deliver something tangible as it relates to our capstone project. While there was a lot that we learned, it should be represented in the future by applying our new knowledge in a practical way. Lastly, I would like to mention that although we had a functioning docker image to use, it has been incredibly slow to use while on campus/in class. There were classes where I felt like I was simply working on setting up my container just to shut it down by the time class was over.

In our retrospective meeting, one of the big things we discussed we could all improve on as a team is thoroughly knowing our issues board. As a team, we should constantly be reading, updating, asking clarifying questions, and breaking down issues into manageable steps. Part of me was afraid of touching issues that my peers created because I didn’t want to change their original idea, but it is exactly this collaborative process that is needed to create a productive sprint. Doing this clarifies the work at hand and prevents things like creating duplicate issues.

When it comes to changes that I can make to improve as an individual, my goal for sprint 3 is to use my class time more effectively. This last sprint has taught me that it is especially difficult for me to dive into my code when my peers are around me. Some of the best technical work I have done comes from me working in an independent, library-like environment. Because of this, I will focus on using daily standup meetings and my class time as an opportunity to get very comfortable with our issues board. If there are issues that require further details I can add them in class and if there are questions I need to ask my peers about issues they’ve created I can ask them in person. I believe making this small change will be more effective than spending my hour and fifteen minutes in class trying to code with intermittent distractions that may pertain to the capstone, but do not always pertain to what I’m coding.

Links to evidence of activity on GitLab with descriptions:

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