Retrospective 3

It’s time for this project’s last sprint retrospective. At the end of the last sprint, I had started implementing our needed endpoints for our API and had rough versions working. So, my first focus for this sprint was getting the API working [link]. Our definition of done requires testing for an issue to be considered done. Thus, I made learning how to automate tests for the API a priority [link]. I ended up finding automated testing through Postman and it’s CLI. Using the Postman IDE, I started writing tests for our endpoints [link] and this allowed me to become better acquainted with how endpoints should behave. Postman’s built in test system made creating the tests relatively simple, as it supplies common test code snippets to use. The tests I wrote check for correct response status, response time to be under 200 milliseconds, request has content type header, and returned data. At this point, the work on the backend was nearly done and was awaiting review.

While the API server was under review, I started working on learning Docker. [link] Since I had worked mostly on the backend, I started with getting the server containerized. Once I had the dockerfile written for the server, I then had to figure out how to use docker-compose to link the database and server in containers. [link] Then I started to split my attention between fixing up the server, writing docker configuration for the backend, and reviewing work.

Most of the backend work was writing up documentation. Our team had a dockerfile written for our frontend, so I started writing a compose file for the entire module. This worked well except I could not figure out how to obtain the backend container IP for the frontend. I have since found it has something to do with the nginx proxy we used in our frontend dockerfile.

Once the planned work for the backend was done, I had some time to address the additional requested endpoints from another team. [link] After completing the endpoints, I reviewed work and assisted where I could. The final issue I worked on was implementing the endpoints in the frontend. [link] This was a last-minute scramble that started a day before review. Thankfully, the entire team came together, and we were able to get the reactive forms implemented and connect their data with the endpoint call before the review.

When this sprint was first being started, our team had a heavy workload if we were to finish everything we had planned. Considering this and the additional unplanned work, our team performed quite well. We communicated better and more often. Our individual work had started to heavily overlap each other’s. I believe this led to increased team cohesion. I, however, had a minor problem with our backend endpoints issue. Since our definition of done required testing, this issue required two other issues to be completed before or with it that had not been started. This only affected my estimation of work-to-time ratio, and I do not believe it added extra work. Overall, I am quite satisfied with my team’s accomplishments and all we were able to complete.

From the blog CS@Worcester – D’s Comp Sci Blog by dlivengood and used with permission of the author. All other rights reserved by the author.

Sprint 3 Retrospective

I think Sprint 3 was the most effective sprint of the semester. I think the success of this sprint was largely due to the team improving our GitLab use and our communication with each other. Unlike the last sprint, the new issues we put on our board for this sprint were specific and clearly defined. Most of the new issues were created with a new template that included sections about how the issue would be worked on and what would be produced as a result. This made it much easier to understand what needed to be done, helping us make more progress. I also think we were more open to communicating with each other, both during our meetings and while working separately. We spent more time in our meetings answering each other’s questions and sharing our progress, which personally helped give me a better understanding of things that confused me as well as the overall state of the project. We were also more active on GitLab outside of our meetings. Every team member participated frequently in discussions on issues and merge requests, which helped us complete issues and merge changes efficiently.

Although this sprint was very effective overall, we still faced a few problems. I think the main troubles we encountered were coordination and time management. Although we were all more active on GitLab, we didn’t know exactly when our teammates would be active or what they would be working on. In my personal experience, this made it difficult to make progress sometimes. Whenever I needed input from a teammate, I would simply wait to ask them in the next meeting because I didn’t know if they would be available to discuss on GitLab. I think coordination issues such as this led to problems with time management. Since our progress was slower than it could have been, we ended up having many issues left unfinished in the last couple of days of the sprint. We did arrange a last-minute meeting to work on these issues, which I thought was effective, but if we had managed our time better this would not have been necessary.

To improve as a team, I think we could’ve focused on our time management. This would’ve been difficult, since we all had different schedules and other classes to work on, but there are a few small changes I think we could have made to make coordination easier. First, we might have tried setting due dates on issues. I think this could have helped us manage time better to avoid having issues pile up at the end. It may have also increased collaboration outside of meetings by encouraging multiple team members to work on each issue at once. Also, I think we could have tried having more meetings outside of class. These would’ve been difficult to arrange because of our different schedules and may not have been necessary, but the one we had this sprint was extremely helpful. I think trying to have more meetings where we work together on issues would have helped the team get more done.

