/project-vagabond

[rails, ruby, group, project]

Project Vagabond

Brief

We have been commissioned to build a travel community, code-named Project Vagabond for now, for users to share tips (AKA posts) about their favorite locations around the world.

Client Contract

The client has provided basic wireframes and user stories. In some cases, these requirements may be vague or incomplete.

Process

The client contract consists of three core sprints and four bonus sprints. Each sprint contains a set of user stories. You may not complete all of the sprints within the time period, and that's ok. The goal is to gain experience working on a development project in a group while navigating a client's feature list.

IMPORTANT: You may not begin a new sprint or start on a bonus without client approval.

You will work in groups of 3-4, and we expect you to pair program for the majority of the time you're writing code.

During morning scrums and in smaller check-ins throughout the day, clearly communicate your current status and next steps to your teammates. Use a kanban-style scrum board such as Trello to organize tasks (example Trello board).

Commit changes at least once for each user story. Consider creating automated tests or even implementing TDD for any complex application behavior.

Put effort into your design. Use a CSS framework (e.g. Bootstrap), partials, and some custom CSS or Sass/Less.

Work as git collaborators, build on feature branches, and submit pull requests for approval and merging.

After each sprint, deploy to heroku to get practice getting the app online. The earlier you resolve deployment, the easier it will be on each updated version.

Refactor your code after each sprint, considering:

  • Indentation
  • Readability/clarity
  • Naming
  • Organization
  • Commenting
  • DRYness

Questions to Ask Yourselves

  1. Are you all clear about what the client wants? Identify vague areas. Seek clarification in any cases where you feel less confident about your interpretation of the client's vision.

  2. What will the UX/UI flow be? Hammer out any areas of ambiguity in the wireframes

  3. Which models do you need to implement? Create an ERD for the client to reference.

  4. What are the major milestones or components that you need to complete? How can these be turned into tasks that group members can complete in pairs? Where do these milestones overlap and how will those related tasks be managed?

  5. What milestones are you and your group members interested in working on? How can you effectively delegate the work into pairs so that each group member is interested, challenged, and productive?

Groups

Each group has an assigned instructor, who will act as your client as well as give technical support during instructor-group meetings.

Team #1 - Nathan

  • Lily Cole
  • Toby Zitsman
  • Brandon Kerr

Team #2 - Arun

  • Chris Chan
  • Teddy Coleman
  • Lynette Duran

Team #3 - Nathan

  • Sherri Aminshahidy
  • Natalia Hess
  • Kenny Bushman

Team #4 - Arun

  • Ryan Hamill
  • Alivia Blount
  • Bill Cheng

Presentation

Each group will present their project on Thursday, Oct 27th starting at 1:30pm for 15 minutes.

Each member of your group should speak for equal parts during your presentation and mention which parts of the project they worked on.

Your presentation should include:

  • Tour (demo) of your app deployed on heroku.
  • Triumphs / Challenges - What was a high point for your team? What was a low point?
  • 3 lines of code (per contributor)
  • Words of Wisdom - What is a lesson you will carry forward to working on Project 2?

Evaluation

You will be evaluated on the following measures:

  1. Project workflow
  • frequent commits with good commit messages
  • cooperative group work including majority of pair programing
  • effective use of branches
  • planning to avoid excessive merge conflicts
  • deliberate approach - routeside-in, logical progress from skateboard to car
  • the code is your original code
  1. Execution
  • to what degree does your app fulfill the user stories?
  • code is clean
  • follows good naming conventions
  • code is free of obvious errors and bugs
  • code demonstrates good problem solving
  • code is DRY
  1. Technical requirements
  • users are authenticated
  • full CRUD for cities
  • custom HTML, CSS, and JavaScript (using the asset pipeline)
  • users are authorized
  • deployed to heroku
  • commenting (optional)
  1. Creativity
  • polished appearance
  • personalized spin, not just a template