MDN/Development/ProcessNext: Difference between revisions
No edit summary |
|||
| (9 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
Version: 0. | Version: 0.4 | ||
== Purpose == | == Purpose == | ||
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. | |||
== Summary == | |||
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 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|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. | |||
All requests go through this process. The team can elect to work on any requests that interest them | |||
== Phases == | == Phases == | ||
| Line 25: | Line 23: | ||
=== Research & Design === | === Research & Design === | ||
The team investigates a technical solution to the change. The team also decides if a detailed design is needed before | 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 === | === Development === | ||
| Line 33: | Line 31: | ||
=== Review & QA === | === 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 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. | 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 === | === Released === | ||
A card is moved here when the corresponding change is pushed to the production server. | |||
== Card Management == | == Card Management == | ||
| Line 43: | Line 41: | ||
=== Work in Progress Limits === | === Work in Progress Limits === | ||
The team uses Work in Progress (WIP) limits to | 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" | {| class="wikitable" style="background-color: transparent" | ||
| Line 50: | Line 48: | ||
|- | |- | ||
|Selected | |Selected | ||
| | |6 | ||
|- | |- | ||
|Research & Design | |Research & Design | ||
| | |2 | ||
|- | |- | ||
|Development | |Development | ||
| Line 59: | Line 57: | ||
|- | |- | ||
|Review & QA | |Review & QA | ||
| | |5 | ||
|} | |} | ||
| Line 66: | Line 64: | ||
Cards are grouped into three different 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 === | === Size === | ||
Cards are roughly equal in size. If a request seems particularly big, the | 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 === | === Assignment === | ||
| Line 78: | Line 78: | ||
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''. | 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, | 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 === | === Deadlines === | ||
The ''Deadline'' feature of Kanbanery is used to highlight changes that have hard deadlines. The team and | 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 === | === Subtasks === | ||
The team is | The team is encouraged to use the ''Subtask'' feature of Kanbanery to break work into more manageable pieces. | ||
=== Blockers === | === Blockers === | ||
| Line 92: | Line 92: | ||
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. | 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. | ||
== Planning and Retrospective | == 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 | 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 == | == Tracking Progress == | ||
| Line 108: | Line 118: | ||
=== Notifications === | === Notifications === | ||
The team publishes several RSS feeds that stakeholders can subscribe to for notifications about progress. | 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. | ||
* [http://pipes.yahoo.com/pipes/pipe.run?_id=a3d378990547aff38f71f3874fb99b73&_render=rss All team progress] | * [http://pipes.yahoo.com/pipes/pipe.run?_id=a3d378990547aff38f71f3874fb99b73&_render=rss All team progress] | ||
Latest revision as of 19:01, 9 July 2013
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 | 2 |
| Development | 5 |
| Review & QA | 5 |
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.