Capstone Project

Learning Goals

• Students use an agile process to turn acceptance requirements into deployed software (mastery)
• Students estimate complexity of user stories (functional)
• Students translate acceptance requirements into user stories that are ready to be worked on (mastery)
• Students verify acceptance requirements using automated testing (mastery)
• Students document intent and usage of their code for effective collaboration (functional)
• Students use pull requests to document discussion about features (functional)
• Students divide applications into components and domains of responsibilities to facilitate multi-developer teams (functional)
• Students build applications that execute in development, test, CI and production environments (functional)
• Students apply accessibility best practices when building their applications (functional)
• Students explore and implement new concepts learned in class this module or on their own (mastery)

Overview

The Capstone Project will last around two weeks and will consist of student’s building meaningful, publishable work of their choosing. An instructor will be assigned to each student and act as the Technical Lead.

Technical Expectations

We would like to give you a fair amount of freedom on this project. We want you to bulid something that you’re excited about, and that you’re proud of. These are a few requirements you should consider when pitching and building your project:

• You build something usable. You should be comfortable publishing your project by the time it’s due in week 6. A spike or exploration into a new concept without a clear deliverable won’t be accepted.
• You must apply at least four new techniques, or build your project in a new language and/or framework. New is something from the 4th module (SOA, Security, Continious integration, etc), or something extra-curricular (something not taught in the Turing backend engineering program).
• If you use something cool for your documentation (StopLight, Apiary, Swagger, JSON-API, etc), we will accept it.

Structure of each week

Each student will be responsible for setting priorities for their project and communicating those to their Technical Lead. Throughout the week, each student should be tagging their Technical Lead in PR’s if they have questions or want feedback on any code they’ve written.

During the halfway checkpoint:

• Each student will spend 2 minutes demoing their project to the entire class.
• Each student will self-assess on the rubric below.
• Each student has the option to meet with their Technical Lead who will evaluate their progress via the rubric below.

During the project:

• The student is responsible for communicating to the Technical Lead throughout each sprint if they are not going at a pace to finish what they’ve prioritized.
• The student is responsible for reaching out to their Technical Lead and the community for feedback/assistance on their code.

At the end of the project (week 6):

• Students will demo their project to the entire class.
• Students will be evaluated (in-person with their Technical Lead) on the rubric below.

Rubric

1. Project Planning & Management

Developer uses an iteration map to plan project scope, breaks down broad features into granular tasks, and exercises good Git workflow (e.g., feature branches, descriptive commits, incremental PRs)

• Above Expectations
• Meets Expectations
• Below Expectations

2. Completion & Pace

Developer plans stories ahead of sprint and makes some scope adjustments along the way. Developer communicates adjustments to Technical Lead as soon as possible (if necessary).

• Above Expectations
• Meets Expectations
• Below Expectations

3. Implementation Quality

Project exhibits tested (where applicable), maintainable, and well-organized code. Developer can speak to architecture and implementation decisions and best practices.

• Above Expectations
• Meets Expectations
• Below Expectations

4. Application of Techniques

Developer implements four new techniques or patterns.

• Above Expectations
• Meets Expectations
• Below Expectations

5. Documentation

Developer provides easy to navigate documentation showing how to setup and contribute to the application.

• Above Expectations
• Meets Expectations
• Below Expectations