To improve as an individual, I think I should continue to work on my communication and participation. As I mentioned earlier, I frequently avoided commenting on GitLab, mainly because I didn’t want to disturb anyone when they weren’t available. This caused me to miss out on important discussions, such as those that took place during planning and on certain merge requests. I started making an effort to participate more during the end of the sprint, but I still found it difficult to do so as my other classes demanded my time and drained my motivation. If I am able to participate more in future projects, I would like to focus on contributing to discussions more and keeping myself informed. I need to stop stressing over my comments so much and just focus on saying what I need to.

Links to my GitLab Contributions:

These are issues I directly worked on, where I left comments about my progress and had discussions with teammates:

I also helped with resolving the Angular Testing issue, which was left over from Sprint 2:

These are merge requests I created to merge branches I worked on, where I also worked with teammates to resolve problems before merging:

I also took part in discussions on these merge requests:

From the blog CS@Worcester – Computer Science with Kyle Q by kylequad and used with permission of the author. All other rights reserved by the author.

Final Sprint Retrospective

Yesterday was the last sprint review for the semester and the conclusion of my work on the UpdateGuest project (at least as required for my software development capstone course).

During this sprint our team worked on putting the whole UpdateGuest service together.

This sprint I helped to review many of the merge requests associated with my teammates branches and I worked on both making decisions and helping implement the Angular form for our frontend.

Specific issues I worked on this sprint are:

I think our team did a really good job this sprint. As Dr. Wurst commented yesterday, our team did really well this sprint with communicating and looking back at the different issues and merge requests from this sprint, I completely agree. Additionally, I was very impressed and excited about the work we accomplished during Sunday when the team met on Discord and worked together to rapidly implement, review, and merge different features.

I think that some things could have gone better too for our team. This includes improving when we work on our issues and working on issues ahead of deadlines, along with having everyone on the team working on reviewing merge requests.

There are a few areas I think I could improve on personally. This includes improved time management and keeping track of overall project progress. This was almost a problem for our team as we had a very last-minute meeting the day before our sprint review to finish our implementation of the frontend and make it work with the backend. I take responsibility for this and I should have setup a meeting to work on this much earlier than Sunday morning, especially as this was suggested by my teammates earlier in the week. Another area I want to improve on is consistently working on issues. This sprint there was a week where I didn’t do any of the work I needed to do for the project and that undoubtedly didn’t help, along with also waiting too long to work on issues. Finally, another issue I would like to improve on is finding a balance between reviewing others’ work and working on my own implementations. This sprint in particular I found that I spent a lot of time reviewing and learning about my teammates work. While I do think this was helpful and led to more refined code getting merged, I think it led to me spending much less time on my own implementations, which I am not as happy about.

Some of the areas I think our team could improve on if we were to continue working together largely relate to some of the issues I could personally improve on. I think both personally and as a team we could further improve on our ability to refine issues and improve on how we estimate the weights for issues. This problem specifically occurred with the implementation of the Angular form where I think it took a lot more time and had more issues than we originally anticipated. Additionally, I think our team could improve on keeping track of overall project progress for meeting deadlines and maybe work towards setting estimated deadlines in all issues with times and dates for issues to be completed. Again, this would help to avoid a last-minute meeting where a lot of work needs to be done in a single day to finish features (or the project). Finally, I think that everyone in our team could work on reviewing more merge requests so that this work is more evenly split and gives others (including me) time to work on their own features.

Overall, I am very happy with the progress our team made during this final sprint and I am especially impressed with how everyone worked together Sunday to finish all of the features we needed for this project to be in a good and working state.

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

Sprint Retrospective #3

https://gitlab.com/LibreFoodPantry/modules/visitmodule-tp/approveguest/Plan/-/issues/59 made a stub for registration component

https://gitlab.com/LibreFoodPantry/modules/visitmodule-tp/approveguest/Plan/-/issues/57 Discuss with Register Guest about endpoint to get all guests

https://gitlab.com/LibreFoodPantry/modules/visitmodule-tp/approveguest/Plan/-/issues/52 Implement register-guest-service

https://gitlab.com/LibreFoodPantry/modules/visitmodule-tp/approveguest/Plan/-/issues/60 Create Docker container Running REST API

https://gitlab.com/LibreFoodPantry/modules/visitmodule-tp/approveguest/Plan/-/issues/35 Create Docker container Running ApproveGuestWebUI

https://gitlab.com/LibreFoodPantry/modules/visitmodule-tp/approveguest/Plan/-/issues/58 Style guest-list component

