Sprint 0 Expectations

The goals of this Sprint are to:

1. To produce a high-level design document for your feature.

2. For all members to have their development environment setup and to establish your staging (“production”) infrastructure and begin deploying code to it.

3. To practice expected team workflow and project management practices.

4. To gain familiarity with the code base and begin making progress.

1. The Design Document

The Design Document has an intermediary deadline of Monday, March 25th.

Your team will produce a design document for your feature. For now, begin writing this in a shared Google Doc with your team. This document will ultimately be markdown file in the docs directory of your team’s repository.

ChatGPT and/or other generative AI tools are not permissible for use in writing this design document. There are at least 3 of you on the team, but generally 4, so between you all there is more than ample time and English-writing ability to craft this relatively short document. The primary value of this document is the thinking, team communication, and internalization of the problem you are trying to solve more than the resulting document itself. If writing produced by generative tools is detected in your design document submission, your group risks earning a 0% for this Sprint which amounts to 12.5% of your final course grade.

The markdown document file should contain well written:

0. Title & Team: Title Your Feature (It can be more creative than the requested CFP Titles) and attribute your team members.

1. Overview: Restate the value and need of the feature in your team’s own words.

2. Key Personas: Describe the key personas your feature serves. What are their needs and goals with your feature?

3. User Stories organized by persona, necessity for a minimum-viable feature, and frequency/importance of use.

4. Wireframes / Mockups: Include rough wireframes of your feature’s user interfaces for the most critical user stories, along with brief descriptions of what is going on. These can be hand-drawn, made in PowerPoint/KeyNote, or created with a tool like Figma. To see an example of a detailed wireframe Kris made this summer before building the drop-in feature, see this Figma board. You will notice the final implementation is not 1:1 with the original wireframe!

5. Technical Implementation Opportunities and Planning

   1. What specific areas of the existing code base will you directly depend upon, extend, or integrate with?
   2. What planned page components and widgets, per the assigned reading, do you anticipate needing in your feature’s frontend?
   3. What additional models, or changes to existing models, do you foresee needing (if any)?
   4. Considering your most-frequently used and critical user stories, what API / Routes do you foresee modifying or needing to add?
   5. What concerns exist for security and privacy of data? Should the capabilities you are implementing be specific to only certaain users or roles? (For example: When Sally Student makes a reservation, only Sally Student or Amy Ambassador should be able to cancel the reservation. Another student, such as Sam Student, should not be able to cancel Sally’s reservation.)

2. Establish Development Environments

To establish your course repository, team project board, and local development environment, please follow the instructions in class on 3/22 found here.

3. Practice project management best practices

Team tasks that are delegated out should be added to your final project board(s), given meaningful descriptions or subtasks, assigned to appropriate team member(s), and updated as progress is made. All cards on the project should also be linked to issues in your team repository. This practice is a slight deviation from industry, where non-codebase related project management and tasking may occur in another tool, but for simplicity purposes we will keep all project management concerns in GitHub to gain comfort with the tool and for standardization in the class.

Changes to the codebase, as described in the design document expectation, should be made on branches and pushed to branches before being Pull Requested and Code Reviewed by a team member. This will simultaneously slow down progress and increase your team feature’s quality and increase shared understanding of the codebase which is a worthwhile trade-off in software engineering.

4. Use git workflow to begin making progress.

After your design document is complete, identify what the most pressing areas of progress toward your most important story minimally look like. Here are places to begin. See the Gradescope submission for more details on what is expected:

Front-end

1. Add a new Component Page and/or Widget(s) to the front-end. All UI must use standard Angular Material UI library widgets wherever possible.
2. Add an Angular Service to the front-end and stub out method signatures with dummy data and console.log messages as needed for verification of methods being called.
3. Connect interactivity of Step 1 to the front-end service methods of Step 2.
4. Be sure your Component Page and/or Widget(s) are navigable through the application (if a full page: add an appropriate link or sidebar link, if a widget: add it where it will ultimately show up)

Back-end

1. Add new route(s) to the API as will be needed by the front-end component/widgets above.
2. Extend with additional fields or add new Pydantic data models for the route(s).
3. Stub out responses such that your /docs OpenAPI user interface responds with expected model data.

You should divvy up tasks on your project board and pair program. We encourage everyone tries to contribute something small that spans both both the front and backend. Do not divide work by breaking up frontend from backend, divide by taking on features that span the full stack across pairs. Everyone is expected to make at least one Pull Request outside of the design spec. The Pull Request should have at least one additional improvement commit that improves based on a Code Reviewer’s suggestions. This PR should ultimatey be approved and merged into Stage ahead of the deadline. After final approval, it is the author’s responsibility to merge the changes in and write the final commit message for your merge. When merging, you should “Squash and Merge” the commits into a single, well documented commit. Commit messages should follow the expectations of our reading on writing commit messages well.

Everyone is expected to serve as a Code Reviewer for at least one Pull Request. As a Code Reviewer, you are expected to find and request at least one improvement to the PR. Once the PR author addresses your concerns with improvement commit(s), you should review and approve the PR author to merge in the changes.

The small steps of progress made in this section will be due by Monday, March April 1st at 11:59pm and must be successfully deployed to your staging environment and demoable in class on Wednesday, April 3rd.

5. Establishing CloudApps Deployment

All members of the team should clean-up their prior OKD cloud deployment to make room for deploying the final project. The steps to follow are:

1. Login to OpenShift (remember: off-campus access requires connecting to the VPN)
2. Open a Terminal on your Dev Container
3. Login to the OpenShift Terminal on your Host Machine
4. Navigate to your project’s directory in the terminal
5. Login to OpenShift’s oc program. You will need a new token from OpenShift: Click your name after logging in, select Copy Login Command, Display Token, copy the oc login ... line, paste into Terminal.
6. Go ahead and delete your EX01 deployment now that everything is graded:

• Run: oc delete all --selector app=ex01

Instructions for OKD deployment of final projects coming soon.