Project 4:
Build a Full-stack MERN App as a Team
Overview
You’ve already worked in small groups to accomplish various labs, exercises and mini-projects, but this time we’re going to challenge you to work in a team on a project.
You and your teammates together will architect, design, and collaboratively build a full-stack web app.
With this project you'll be building an exciting full-stack app that uses the JS-based MERN.
This project will push you both technically and collaboratively!
You'll likely be working as part of a team in the workplace and this project will provide you with that important team development experience.
However, working on a project as part of a team can be more challenging due to logistical reasons, differing opinions, etc.
During this project, your instructors are going to be evaluating your ability to listen to and respect other opinions; to share and contribute your ideas with the team; and form a consensus and compromise when opinions differ.
In fact, your ability to work in a team during this project is more important to your instructors than the project itself.
Planning & Presentation Requirements
Working in a team is going to require more upfront planning to ensure the team is "on the same page"...
Pitch Deck
☐ Pitch your project to the class with a pitch deck that includes:
- The application name.
- Your team members and their roles.
- The problem you are going to solve with your app.
- Check out previous decks: Meal Ticket, Tripio, Pantry, ArtWorld
Trello Board
-
A Trello board with:
☐ User Stories, each moving from left to right in the following three lists in your board:
- Ice Box
- Current/MVP
- Completed
User Stories must follow the following template:
As a <user role>, I want <feature>, because <reason>.
The reason is optional if it's blatantly obvious.
Note: Prioritize your user stories within the Ice Box with your "wish list" stories at the bottom.☐ Wireframes of the main pages of functionality, e.g. Landing Page, Posts Index Page, Favorite Posts Page, Add Post Page, etc.
☐ An ERD showing the attributes of each entity and the relationships between them. Refer to the Data Modeling lesson for assistance.
Presentations
Your entire team must participate in the presentation of the project.
You will have approximately 15 minutes to present your project following these guidelines:
-
Introduce the Project:
☐ Intro your project by paraphrasing the README.
-
Demonstrate the Project:
☐ Launch the project by clicking the link in the README.
☐ Sign up a new user, then immediately log out.
☐ Log in with your preferred user and demonstrate the features of the app.
☐ Be sure to demo all CRUD data operations.
-
Show/discuss your code:
☐ Show the "main" Mongo model.
☐ Show your favorite Mongo template.
☐ Show the code for the main model's controller, routes and React Components.
-
Share the experience:
☐ What was your biggest challenge? (besides Team Git Workflow)
☐ What are your key learnings/takeaways?
- Q & A + Feedback
Technical Requirements
Your App Must:
☐ Be a full-stack MERN application.
☐ Persist data in MongoDB.
☐ Authenticate users using JWT Auth.
☐ Implement authorization by restricting access to the Creation, Updating & Deletion of resources.
☐ Be deployed online using Digital Ocean.
The app may optionally:
☐ Consume data from a third-party API.
Workflow:
☐ Your team must manage team contributions and collaboration using Git, GitHub and a standard team work-flow. Here are some references:
☐ All team members need to contribute to the project via git commits.
☐ The repo must include a README.md
with:
- An introduction of your app along with a screenshot (one is all you need to "introduce" your application).
- Explanations of the technologies used (including outside APIs).
- A link to your pitch-deck.
- A link to your Trello board that contains your user stories, ERD, and wireframes.
- A link to your deployed app on Digital Ocean.
- Description of any future enhancements planned.
Suggestions for Success
-
Identify roles on the team, which may be:
- Scrum Master: the leader of the Agile processes (user stories, stand-ups, etc.) and manager of Trello.
- GitHub Manager: the primary person for managing the repo and GitHub team workflow (merging pull requests, etc.).
- Documenter: the person in charge of the README, etc.
- API Manager: the person in charge of researching, registering with, etc. APIs.
- Designer: the person in charge of UI design/layout and styling.
- Database manager: this person will be in charge of creating and managing the models and their relationships.
You don't have to formally fulfill any of the above roles! They are only listed to provide guidance.
- Because your app's functionality revolves around the logged in user, implement authentication and basic navigation first!
- Remember to keep things small and focus on the MVP – feature creep can doom a project!
- Read the docs for whatever technologies / frameworks / API’s you use. Definitely
- Be consistent with your code style. You're working in teams, but you're only making one app per team. Make sure it looks like a unified effort.
- Do your best to have only one dev working on a certain file between commits. This will avoid merge conflicts. This is another reason to separate responsibilities between team members.
- Commit early, commit often. Don’t be afraid to break something because you can always go back in time to a previous version.
- Pair programming can be a great way for team members to share knowledge and contribute to the project.
- Consider following a Mob Programming approach where the team is always developing together on a single computer. Read this post for more information.
Obtaining Assistance from an Instructor
- Although your kind instructors will be available to assist during project time, the amount of assistance you require is expected to be minimal due to the fact that you will be collaborating as a team regularly.
- All requests for assistance should be slacked to the class support channel, not individual instructors. This approach will provide the best and quickest response for your team, as well as be helpful to other teams that may be faced with the same issue.
Project Feedback + Evaluation
- Your instructors will be evaluating your project during your demonstration as well as reviewing the code in your repo.
- If your instructor(s) determine that your project does not meet the above requirements (denoted using checkboxes), you will be given 3 calendar days to address the deficiencies identified. However, be aware that there is only a single opportunity to resubmit a project during the course. For example, if you already resubmitted Project 2, you will not be permitted to resubmit this project.
- Immediately after your presentation, your instructor and/or outcomes may provide you with feedback that will benefit your project and perhaps the projects of other students as well.
- If there is a specific section of code that you would like an instructor to provide additional feedback, please ask!