A pitch deck, presented as a team to the class Thursday morning. A working app, built by the entire team. A team Git repository hosted on Github, with frequent commits from every team member dating back to the very beginning of the project. A README.md file 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 Heroku. Documentation for your app's RESTful API endpoints. Descriptions of any unsolved problems your team had to overcome. Description of any future enhancements planned.
Working in a team requires more upfront planning to ensure the team is "on the same page"...
Pitch your project to the class first thing Friday 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.
- Craft thoughtful User Stories together as a team and manage them in Trello.
- Team Workflow Video
- Understanding The GitHub Flow
- A Successful Git Branching Model
- Cheatsheet in Class Repo
Be a full-stack Django application. Persist data in PostreSQL. Authenticate users using Django's build-in authentication. Implement authorization by restricting access to the Creation, Updating & Deletion of resources. Be deployed online using Heroku.
Consume data from a third-party API
the leader of the Agile processes (user stories, stand-ups, etc.) and manager of Trello.
the primary person for managing the repo and GitHub team workflow (merging pull requests, etc.).
the person in charge of the README, etc.
the person in charge of researching, registering with, etc. APIs.
the person in charge of UI design/layout and styling.
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.
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.
React
Typescript
Django
Laravel
Facebook
Microsoft
Google
Alibaba
D3
Tencent