During the project, our team defined a sub-process that we would iterate every week.
Within that process we created distinct roles with responsibilities.  Those roles
and responsibilities are discussed in this page.

- **Author**: Alex Wilkes <[adw4236@rit.edu](mailto:adw4236@rit.edu)>

# Roles
At the start of our project, we did not have well-defined roles and instead just assigned
individuals responsibilities based on what they were comfortable with.  This worked to a
certain extent, but as we developed our process more, we ultimately fell into a few well
defined roles.

![Roles](./images/roles.png)

This cycle spanned over the course of a single sprint, but would start slightly offset.
Each part of this cycle was not only a step in our sub-process, but also our definition
of a role.

## Requirements
This step would involve gathering requirements from the sponsor during the sprint before
those requirements would be worked on.

**Responsibilities**

- Lead communications with sponsor
- Organize and plan meetings
- Work with the sponsor to define requirements

## Mockups
Again, during the sprint before the features would be worked on, someone would be in charge
of converting the defined requirements into mockups that we could present and get confirmation
on.

**Responsibilities**

- Create mockups
- Present mockups to sponsor
- Keep mockups updated during development

## Defining APIs
Once the mockups were agreed on, one person would take the requirements and the mockups and
define the technical details needed for implementing the features.  The definition of the API
was usually sufficient for our team as far as technical details go.

**Responsibilities**

- Convert technical details to API
- Report any technical limitations of the requirements
- Outline the requirements on the Wiki in a readable format

## Development
When the sprint started, the whole team would begin development split into their respective
sections, front-end and back-end.

**Responsibilities**

- Develop their respective parts of the requirements
- Write tests for any new code
- Fix bugs that appeared in previous sprints

## GitHub Standards
At the end of the sprint, everyone would open up their pull requests and perform their code
reviews.  We would ultimately merge to master and kick off our deployment.

**Responsibilities**

- Bug Tracking, ensure bugs are assigned to individuals
- Merging, ensure standards are followed and merge sprint branch to master
- Create next sprint branch according to naming conventions

## Acceptance Testing
Before the final sprint demo, an individual would go over the final result and ensure there
are no major bugs present

**Responsibilities**

- Ensure all requirements were properly implemented
- Record bugs that are present in the system
- Demo the application to the sponsor

## Other Responsibilities
Some responsibilities we assigned individuals that were not part of this process are:

- Scribe notes during meetings
- Track wiki changes and note any updates that are needed
- Azure configuration expert / management
- CI/CD expert / management
- Testing expert / QA, ensures everyone properly tested