MDN/Development/ProcessNext: Difference between revisions
No edit summary |
No edit summary |
||
| Line 33: | Line 33: | ||
=== Review & QA === | === Review & QA === | ||
The development team | The development team completes a code review and performs a spot check. The team considers not only functionality but also security, performance, and other important factors during this phase. 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 and meets other quality standards. | ||
=== Released === | === Released === | ||
Revision as of 16:51, 20 March 2013
Version: 0.2.5
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 performs a spot check. The team considers not only functionality but also security, performance, and other important factors during this phase. 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 and meets other quality standards.
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 work is started.
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.