Bootcamp week 5: Group project
This week we did the first group project of the course. The learning objectives were:
- Learn to work and communicate effectively as part of a team to build a web application.
- Learn to break down projects into tasks and assign them to pairs.
- Learn to use agile ceremonies to organise your work and improve your processes.
- Learn to use the developer workflow to plan, implement and peer-review features.
I was in a group with four great teammates: Arbnor, Heather, Osman and Shoaib. Our project for the week was to build a ‘MakersBnB’. We used Ruby, Sinatra and PostgreSQL for the backend, and some fairly basic HTML and CSS for the frontend.
Workflow
On Monday, we all got together to review the guidance from Makers and agree how we were going to approach the project.
We decided we’d have a standup every morning at 10am, and a retro every afternoon at 5pm. We also broke the week up into three tiny sprints to try and get a flavour of the Agile workflow.
The first tasks was to take the requirements we’d been given and turn them into user stories. We then broke those stories down into tasks and added them to a Trello board.
Once we’d agreed the tasks, we split into pairs and rotated the groups for each sprint. I focused slightly more on the backend, as a lot of what I’d done the previous week for the Chitter challenge (like authentication, session management and some of the database tasks) meant I could help get the basics up and running fairly quickly.
I paired with Osman for most of the week. We made a great team, bouncing ideas off of each other and suggesting alternative approaches whenever we got stuck.
The finished product
We managed to implement all the core functionality by the end of the week: hosts could list properties and approve bookings, and guests could find somewhere to stay and submit a booking request.
Given slightly more time, the next steps would have been to improve the design, implement better UI features (like a proper avaiability calendar), and add email and SMS booking confirmations.
Overall, we were really pleased with the final product and learnt a lot about effective ways of working together on projects like this.
1. Regular standups and retros are massively useful for aligning with the rest of the team and helping each other overcome any obstacles. At first it seemed like a lot of time to take out of each day, but it paid dividends and meant we were all really clear about what we should be working on.
2. Although we all had slightly different visions of what the end product should be, we were happy to compromise and make sure that everyone got to contribute equally. We ended the week as a happy team and would all be keen to work together again.
3. It was important to be realistic about what we could achieve in the time available. We decided on the first day that we would focus on creating a good MVP with all the basic requirements, and add bells-and-whistles after that was done. That turned out to be the right approach, as we ended up being really pushed for time to even get the MVP completed.
1. Creating tasks that are clear, specific and achievable within a sprint is key to success, and also really difficult. We oscilated between having tasks that were too broad that ended up taking all week, and tasks that were so small and specific that we could finish them within half an hour.