https://gitlab.com/LibreFoodPantry/modules/visitmodule-tp/approveguest/Plan/-/issues/38 Implement guest-list-component in ApproveGuestWebUI

https://gitlab.com/LibreFoodPantry/modules/visitmodule-tp/approveguest/Plan/-/issues/55 Implement data-service in ApproveGuestWebUI

https://gitlab.com/LibreFoodPantry/modules/visitmodule-tp/approveguest/Plan/-/issues/61 Create Header for ApproveGuestWebUI

https://gitlab.com/LibreFoodPantry/modules/visitmodule-tp/approveguest/Plan/-/issues/54 Determine design for frontend component that will display guests

This was the first that was entirely online and remote and because our team now had the experience of how to work on this project online thanks to the last sprint, it went a lot smoother and we got a lot of difficult work done. Something I felt worked very well was on Mondays and Wednesdays we would write in discord what we have done since the last stand up, what we plan to do and any issues that we were facing. By using this channel consistently, our team had great communication on where we were in the sprint and where we were heading with the time remaining. Schedules and situations affected our ability to meet in zoom at the normal class time, but we all compromised and tried to make time for one another to answer questions and work together on the sprint, which to me was very thoughtful and helpful for this sprint. This sprint was our strongest sprint out of the three, in my opinion, because we were able to accomplish a lot and almost finalized what we set out to do from the very beginning which is very impressive given the circumstances. As a team, I think we could have met at least one more time outside of the normal sprint days to really get more work done and be more responsive to issues and how we could work to help one another. Our team should have made a schedule of what days and times we would meet to work on the issues rather than just spur of the moment “lets all get on and work”, not to say that didn’t work, but having a schedule would have made it easier to get work done and plan out the week. I think I should have asked what more I could have done to help with this sprint because I found myself only doing small tasks that related to the backed because that’s what I felt comfortable with and knew I could do. I should have asked to help with different aspects of the front end and tried to learn more about what they were doing and how I could help. Moving forward I will be more proactive with other aspects of a sprint and ask about how things work even if I am not directly working on it, so that if I do need to work on it, then I can just get right into the work that needs to be done. I also feel that I got complacent and lazy due to being at home and surrounded by distractions and no motivation to get work for the sprint done. If we had another sprint and more time to work on this project I would suggest that we try to stay in touch with one another more frequently, make a schedule of when to meet, and try to teach one another about what we have done on the project in more depth. Overall I am extremely proud of my team and what we have accomplished in this final sprint and I wish we had more time to work on this great project.

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

Share What You Learn

I can not overstate how much a generous spirit contributes to good luck. Look at the luckiest people around you, the ones you envy, the ones who seem to have destiny falling habitually into their laps. What are they doing that singles them out? It isn’t dumb luck if it happens repeatedly. If they’re anything like the fortunate people I know, they’re prepared, they’re always working at their craft, they’re alert, they involve their friends in their work, and they tend to make others feel lucky to be around them.

—Twyla Tharp, The Creative Habit

Sharing What You Learn pattern shows how important it is for an apprentice to share their knowledge so that the superiors know how far they have gone, and other apprentices can learn from them. An apprentice is a person who is constantly learning. The best part of being an apprentice is when you start knowing a lot of things, and people come to see you as a source of information. That is the moment when you start feeling somehow accomplished. Before an apprentice gets there, he/she must focus on improving his/her knowledge and learning to communicate effectively with the team. No one has ever said that the journey is going to be easy. On the contrary, it is very challenging at first.

What I found interesting in this pattern is that an apprentice is for sure not a master, but it’s very common that between a couple of apprentices working together, one of them could know a little bit more than the others. Just because an apprentice doesn’t know very much, doesn’t mean that they cannot share what they have learned. Precisely for that, their explanation could be very clear and concise. The best part of the apprenticeship is to learn and to share with another apprentice what you have learned so far. However, there is always a bad side, which is not appreciating what people share. It is important to note that there is an ethical aspect to education and that such experiences are not to be discussed. We need to think before we share something because it could be a secret, or it could hurt others. We should not exchange any lessons if any of our team members get harmed. Furthermore, it is not good if someone finds out that you are not modest enough in the way you share the information. As a conclusion, sharing what you learn is very important not only for people who are listening but for the person who is sharing as well.

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

Retrospective Sprint-3

https://gitlab.com/LibreFoodPantry/modules/visitmodule-tp/checkout/Plan/-/issues/47
Create MongoDb Docker Container

