Roles
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>
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.
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.
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
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
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
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
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
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
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