MDN/Development/Process: Difference between revisions
(Replacing process with Kanban 0.1-pre) |
No edit summary |
||
| Line 1: | Line 1: | ||
Version: 0. | Version: 0.2 | ||
== Purpose == | == Purpose == | ||
The MDN team | The MDN team uses 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 | This document describes an 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 parties are satisfied with. | ||
== Overview == | == Overview == | ||
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 | 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, based on stakeholder feedback, decides which ones 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: ''Design'', ''Development'', ''Review & QA'', and ''Released''. | ||
The team uses Kanbanery and Bugzilla to manage this process. Each Kanbanery card | 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 might use the bug to share designs or hold technical discussions. | ||
When | 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 required for a given 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, but they are first approved by the Project Manager (to ensure they | 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 fit with other priorities) and go through the same phases (to ensure quality). | ||
== Phases == | == Phases == | ||
| Line 23: | Line 21: | ||
=== Selected === | === Selected === | ||
One card is added to this phase for each change that should be completed soon. | |||
One card is added to this phase for each change that should be completed | |||
=== Design === | === Design === | ||
The team collaborates on a detailed design for the change. The card is marked as ''Ready'' after a designated person (or group) signs off on a design. | |||
The team | |||
=== Development === | === Development === | ||
The development team implements the change. The card is marked as ''Ready'' after a pull request is submitted for the change. | |||
The team implements the change. | |||
=== 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 card is marked as ''Ready'' when the team is confident that the change works as designed. | |||
=== Released === | |||
The change has been released to the production server. | |||
== Card Management == | |||
=== | === Work in Progress Limits === | ||
The team | The team uses Work in Progress (WIP) limits to control the amount of work being done at a given time. A card is not pulled into a new phase if this limit has already been reached. | ||
== | {| class="wikitable" style="background-color: transparent" | ||
! scope="col"| Phase | |||
! scope="col"| WIP Limit | |||
|- | |||
|Selected | |||
|3 | |||
|- | |||
|Design | |||
|3 | |||
|- | |||
|Development | |||
|5 | |||
|- | |||
|Review & QA | |||
|3 | |||
|} | |||
=== Work Types === | === Work Types === | ||
| Line 90: | Line 72: | ||
=== Size === | === Size === | ||
Cards are roughly equal in size. If a request seems particularly big, the MDN Project Manager works with the team to break it down before a Kanban card is created to represent it. | |||
=== 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, she changes the assignee to ''nobody''. At any point, another team member can assign one of these cards to herself and begin working on it. | |||
=== Deadlines === | === Deadlines === | ||
| Line 104: | Line 86: | ||
=== Subtasks === | === Subtasks === | ||
The team is strongly encouraged, but not required, to use the ''Subtask'' feature of Kanbanery to break work into more manageable pieces. | |||
=== Blockers === | === Blockers === | ||
If a card cannot move | 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 | == 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. | The development team, Product Manager, Project Manager and interested users meet every two weeks to discuss process improvements and review the state of development. | ||
| Line 122: | Line 100: | ||
=== Visual Overview === | === Visual Overview === | ||
The [https://mdn.kanbanery.com/projects/32137/board/?key=0383ba5f05e165e0eb19d8476654fe9775ce2ca7 best indication of progress] is the visual overview provided by | The [https://mdn.kanbanery.com/projects/32137/board/?key=0383ba5f05e165e0eb19d8476654fe9775ce2ca7 best indication of progress] is the visual overview provided by Kanbanery. | ||
=== Written Overview === | === Written Overview === | ||
The team communicates [http://standu.ps/project/mdndev more detailed progress] using Standup. | The team sometimes communicates [http://standu.ps/project/mdndev more detailed progress] using Standup. | ||
=== Notifications === | === Notifications === | ||
The team publishes several RSS feeds that | The team publishes several RSS feeds that stakeholders can subscribe to for notifications about progress. Remember that information might change by the time you receive the notification. Always click through the notification or consult [https://mdn.kanbanery.com/projects/32137/board/?key=0383ba5f05e165e0eb19d8476654fe9775ce2ca7 the board] for the most up-to-date information. | ||
* [http:// | * [http://pipes.yahoo.com/pipes/pipe.run?_id=a3d378990547aff38f71f3874fb99b73&_render=rss All team progress] | ||
* [http:// | * [http://pipes.yahoo.com/pipes/pipe.run?_id=635225e2ec8e20390f63d44e2bf52dc0&_render=rss Changes that are ''Ready'' to be pulled into the next phase] | ||
* [http:// | * [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:// | * [http://pipes.yahoo.com/pipes/pipe.run?_id=5cf8dd8eb931c1494aa8f9bc954a1dac&_render=rss Changes that have been released] | ||
* [http:// | |||
Revision as of 00:05, 7 March 2013
Version: 0.2
Purpose
The MDN team uses 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 an 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 parties are satisfied 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, based on stakeholder feedback, decides which ones 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: 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 might use the bug to share designs or 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 required for a given 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, but they are first approved by the Project Manager (to ensure they fit with other priorities) and go through the same phases (to ensure quality).
Phases
Selected
One card is added to this phase for each change that should be completed soon.
Design
The team collaborates on a detailed design for the change. The card is marked as Ready after a designated person (or group) signs off on a design.
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 design. The card is marked as Ready when the team is confident that the change works as designed.
Released
The change has been released to the production server.
Card Management
Work in Progress Limits
The team uses Work in Progress (WIP) limits to control the amount of work being done at a given time. A card is not pulled into a new phase if this limit has already been reached.
| Phase | WIP Limit |
|---|---|
| Selected | 3 |
| Design | 3 |
| Development | 5 |
| Review & QA | 3 |
Work Types
Cards are grouped into three different work types.
- Bug
- New feature
- Change to existing feature
Size
Cards are roughly equal in size. If a request seems particularly big, the MDN Project Manager works with the team to break it down before a Kanban card is created to represent it.
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, she changes the assignee to nobody. At any point, another team member can assign one of these cards to herself 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 strongly encouraged, but not required, 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.
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 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. Remember that information might change by the time you receive the notification. Always click through the notification or consult the board for the most up-to-date information.