Project: Final Project Deliverables

Final Due Date: 2024-12-12 11:59PM

Github Classroom
Submission: See detailed submission instructions below.

End of the Project Deliverables

The checklist for the end of the project is largely a superset of the “Sprint 1+” deliverables.

A commit tagged “sprint3” on main pushed to GitHub marking the completion of the sprint (and project).
A set of User Stories or other work items in your sprint backlog tracker assigned to sprint 3 marked as “done”.
Working deployment of the tagged commit demonstrating you application (there should be a valid link in the README of your repository to your deployment so we can find it).
The Github Actions CI build for your tagged commit is passing (“green”).
Each team member has completed the confidential self- and peer-evaluation survey (due 12/12 4:15PM).
Final checkpoint (a checklist, detailed below, to ensure that your project could be handed-off to another team).
Instead of a short demo, you will give a longer final technical presentation.
A short write-up as a team summarizing the project submitted to Gradescope (details below).
A short write-up as an individual summarizing your contributions to and experience working on the project submitted to Gradescope (details below).

Final checkpoint

The final checkpoint is intended to ensure that your project could be “handed off” to a future team for enhancements and maintenance, that is a future CS312 group could get your application “up and running” in both a development and production environment without your help.

Make sure the following is true for your application on the main branch when starting from a fresh clone of your repository:

You can successfully install all dependencies with 💻 npm install.
Executing 💻 npm run dev in the top-level directory successfully starts the application in the development environment. If any additional steps are needed to the run the application in development (e.g. starting a database, migrating and seeding the database, etc.) document those steps (including any commands) in your README.md file.
All tests and linting pass, i.e. the following commands do not give errors (should be true if your CI build passing):
```
💻 npm test
💻 npm run lint
```
Your application can be deployed. All necessary deployment steps should be documented, including any environment variables that must be set, database migrations, etc. In the case of “secret” (or not-secret) environment variables, note that such variables are needed and send any “dot-env” files, e.g., .env.local, to the instructor(s) (don’t include those secrets in your README). For example, “the ‘AwesomeApp’ requires a Google Maps API key and a Google authentication client ID”. Any other information needed to use the application in production, such as an “admin” password, should be similarly documented.

In short, using just the information in your README.md file and any “dot-env” files you send to the instructor(s), we should be able to successfully develop and deploy your application starting from a fresh clone of your repository.

Final Technical Demo

At the end of the semester you will give a 10-15 minute technical presentation about your project. Your presentation should include:

A demonstration of your deployed project. Your demo should include a walk-through of the features from a user perspective(s) as well as a description of any important back-end functionality you implemented (e.g. specialized algorithms, interesting technologies you utilized).
A discussion of the major challenges you faced. These can be both technical as well as challenges of working in a (large) team.
Comment on your scrum process, including:
- What was your final velocity? Did it change over time?
- What changes did you make to your development process based on your Sprint Retrospectives?
With the benefit of hindsight, what, if anything, would you have done differently? What lessons did you learn? Again these can be technical (e.g., we would have designed our application differently) or process-focused.
Future work: What is left to be completed to get to “version 1.0” of your project? What will happen to your application in the future?

We do not expect that everyone will be present or that everyone will actually be a presenter. However everyone is expected to contribute to creating and refining the presentation. If you are not present make sure that you are equivalently contributing to your team in other ways.

We expect your presentation will have three “main” sections:

An introduction, likely using slides, which briefly describes the problem you are solving and provides any background the audience needs to understand your application. For example: Who are your users? What constraints were imposed on your design (by your customer, the College, etc.)?
The demonstration. Your demonstration should be organized and polished. Make a plan for how you will show all the features you have implemented, and what you will say about each. If there is a natural “story” to how users will interact with your application, i.e. first they do ‘X’ then ‘Y’, try to organize your demo around those stories. Some features, e.g. back-end features may not be amenable to demonstration, and instead may be best described with slides.
A description of the process, also likely using slides. Address the questions the above. One of the goals for this portion of the presentation is learn from our classmates experience. I suspect that there will be some common themes, but also unique challenges and solutions that we can all learn from.

Final Team Write-up

As a team, submit a three-page (max) write-up to Gradescope summarizing your project. The report must discuss the following:

What was the original project plan/goal? How much of that plan did you accomplish?
What were some of the challenges in implementing the project?
What were some of the challenges/benefits of the Scrum process from your teams’ perspective?
What changes did you make to your development process based on your Sprint Retrospectives?
What was your team’s “velocity” by the end? Specifically, how much work could your team accomplish during a sprint (state this in whatever terms you were using to score User Story difficulty). Was this consistent over the sprints?

In addition to the above, we should be able to see in GitHub the User Stories/work items and estimated difficulty that you assigned to each Sprint Goal (i.e. what you planned to do for that sprint) and which items were completed by the end of the Sprint (i.e. what you accomplished during the sprint). In an Appendix (which does not count towards your page limit), describe how to find the above information in your tracker (i.e. how Sprint goals are tagged, how “done” is indicated, etc.). If the above information is not available in your tracker, please include it in a table in the Appendix.

We expect that there will be substantial overlap between the final presentation and write-up. That is intended. Think of the write-up as the “take home” accompaniment to your presentation.

Only one group member needs to submit your write-up to Gradescope. When they do so, the submitter should add their group members as shown here.

Final Individual Write-up

As an individual, submit a 1.5-page (max) summary to Gradescope of your overall contributions to and experiences working on the project. Your report must discuss the following:

What were your overall contributions to the project? Certainly use your backlog tracker, GitHub, etc. for reference, but this should be a high-level summary.
Describe your role(s) in the team.
What were some of the challenges you encountered while working on the project?
What were some aspects of project to which you think you were a particularly valuable contributor? These could be technical and/or team/process-focused.

Project Evaluation

The rubric for the project evaluation will be developed with you as a class and your specific team as the project begins and evolves. Note that unlike our programming assignments there isn’t a pre-determined goal, but instead you as a team are defining the “face” of your Mona Lisa. Your project is primarily evaluated on your demonstration of effective development processes, not the end result. However, effective development processes lead to deploying working and maintainable code, i.e., a process that doesn’t produce a deployed application is by definition not effective.

Each project sprint you will receive feedback based on the following metrics:

The deliverables described above
User stories: User stores are INVESTable, cover the work done over the sprint and include relevant supporting information, e.g., lo-fi design sketches, CRC cards, where appropriate.
Agility/scrum: Agility will be demonstrated through a consistent pattern of commits, use of scores to keep track of velocity, and good use of the backlog.
Integration: Your team uses feature branches and pull requests to move your project forward. Pull requests are reviewed before merging into main, and pull requests with failing tests are not merged.
Implementation: The code you produce should be maintainable (i.e., represents “strategic programming”) and supported with tests.
Functionality: The project actually does what was promised by the end of the sprint.

These metrics will be considered for the project as well as for individuals. To facilitate tracking contributions when Pair Programming, use GitHub’s co-authoring feature. Add the following line to the end of your commit message (after a blank line):

Co-authored-by: name <name@example.com>

The key information is the e-mail address, which must be the e-mail address associated with the person’s GitHub account. Each commit can have multiple co-authors.