Scene is a tool to connect bussineses with local artists to turn boring workspaces into beautiful and meaningful scenes.
Team & Time:
This project was developed in 7 days. The week of September 7th 2015.
The team were 5 amazing full stack developers.
- Find local artists in your area.
- Browse artists scenes (their work).
- As an artist share your work in the platform to get hired.
Fameworks and languages
- Ruby version: 2.2.1
- Rails version: 4.2.3
The first thing we did was to spend the day in a room without writing one line of code. We dedicated the whole day to planification and the rest 6 (six) days for execution. This helped us develop all are team dynamics and communication. Nevertheless keeping in mind our goals:
Individual goals: sharing our individual goals lets us know what each team member is looking for in this project. This helped us split the work, communicate and most importantly to understand the why of our actions and behaviours when approaching difficult situations.
Team goals: talking about goals as a team helped us define a strategy and vision as a team. One of the key factors to achieving our goals where defining them as a team and having solid and fundamental values during the development phase.
We defined two mandatory standups (9AM & 9PM) responding to three questions in two minutes each.
- What did you do in the last session for the team?
- What are you going to work on the next session for the team?
- Are you having problems or need help with something?
Mandatory Group Lunch
We figured out that getting together and spending quality time was one of the reasons the project was a total success as a team execution.
Pivotal tracker was used as the project mangament tool to keep track of our work. All the features and functionalities of the platform where listed as user stories.
To start developing each team member picked a user story that would be happy and had to be developed in a vertically sliced way meaning that the feature had to be developed from the back end all the way to the front end.
We defined our Git workflow as commandments in the following illustration:
Pairing was optional for the team. If any team member wanted to pair on developing a user story it was as easy as communicating with another team member or another option was going solo.
When any team member pushed code to the remote repository in order to merge the new code that was pushed code reviews had to be done. Code reviews worked in the following way:
- Work on a feature and commit (commit often).
- Let your team know that you are goint to push. So in a loud voice from your seat say to your team members: "I am going to push" (then go ahead and push your code to the remote repository!)
- Ask a team member to review your code and merge or close the pull request (depending on the quality of the code).
• Controller Specs
Testing was not planned for the MVP execution. Nevertheless some controller tests were done to ensure the proper functioning of the RESTful implementation.