MozillaWiki

MDN/Development/ProcessNext: Difference between revisions

Page Discussion

MDN/Development/ProcessNext (view source)

Revision as of 19:01, 9 July 2013

538 bytes added ,  9 July 2013
→‎Work in Progress Limits
No edit summary
 
(32 intermediate revisions by the same user not shown)
Line 1: Line 1:
Version: 0.2
Version: 0.4
 
<div class="toclimit-3">__TOC__</div>


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


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 pleased with.
== Summary ==


== Overview ==
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''.


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 three other phases in order: ''Design'', ''Development'', and ''Review & QA''.
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 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 being 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 needed for a particular card, the group responsible for that phase simply marks the card as ''Ready'' immediately after it is pulled in.


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.
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, 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 ==
== Phases ==
=== Backlog ===
MDN product backlog. All things that we could be done.


=== Selected ===
=== Selected ===


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


Things that we should do soon. One card is added to this phase for each change that should be completed. Cards are roughly prioritized by the Project Manager.
=== Research & Design ===


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


=== Development ===
=== Development ===


==== Activity ====
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.
 
==== Ready criteria ====
 
* A pull request for the change has been submitted


=== Review & QA ===
=== Review & QA ===


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


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


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


* The code has been reviewed by a developer
== Card Management ==
* 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


=== Archive ===
=== Work in Progress Limits ===


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


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.
{| class="wikitable" style="background-color: transparent"
 
! scope="col"| Phase
== Card Management ==
! scope="col"| WIP Limit
|-
|Selected
|6
|-
|Research & Design
|2
|-
|Development
|5
|-
|Review & QA
|5
|}


=== Work Types ===
=== Work Types ===
Line 78: Line 64:
Cards are grouped into three different work types.
Cards are grouped into three different work types.


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


=== Size ===
=== Size ===


Everything on the Kanban board should be roughly equal in size. This makes work less intimidating and easier to handle. John works with the team to find large high-priority items in the MDN product backlog and break them down to be roughly equal in 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 ===
=== 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.
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''.


If a person is no longer working on a card, he should change the assignee to "nobody". Anyone else who comes along should feel free to pick up "nobody" tasks and work on them themselves.
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 Project Manager pay special attention to these cards to ensure they are completed on time.
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 ===


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.
The team is encouraged to use the ''Subtask'' feature of Kanbanery to break work into more manageable pieces.


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


=== Work in Progress Limits ===
== Meetings ==


Important to note that these describe active work being done. Columns are not queues. If only 3 cards can be actively worked on in a column, the WIP limit should be 3, or 4 to allow for some flexibility. There should not be a backlog of things going on in a column -- just things being actively done.
=== Priority meeting ===


* Selected: 3
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.
* Design: 3
* Development: 5
* Review: 3


== Planning and Retrospective meeting ==
== 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.
 
== 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 ==
== Tracking Progress ==
Line 121: Line 110:
=== 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 team kanban board.
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 interested parties 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://bit.ly/mdn-dev-rss-all All team progress]
* [http://pipes.yahoo.com/pipes/pipe.run?_id=a3d378990547aff38f71f3874fb99b73&_render=rss 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://pipes.yahoo.com/pipes/pipe.run?_id=635225e2ec8e20390f63d44e2bf52dc0&_render=rss Changes that are ''Ready'' to be pulled into the next phase]
* [http://bit.ly/mdn-dev-rss-blockers Blockers that have been resolved]
* [http://pipes.yahoo.com/pipes/pipe.run?_id=31bcc67c8ed29426bd10e889850332a0&_render=rss Changes that are being designed]
* [http://bit.ly/mdn-dev-rss-being-designed Cards that are being actively designed]
* [http://pipes.yahoo.com/pipes/pipe.run?_id=de2003d8825b98844ceacda135a3ffcb&_render=rss Changes that have moved into a new phase]
* [http://bit.ly/mdn-dev-rss-new-phase Cards that have moved into a new phase]
* [http://pipes.yahoo.com/pipes/pipe.run?_id=5cf8dd8eb931c1494aa8f9bc954a1dac&_render=rss Changes that have been released]
* [http://bit.ly/mdn-dev-rss-released Changes that have been released]
John Karahalis
Confirmed users
1,193

edits

Retrieved from "https://wiki.mozilla.org/Special:MobileDiff/537406...674300"