MDN/Development/Process: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
No edit summary
 
(21 intermediate revisions by 2 users not shown)
Line 1: Line 1:
The MDN development team follows the [http://en.wikipedia.org/wiki/Scrum_%28development%29 Scrum development framework] to manage its work.
Version: 0.4


== Overview ==
== Purpose ==


The team works in short development periods called <em>Sprints</em>. Each Sprint starts with a [[MDN/Development/Process#Planning_and_Retrospective_Meeting|Sprint Planning meeting]] and ends two weeks later.
This document provides an overview of the process that the MDN development team uses to manage its work. This process is based on [https://en.wikipedia.org/wiki/Kanban Kanban] and other techniques that the team finds to be helpful.


At each Sprint Planning Meeting, the team decides on a subset of features important to the MDN and commits to completing them before the two weeks end. This subset of features is captured in a list called the [[MDN/Development/Process#Sprint_Backlogs|Sprint Backlog]].
== Summary ==


== Artifacts ==
Users and other stakeholders can request changes to the MDN at any time by [https://bugzilla.mozilla.org/form.mdn filing a bug on Bugzilla]. The MDN project manager occasionally reviews these requests and, based on priorities that are identified, chooses some for the team should complete. For each of these, a new Kanban card is created and added to a phase called ''Selected''. Over time, these cards move out of ''Selected'' and through four other phases in order: ''Research & Design'', ''Development'', ''Review & QA'', and ''Released''.


The team maintains a few [http://en.wikipedia.org/wiki/Artifact_%28software_development%29 artifacts] to keep track of work.
<span id="bugzilla-ssot"></span>


=== Product Backlog ===
The team uses Kanbanery and Bugzilla to manage this process. Each Kanbanery card refers to the Bugzilla bug (created by the ''Mozilla Developer Network Feedback'' form) that describes the original request. The team uses the bug to collaborate as progress is made. For example, the team uses the bug to share designs and hold technical discussions.


The <em>Product Backlog</em> is a large list of features that the team plans to implement. The Product Backlog is prioritized by a combination of thoughts from the development team, feedback from users, and strategic planning.
When a phase is completed (see the section [[#Phases|Phases]]), the card is marked as ''Ready'' in Kanbanery. At any point, a team member working in the next phase can pull a ''Ready'' card into his phase and begin working on it. Phases are not skipped when a card is moved. If a phase is not needed for a particular card, the group responsible for that phase simply marks the card as ''Ready'' immediately after it is pulled in.


The team maintains its [http://is.gd/NkQHkd Product Backlog] on Bugzilla. It is currently very large and somewhat difficult to understand, but the team plans to reorganize it soon to make it more understandable to outsiders.
All requests go through this process. The team can elect to work on any requests that interest them by contributing to priority discussions.


=== Sprint Backlogs ===
== Phases ==


At each [[MDN/Development/Process#Planning_and_Retrospective_Meeting|Sprint Planning meeting]], the development team decides what features it should complete in the upcoming Sprint based on the priorities reflected in the Product Backlog. The individual tasks that are needed to complete those features are captured in a list called the <em>Sprint Backlog</em>. A different Sprint Backlog is used for every Sprint.
=== Selected ===


The team maintains its [[http://scrumbu.gs/t/mdn/ Sprint Backlogs]] on Scrumbugs.
One card is added to this phase for each change that should be completed soon.


=== Sprint Burndown Chart ===
=== Research & Design ===


==== Organization ====
The team investigates a technical solution to the change. The team also decides if the change is small enough to be implemented without a detailed design, if a detailed design is needed before development beings, or if the feature is so big that it should be implemented behind a feature flag (allowing the team can iterate on it over time). The card is marked as ''Ready'' when the team feels comfortable starting development.


Features in the Sprint Backlog can sometimes become very broad. To avoid this, the team breaks features down into smaller tasks whenever possible. For example, a feature for user login might be broken down into tasks like "Design interface for user login" and "Talk to Tim about how he implemented user login". Breaking features up in this way makes them less intimidating and helps the team track its progress at a more granular level.
=== Development ===


The team pays special attention to breaking features into smaller tasks when a feature becomes blocked. In general, the longer a feature goes without completion, the more it is broken down.
The development team implements the change. The card is marked as ''Ready'' after a pull request is submitted for the change.


The team finds research tasks to be especially valuable. For example, when starting the user user login feature, the team might create a task like "Research: What services can we use to power login?". The team discusses the question and shares decisions in an associated Bugzilla bug.
=== Review & QA ===


=== Velocity ===
The development team completes a code review and a spot check. Sometimes, additional quality assurance is completed and sign-off is requested from the person (or group) who signed off on the detailed design. The team considers not only functionality but also security, performance, and other important factors during this phase. The card is marked as ''Ready'' when the team is confident that the change works as designed and meets other quality standards.


=== Status reports ===
=== Released ===


The team tracks its progress throughout each Sprint. Each team member shares a status update occasionally as important work is completed. If a member of the team is having a hard time making progress on a task, he or she can add the tag <code>#blocked</code> to his status report to request help from the MDN project manager.
A card is moved here when the corresponding change is pushed to the production server.


The team records its [http://standu.ps/project/mdndev status reports] with a service called Standups.
== Card Management ==
 
=== Work in Progress Limits ===
 
The team uses Work in Progress (WIP) limits to limit the amount of work being done at a given time. A card is not pulled into a new phase if its limit has already been reached.
 
{| class="wikitable" style="background-color: transparent"
! scope="col"| Phase
! scope="col"| WIP Limit
|-
|Selected
|6
|-
|Research & Design
|4
|-
|Development
|5
|-
|Review & QA
|3
|}
 
=== Work Types ===
 
Cards are grouped into three different work types.
 
* BLOCKER - a severely critical defect on the production site; these should interrupt other work
* BUG - a defect affecting the production site
* FEATURE - a new feature
* CHANGE - a change to an existing feature
* DEV - a task to make developers happier
 
=== Size ===
 
Cards are roughly equal in size. If a request seems particularly big, the project manager works with the team to identify a smaller piece to start on. A card is created for that piece and added to the ''Selected'' column. The process is then repeated until the entire request is completed.
 
=== Assignment ===
 
Every card is assigned to someone in Kanbanery, with the exception of cards in the ''Selected'' phase. Assignment is self-directed. The person assigned to a card is not necessarily the only person working on it, but the person ultimately responsible for ensuring that the card becomes ''Ready''.
 
When a person is no longer working on a card, he changes the assignee to ''nobody''. At any point, another team member can assign one of these cards to himself and begin working on it.
 
=== Deadlines ===
 
The ''Deadline'' feature of Kanbanery is used to highlight changes that have hard deadlines. The team and project manager pay special attention to these cards to ensure they are completed on time.
 
=== Subtasks ===
 
The team is encouraged to use the ''Subtask'' feature of Kanbanery to break work into more manageable pieces.
 
=== Blockers ===
 
If a card cannot move forward until some other work is done, that other work is marked as a ''Blocker'' in Kanbanery. The blocker might be another card, the address of a Bugzilla bug, or even just a written description of the impediment.


== Meetings ==
== Meetings ==


=== Planning and Retrospective Meeting ===
=== Priority meeting ===


The team meets at the beginning of each Sprint for a <em>Planning and Retrospective Meeting</em>. The meeting is broken down into two parts.
The product manager and project manager meet every two weeks to discuss priorities. Over time, other MDN stakeholders will be invited to this meeting to inform priority decisions.


==== Retrospective ====
== Planning and Retrospective meeting ==


In the first part of the meeting, the team discusses aspects of its process that have been working well and aspects of the process that could use improvement.
The development team, product manager, project manager and interested users meet every two weeks to discuss process improvements and review the state of development.


All thoughts shared in the Retrospective are reflected on this page. The MDN project manager treats this page like a Developer Bill of Rights, and works to ensure that the policies written here are enforced.
== Working with contributors ==


==== Planning ====
The project manager lists himself as a mentor in bugs that seem like good candidates for contributors. Contributors are encouraged to choose bugs from this list, but can work on any other bugs that interest them.


In the second part of the meeting, the team decides what features it should complete in the upcoming Sprint based on the priorities reflected in the [[MDN/Development/Process#Product_Backlog|Product Backlog]]. The team aims for variety in the features it chooses so that everyone can find something interesting to work on. The team plans to complete about two-thirds of the work it normally completes as reflected in its [[MDN/Development/Process#Velocity|Velocity]]. The remaining one-third of work is left open for other features that developers choose based on their interests. These features are not added to the Sprint Backlog because doing so would complicate our Velocity and cause bumps in our Sprint Burndown chart.
== Tracking Progress ==


After building the Sprint Backlog, the team plays [http://en.wikipedia.org/wiki/Planning_poker Planning Poker] to discuss the tasks in more detail and estimate how long it will take to complete each. If the team realizes that it has taken on too much or too little work, it adds or removes features from the Sprint Backlog accordingly.
=== Visual Overview ===


== Working ==
The [https://mdn.kanbanery.com/projects/32137/board/?key=0383ba5f05e165e0eb19d8476654fe9775ce2ca7 best indication of progress] is the visual overview provided by Kanbanery.
 
=== 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.
=== Written Overview ===


=== Handling development annoyances ===
The team sometimes communicates [http://standu.ps/project/mdndev more detailed progress] using Standup.


Occasionally, the team runs into minor annoyances that affect their development work, such as an error that causes an overwhelming amount of email. These problems are usually not much of a problem on their own, but they can pile up over time. To handle this, anyone affected by these issues 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.
=== Notifications ===


== Updating the MDN ==
The team publishes several RSS feeds that stakeholders can subscribe to for notifications about progress. The status of a card might change by the time a notification is seen, so subscribers are encouraged to always consult the corresponding Kanban card for the most up-to-date information.


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.
* [http://pipes.yahoo.com/pipes/pipe.run?_id=a3d378990547aff38f71f3874fb99b73&_render=rss All team progress]
* [http://pipes.yahoo.com/pipes/pipe.run?_id=635225e2ec8e20390f63d44e2bf52dc0&_render=rss Changes that are ''Ready'' to be pulled into the next phase]
* [http://pipes.yahoo.com/pipes/pipe.run?_id=31bcc67c8ed29426bd10e889850332a0&_render=rss Changes that are being designed]
* [http://pipes.yahoo.com/pipes/pipe.run?_id=de2003d8825b98844ceacda135a3ffcb&_render=rss Changes that have moved into a new phase]
* [http://pipes.yahoo.com/pipes/pipe.run?_id=5cf8dd8eb931c1494aa8f9bc954a1dac&_render=rss Changes that have been released]

Latest revision as of 23:25, 8 July 2014

Version: 0.4

Purpose

This document provides an overview of the process that the MDN development team uses to manage its work. This process is based on Kanban and other techniques that the team finds to be helpful.

Summary

Users and other stakeholders can request changes to the MDN at any time by filing a bug on Bugzilla. The MDN project manager occasionally reviews these requests and, based on priorities that are identified, chooses some for the team should complete. For each of these, a new Kanban card is created and added to a phase called Selected. Over time, these cards move out of Selected and through four other phases in order: Research & Design, Development, Review & QA, and Released.

The team uses Kanbanery and Bugzilla to manage this process. Each Kanbanery card refers to the Bugzilla bug (created by the Mozilla Developer Network Feedback form) that describes the original request. The team uses the bug to collaborate as progress is made. For example, the team uses the bug to share designs and hold technical discussions.

When a phase is completed (see the section Phases), the card is marked as Ready in Kanbanery. At any point, a team member working in the next phase can pull a Ready card into his phase and begin working on it. Phases are not skipped when a card is moved. If a phase is not needed for a particular card, the group responsible for that phase simply marks the card as Ready immediately after it is pulled in.

All requests go through this process. The team can elect to work on any requests that interest them by contributing to priority discussions.

Phases

Selected

One card is added to this phase for each change that should be completed soon.

Research & Design

The team investigates a technical solution to the change. The team also decides if the change is small enough to be implemented without a detailed design, if a detailed design is needed before development beings, or if the feature is so big that it should be implemented behind a feature flag (allowing the team can iterate on it over time). The card is marked as Ready when the team feels comfortable starting development.

Development

The development team implements the change. The card is marked as Ready after a pull request is submitted for the change.

Review & QA

The development team completes a code review and a spot check. Sometimes, additional quality assurance is completed and sign-off is requested from the person (or group) who signed off on the detailed design. The team considers not only functionality but also security, performance, and other important factors during this phase. The card is marked as Ready when the team is confident that the change works as designed and meets other quality standards.

Released

A card is moved here when the corresponding change is pushed to the production server.

Card Management

Work in Progress Limits

The team uses Work in Progress (WIP) limits to limit the amount of work being done at a given time. A card is not pulled into a new phase if its limit has already been reached.

Phase WIP Limit
Selected 6
Research & Design 4
Development 5
Review & QA 3

Work Types

Cards are grouped into three different work types.

  • BLOCKER - a severely critical defect on the production site; these should interrupt other work
  • BUG - a defect affecting the production site
  • FEATURE - a new feature
  • CHANGE - a change to an existing feature
  • DEV - a task to make developers happier

Size

Cards are roughly equal in size. If a request seems particularly big, the project manager works with the team to identify a smaller piece to start on. A card is created for that piece and added to the Selected column. The process is then repeated until the entire request is completed.

Assignment

Every card is assigned to someone in Kanbanery, with the exception of cards in the Selected phase. Assignment is self-directed. The person assigned to a card is not necessarily the only person working on it, but the person ultimately responsible for ensuring that the card becomes Ready.

When a person is no longer working on a card, he changes the assignee to nobody. At any point, another team member can assign one of these cards to himself and begin working on it.

Deadlines

The Deadline feature of Kanbanery is used to highlight changes that have hard deadlines. The team and project manager pay special attention to these cards to ensure they are completed on time.

Subtasks

The team is encouraged to use the Subtask feature of Kanbanery to break work into more manageable pieces.

Blockers

If a card cannot move forward until some other work is done, that other work is marked as a Blocker in Kanbanery. The blocker might be another card, the address of a Bugzilla bug, or even just a written description of the impediment.

Meetings

Priority meeting

The product manager and project manager meet every two weeks to discuss priorities. Over time, other MDN stakeholders will be invited to this meeting to inform priority decisions.

Planning and Retrospective meeting

The development team, product manager, project manager and interested users meet every two weeks to discuss process improvements and review the state of development.

Working with contributors

The project manager lists himself as a mentor in bugs that seem like good candidates for contributors. Contributors are encouraged to choose bugs from this list, but can work on any other bugs that interest them.

Tracking Progress

Visual Overview

The best indication of progress is the visual overview provided by Kanbanery.

Written Overview

The team sometimes communicates more detailed progress using Standup.

Notifications

The team publishes several RSS feeds that stakeholders can subscribe to for notifications about progress. The status of a card might change by the time a notification is seen, so subscribers are encouraged to always consult the corresponding Kanban card for the most up-to-date information.

Retrieved from "https://wiki.mozilla.org/index.php?title=MDN/Development/Process&oldid=995588"