We are building our own Airbnb!
The 6th week at Makers was the first group project week — quite a new experience for me. The goal of this week is to build a “skeleton” version of Airbnb, and I gave it 9 out of 10 to conclude the week, as I enjoyed it and learnt so much.
Side note: this blog has been literally lying in my unpublished stories collection for a whole week before I realise that I forgot to click the “publish” button. Promise this will never happen again, as I pretend that I have a million subscribers waiting for my blog every week :).
So here are the actionable goals for this week.
By the end of the week all developers can build tested, easy-to-change software in a team using these processes:
- Break down projects into tasks and allocate them to pairs
- Build to a specification
- Run stand-ups and
- Use a branch/PR/merge git workflow
And this is how we arranged the five days of our week:
- Mon: 70% time in planning, 30% in setting up the project base (create a git repo, add members as collaborators, decide on the gems to use, break down the projects into small tasks, etc.)
- Tue: Building up the MVP
- Wed: 20% time in finalising the MVP, 80% in building advanced core features
- Thur: 70% time in building advanced core features, 30 % in writing tests and adds-on features
- Fri: 80% in finalising the project, 20%? Celebration!
Looking back, I’m glad we’ve done several things right:
- Have a good planning ahead, even this took us a long time. For example, we broke down the whole specification into 14 user stories, and took turns to add/delete details attached to the stories to make sure that we were on the same page. Without this step, we would easily fall into argument in the later execution regarding what to or not to include in the features. Also a thump-up to the project management tool Trello! Save us huge effort in communication. I’d like to try more geeky product like Jira though next time.
- Make sure the each user story is small enough. This is of essential importance, as some user story could contain more than one feature, e.g. “Any signed-up user can list a new space.” This should be separated into “creating a sign-up feature” and “enabling a listing new space function”. Otherwise, the workload will become imbalanced among user stories.
- Prioritise the user stories. This carries a lot weight to us as we only have 5 days to accomplish as much as possible. Once we finished the MVP on Tuesday, we need to prioritise resources based on the core features, whilst allowing space to explore some fun adds-on features (in our case, the encrypted password functionality and flash notice on the web page)
- Run stand-up everyday. Due to different schedule, we didn’t manage to run a daily debrief before we left office, but doing morning stand-up proved to be rewarding. It helps us to plan the day well and communicate ahead regarding challenges and difficulties. It was also a great time to learn from yesterday’s mistakes and improve.
However enjoyable as it sounds, this week is not perfect. I also have a few points I regret not doing and promise myself that I will do next time:
- Breaking down user stories is great, but also remember to set the acceptance criteria. Why? because you work as a team! When you work with another group on different parts of a business logic, it is important to know what the input and the output of each group’s work, so downstream group can seamlessly connect their work to the upper stream without adding/missing details of their parts.
- Daily stand-up is great, but try to have a scrum master next time. There were times during the standup when everyone tried to voice his ideas, and ended up no one listening to anyone. A scrum master can help to organise the stand-up, control the time, lead the flow and turn to external resources for help when needed. This greatly reduce the friction in internal communication and help us to focus on the project itself.
- Did I mention Git? Yes improving our experience with Git workflow. Even we did follow Github development workflow, there were still times when someone forgot to create a new branch for his piece of work and almost pushed his part to the master branch.
Well, if you are interested, below is a list of implemented features and features to be built in the future.
✓) Any signed-up user can list a new space.✓) Users can list multiple spaces.✓) Users should be able to name their space, provide a short description of the space, and a price per night.✓) Users should be able to offer a range of dates where their space is available.✓) Any signed-up user can request to hire any space for one night, and this should be approved by the user that owns that space.✓) Nights for which a space has already been booked should not be available for users to book that space.✓) Until a user has confirmed a booking request, that space can still be booked for that night.✓) User account password is encrypted ✓) Use flash to add one-time alert to the webpageTo-do features:
1. Users should receive an email whenever one of the following happens:
Sign up/create a space/update a space/requests to book their space/confirm a request/request to book a space/request to book a space is confirmed/request to book a space is denied2. Users should receive a text message to a provided number whenever one of the following happens:
A user requests to book their space/Their request to book a space is confirmed/Their request to book a space is denied3. A ‘chat’ functionality once a space has been booked, allowing users whose space-booking request has been confirmed to chat with the user that owns that space4. Basic payment implementation though Stripe.
That’s all for this week. See you around next week：）
==========Highlights of the Week=============
A. Minimum viable product (MVP)
The smallest thing that implements the core idea. Think about what this is for Airbnb. Build those user stories first. This MVP will exclude most of the headline specification items in the spec.
If your specification asks for a car, don’t build the wheels in the first week, the doors in the second week, etc. The customer can’t try it! Instead, build a skateboard in the first week.
B. XP values
Extreme Programming (XP) is based on values. The rules we just examined are the natural extension and consequence of maximizing our values. XP isn’t really a set of rules but rather a way to work in harmony with your personal and corporate values. Start with XP’s values listed here then add your own by reflecting them in the changes you make to the rules.
Simplicity: We will do what is needed and asked for, but no more. This will maximize the value created for the investment made to date. We will take small simple steps to our goal and mitigate failures as they happen. We will create something we are proud of and maintain it long term for reasonable costs.
Communication: Everyone is part of the team and we communicate face to face daily. We will work together on everything from requirements to code. We will create the best solution to our problem that we can together.
Feedback: We will take every iteration commitment seriously by delivering working software. We demonstrate our software early and often then listen carefully and make any changes needed. We will talk about the project and adapt our process to it, not the other way around.
Respect: Everyone gives and feels the respect they deserve as a valued team member. Everyone contributes value even if it’s simply enthusiasm. Developers respect the expertise of the customers and vice versa. Management respects our right to accept responsibility and receive authority over our own work.
Courage: We will tell the truth about progress and estimates. We don’t document excuses for failure because we plan to succeed. We don’t fear anything because no one ever works alone. We will adapt to changes when ever they happen.
C. Development workflow
- Create a Github issue in the relevant repository relating to the user story or bug.
- When you are ready to work on the user story, create a branch for it, e.g.
- Pair on implementing the user story.
- When you are done, create a pull request from your branch to
- Get another member of the team to review your PR.
- Use the pull request comments section to discuss the code and make improvements until the code reviewing pair are satisfied.
- When you get a or other similarly appropriate emoji, merge your PR.
- When you’re happy, merge your changes on GitHub. You should then deploy immediately. If you have CI setup you can get it to do this for you automatically.
- Do some QA on your live site if you have it set up.
- Highfive someone/something.