MDN/Development/Process: Difference between revisions
No edit summary |
|||
| Line 59: | Line 59: | ||
=== Handling minor problems === | === Handling minor problems === | ||
Occasionally, the team runs into minor errors, usually in the form of error emails. These problems are usually not much of a problem on their own, but they can pile up over time. To handle this, the person affected should open a bug with the keyword [dev-papercut] in the status whiteboard. The team will watch a list of [ | Occasionally, the team runs into minor errors, usually in the form of error emails. These problems are usually not much of a problem on their own, but they can pile up over time. To handle this, the person affected should open a bug with the keyword [dev-papercut] in the status whiteboard. The team will watch a list of [http://mzl.la/UeVyMo ignored papercuts] to make sure they don't pile up. | ||
== Updating the MDN == | == Updating the MDN == | ||
During the sprint, we occasionally add our new features to the MDN by pushing code to our production server. We push about once per week (usually on Tuesdays or Thursdays) and avoid pushing on Mondays and Fridays. | During the sprint, we occasionally add our new features to the MDN by pushing code to our production server. We push about once per week (usually on Tuesdays or Thursdays) and avoid pushing on Mondays and Fridays. | ||
Revision as of 00:58, 20 September 2012
The MDN development team loosely follows Scrum to manage its work.
Overview
We work in short development periods called Sprints. A Sprint starts with a Sprint Planning Meeting (see the section Planning and Retrospective Meeting) and ends two weeks later.
During each Sprint, we work on a subset of features important to the MDN. These features are captured in a list called a Sprint Backlog (see the section Sprint Backlogs).
Documents
Product Backlog
Our Product Backlog is maintained on Bugzilla.
The Product Backlog is a large list of features that we plan to build, prioritized by a combination of thoughts from the development team, feedback from users, and strategic planning. Priorities are re-evaluated according to these criteria before each Sprint.
Oour Product Backlog is currently very large and somewhat difficult to understand. We are planning to soon reorganize it to make it more understandable to people outside of the development team.
Organization
At times, features in the Product Backlog can become unnecessarily broad or vague. To avoid this, we should break features down into smaller actions when necessary. For example, we might break up a feature about searching for demos by creating subtasks like"Create a mockup for demo searching" and "Research the tools that we could use to power demo searches".
We should pay special attention to breaking things down when features become blocked. For example, if a feature has been planned in more than one Sprint without much visible progress (or even if a feature does not make much visible progress during the course of one Sprint), we could break that feature down into front-end and back-end components and complete one piece at a time.
Sprint Backlogs
Our [Sprint Backlogs] are maintained on Scrumbugs.
At each Sprint Planning Meeting, we look at the highest priority features on the product backlog and decide which ones we should complete during the upcoming Sprint. We capture these features in a list called the Sprint Backlog. Each Sprint has its own Sprint Backlog.
Daily Scrum
We record our Daily Scrums with Standups.
We use a status reporting service called Standup to share our progress during a Sprint. We post status updates occasionally as important work is completed. If someone is having a hard time making progress on a task, he adds the #blocked tag to his status report so that John can help.
Meetings
Planning and Retrospective Meeting
We meet as a team once every two weeks for a Planning and Retrospective Meeting. This meeting is broken down into two parts.
Retrospective
During this part of the meeting, we discuss aspects of our process that have been working well, and aspects of our process that could use improvement. John updates this page based on our discussions.
Planning
In the second part of the meeting, we build a new Sprint Backlog by looking at the Product Backlog and deciding which of the features we should complete in the upcoming Sprint. We try to keep a good balance of variety in the bugs we choose -- some front end, some back end, etc. -- so that everyone has something to work on that interests them. We plan for about two-thirds of our Sprint velocity (the amount of work we normally complete in a Sprint), and leave the last third open for other features that developers choose based on their interests.
After building the Sprint Backlog, we play Planning Poker to discuss the features in more detail and estimate how long it will take us to complete them. If Planning Poker reveals that we taken on more or less work than we usually complete, we add or remove features to the Sprint Backlog accordingly.
Working
Assignment
Between the start of the Sprint and the end of the Sprint, the development team works on the features that they added to the Sprint Backlog. When a developer knows that he will be working on a particular feature, he assigns that feature to himself. When he knows that he will no longer work on it, he updates the feature to be unassigned so that someone else can begin working on it.
Handling minor problems
Occasionally, the team runs into minor errors, usually in the form of error emails. These problems are usually not much of a problem on their own, but they can pile up over time. To handle this, the person affected should open a bug with the keyword [dev-papercut] in the status whiteboard. The team will watch a list of ignored papercuts to make sure they don't pile up.
Updating the MDN
During the sprint, we occasionally add our new features to the MDN by pushing code to our production server. We push about once per week (usually on Tuesdays or Thursdays) and avoid pushing on Mondays and Fridays.