knowledge-kitchen

Project Kickoff (within an Agile Software Development Course)

Setting appropriate expectations

1. Ready, Set, Go!
2. Division of Labor
3. Discord
4. GitHub
5. Product Backlog
6. Planning Poker
7. Sprint Backlogs
8. Task Boards
9. Git
10. Daily Standups
11. Conclusions

Ready, Set, Go!

Kickoff

Teams are know working on their projects. Let’s make sure your workflow and expectations are in order.

Sprints

Work is divided into increments:

• Sprint 0 - quick prototyping
• Sprint 1 - focus on front-end development
• Sprint 2 - adding in back-end development
• Sprint 3 - adding in database integration
• Sprint 4 - finishing what you’ve started

Expectations

• Teams divide labor fairly and wisely.
• Teams communicate primarily in-person and through Discord.
• Teams use GitHub as both a central code repository and a project management tool.
• The Product Backlog represents the full list of user requirements of the project. It gets updated regularly.
• Teams estimate work using Planning Poker cards.
• A Sprint Backlog shows which user requirements are being worked on during the current Sprint.
• A Task Board shows the up-to-date status of all work at all times.
• Individuals use Git systematically to isolate code and track changes.
• Teams meet primarily in person for Daily Standups.
• At the end of each Sprint is the release of a working, but incomplete, product.

Division of Labor

Wise Use of Human Resources

• Do not dedicate some humans to front-end development and others to back-end - share all responsibilities.
• Do not let some members do all the database work - share the responsibilities.
• Do teach each other what some of you know - if teammates flounder, the whole team will suffer.
• Do not allow one person to dominate the role of Product Owner - switch roles every Sprint.
• Do not allow one person to dominate the role of Scrum Master - switch every Sprint.
• Do not assume your stakeholders (Professor, Tutor, Grader) will always tell you what to do and how to do it - take initiative.

Discord

Channels

Each team must have two private channels set up in Discord, e.g.:

• team_octapus - general discussion
• team_octapus_standups - after each standup, document each member’s answers to the three questions

Key stakeholders - professor and any course assistants, tutors, and graders - must be invited.

Organization

Each team is a member of the larger course organization.

All teams are using the same general technologies and facing the same problems.

Communicate with other teams via Discord. Help each other. Take initiative.

GitHub

Repository

All team members have access to their project’s GitHub repository.

All repositories must include:

• README.md - an always up-to-date overview of the project
• CONTRIBUTING.md - detailed instructions that govern participation in the project
• .gitignore - a Git settings file that instructs git to not track certain directories and files

Gitignore

Each repository must include a file named .gitignore in the root directory that instructs git to not track certain files and directories.

This file must instruct git to ignore (i.e. not track):

• platform code - e.g. React.js itself, Node.js itself, etc
• 3rd party library code - e.g. any installed Node.js modules, python packages, etc
• any files containing authentication credentials - e.g. database username/password, Spotify API credentials, etc.
• any files containing personal information - e.g. if your app stores data about users in files or databases, don’t track those

Here is an example general-purpose .gitignore file.

Product Backlog

User Stories

Before work on a project can begin, it must have an initial Product Backlog - a set of user requirements for the project written in User Story form.

Issues

Every GitHub repository has an Issues tab where User Stories in the Product Backlog should be written and stored.

• User Stories in the Product Backlog must be listed in order of importance

• more about GitHub Issues
• more about the Product Backlog

Label

Create an Issue for each User Story in the Product Backlog and assign it the user story label to differentiate it from other types of Issues.

• more about GitHub Labels

Issue Numbers

Once created, each Issue in GitHub is automatically assigned a unique Issue number.

You will use these numbers:

• to link up Tasks to their associated User Stories.
• to link up Git branches to the issues they are meant to implement

Issue Templates

Your use of GitHub’s Issues feature must also make use of GitHub Issue Templates:

1. Download a set of Issue Template Markdown files.
2. Place these example Markdown files into a directory in your repository named .github/ISSUE_TEMPLATE/.
3. Push them to the GitHub central repository.
4. Now every time you create a new User Story, Task, or Spike, GitHub will offer for you to use one these as a starter template.

Planning Poker

Work Estimation

At the start of each Sprint, team members discuss each User Story they are considering including in the new Sprint.

The group will often assign each User Story an estimated level of effort using Planning Poker or some other agreed-upon estimation scheme.

Fibonacci

In planning poker, every member of the team must print a set of Fibonacci-based planning poker cards.

• Find a deck you like or design your own.
• Include a link to your deck on the CONTRIBUTING.md file.
• Bring them to Sprint Planning meetings.

Sprint Backlogs

Selecting User Stories

Those User Stories selected for the current Sprint are added to the Sprint Backlog.

In addition to the basic requirements for User Stories in the Product Backlog, User Stories in the Sprint Backlog must be assigned:

• a GitHub Milestone representing the current Sprint
• an optional Estimate of Effort required to complete the User Story
• an optional set of Acceptance Criteria for the User Story

Tasks

Each User Story selected for the current Sprint is immediately broken up into Tasks.

A Task is a unit of work that would ideally take one developer one day.

Task Requirements

• The description of each Task includes a reference to the User Story to which it belongs - writing the User Story’s Issue ID number, e.g. #22, in the Task description will create a link to it.
• Each Task is assigned to a specific developer
• Each Task is saved as a GitHub Issue with the label, “task”.
• Each Task is assigned the GitHub Milestone representing the current Sprint.

Spikes

Any work to be done that does not relate directly to a user requirement is documented as a Spike.

In GitHub, spikes are treated like Tasks in all respects except that they are labeled “spike”, not “task”.

Spike Requirements

