Jessica Spinetti Retrospective Sprint 2
Jessica Spinetti - Retrospective for Sprint 2
Links to Activity
-
I created the .gitlab-ci.yml file for ViewOrder and included a template. This will provide a foundation in which the test template can be edited or changed later on to fit the needs of the project. Issue #48 (closed)
-
I dockerized the frontend of ViewOrder. Currently, there is a generic welcome tag that displays on localhost:8081 when docker is running. Issue frontend#35 (closed)
-
I dove into research in regards to pipelines, schedules, and jobs that are found under the CI/CD tab in Gitlab. This research was essential as we now know what each of these components are and how to utilize them as we further progress with ViewOrder. Issue #50 (closed)
-
I conducted a brief meeting with the PlaceOrder CI/CD member in regards to software implementation between CI/CD members across various BNM projects. We reached a conclusion that the implementation should remain being handled by Gitlab for where we are currently in the project (this could change later on as BNM progresses). I will keep tabs on the PlaceOrder testing tickets as they will utilize pipelines to begin testing and take note on the results as well as what is done with the technology. Issue #49 (closed)
What Worked Well
Communication, trust, and team organization were huge for this sprint. As there were unforeseen blockers that emerged midway through the sprint, the team did a fantastic job communicating their blockers and an emergency zoom meeting allowed us to navigate around the blockers to ensure all critical components of the sprint were completed by the due date. Each team member trusted that every other member would handle their own work at their own pace and did not attempt to overtake anyone else's role. Team organization was better handled in this sprint than the last. Each member was prepared with due dates, last minute changes, and adapted to make meeting times. Overall, the efficiency of the team in terms of production and communication improved.
What Did Not Work Well
In regards to this sprint there was not necessarily any thing that did not work well. While blockers are inevitable, when an unforeseen blocker arose that could have potentially hindered the teams overall production, the team implemented an emergency meeting at everyone's earliest convenience and discussed the situation. From there, a game plan was drafted and each member agreed and accommodated to any changes that were brought up. This ensured that no member was hindered or blocked and all work could be completed before the end of the sprint. We have found that emergency meetings via zoom allowed direct communication and faster decisions than messaging or emailing did.
Changes To Be Made For Team Growth
While I believe the team grew immensely this sprint, in the future I think more zoom meetings over email exchanges may work better in terms of efficiency and understanding when issues arise. Currently, we have our weekly zoom meeting as well as a zoom planning meeting. In the next sprint, I believe we should implement more zoom meetings when important conversations need to take place as we saw great success with our emergency zoom meetings in this sprint. The zoom meetings allow more direct conversation and screen sharing so that all members can see and hear about the issues taking place and troubleshoot the best way to navigate the issues rather than a delayed response that a group message or email would contain. However, I do believe the group messages and emails are still a great way to communicate and update team members throughout the sprint. The group messages and email exchanges are not something we should lose.
Changes To Be Made For Individual Growth
In regards to personal growth, I feel I made bigger strides this sprint than last. I feel more confident in leadership roles (presenting the Sprint 2 update allowed me this 'leadership' position). I have a clearer understanding of the project and each members CoP. Moving forward, I want to work on the presentation of my issues. I feel I can improve on the word choice and detail of certain issues to make them more understandable to someone just coming into this project with no prior experience in BNM. By this, I mean the Outcomes portion of my issue tickets could be better worded as could the 'Why is this important' section. I want to improve my description in regards to technological terms as well as finding a better balance between speaking 'tech' and keeping it more simple in regards to new members joining and wanting to get caught up on the work already produced.