Every individual and group must complete the following kickoff process to have the tools setup to allow them to collaborate effectively on team projects.
Each team will decide, using whatever decision-making process they prefer, on which two members will fill the initial roles of Scrum Master and Product Owner.
- all team members, including Scrum Master and Product Owner, are also Developers - everyone is expected to do the design and code work in every sprint.
- these roles must shift every Sprint, so each team member should fill each role at least once.
- each team must announce which team members are Scrum Master and Product Owner at the start of each Sprint
Slack is each team's primary communication tool. Each member's communications and contributions within Slack are tracked and used towards grading. Communications within private channels are not visible to the Professor and therefore will not be considered when grading.
Each team must have at least one Slack channel where the professor, course assistants, graders, and tutors are also invited to be members:
- use this channel for general team communication
- individual participation in this and other channels may be used towards each member's grade
Channel names must be short and consistent. For example, if a team is named octopus, their main channel might be called team_octopus
GitHub is each team's primary resource for version control, project planning, issue tracking, and project documentation. Each member's contributions within GitHub are tracked and used towards grading.
GitHub repositories have been created for each team and are in the control of the team. There are several key files that all repositories must have properly set up.
Every project must have a README.md that automatically renders on the project's main repository page with basic details of the project, including:
- a description of project, including the Product Vision Statement
- the core team members, including links to their GitHub accounts and any other web presence they have
- a short history of how the project came to be and information about how to contribute to the project (i.e. a link to the CONTRIBUTING.md document)
- instructions for building and testing the project (update with that information once the project reaches that stage)
- links to any additional Markdown documents or web pages that may be relevant reading about the project
- anything else you think is important to communicate to people viewing the project
Each team must collaboratively draft a CONTRIBUTING.md - a Markdown document exclusively dedicated to how others can contribute to this project. This document is essentially a contract agreed-upon by all developers and contributors, and includes at a minimum:
- the project's values and team norms, including the definition of "done"
- the Git workflow that the team follows
- a detailed description of the rules of contributing and any considerations or how and what to contribute
- how disagreements or conflicts among team members will be resolved
- instructions for setting up the local development environment in order to work on this project
- instructions for building and testing the project (update with that information once the project reaches that stage)
This documents allows potential contributors, whether in the open source community or in a private organization, to see the project's rules and processes for contributions. It should be well-formatted with clear headings and subheadings.
GitHub provides a link to this document automatically to any user who creates a Pull Request on this project.
Each repository must have a .gitignore file that informs git not to track platform code, 3rd party library code, and other common development artifacts that are not your own code. It is also imperative to not track files that contain sensitive information, such as usernames/passwords to a database, or files containing users' personal information.
Use this example .gitignore file for Node.js-based web apps as the baseline for your .gitignore file.
Each team must create a set of labels for using within GitHub's Issues tracker. Labels allow you to tag an issue in a particular category or context for easy filtering later.
Begin by creating the following labels. Once you begin development, every Issue in GitHub's Issues tracker must be assigned one of these labels:
user story- to be used for all user storiestask- to be used for all tasksspike- to be used for all spikes.
Feel free to create other labels that are useful to your team.
Each team must have a set of Milestones to represent each Sprint within GitHub's Issues tracker:
Sprint 0Sprint 1Sprint 2Sprint 3Sprint 4
What to include in each Milestone's settings:
- a description of the big picture idea of what the Sprint is aiming to achieve
- the due date for the Sprint, as indicated by the due date of the Stakeholder Demos on the course schedule
Once a particular sprint has begun, all issues representing tasks that have been decided to be addressed within that sprint must be assigned to the proper Milestone representing that sprint.
Each team must create a project board for each of the four Sprints following these setup instructions.
Each team member must clone their team's GitHub repository onto their own local machine and push any changes they make back to GitHub at regular inteverals - usually every few days at the least.
Each team must have an initial product backlog of user stories based on their understanding of the project requirements so far.
- each item in the product backlog must be added as an Issue to GitHub's Issue tracker
- follow the recommended workflow for adding issues to GitHub's issue tracker
- make sure all user stories in the product backlog have appropriate labels attached to them:
- user stories have the
user storylabel - spikes have the
spikelabel - other types of tasks have the
taskslabel - etc.
- user stories have the