Capstone Project Expectations

Back to Capstone Overview

In this section we will cover expectations for the whole project as well as expectations for the Front End team, Backend Team, and the Project Managers.

General Expectations

This project will consist of a front-end (FE) and back-end (BE) with the following:

• One Github Organization to house the repositories, project board, wiki, etc.
• One Github Project Board to track stories and progress
• The FE and BE applications live in separate repositories that communicate with each other using API requests
• Use of continuous integration
• Early and consistent deployment to production
• In-depth README.md for each repository describing the project, setup procedure, testing procedure, screenshots, API documentation
• Create and use pull request templates that document and create discussion for finished features
• Stretch technologies implemented on both FE and BE

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 a required part of your MVP and will only be included at the discretion of your project managers! This doesn’t mean that your application can’t have users, or that you can’t store user information in the backend. It means that you shouldn’t build out the log in and authorization functionality. Instead, consider hard-coding a “logged in” User. Future iterations can include the ability to log in to different user accounts.

Back-End Expectations

• 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
  • Other (please discuss with your project manager)
• Set up a Mock Server on Postman
  • Use JSON contracts to create live mock endpoints the FE can consume
  • You must do this in the web browser version of postman (not desktop)

Front-End Expectations

• 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)
  • Other (please discuss with your project manager)

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.

Project Planning Deliverables

Week 1 is all about planning, not coding! After your project kick off, your team should collaborate on the following deliverables as part of your inception period. These will be reviewed during your first project checkin. Consider using this resource for help structuring your inception meetings and determining an MVP.

1. Create a Slack Channel - add group members and project manager.
2. You must have setup CI/CD (even if the build is failing) for your first check in and ask your questions if any. No need to have more than one test setup during this session.
3. DTR (use gist or Google Document)
4. Create your Github Organization
5. Initialize your repositories (don’t write any code just yet besides one initial test and a CircleCI config file!)
6. Create a PR template
7. Create wireframes
8. Construct database schema design
9. Set up your project board with Github projects
   • You’ll be required to use a single board. This will make it easier to see what everyone is working on during the project.
   • You should create cards for your user stories, but it’s okay if all the details have not been adding by the end of week 1. You will add more stories and refine details during your Backlog Refinement meetings.
10. Determine the MVP
    • What do you want to have completed at the end of the project?
    • This can change as the project progresses, just be sure to communicate with the Project Manager
11. Determine Stretch tech
    • One stretch tech for the BE and one stretch tech for the FE. Some techs will be the stretch tech for both FE and BE, such as GraphQL.
12. Pin all the deliverables mentioned above to the Project’s Slack Channel

Note: you should not be writing any code until after your first Project Checkin.

Check-Ins and Demos

Instructors will serve as project managers and hold check-ins. Each check in on the calendar will have specific instructions for what teams should be prepared to present. Here is a list of some of things you will need to do during check ins:

• Project Planning deliverables outlined in the previous section (first project checkin only)
• Demo the Application
• Project board, what is in progress and if the team is expecting to meet deadlines
• 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

Group Communication Expectations

Daily Standups

• During standups, reference your project board to make sure it reflects what each developer is working on.
• Make a team copy of this document.
• Each member should update daily
  • Even if you have a day where you cannot find time to work on the project, you should still be updating the document for visibility.
• Standups should be brief - 10-15 min. If there are blockers, schedule a separate time with the appropriate people to address.
• If you can meet in person (preferred)
  • Discuss standup as a team
  • You can fill out the document as you conduct the meeting.
  • Make use of the project board to track progress on tasks. All work that is being done should be reflected on the project board.
• If you cannot meet in person
  • Fill out the document asynchronously
• Status updates from each team member should be productive and transparent. Consider answering these questions:
  • What work remains on this task?
  • What blockers are you facing?
  • Is there anything the team could help with to move progress along?
  • Any victories you’d like to share?

Pull Requests

• Create PR template
  • You can do this by creating a file called pull_request_template.md in the root of your project
  • If you do not already have one, you can use this example
• PRs should not be merged until reviewed by at least one team member
• Your team is required to complete a PR Review with an Instructor at least two times, once with the FE team and once with the BE team.
  • Tag your instructors for review on the PR
  • The instructors will complete the review on GitHub
  • If needed, the reviewer will reach out to schedule a follow up meeting to discuss
  • Once the review is complete and the necessary changes have been made, the authors can merge the Pull Request.

JSON Contracts

• Create a JSON Contract between FE and BE
• Use BE README to document example requests and responses
• Keep up to date!
• Use mock servers through Postman to mock out responses from the BE while the API is being set up.

Project Board

• Should include MVP user stories, chores, bugs, and spikes
• Should be kept up-to-date and members should assign themselves when working on a card.
• The team should look at the planning board at every stand up to make sure it’s up to date.
• Only one project board used by both FE and BE

Retro and Backlog Refinement

• Weekly retros and backlog refinement is scheduled on the calendar.
• Backlog Refinement:
  1. Review Project board and update cards as necessary
  2. Prioritize cards and ensure everyone is up-to-date
• Retro:
  1. As a team, choose a format and follow guide.
  2. Give Feedback to team members.
  3. Capture summary with screenshot of retro board and include in Slack channel with summary of team’s takeaways. Tag project manager.

Conflict Management

• Despite our best intentions, conflicts some times arise among team members
• Conflicts can often be resolved between team mates
  • Retros are a great opportunity to provide feedback and discuss challenges
• After doing your best to resolve the issue within your team, if you are still having difficulties please reach out to your project managers