diff --git a/module4/projects/capstone/evaluation.md b/module4/projects/capstone/evaluation.md index 78777c4..16e9be0 100644 --- a/module4/projects/capstone/evaluation.md +++ b/module4/projects/capstone/evaluation.md @@ -9,7 +9,7 @@ layout: page ## Overview -You will notice that much of the rubric asseses: +You will notice that much of the rubric assesses: * Your regular, continual, and active participation in the project * Your ability to collaborate with your team * Your ability to implement features and solve problems while adhering to the project's conventions @@ -18,7 +18,7 @@ As such, you will be assessed throughout the duration of the project rather that ## Self Assessment -Self assessment is a required part of the project. Failure to submit the self-assessment will result in a failure for the project. It is an opportunity for you to reflect on your work, identify areas for improvement, share your successes, and celebrate your accomplishments. Self Evaluation is also common in professional environments. Typically this happens during your annual review (or whatever cadence your company uses). +Self assessment is a required part of the project. Failure to submit the self-assessment will result in a failure for the project. It is an opportunity for you to reflect on your work, identify areas for improvement, share your successes, and celebrate your accomplishments. Self evaluation is also common in professional environments. Typically this happens during your annual review (or whatever cadence your company uses). You should include the following in your self assessment: * Share feedback you have received from at least two teammates @@ -112,7 +112,7 @@ Students are expected to score in the **Meets Expectations** category. If any on * Effectively addresses feedback from code reviews * At least 90% of code is well tested, including sad paths and edge cases * Implements proper error handling - * Demonstrates understanding of code organization principles (e.g., separation of concerns, DRY) + * Demonstrates understanding of code organization principles (e.g., separation of concerns, SRP, DRY) * Maintains a clean and organized codebase, following agreed-upon coding standards - **Approaching Expectations:** * Usually demonstrates a strong understanding of the primary programming language and framework used in the project though occassionally strays from conventions or the project's coding standards @@ -134,9 +134,9 @@ Students are expected to score in the **Meets Expectations** category. If any on * Assists teammates as needed in debugging and problem solving * Regularly seeks out, applies, and offers feedback to improve problem-solving approaches - **Meets Expectations:** - * Consistently breaking down complex issues into manageable components + * Consistently breaks down complex issues into manageable components * Identifies potential problems before they become critical issues - * Shows the ability to adapt existing knowledge to new situations and technologies + * Shows the ability to apply existing knowledge to new situations and technologies * Effectively uses debugging tools and techniques to isolate and resolve issues * Regularly applies feedback to improve problem-solving approaches - **Approaching Expectations:** @@ -155,26 +155,26 @@ Students are expected to score in the **Meets Expectations** category. If any on
### Git Workflow and Deployment - **Exceeds Expectations:** - * Uses Pull Request templates and at least four PRs include specific questions or asks of the code reviewer + * Uses Pull Request templates and at least four PRs include specific questions/asks of the code reviewer * Always creates focused, small pull requests that are easy to review * Rebases before merging * Deletes branches after merging * App has passing CI and is deployed successfully after every PR is merged - **Meets Expectations:** - * Uses Pull Request templates and at least three PRs include specific questions or asks of the code reviewer + * Uses Pull Request templates and at least three PRs include specific questions/asks of the code reviewer * Writes clear and descriptive commit messages following a consistent convention * Creates focused, small pull requests that are easy to review, but one may be larger than expected * Regularly pushes code and keeps the remote repository up-to-date * Uses a new branch for each issue and each Pull Request; Never reuses a branch * App has passing CI and is deployed successfully after almost every PR is merged, with few exceptions (misses no more than twice) - **Approaching Expectations:** - * Uses Pull Request templates and at least two PRs include specific questions or asks of the code reviewer + * Uses Pull Request templates and at least two PRs include specific questions/asks of the code reviewer * Creates focused, small pull requests that are easy to review, but up to two may be larger than expected * Commit messages are usually clear and always professional, but don't always follow a consistent convention * Uses a new branch for each issue and each Pull Request but may accidentally reuse a branch once or twice * App usually has passing CI and is usually deployed successfully after a PR is merged, with some exceptions (misses no more than 3 times) - **Below Expectations:** - * Uses PR templates but fewer than two PRs include specific questions or asks of the code reviewer + * Uses PR templates but fewer than two PRs include specific questions/asks of the code reviewer * Commit messages are often unclear, sometimes unprofessional, and don't always follow a consistent convention * Creates focused, small pull requests that are easy to review, but more than two may be larger than expected * Inconsistently pushes code or pushes directly to `main` diff --git a/module4/projects/capstone/expectations.md b/module4/projects/capstone/expectations.md index 6adc8c9..801791f 100644 --- a/module4/projects/capstone/expectations.md +++ b/module4/projects/capstone/expectations.md @@ -6,13 +6,13 @@ layout: page [Back to Capstone Project Overview](./index.html) ## Onboarding -Everyone will be assigned to an application at the start of the project. You might all be assigned to the same application or you might be assigned to different applications. It will be your project manager's job to make sure you have a good mix of people to work with. We will do our best to match you to a project that is a good fit for your skills and interests. Some projects will be new and some will be existing applications. Most typically, students will be assigned to an existing application so that is where this guide will focus. +Everyone will be assigned to an application at the start of the project. We will do our best to match you to a project that is a good fit for your skills and interests. Some projects will be new and some will be existing applications. Most often, students will be assigned to an existing application so that is where this guide will focus. This project will span 4 weeks. Although you are working as a team, you will be assessed individually. **If it is a new application,** you will be given a project brief with a list of features to implement. Your first several days will be spent planning and designing the technical aspects of the application. -**If it is an existing application,** follow the project's documentation and set up your development environment. This might include setting up multiple apps or services. If anything about the setup instructions are unclear or incorrect, take notes, ask questions, and then update the README with the correct information if applicable. **Plan to spend at least a whole day on setup and getting familiar with the project.** +**If it is an existing application,** you will follow the project's documentation and set up your development environment. This might include setting up multiple apps or services. If the setup instructions are unclear or incorrect, you will be expected to take notes, ask questions, and then update the README with the correct information if applicable. **Plan to spend at least a whole day on setup and getting familiar with the project.**
Pro-Tip: Updating the README is a great way to get familiar with the project and make a first contribution on the job, too! @@ -28,10 +28,10 @@ As you are getting familiar with the codebase, consider the following questions: * What is the data flow in the application? * What is unfamiliar? (different file structures, new packages or gems, etc.) -Take notes on your findings and questions. This will help you as you begin to work on your project as well as be a great resource to come back to when you start your first job. +Take notes on your findings and questions. This will help you as you begin to work on your project and will be a great resource to come back to when you start your first job. ## Working Like a Developer -After the onboarding and setup period, you will be assigned your first feature. Some features will be small and others will be large enough that you will need to break them into multiple issues. You should ask clarifying questions with your project manager as needed. There will be daily opportunities to do this synchronously in the daily check in, otherwise you can use Slack to communicate with your project manager or ask to schedule a call. Your project manager will be the final decision maker on the scope of the feature, but you are encouraged to ask questions and provide input. +After the onboarding and setup period, you will be assigned your first feature. Some features will be small and others will be large enough that you will need to break them into multiple issues. You should ask clarifying questions to your project manager as needed. There will be daily opportunities to do this synchronously in the daily check in, otherwise you can use Slack to communicate with your project manager or ask to schedule a call. Your project manager will be the final decision maker on the scope of the feature, but you are encouraged to ask questions and provide input. As the developer, you are responsible for: * Planning the feature (see below) @@ -48,7 +48,7 @@ As the developer, you are responsible for: * Breaking down the feature into smaller issues if needed AND adding those issues to the project board * Remember, PRs should be focused on a single feature or bug fix. If you are working on a large feature, break it into smaller pieces and submit them as separate PRs. Each PR should have a single purpose and address a single issue. * Choosing the appropriate tools, patterns, and technologies to implement the feature - * This might include discussing tradeoffs with the project manager or other developers + * This might include a research spike and discussing tradeoffs with the project manager or other developers
### Breaking Down a Feature Example @@ -113,10 +113,11 @@ A good rule of thumb for breaking down a feature is to think about the happy pat ## Structure and Rituals of Agile Development (and thus this project) -* Every day you will have a check-in with your project manager where we will discuss your progress, any blockers, and your plan for the day. Usually this will be scheduled in the morning following the Warm Up or immediately after lunch, but depending on your lessons and the project manager's schedule, it may be scheduled at a different time. Occassionally, these will happen on Slack instead. -* You will be assigned issues on the project board and your project manager will expect you to update the issue as you work on it. +* Every day you will have a check-in with your project manager where we will discuss your progress, any blockers, and your plan for the day. + * Usually in the morning following the Warm Up or immediately after lunch. Occasionally, these will happen at an off time or on Slack instead. +* You will be assigned issues on the project board and be expected to update the issue as you work on it. * If your tasks aren't being updated, your project manager will assume you are not working on them which will result in a failing grade. -* You are expected to create new issues for your features as needed and to update the project board with new issues in the backlog as you discover them. +* You are expected to create new issues for your features as needed and to update the project board's backlog with new issues as you discover them. * Retros will be held 2-3 times over the course of the project. * Backlog Refinement sessions will be held 2-3 times over the course of the project. @@ -125,10 +126,10 @@ Work should generally be limited to the scheduled work time hours on the calenda
### What is a... -* **Check-In/Standup**: A brief daily meeting with your project manager where we will discuss your progress, any blockers, and your plan for the day +* **Check-In/Standup**: A brief daily meeting with your team where we will discuss your progress, any blockers, and your plan for the day * **Issue**: A task or unit of work that needs to be completed * **Blocker**: A problem that is preventing you from completing your work or moving forward -* **Backlog**: A list of issues that need to be completed but not yet scheduled +* **Backlog**: A list of issues that need to be completed but are not yet scheduled * **Retro(spective)**: A meeting where we will discuss what went well, what didn't go well, and how we can improve * **Backlog Refinement**: A meeting where we will discuss the issues in the backlog and decide which ones to work on next * **Project Board**: A place to track the status of your issues @@ -167,6 +168,7 @@ Our Project Board will have the following status columns: * Code should be reviewed and approved by at least one other person before merging * Reviews should include comments and suggestions for changes. Just saying "Nice work" is not helpful. See below for more details. * Each team member is expected to provide at least three detailed and feedback-rich reviews over the course of the project + * The developer and the reviewer _equally_ share the responsibility of ensuring broken/breaking code is not pushed to production. * PRs should be reviewed within 24 hours, Monday through Friday, or acknowledged in Slack if and why there will be a delay on the review * Deploy your code immediately after merging your approved pull requests to main **and then visit the production application to ensure your deployed changes are functioning as expected** * Use pull request templates that document and create discussion for finished features diff --git a/module4/projects/capstone/index.md b/module4/projects/capstone/index.md index 3db4484..ba700dd 100644 --- a/module4/projects/capstone/index.md +++ b/module4/projects/capstone/index.md @@ -5,11 +5,11 @@ layout: page --- ## Objective -The overall objective of the Capstone Project is to demonstrate your ability to apply the skills you've learned in this program to solve technical problems in the context of a real project and following professional software development practices. +The overall objective of the Capstone Project is to demonstrate your ability to apply the skills you've learned in this program to solve technical problems in the context of a real project and to follow professional software development practices. ## Learning Goals * Strengthen your ability to apply the skills you've learned in this program to solve technical problems -* Work in a full stack, agile, production or production-like environment +* Work in a full stack, agile production or production-like environment * Research and implement solutions that you have not been explicitly taught * Practice an advanced, professional git workflow