MDN/Development/Process: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
(Replacing process with Kanban 0.1-pre)
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.1-pre
 
<div class="toclimit-3">__TOC__</div>
 
== Purpose ==
 
The MDN team plans to adopt Kanban to manage its work. The team feels that Kanban better fits its style of working and provides benefits that align with current goals.
 
This document describes and early, minimum viable Kanban process. The team will use and refine this process over time. When the process reaches a certain level of maturity, the team will request feedback more widely and use that feedback to formalize a process that all stakeholders are pleased with.


== Overview ==
== Overview ==


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.
Users and other stakeholders can request changes to the MDN at any time using the [https://bugzilla.mozilla.org/form.mdn Mozilla Developer Network Feedback] form. The MDN Project Manager occasionally reviews these requests and decides which ones the team should complete based user and stakeholder feedback. 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 five other phases in order: ''Design'', ''Technical research'', ''Development'', ''Review & QA'' and ''Released''.


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. The tasks needed to complete those features are captured in a list called the [[MDN/Development/Process#Sprint_Backlogs|Sprint Backlog]].
The team uses Kanbanery and Bugzilla to manage this process. Each Kanbanery card references the Bugzilla bug (created by the ''Mozilla Developer Network Feedback'' form) that describes the original request. During development, the bug is used to collaborate and share progress. For example, the team might use the bug to share mock-ups or hold technical discussions.


== Artifacts ==
When the ''Ready criteria'' are met for a phase (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 occasionally skipped. For example, a card that describes a technical change that has no direct impact on design can skip the ''Design'' phase. When this happens, the team member who skips the phase updates the bug with a written justification.


The team maintains a few [http://en.wikipedia.org/wiki/Artifact_%28software_development%29 artifacts] to keep track of work.
All requests go through this process. The team can elect to work on any requests that interest them, but they are first approved by the Project Manager (to ensure they balance with other priorities) and go through the same phases (to ensure quality).


=== Product Backlog ===
== Phases ==


Available at: [https://bugzilla.mozilla.org/buglist.cgi?list_id=4575510;cmdtype=doit;remtype=asdefault;query_format=advanced;bug_status=UNCONFIRMED;bug_status=NEW;bug_status=READY;bug_status=ASSIGNED;bug_status=REOPENED;product=Mozilla%20Developer%20Network Bugzilla]
=== Selected ===


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.
==== Activity ====


The MDN Product Backlog is currently very large and somewhat difficult to understand, but the team plans to reorganize it soon to make it more understandable to outsiders.
One card is added to this phase for each change that should be completed. Cards are roughly prioritized by the Project Manager.


=== Sprint Backlogs ===
=== Design ===


Available at: [http://scrumbu.gs/t/mdn/ Scrumbugs]
==== Activity ====


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. 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 created for each Sprint.
The team iterates on a visual design and a written description of behavior.


==== Organization ====
==== Ready criteria ====


Tasks in the Sprint Backlog can sometimes become very broad, making the work more intimidating and more difficult to track. To avoid this, the team uses a few different criteria to break them down.
* A Photoshop document (.psd) or very detailed mock-up has been shared
* A written description of behavior has been shared
* A designated person (or group of people) has signed off on these assets


In general, the team breaks tasks down to be as small as is reasonable. For example, a task for implementing user login might be broken further into tasks like "Design interface for user login" and "Talk to Tim about how he implemented user login". The team also uses research tasks whenever possible. For example, when building a 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.
=== Technical research ===


The team sometimes needs to coordinate with IT to complete a feature. When this happens, the feature is broken down by responsibility, with at least one task for the team to complete and at least one task for IT to complete. The tasks are written to be independent, so that the team can mark its tasks as complete even if the IT tasks are progressing more slowly. If more work is needed from the team after IT finishes its tasks, new tasks are open for the team.
==== Activity ====


The team pays special attention to breaking work down when a feature goes a long time without being merged into the MDN source code repository. When this happens, the work is broken down into one or more back-end tasks and one or more front-end tasks. As back-end tasks are implemented, they are merged without the corresponding front-end tasks. If there is more than one front-end task, the team uses Django Waffle flags during implementation to ensure that the front-end is not accessible until all of the tasks are complete. When all of the front-end tasks have been implemented, the Waffle flag is enabled to make the entire front-end available. Waffle flags can also be used to make incomplete parts of the front-end available to special users for testing.
The team researches technical solutions to implementing the change.


=== Sprint Burndown Charts ===
==== Ready criteria ====


Available at: [http://scrumbu.gs/t/mdn/ Scrumbugs] (shown on each Sprint's page)
* The team has determined how the change will be implemented. A written record of this can be helpful, but is not always necessary.


The team uses a <em>Sprint Burndown Chart</em> during each Sprint to measure progress. A Sprint Burndown Chart lists amount of work on the y-axis and time on the x-axis, so that the trend line gradually moves toward the bottom right of the chart as work as completed.
=== Development ===


=== Velocity ===
==== Activity ====


Available at: [https://docs.google.com/spreadsheet/ccc?key=0AtSmmChL-hpUdFNXeFVwbmZGMDFzbUhVQS1oQ0FnbFE#gid=1 Google Docs]
The team implements the change.


To estimate how much work can be completed in each Sprint, the team measures its development speed or <em>Velocity</em>. Velocity is measured in <em>story points</em>, a unitless value of development effort.
==== Ready criteria ====


=== Status Reports ===
* A pull request for the change has been submitted


Available at: [http://standu.ps/project/mdndev Standups]
=== Review & QA ===


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 Scrum Master.
==== Activity ====


== Meetings ==
The team completes a code review, a spot check, acceptance testing and (as needed) additional quality assurance.


=== Planning and Retrospective Meeting ===
==== Ready criteria ====


The team meets at the beginning of each Sprint for a <em>Planning and Retrospective Meeting</em>. The meeting is broken into two parts.
* The code has been reviewed by a developer
* The change has been spot-checked by a developer
* The change has been approved by the same person (or group of people) who approved the design
* The change has been merged, and can be pushed at any time


==== Retrospective ====
=== Released ===


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.
==== Activity ====


All thoughts shared in the Retrospective are reflected on this page. The Scrum Master treats this page like a Developer Bill of Rights, and works to ensure that the policies written here are enforced.
The team pushes the change to staging and production. The card is moved into the ''Released'' phase and the corresponding bug is marked as RESOLVED:FIXED.


==== Planning ====
== Card Management ==


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]]. Tasks needed to complete these features are captured in the Sprint Backlog.
=== Work Types ===


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 average [[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 Velocity and cause bumps in Sprint Burndown Charts.
Cards are grouped into three different work types.


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.
* Bug
* New feature
* Change to existing feature


== Working ==
=== Size ===
 
Every ''Selected'' item is estimated on a t-shirt scale, with the choices ''X-Small'', ''Small'', ''Medium'', ''Large'', and ''X-Large''. The team collects information about how long each size of request usually takes to complete, and uses this information to communicate expected dates of delivery to stakeholders.
 
Changes that are especially large are broken down so that stakeholders can see progress and share feedback within a reasonable amount of time.


=== Assignment ===
=== Assignment ===


During each Sprint, the team works on the tasks that they added to the Sprint Backlog. A developer can work on any task that is not already assigned to someone. When he begins working on a task, he assigns it to himself. If he later decides that he does not want to work on the task, he removes the assignment so that someone else can work on it.
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 the ''Ready criteria'' are met.
 
=== 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 ===
 
Team members are encouraged, but not required, to use the ''Subtask'' feature of Kanbanery to break their work into more manageable pieces. Subtasks are only used to track work in the current phase.
 
=== Blockers ===
 
If a card cannot move to the next phase until some work is done, that work is marked as a ''Blocker'' in Kanbanery. The Blocker might be another card, the address of a WebOps bug or just a written description of the impediment.
 
=== Work in Progress Limits ===
 
Work in progress limits are managed informally. The team only pulls a card into a new phase when there are sufficient resources available in that phase.
 
== 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.
 
== Tracking Progress ==
 
=== Visual Overview ===


=== Handling development annoyances ===
The [https://mdn.kanbanery.com/projects/32137/board/?key=0383ba5f05e165e0eb19d8476654fe9775ce2ca7 best indication of progress] is the visual overview provided by the team kanban board.


The team occasionally encounters minor annoyances that affect their development work, such as receiving an overwhelming amount of error report emails. These problems are usually not serious on their own, but they can become more serious as they pile up. To manage this, each team member opens a Bugzilla bug with the keyword [dev-papercut] in the Status Whiteboard. At each planning meeting, the team considers a list of [http://mzl.la/UeVyMo ignored papercuts] when building the Sprint Backlog.
=== Written Overview ===


=== PTO ===
The team communicates [http://standu.ps/project/mdndev more detailed progress] using Standup.


Team members notify the Scrum Master when they file PTO, so that he can help the team prepare accordingly.
=== Notifications ===


== Updating the MDN ==
The team publishes several RSS feeds that interested parties can subscribe to for notifications about progress.


Throughout the Sprint, the team occasionally pushes new changes to our production server. The team does this about once per week, usually on Tuesdays or Thursdays. Pushes on Monday and Friday are avoided.
* [http://bit.ly/mdn-dev-rss-all All team progress]
* [http://bit.ly/mdn-dev-rss-ready Cards that have passed ''Ready criteria'' and can be pulled into a new phase]
* [http://bit.ly/mdn-dev-rss-blockers Blockers that have been resolved]
* [http://bit.ly/mdn-dev-rss-being-designed Cards that are being actively designed]
* [http://bit.ly/mdn-dev-rss-new-phase Cards that have moved into a new phase]
* [http://bit.ly/mdn-dev-rss-released Changes that have been released]

Revision as of 16:06, 6 March 2013

Version: 0.1-pre

Purpose

The MDN team plans to adopt Kanban to manage its work. The team feels that Kanban better fits its style of working and provides benefits that align with current goals.

This document describes and early, minimum viable Kanban process. The team will use and refine this process over time. When the process reaches a certain level of maturity, the team will request feedback more widely and use that feedback to formalize a process that all stakeholders are pleased with.

Overview

Users and other stakeholders can request changes to the MDN at any time using the Mozilla Developer Network Feedback form. The MDN Project Manager occasionally reviews these requests and decides which ones the team should complete based user and stakeholder feedback. 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 five other phases in order: Design, Technical research, Development, Review & QA and Released.

The team uses Kanbanery and Bugzilla to manage this process. Each Kanbanery card references the Bugzilla bug (created by the Mozilla Developer Network Feedback form) that describes the original request. During development, the bug is used to collaborate and share progress. For example, the team might use the bug to share mock-ups or hold technical discussions.

When the Ready criteria are met for a phase (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 occasionally skipped. For example, a card that describes a technical change that has no direct impact on design can skip the Design phase. When this happens, the team member who skips the phase updates the bug with a written justification.

All requests go through this process. The team can elect to work on any requests that interest them, but they are first approved by the Project Manager (to ensure they balance with other priorities) and go through the same phases (to ensure quality).

Phases

Selected

Activity

One card is added to this phase for each change that should be completed. Cards are roughly prioritized by the Project Manager.

Design

Activity

The team iterates on a visual design and a written description of behavior.

Ready criteria

  • A Photoshop document (.psd) or very detailed mock-up has been shared
  • A written description of behavior has been shared
  • A designated person (or group of people) has signed off on these assets

Technical research

Activity

The team researches technical solutions to implementing the change.

Ready criteria

  • The team has determined how the change will be implemented. A written record of this can be helpful, but is not always necessary.

Development

Activity

The team implements the change.

Ready criteria

  • A pull request for the change has been submitted

Review & QA

Activity

The team completes a code review, a spot check, acceptance testing and (as needed) additional quality assurance.

Ready criteria

  • The code has been reviewed by a developer
  • The change has been spot-checked by a developer
  • The change has been approved by the same person (or group of people) who approved the design
  • The change has been merged, and can be pushed at any time

Released

Activity

The team pushes the change to staging and production. The card is moved into the Released phase and the corresponding bug is marked as RESOLVED:FIXED.

Card Management

Work Types

Cards are grouped into three different work types.

  • Bug
  • New feature
  • Change to existing feature

Size

Every Selected item is estimated on a t-shirt scale, with the choices X-Small, Small, Medium, Large, and X-Large. The team collects information about how long each size of request usually takes to complete, and uses this information to communicate expected dates of delivery to stakeholders.

Changes that are especially large are broken down so that stakeholders can see progress and share feedback within a reasonable amount of time.

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 the Ready criteria are met.

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

Team members are encouraged, but not required, to use the Subtask feature of Kanbanery to break their work into more manageable pieces. Subtasks are only used to track work in the current phase.

Blockers

If a card cannot move to the next phase until some work is done, that work is marked as a Blocker in Kanbanery. The Blocker might be another card, the address of a WebOps bug or just a written description of the impediment.

Work in Progress Limits

Work in progress limits are managed informally. The team only pulls a card into a new phase when there are sufficient resources available in that phase.

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.

Tracking Progress

Visual Overview

The best indication of progress is the visual overview provided by the team kanban board.

Written Overview

The team communicates more detailed progress using Standup.

Notifications

The team publishes several RSS feeds that interested parties can subscribe to for notifications about progress.

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