Confirmed users
1,193
edits
MDN/Development/ProcessNext: Difference between revisions
no edit summary
No edit summary |
|||
| Line 1: | Line 1: | ||
Version: 0.2 | Version: 0.2-pre | ||
<div class="toclimit-3">__TOC__</div> | <div class="toclimit-3">__TOC__</div> | ||
| Line 7: | Line 7: | ||
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. | 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 | 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 == | ||
| Line 13: | Line 13: | ||
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'', and ''Review & QA'', and ''Archive''. | 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'', and ''Review & QA'', and ''Archive''. | ||
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 | 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 mock-ups or 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 required for a given card, the group responsible for that phase simply marks the card as ''Ready'' immediately. | 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 balance with other priorities) and go through the same phases (to ensure quality). | 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). | ||
| Line 35: | Line 35: | ||
=== Review & QA === | === Review & QA === | ||
The development team completes a code review and a spot check. | 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. | ||
=== Archive === | === Archive === | ||
| Line 45: | Line 45: | ||
=== Work in Progress Limits === | === Work in Progress Limits === | ||
The team uses Work in Progress (WIP) limits to control the amount of work being done at | 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. | ||
* Selected: 3 | * Selected: 3 | ||
| Line 66: | Line 66: | ||
=== Assignment === | === 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 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 no longer | When a person is no longer working on a card, she changes the assignee to ''nobody''. At any point, a team member can assign one of these cards to herself and begin working on it. | ||
=== Deadlines === | === Deadlines === | ||
| Line 76: | Line 76: | ||
=== Subtasks === | === Subtasks === | ||
The team is encouraged, but not required, to use the ''Subtask'' feature of Kanbanery to break work into more manageable pieces. | The team is strongly encouraged, but not required, to use the ''Subtask'' feature of Kanbanery to break work into more manageable pieces. | ||
=== Blockers === | === Blockers === | ||
| Line 90: | Line 90: | ||
=== 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 === | ||