https://gitlab.com/LibreFoodPantry/modules/visitmodule-tp/checkout/Plan/-/issues/50
Setup Rest Api Endpoint to Add to MongoDb

https://gitlab.com/LibreFoodPantry/modules/visitmodule-tp/checkout/Plan/-/issues/31
Implement methods in weight-entry component to communicate with REST API

https://gitlab.com/LibreFoodPantry/modules/visitmodule-tp/checkout/Plan/-/issues/30
Add checks for remaining weight allowed based on previous transactions

During our third and final sprint our teamwork and role designation really benefited our workflow. We applied ourselves to areas of work that we each had the most knowledge with (Rest Api, Mongo, Web UI, and Docker) and focused our workflow individually in those subjects. While at this juncture in the project most of the work is overlapping in order to connect either through Docker or with specific method calls we were all exposed to each other’s work. This way we each had an opportunity to learn about the different parts of the project and all had a deep understanding of our own work. Having such deep understanding of our own work allowed us to explain it to each other and to overcome obstacles when finalizing the connection between everything either locally or via Docker. So whereas in previous sprints we worked solely on our own part of the project, this sprint really started to blur the lines of our issues. 

For example, many of our Rest Api Endpoints needed to be set up to work properly with the Front End Angular Methods. Issues like Issue 50 Setup Rest Api Endpoint to Add to MongoDb became a three part issue. We need to make sure the Rest Method could add correctly to our MongoDb, but also this needed to be tested with the Front End code before it could be finalized. While working on this issue I found that roles were often switched and juggled between my teammate and I as I worked on Front End Angular code and they worked on some Rest Api Backend code.

There isn’t much that didn’t work well in this Sprint but I feel that keeping our Merges to Master on Git up to date and correct was sometimes a problem. We did not alway communicate code correctly and would send snip-its in discord that we would copy and paste instead of sharing it through git. Sometimes certain important code segments would get merged and then someone with old code from copy and pasted work may merge and we would lose that important segment of code in our most recent commit.

As a team we could improve our Git presence and organization. We should have been using it to solely share code instead of copy and pasting in discord. If we used Git only certain things would not have gotten lost in translation and confused. Overall, if we worked more cleanly on git we would have saved quite a bit of time on the project.

As an individual I could improve my knowledge and understanding of the parts of the project I wasn’t assigned to. Sometimes if an issue would arise with a field of familiarity like the Rest Api I would feel compelled to help my teammates with the problem. However, I could have designated some of that time to look over things like the Docker containers more and familiarize myself with their function better. Docker would not work on my computer so the only exposure I had with it was when working with my team members. I feel I could have learned more about the Rest Api and Angular Docker containers as opposed to just the Mongo Container.

From the blog cs@worcester – Zac's Blog by zloureiro and used with permission of the author. All other rights reserved by the author.

Expose Your Ignorance

The apprenticeship pattern Expose Your Ignorance is like climbing a mountain taller than you may have climbed before. It seems so difficult and intimidating but once you are at the top, you realize how the hard part is over and it will now be easier moving forward. You may feel great pressure if your team has a task and they all seem to understand while you have some questions or are unfamiliar with the material. It seems as though exposing to them your ignorance will ruin their confidence in you or hurt your pride. However, exposing your ignorance does just the opposite! Your team members will see that your ability to learn is your strong suit and their confidence in you will be even greater. You will not be a master in one specific field but a master at obtaining skill and knowledge in any field you are presented with.

In my own experience, exposing your ignorance can be a great ice breaker at the beginning of a project. Just because your whole team may seem more knowledgeable than you on the material does not mean that they don’t need a refresher or are just putting on an act of confidence before they do research on their own to catch up. The most direct and fastest route to the knowledge is to ask your team member who has immediate knowledge. Perhaps the situation is vice versa and you have more knowledge than your team, asking revealing questions even if they are just for review can open the conversation for people to expose their ignorance and then learn the fastest way possible. It can be hard to swallow pride and fear judgment but if you remember that the most important thing is the project then your own pride becomes secondary. It is also better to have someone ask the questions they need than to put on an act and slow things down by learning as they go when the time could have been taken to spread knowledge amongst the whole team simultaneously. Now while you still may have to learn as you go after having exposed your ignorance, at least your team is aware and can now take proper steps to aid you until you have obtained the necessary knowledge.

