π·οΈ backlog
Module-Piscine π
Code review in your team π Clone
Link to the coursework
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
Practise your demo π Clone
Link to the coursework
https://codelikethis.com/lessons/tricks-of-the-trade/how-to-demo
Why are we doing this?
Each week in class you will demo something for two minutes, and then take questions for five minutes. You don’t need to spend hours practising this, but it’s a good idea to put a simple plan together before class and practise with a friend.
On Fridays we do demos at CYF, so you are welcome to come to a Meet and demo with other people for practise.
Maximum time in hours
.5
How to get help
Ask in Slack for someone to watch your demo and ask you questions. Remember, we do not want an elaborate slide show or a very long presentation. We want a couple of minutes about one interesting thing you learned, made, or broke this week.
- π― Topic Communication
- π Priority Mandatory
- ποΈ Priority Stretch
- π Size Medium
- π Sprint 2
Answer a technical question π Clone
Link to the coursework
https://curriculum.codeyourfuture.io/guides/getting-help/asking-questions/
Why are we doing this?
We want to select people who are ready to work together in teams to develop software. This means being able to talk through a technical problem with a team member. You might not be able to solve the problem, but talking through the issue systematically is always useful.
Task: Find a technical question in Slack that has not been resolved. Join the thread and help.
How to submit
Post your help in Slack. If there are no questions yet, ask one!
How to review
Before answering a question, check in with yourself and make sure you have done the following:
I have…
- Read the question carefully and explored any links or code added
- Asked clarifying questions to narrow down the problem
- Explained my own reasoning
- Checked my spelling and grammar
- Read my whole reply 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?
- π― Topic Communication
- π― Topic Problem-Solving
- π― Topic Requirements
- π― Topic Teamwork
- π Priority Mandatory
- π Size Small
- π Sprint 2
- π Sprint 3
Play computer: team code π Clone
Link to the coursework
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
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