🏷️ backlog

Module-Piscine 🔗

Code review in your team 🔗 Clone

https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/about-pull-request-reviews

Why are we doing this?

You must set aside a part of your development time to review the work of your team. In your technical interview, you may to asked to discuss a feature written by someone else in your team, so you will need to read and understand it.

How to review

  • Use the GitHub PR interface, either on GitHub or via VSCode
  • Checkout the PR locally gh pr checkout 123 and run the code to make sure it works
  • Test the code using the acceptance criteria on the ticket
  • Ask clarifying questions to make sure you understand the code
  • Offer any fixes or improvements you can see

Maximum time in hours

2

How to get help

Volunteers and other team members can help you with code review. You may choose to spend some time in class doing this together.

How to submit

Submit your review directly on your teammates PR.

  • 🎯 Topic Code Review
  • 🎯 Topic Requirements
  • 🎯 Topic Teamwork
  • 🎯 Topic Testing
  • 📅 Sprint 1
  • 📅 Sprint 2
Play computer: team code 🔗 Clone

https://github.com/CodeYourFuture/CYF-Workshops/tree/main/playing-computer

Why are we doing this?

In your technical interview, you may be asked to play computer.

💡 Tip

Playing computer means simulating how the computer executes our code. We “step through” the code, line by line, and work out what the computer does when it follows each instruction.

Practice playing computer now. This time, use a pull request opened by another member of your team on your current project. For best results, book a call with your team member and step through the code together.

Maximum time in hours

1

How to get help

Ask for someone to play computer with you in Slack.

  • 🎯 Topic Communication
  • 🎯 Topic Programming Fundamentals
  • 🏝️ Priority Stretch
  • 📅 Sprint 1
  • 📅 Sprint 2
  • 📅 Sprint 3
Ask a technical question 🔗 Clone

https://curriculum.codeyourfuture.io/guides/getting-help/asking-questions/

Why are we doing this?

When you hit a blocker, write up your blocker as a technical question. You can write this directly in Slack or on a ticket on your board and then link it in Slack. The process of writing out your blocker is key to resolving it.

📝 Note

Before asking a question Make a prediction and explain why you think that will happen Run the code Compare your prediction against what actually happened

Now, write up your mental model using this format:

What I did What I expected What actually happened

How to submit

Post your question in Slack

How to review

Before asking a question check in with yourself and make sure you have done the following:

I have…

  • Done some research myself
  • Explained what I’ve already tried to solve my problem
  • Stated what I expected, why I expected it, and the actual results
  • Formatted my code
  • Checked my spelling and grammar
  • Pasted the exact, complete error message, if there is one
  • Read my whole question carefully to make sure it makes sense and contains enough information for someone coming to it without any of the context that I already know?

After you’ve asked your question

I have checked…

  • Are you monitoring your questions and replying to people giving their time to help you?
  • Have you been asked for a Minimum Reproducible Example?
  • Have you posted an easy to understand answer to your questions that includes everything you learnt
  • 🏕 Priority Mandatory
  • 🐂 Size Medium
  • 📅 Sprint 1
  • 📅 Sprint 3
Refine a ticket 🔗 Clone
As a developer, you want to refine tickets so that anyone in your team can pick up and deliver any feature in your application.

Given a ticket in the backlog When I refine the ticket Then it is ready to be worked on

I expect a refined ticket to have

  • a user story
  • G/W/T
  • testable criteria
✅ Checklist

So a refined ticket has all the information anyone might need to complete a feature. This is usually:

  • A user story
  • Specification by example (Given/When/Then)
  • Acceptance criteria or assertions

🖼️ Refining Tickets Workflow

  • 🔥 How important is this task? Prioritise 🤔
  • 🐋 How long will this take? Estimate ⚖️
  • 📆 Does this task have a deadline? Schedule 📆
  • 🗃️ What type of work is this? Sort 📐
  • 😶‍🌫️ What would someone else need to know to complete this task? Explain 🎨 (or Ask)

A ticket is fully refined when anyone in your team could pick it up. If you can validate a ticket in the Backlog as Ready, move it to Ready now.

Only tickets In Progress can belong to any particular team member, so don’t claim tickets now.

🎫 Refine some tickets

Read over your team backlog. Validate the tickets against the checklist given above. If there are any tickets that are Ready, promote them from the Backlog.

Now select a ticket from the Backlog to refine. Use the refining tickets workflow. Don’t promote your own ticket to Ready - leave that to a team-mate to validate.

You can do this asynchronously or in a call with your team. Whichever helps you to make progress.

  • 🎯 Topic Communication
  • 🎯 Topic Delivery
  • 🎯 Topic Iteration
  • 🎯 Topic Problem-Solving
  • 🎯 Topic Requirements
  • 🎯 Topic Teamwork
  • 🎯 Topic Time Management
  • 🏕 Priority Mandatory
  • 📅 Sprint 1
  • 📅 Sprint 2
  • 📅 Sprint 3
  • 📅 Sprint 4
Unblocking Barriers 🔗 Clone

https://signposts.codeyourfuture.io/

Why are we doing this?

Everyone at CYF has barriers to education, and we can help with some things.

If you cannot come to class because you can’t afford:

🧒 Childcare, then go to 👉 signposts/childcare 💻 A computer or broadband, then go to 👉signposts/equipment 🚌 Bus or train tickets, then go to 👉signpost/transport 🥪 Food will be provided

How to get help

If you hit a blocker and can’t work out how to access this support, email us at expenses@codeyourfuture.io and we will help you.

  • 🐇 Size Small
  • 📅 Sprint 1