From the blog cs@worcester – Zac's Blog by zloureiro and used with permission of the author. All other rights reserved by the author.

Concrete Skills

  • Summary of the pattern.

The pattern is about how you need to have concentrate skills that can actually contribute to a team. In addition to general knowledge and willingness to learn. It says how a lot of teams want someone who can help in some way at the beginning and don’t need to be taught everything before they can help the team at all.

  • Your reaction to the pattern.
  • What did you find interesting
  • What did you find useful
  • What did you find thought-provoking about the pattern
  • Has the pattern caused you to change the way you think about your intended profession, or how you think you will work? 
  • Do you disagree with something in the patterns And why?
  • The tag for the in which the post was made, E.g. Week-1. (See the Schedule at the end of this syllabus for numbers.)
  • 350-450 words.

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

Learn How You Fail

The pattern that from Apprenticeship Pattern that I read for this week is “Learn How You Fail”. The chapter mainly talks about how to identify our own problem during the development process and seek to fix it in order to get better.
I really like what the author said within the context. Failure is inevitable and people who has never failed would either stay in their comfort zone and avoid going over the boundaries, or they have overlooked and ignore their mistake all along. This holds true to me since I have done multiple personal projects that requires me to constantly make mistake and discover what is needed to be done for even a single line of code to work. It is pretty obvious that errors will push ourselves to find out what works and what does not, give us a space to fully explore the capacity of the technology so that we will not make a same mistake later on. Moving on to the problem, he states that the learning skills may bring us success, but there are weakness and failures still remains. I agree with this and I think he did it brief but covered all the aspect of this chapter. The author then gives us the solution, which is as simple as to always seek the errors or failures and resolve what is worth fixing, and more importantly, we have to accept that there will be a lot of things that we are not good at. The solution itself is pretty much self-explanatory and I agree that there’s no better way to improve it without starting to identify the problems and spend time and effort to fix it.
Another way to solve this problem is to is to always arm ourselves with knowledge to make better decisions when carrying out working and identify our own boundaries and limitation to push it when we need to. These changes and improvement can also enable us to have a realistic limitation on our goal. That limitation is what we need to be mindful about as we cannot know everything, and that limitation will greatly help us in filtering out which one is distraction, which on we should spend more resources on to excel at what we are trying to accomplish. I like the example that he put out, which is making time for PhD courses, or simply give up what we know as it requires maintenance to be fortified and maybe to make room for what we need at the moment. I both experience a similar form of these two examples since I had to dedicated time and resources to be able to just learn a new language or a piece of technology.
Personally, I like the chapter because of its simplicity and how it encourages people to not afraid to push their boundaries, while at the same time, accept that we can never know everything, and we have to prioritize one over the other. Like I mentioned, I had experience what this pattern is saying in the past, and I believe that this can be extremely useful for a lot of people, especially the one who has quite some decent knowledge about an area to encourage them to learn something not quite similar to what they have been using.

From the blog #Khoa'sCSBlog by and used with permission of the author. All other rights reserved by the author.

Jumping Off the Deep End

The pattern “The Deep End” is all about taking on challenges and hard tasks to further your progress in learning and avoid plateauing. The pattern also talks about how it will help build your portfolio and give you more experience in different areas and fields of computer science. There is also a risk for this pattern which is that you may feel like you are drowning when you are unable to complete or work on the task because it is too difficult. According to the pattern, you should write down the biggest project you worked on was and the biggest code base you have made and look for projects of similar dimensions and attempt to work on those as well. The best way to grow is to challenge yourself and take on bigger and bigger tasks to both show your progress and what you can achieve. I relate to this pattern since I believe that its the best way to grow and learn when it comes to everything else so it makes sense that it applies here as well. There will always be a ability to fail, but it takes a strong person to look at that possibility and still push forward. I feel that this pattern made me think of how I will be doing a fair amount of work outside of any job that I employed to do because I will want to and need to learn and experience more to grow.
I feel that this pattern is helpful and useful information for anyone in any profession since it can be applied in different ways. The pattern talks about keeping your head above water, but I feel that at times you need to really go down under water to get stronger. I think it’s important to be reasonable with what you can handle, but I don’t think that means you need to be afraid of being really challenged by a task or project that pushes you “under water”. By taking calculated risks and challenges, we can achieve greater heights of what we are able to do. I feel like this pattern pushed me to want to take on greater challenges and work on larger projects to build up my portfolio and learn new things that I will be able to use in future professions/projects.

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