• Each Spike is assigned to a specific developer
• Each Spike is saved as a GitHub Issue with the label, “spike”.
• Each Spike is assigned the GitHub Milestone representing the current Sprint.

Proper Attribution

If the nature of the work requires a particular Task or Spike to be done independently by each developer, it must be split into separate Tasks or Spikes with each assigned to a single team member.

For example:

• If all team members must learn Node.js during Sprint 0, then each team member has an individual responsibility to complete this.
• There must be a distinct Spike on the Task Board for each team member indicating the current status of their personal work completing this.

Task Boards

Concept

Each GitHub repository has a Projects tab, where Task Boards can be linked.

Make one Task Board for each Sprint. If your team were named Octapus, name your task boards:

• Team Octapus - Sprint 1
• Team Octapus - Sprint 2
• Team Octapus - Sprint 3
• Team Octapus - Sprint 4

Columns

Each Task Board must have the following columns:

• Sprint Backlog (User Stories) - the list of User Stories selected for this Sprint.
• To Do (Tasks) - the list of Tasks and Spikes that have not yet begun
• In Process (Tasks) - the list of Tasks and Spikes that are currently being worked on
• Awaiting Review (Tasks) - the list of Tasks and Spikes that are complete and awaiting peer review
• Done (Tasks) - the list of Tasks and Spikes that are complete and have passed peer review.

Starting State

At the start of each Sprint, the current Task Board in GitHub must contain:

• the full list of User Stories selected for this Sprint in the “Sprint Backlog (User Stories)” column
• the full list of Tasks and Spikes in the “To Do (Tasks)” column

Changing State

The state of the Task Board must be kept up-to-date at all times.

• User Stories always stay in the “Sprint Backlog” column
• Tasks and Spikes move around - as developers work on their own assigned Tasks and Spikes, they are personally responsible for moving them to the appropriate columns.

Missing Work

Your performance evaluation/grade depends upon you accurately listing all work you are doing on the Task Board at all times.

If you are doing work whose existence or status is not accurately reflected on the Task Board, you are not doing Agile Development and you will not receive credit for it.

• more about GitHub Task Boards

Git

Matching Credentials

The git username and email you use on your local development machine must match exactly your GitHub account login name and email.

git config --global user.name "monalisa"
git config --global user.email mona.lisa@louvre.org

Matching Credentials (continued once more)

Once you’ve made a few commits and pushes via git and tried opening and merging a Pull Request or two on GitHub, take a look at your git logs to verify that your usernames are consistently the same.

1. Check that your usernames match: run git config user.name to see your git username on your local machine - this is your git username. Make sure it is exactly the same as your login name on GitHub.
2. Look at your git logs: run git log. Hit the space bar to scroll through the logs and hit q to quit when you’re done. Check your username as it shows up in the logs… is it always correct for every log entry and does it match what you see in your grading emails? If so, you’re done. If not, continue…
3. If your usernames don’t match, then run this: git config --global user.name "monalisa", where monalisa is replaced with your GitHub login name. Now your usernames match!

Turn off rebasing

git has two ways it can handle pull events, where changes from a remote repository are downloaded and integrated into the local repository: merge and rebase. We want to use merge because this maintains the full history of the project, whereas rebase changes the history to make it simpler and you thus may not receive credit for your full contribution to a project.

To turn off rebasing and use regular merging, you must run this command:

git config --global pull.rebase false

Read more about rebase vs. merge if interested - note the last section of the document.

Turn off rebasing (continued)

When merging pull requests on GitHub, you must always use the “Create a merge commit” option, never the “Rebase and merge” option, for the same reason.

Clone

Each team member must clone their team’s remote GitHub repository to their development machine.

Branches

Requirements:

• Make all changes to the code in isolated branches.
• Create a new branch for every Task or Spike under development.
• Never work directly in the main branch.
• Name branches after the User Story and Task/Spike which they are intended to implement, including: – the user story issue number (if any) – the task or spike issue number – a shorthand name for the branch that describes what changes it includes

Examples:

• A branch intended to implement Task #9, which is part of User Story #13:

git checkout -b user-story/13/task/9/implement-user-login

• A branch intended to implement Spike #27:

git checkout -b spike/27/learn-react-js

Peer Review

The developer who makes changes must never be the one to merge their own branch into the trunk.

1. The developer making changes must push their completed branch to GitHub and then issue a Pull request to the main branch
2. The same developer must, of course, update the position of the relevant Task that this branch implements on the Task Board.
3. A second developer must review the changes in the pull request, approve them if good, and merge them into main.

Both developers are responsible if poor quality code is integrated into the main branch.

• more about the Feature Branch Workflow

Daily Standups

Concept

Every morning, the entire development team gets together. Everyone quickly and honestly answers three questions:

1. What did you do yesterday (or since last meeting)?
2. What are you doing today (or until next meeting)?
3. Do you have any problems that are blocking your progress?

Documentation

The current Scrum Master must document each team member’s answers to the three questions and post them to their team’s Discord standups channel.

Include the Discored handle of each member and their responses and whether they were in-person or remote, e.g.

@foo_barstein (in-person, synchronous):
- did: Completed 95% unit testing code coverage of codebase
- doing: Implementing the Observer design pattern
- blocking: Nothing

Include notes for all team members in a single post.

Honesty

All teams must include in their Team Norms that team members agree to answer the Daily Standup three questions honestly and fully.

It is in all team members’ interests to report blocking problems or underperforming team members to their “managers” immediately.

If a team member is doing the same work for several Standups in a row, yet is not reporting any blocking problems, this is a sign of a big problem for the entire team.

• more about Daily Standups

Conclusions

Thank you. Bye.