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 Wednesday, November 1st.

Your team will produce a design document for your feature. This document should be a markdown file in the docs directory of your team’s repository.

Specific git / GitHub Workflow Expectations exist for editing this document and will be graded as part of this sprint. The document should be named after your feature, for example docs/feature-name-design-doc.md. Your team should collaborate on this document in a branch initially named design-doc. After the initial draft is pushed to this branch, every member of the team should create a new branch off of design-doc named design-doc/ONYEN where ONYEN is your UNC ONYEN. For example, design-doc/krisj. Each team member should make contributions to the document in their own branch, then open a pull request to merge their changes into design-doc. Every team member should perform a review, requesting at least one minor improvement in each review, and then after the improvement is made, approving the PR and merging the changes into design-doc. When the team is ready to submit the design document, the team should open a pull request to merge design-doc into stage.

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 and Staging Infrastructure on Carolina CloudApps

The Staging Infrastructure on CloudApps an intermediary deadline of Wednesday, November 1st.

All members of the team should have a working development environment running on their local machine. We began this process in class on Wednesday, October 25th. Steps for setting up a Team Member’s Development Repository can be found here: <exercises/final-project-setup.html#setting-up-team-members-development-repositories>

All members of the team should clean-up their EX04 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 Host Machine (not the VSCode Dev Env!)
3. Login to the OpenShift Terminal on your Host Machine (not the VSCode DevEnv!)
4. Navigate to your project’s directory in the terminal
5. Login to OpenShift’s oc program you installed for EX03. 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 EX03 deployment now that everything is graded:

• Run: oc delete all --selector app=comp423-ex04

Your team should then establish your staging environment(s) on Carolina Cloud Apps, as described here.

3. Practice project management best practices.

Evidence of using PM best practices has an intermediary deadline of Wednesday, November 1st.

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. To gain familiarity with the code base and git workflow to begin making progress.

This first sprint is all about planning before programming and on-boarding with a new code base. We do want to promote some progress, though, to promote a sense of progress and create some momentum going into the next sprint.

After your design document is complete and submitted, identify what the most pressing areas of progress toward your most important story minimally look like. Here are our suggestions:

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 alert messages.
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 to both the front and backend tasks. 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 Sunday, November 5th at 11:59pm and must be successfully deployed to your staging environment and demoable in class on Monday, November 6th.