For the first time ever, you get to work across programs and create a project that might not be possible otherwise! In this project plan, we’ll kick-off the project and define expectations and deliverables for teams.
This is a unique opportunity that presents some valuable goals:
- Demonstrate knowledge you’ve gained throughout Turing
- Use an agile process to turn well defined requirements into deployed and production ready software
- Gain experience dividing applications into components and domains of responsibilities to facilitate multi-developer teams. Service oriented architecture concepts and patterns are highly encouraged.
- Explore and implement new concepts, patterns, or libraries that have not been explicitly taught while at Turing
- Practice an advanced, professional git workflow using Git Rebase
- Gain experience using continuous integration tools to build and automate the deployment of features
- Build applications that execute in development, test, CI, and production environments
- Focus on communication between front-end and back-end teams in order to complete and deploy features that have been outlined by the project spec
Generally, this project will consist of a front-end (FE) and back-end (BE) with the following:
- Use Github Projects to track stories and progress
- The FE and BE applications live in separate repositories that communicate to each other using API requests
- Early and consistent deployment to production
README.mdfor each repository describing the project, setup procedure, testing procedure, and screenshots, if applicable (API documentation, if applicable)
- Create and use pull request templates that document and create discussion for finished features
If you do not see your project following this outline, then speak to your instructors about it.
Regarding Authentication Please Read Carefully!!!!!!
Authentication will NOT be part of your MVP; and will only be included at the discretion of your project managers!
Test the BE:
- If you use Rails for your BE, then we expect above 80% test coverage
- If you experiment with a new BE language/framework outside of Rails, then BE test coverage is expected to be at least 25%
You must pick 1 of the following stretch goals:
- Implement BE in a framework or language you have not used before in a project
- Create a Backend API using GraphQL
- Create a micro service or two and abstract out functionality into a separate application
- Utilize websockets rather than traditional HTTP/HTTPS
- Interface with the BE team’s API(s) that serve JSON data and incorporate that data into your FE
Test the FE:
- If you use Cypress for testing React, Vue, Svelte, etc. for your FE, then we expect at least 80% test coverage
- If you experiment with a new FE testing framework for something like a React Native app, then FE test coverage is expected to be at least 25%
- You must pick 1 of the following stretch goals:
- Implement FE in a framework you have not used before in a project
- Implement GraphQL with Apollo Client
- Implement Progressive Web App (PWA) technologies like: background sync, IndexedDB, static assets caching using a Service Worker
- Implement Redux into your application as your global state manager
- Utilize websockets rather than traditional HTTP/HTTPS (maybe socket.io)
Note: FE students can be the BE creators and vice versa, if it fits into your learning goals. Please also note that you should have a total of 2 stretch goals.
As a team, you should collaborate on the following:
- Create a Slack channel - add group members and project manager
- Pin the DTR, Repository links, and Project Board in channel
- DTR (use gist or Google Document)
- Initialize your repositories (don’t write any code just yet!)
- Normalize on the Git Rebase workflow and create a PR template
- Determine the MVP (knowing it could change as the project continues)
- Create wireframes
- Construct schema design
- Set up your project board with Github projects
- You’ll be required to use a single board for all repos. This will make it easier to see what everyone is working on during the project.
- Write all stories for what you are committing to have completed by first check-in. Label with Phase 1
Group Communication Expectations
- Make a team copy of this document. Each member should update daily before meeting as a team.
- Schedule to meet as a team daily to give brief update on everyone’s progress
- If there are blockers, schedule a time with the approiate people to address
Create a JSON Contract between FE and BE
- Include example requests and responses in README documentation and keep updated
- Create PR template
- Feature PRs should have two reviewers: 1 from BE and 1 from FE for feature pull requests
- Should include MVP user stories, chores, bugs, and spikes
- Should be kept up-to-date and members should assign themseleves when working on a card
Retro and Backlog Refinement
- Weekly retros and backlog refinement is scheduled on the calendar.
- Backlog Refinement:
- Review Project board and update cards as necessary
- Prioritize cards and ensure everyone is up-to-date
- As a team, choose a format and follow guide.
- Give Feedback to team members.
- Capture summary with screenshot of retro board and include in Slack channel with summary of team’s takeaways. Tag project manager.
Instructors will serve as project managers and hold check-ins:
The teams are expected to be prepared to discuss the following:
- Project board, what is in progress and if the team is expected to meet dealines
- Difficulties, roadblocks, and bugs
- Stories on board for what the next phase will be and what the team is committing to by next check-in
- Review of git commits and PRs
Some checkins may be done asynchronously. In these scenarios, project managers will send the group a list of questions a day in advance to answer. Questions may include:
- How is progress going since your last checkin? What do you still have left to do for the weekend?
- Are you running into any blockers that are preventing you from moving forward?
- Are there any major pivots that you need to make in order to reach most of your MVP by the next checkin?
- Brainstorm 1 or 2 more questions that your have for your project managers.
After reading through responses, project managers will respond with suggestions, feedback, and potentially more clarifying questions. Depending on discussions had, your project managers may also follow up and meet with you to better support your team.
After project evaluations, teams will demo their application to the class and instructors.
- Have your application up and ready to go before you start. Other windows should be closed.
- Live demo your application in production, if possible.
- Explain who is the audience for the application and what problem it is solving.
- Provide a brief summary of team’s takeaways from the project experience. Discuss if there is anyting your team woud change if you were to start over.
- Be proud of your application! You’ve spent a lot of time and hard work on this, now is your chance to show it off. Your demo should really showcase that hard work and accomplishments.
We recommend that you have a quick 30 sec - 1 min statement about what your app is and then jump straight into your demo. After the demo is complete, you can go in more depth and talk about the other points.
For your evaluation your team is expected to come prepared with a 20 minute presentation (10 minute back-end and 10 minute front-end) The presentation should use the rubric as a guideline for what needs to be covered.
Teams - it’s your responsibility to ensure you are on track to meet expectations of the rubric, which can be found here.