Rubric

Rubric

You will be graded by an instructor on the criteria below. The rubric below outlines the key areas in which you will be graded. The rubric items below are in order of importance in how you will be graded for this final project.

Important:

You will be required to test drive your code, as it will lead to higher quality software. It also catches any bugs and increases productivity throughout the duration of your project.

Project management will also be required. It is one of the most essential elements in building successful software. The use of creating well written user stories on an agile board will result in quicker implementation and higher quality software for the end user. If the agile process is followed, the developer will be well organized and will set themselves up for success in whatever project they are focused on.

Project Management/Agile Practices

• 4: Developer satisfies all criteria below in section three. Developer creates 10 additional cards that focus on research spikes, code reviews, and chores for dedicated code refactors. Developer creates additional agile board columns for quality assurance, code review, and current deployments.

• 3: Developer regularly uses an agile board of their choosing. Before starting to code, they write user stories that focus on each individual feature that will be created in the application. Each user story will contain a descriptive title in relation to the feature being built. Each user story will also contain information pertaining to the feature being built within the description of the card. This may include steps that a user may need to do in order to achieve their goal, or expected request/response data that may be seen during the use of an API. Developer is able to articulate the agile process during the project evaluation.

• 2: Developer creates an agile board but uses it sparingly after the initial start date of the project. Developer creates a few stories but never pulls them into their respective columns at the appropriate time. Most stories do not have written descriptions.

• 1: Developer creates an agile board but doesn’t utilize it for the duration of the project.

Git Workflow

• 4: Developer satisfies all criteria below in section three. Developer demonstrates their git workflow as being 100% consistent in regards to the creation of branches, issuing pull requests, using PR templates, asking for feedback, and writing clear and concise commit messages.

• 3: For each feature listed on their agile board, the developer has created a branch on git. Developer pushes their changes to their respective branches found on Github. Developer opens pull requests for every branch they create. All commit messages will be in present tense, start with a capital letter, and be consistent for the duration of the project. If on a paired or group project, developers must tag other collaborators in their PR’s and ask for feedback before merging in their changes.

• 2: Developer creates pull requests on separate branches but often pushes directly to master. Developer is inconsistent in how they write commit messages. Some commit messages lack clarity and purpose for the code submitted. Developer may tag collaborators at times.

• 1: Developer only pushes to master, never creates branches for their features work, and has very few commit messages at the end of the project. Commit messages are not informative and lack clarity as to what each piece of code is focused on. Commit messages are not consistent and lack proper structure across the project history.

Software Quality/Feature Functionality

• 4: Developer satisfies all criteria below in section three. Developer demonstrates additional features that goes beyond the standard scope of the project. This could include adding more functionality that was not outlined by the standard back-end spec.

• 3: Developer demos their application and proves that all specified functionality works properly. This includes any extensions that are required of the developer. Developer demonstrates that no bugs are present and that edge cases have been accounted for. This also includes demonstrating that the application has been deployed to a production server.

• 2: Developer demos their application and proves that the specified functionality does not work properly. For specifically, this may include one to many features not working properly. Developer demonstrates that bugs still exist in their application. The application has not been deployed to a production server.

• 1: Developer demonstrates that the majority of the application’s core functionality does not work. The application has not been deployed in any capacity.

Presentation and Defense

• 4: Developer satisfies all criteria below in section three. Presentation is in line with one that would be presented during a demo competition. This includes slides that focus on their story, passion, and clarity in decision making.

• 3: Developer clearly presents their individual process and approach to how they completed the project. Developer comes to evaluation with a prepared presentation. Developer shares the pros and cons of their decision making for the duration of the project.

• 2: With several prompts, the developer was able to speak to their development and decision making process. Developer was unable to defend their decisions with solid rational.

• 1: Developer comes to evaluation unprepared with a structured presentation. Developer has a difficult time communicating their process.

Testing

• 4: Developer satisfies all criteria below in section three. Test coverage is at 90% and above. This coverage includes happy/sad path and a majority of edge cases.

• 3: Developer codes and uses test driven development during all iterations. Test coverage must be at 75% and include happy/sad paths. Tests will also be run using a continuous integration tool such as TravisCI.

• 2: Developer codes and uses test driven development during some iterations. Test coverage must be at 25% and include happy paths. A continuous integration tool such as TravisCI is not used for the duration of the project.

• 1: Developer codes and does not use test driven development for the duration of the project. No specs can be run at any time.

Documentation

• 4: Developer satisfies all criteria below in section three. Developer contributes additional information. This includes links to their agile board and any available production links.

• 3: A thorough README is found in all related repositories. A README contains sections such as Introduction, Initial Setup, How to Use, Known Issues, Running Tests, How to Contribute, Core Contributors, Schema Design, and Tech Stack List. If the product is front-end focused, screenshots of the application will be required. Each section is thoroughly filled in with important information for visitors of your application’s repo.

• 2: A thorough README is found in all related repositories. A README contains sections such as Introduction, Initial Setup, How to Use, Known Issues, Running Tests, How to Contribute, Core Contributors, Schema Design, and Tech Stack List. Each section is not filled out thoroughly

• 1: A default README is found in all related repositories. No additional sections have been added. Developer has not added any related information to the project.