Whale Spotting

Exercise

This exercise builds on the Trello tickets created in the previous exercise. The task is to now actually build the Whalespotting website over the next two weeks.

Recap

The following is taken from the previous exercise and recapped here for convenience:

Getting started

A starter code repo has been created here.

Your team should make a fork of that repo in a GitHub account that you can all access, then each of you should follow the steps in the readme file of that repo.

If the team that you did the planning with is combining with another team, then as a group you’ll need to go through the tickets and decide which ones to keep/combine. Even if your team isn’t combining, you should go through the tickets and prioritise them in some order.

On the Trello board from last exercise you may have both Backlog and To Do columns. The To Do column is suggested for holding the next few tickets so it’s clear what the priorities are; you’ll need to bring some from the Backlog now and then.

Working in a team

You’ll be working in a team on this project, so as a group you should agree some ways of working. Recommendations include the following.

Ceremonies

Each day you should have a team standup. This helps you stay in touch with each other’s progress and gives a forum for the team plan together. During each standup:

• Each member of the team gives an update on their progress since the last standup and brings up any issues that they’re facing
• The team might be able to solve any issues together quickly, but bigger issues should be addressed later (perhaps in a pair)
• Make sure that the board is up to date – that each ticket is in the correct column and is assigned to the right person
• If anyone will be ready to pick up another ticket then assign it to them from the To Do column

It’s a good idea to a team retro at the end of each week. This doesn’t need to be formal. The important thing is that it is an open discussion of things that have gone well and things that have gone not so well, and sharing of ideas; the team should endeavour to solve any problems together.

Occasional reprioritisation of tickets is a good idea. It’s likely that you’ll have more tickets on your board than the team can implement over the course of two weeks, and as you go through the project the expectations of what is feasible and opinions on which tickets are the most worthwhile can change. Since the project is two weeks long, it might be worth having a short team discussion after standup on days 3 and 6 in which you agree on any changes in priority and update the board’s To Do Backlog columns.

Development process

The following is a suggested development process. As a team you can agree your own approach, but it’s wise to discuss any changes with your trainer.

When you pick up a ticket

1. Come up with a technical design for how you’re going to implement the solution for the ticket
2. Create a new branch in the team’s fork of the repo – give the branch a sensible name so it’s clear what it’s for
3. Implement your solution and commit it to that branch locally (remember to commit small and often)
4. Push the branch to the repo

When you’re finished implementation

1. Create a Pull Request from the branch in GitHub
2. Potentially have the code reviewed by another team member or your trainer – you won’t have time to review all of each other’s tickets, but it is good experience to do some reviewing of other team members’ code
3. If there are any changes needed after review, push them to the branch
4. Merge your PR into the main branch – you’ve learned how to resolve merge conflicts in an earlier exercise so watch for this