Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Retrospective #102

Merged
merged 11 commits into from
Jan 11, 2025
115 changes: 105 additions & 10 deletions collaboration/retrospective.md
Original file line number Diff line number Diff line change
@@ -1,23 +1,118 @@
<!-- this template is for inspiration, feel free to change it however you like! -->

# Retrospective
# Retrospective

## Stop Doing
“_Regardless of what we discover, we understand and truly believe that everyone
did the best job they could, given what they knew at the time, their skills and
abilities, the resources available, and the situation at hand._” __NORM KERTH.__

## Continue Doing
___Over the past weeks, our group embarked on the journey of learning and
practicing effective code reviews. This retrospective aims to reflect on our
experiences, evaluate what went well, identify areas for improvement, and
outline actionable steps to enhance our skills further. By reviewing our
process and establishing the best practices for future code reviews, we hope
to foster a collaborative environment.___

## Start Doing
## Stop doing 🙅‍♂️

## Lessons Learned
1. Stop merging changes without proper reviews.
2. Avoid sharing external links or performing actions that do not comply with
the application’s policy to ensure security and consistency.
3. Stop opening Pull Requests without verifying the target branch to prevent
errors and confusion in the version control process.

______________________________________________________________________
## Continue doing 👍

1. Regular code reviews.
2. Helping each other out to ensure no one is left behind.
3. Carrying out regular video calls
4. Being active in the group
5. Automated testing for critical features
6. Setting clear deadlines for deliverables
7. Sharing resources and insights to improve team knowledge and skills collectively.
8. Divide tasks before starting to ensure clear responsibilities.
9. Ask for help when facing challenges to avoid unnecessary delays.
Consider all perspectives when solutions differ. Refer to reliable resources,
and discuss the options with the team to decide on the best approach.

## Start doing 🚀

1. __Conducting regular check-ins to align on progress and adjust priorities
as needed.__
2. __Tracking and addressing recurring issues__; _We noticed that some issues,
like not using descriptive enough names for variables (e.g., naming a
variable s instead of binary_str), kept coming up during our reviews. To
avoid making the same mistakes as a group and having to point them out
individually each time, we plan to keep a shared list of these common
issues. This way, everyone can see and remember them, helping us improve
and use better practices in future projects._
3. __Sharing knowledge among team members before starting the project__: _By
sharing our individual skills and knowledge at the start, we can help each
other become more effective and efficient in the work we do._
4. __Creating a list of each member’s skills and capabilities__: _Knowing who
is
best suited for each task will enable us to make better decisions on task
delegation and leverage everyone's strengths._
5. __Documenting work steps, policies, and best practices__: _Clear documentation
will ensure that all team members are on the same page, reducing confusion
and the chances of mistakes in the future._

## Lessons Learned 🎓

1. __Importance of clear communication and task assignment__
2. __Benefits of automated testing and continuous integration__
3. __Value of regular team feedback and retrospectives__
4. __The importance of role clarity__: _Assigning clear roles in each review
cycle (e.g., reviewer, author, maintainer) ensures accountability and
smoothens the workflow_.
5. __The value of iterative learning__: _Every mistake or challenge faced during
this process offered an opportunity to grow and refine our practices._
6. __Effective prioritization leads to efficiency__: _Focus on the most
impactful changes during reviews to optimize time and effort._
7. __Focusing on weaknesses and learning from others__: _Recognizing areas of
improvement, learning from mistakes, and taking guidance from others are
crucial for personal and team growth._
8. __Frequent code reviews enhance expertise__: _Regular code reviews not only
improve the quality of our code but also reduce errors in our own work._
9. __Clear initial planning and sharing it with the team__: _Creating a clear
plan
at the beginning and sharing it with everyone helps to streamline the project
and avoid confusion later on._

---

## Strategy vs. Board

### What parts of your plan went as expected?
### What parts of your plan went as expected? 👍

1. __Improved understanding of code-reviewing principles__; _Throughout this
project, we gained a deeper understanding of the importance of code-reviewing
and how to apply best practices._
2. __Effective collaboration__; _Group members worked well together, providing
constructive feedback and supporting each other in the learning process which
allowed us to refine our approach and improve both our coding practices and
communication. This made the code review process not only more effective but
also more rewarding, as we could see visible improvements over time._
3. __Keeping deadlines on track and the delivery of work as expected.__

### What parts of your plan did not work out? 👎

1. __Initial struggle with code review tools__; _We faced some challenges
getting familiar with the code review tools, but eventually got the hang of it._
2. __We weren't quite able to fully help each other out as a colleague of
ours decided not to continue with the program.__

### Did you need to add things that weren’t in your strategy? 🤔

### What parts of your plan did not work out?
1. __Dedicated Learning Time for Tools__; _Some team members needed more time
to learn and practice using tools like GitHub and setting up the environment.
While we helped each other whenever needed during our meetings, it would
have saved time if we had set aside time specifically for learning the tools.
This could have been done either together in a session at the beginning or
by giving everyone extra time upfront to get familiar with the tools.
Extending the deadlines a bit would also have helped everyone feel more
comfortable and avoided early delays._

### Did you need to add things that weren't in your strategy?
### Or remove extra steps? 🚮
TekaMesfinAbel marked this conversation as resolved.
Show resolved Hide resolved

### Or remove extra steps?
We didn't have any members remove steps in their strategy.