canmove, Confirmed users
2,745
edits
Bsternthal (talk | contribs) No edit summary |
Bsternthal (talk | contribs) No edit summary |
||
(26 intermediate revisions by the same user not shown) | |||
Line 1: | Line 1: | ||
[[Category:Webdev|Processes]] | |||
{{LastUpdated}} | |||
<h2> | <div class="toclimit-3">__TOC__</div> | ||
<h2>Introduction</h2> | |||
<p>This document is an overview and guide for using Kanban on Web | <p>This document is an overview and guide for using Kanban on Web | ||
Production (WP) projects. WP uses kanbanery.com to host our | Production (WP) projects. WP uses kanbanery.com to host our Kanban boards | ||
and this document contains information specific to their implementation.</p> | and this document contains information specific to their implementation.</p> | ||
< | <p> | ||
Note this is a general guide and intended as a good starting point. It is expected that each team will develop a process tailored to what works best for them. | |||
</p> | |||
<p>WP projects have the option to use Kanban methodology for organizing work. You can use | <p>WP projects have the option to use Kanban methodology for organizing work. You can use Kanban boards | ||
as part of a full | as part of a full Kanban project or as a visualization tool on scrum/sprint based projects. </p> | ||
<h2>Candidate Projects</h2> | <h2>Candidate Projects</h2> | ||
Line 22: | Line 26: | ||
<li>Reactive projects.</li> | <li>Reactive projects.</li> | ||
<li>Projects in maintenance mode.</li> | <li>Projects in maintenance mode.</li> | ||
<li>Projects that need to adjust work during a 'sprint'.</li> | |||
</ol> | </ol> | ||
<p>If your project is short-term, release or event based you might consider using a mix of Scrum and Kanban. You can use | <p>If your project is short-term, release or event based you might consider using a mix of Scrum and Kanban. You can use Kanban | ||
boards in the traditional manner or you can use them just to visualize what's currently being worked on. It's flexible.</p> | boards in the traditional manner or you can use them just to visualize what's currently being worked on. It's flexible, use the tool | ||
that works for you and your team.</p> | |||
<h2>Accounts</h2> | <h2>Accounts</h2> | ||
<p>Please contact | <p>Please contact bsternthal@mozilla.com if you need account credentials on kanbanery or if you need to create a new baord.</p> | ||
<h2>Kanbanery Board Overview</h2> | <h2>Kanbanery Board Overview</h2> | ||
Line 36: | Line 42: | ||
If you are using a 'scrumban' approach or some other hybrid, please customize to suit your specific needs.</p> | If you are using a 'scrumban' approach or some other hybrid, please customize to suit your specific needs.</p> | ||
<p>If using | <p>If using Kanban there are only 2 'must follow rules':</p> | ||
<ol> | <ol> | ||
<li>Visualize the workflow</li> | <li>Visualize the workflow.</li> | ||
<li>Limit work in progress</li> | <li>Limit work in progress.</li> | ||
</ol> | </ol> | ||
Line 48: | Line 54: | ||
<h2>Column Overview</h2> | <h2>Column Overview</h2> | ||
<p>Columns reflect the | <p>Columns reflect the life cycle of a task. WebProd projects are given default columns. You can adjust columns | ||
to match the workflow on your specific project. You should model how your team currently works.</p> | to match the workflow on your specific project, the below is just a suggestion. You should model how your team currently works.</p> | ||
<ul> | <ul> | ||
Line 70: | Line 76: | ||
<p>Set WIP limits on columns where appropriate. These numbers can be changed/updated as you learn | <p>Set WIP limits on columns where appropriate. These numbers can be changed/updated as you learn | ||
what works best for the team. For coding a good start is 2 items in'coding' at a given time per developer. If an open slot | what works best for the team. For coding a good start is 2 items in 'coding' at a given time per developer. If an open slot | ||
is not available, you can not take on more work.</p> | is not available, you can not take on more work.</p> | ||
<p>If you are using | <p>If you are using Kanban you must use WIP limits, they are important!</p> | ||
<h2>Kanbanery Card Overview</h2> | <h2>Kanbanery Card Overview</h2> | ||
Line 79: | Line 85: | ||
<h3>Task Title & Description</h3> | <h3>Task Title & Description</h3> | ||
<p>Use a good title. Description is required for cards not associated with | <p>Use a good title. Description is required for cards not associated with an item in Bugzilla.</p> | ||
<h3>Task Types</h3> | <h3>Task Types</h3> | ||
Line 95: | Line 101: | ||
</ul> | </ul> | ||
<p>While you can customize the work types, we | <p>While you can customize the work types, we recommend general types rather than specific or feature based | ||
(like API) unless those types are relevant for the life of the project. </p> | (like API) unless those types are relevant for the life of the project. </p> | ||
<h3>Estimates</h3> | <h3>Estimates</h3> | ||
<p>The default size scale includes 0, .5, 1, 2, 3, 5, 8, 13, 21. | <p> | ||
and | Estimates in Kanban are much less important than in Scrum. However you should still estimate tasks in the backlog as a general reflection of total effort. | ||
</p> | |||
<p>The default size scale includes 0, .5, 1, 2, 3, 5, 8, 13, 21. For example: | |||
<ul> | |||
<li>.5 - text change</li> | |||
<li>2 - change to code, pull request review</li> | |||
<li>5 - significant changes to code, multiple files, requires formal QA, possibly other teams</li> | |||
<li>21 - large task involving significant investigation, coding, QA, involves multiple teams</li> | |||
</ul> | |||
Try to have tasks that are generally the same size, tasks that are 5 and above can usually be broken into smaller tasks.</p> | |||
<h3>Bugzilla & Single Source Of Truth</h3> | <h3>Bugzilla & Single Source Of Truth</h3> | ||
<p>Tasks that are non-trivial, require formal QA, involve another group, and/or require public discussion should have a corresponding bug in | <p>Tasks that are non-trivial, require formal QA, involve another group, and/or require public discussion should have a corresponding bug in Bugzilla. | ||
When creating a card:</p> | When creating a card:</p> | ||
<ol> | <ol> | ||
<li>Create a bug in | <li>Create a bug in Bugzilla.</li> | ||
<li>Enter the bug into the description field of the card.</li> | <li>Enter the bug into the <strong>description</strong> field of the card.</li> | ||
<li>All comments / discussion / attachments are entered into | <li>All comments / discussion / attachments are entered into Bugzilla.</li> | ||
</ol> | </ol> | ||
<p>Bugzilla is used by everyone at | <p>Bugzilla is used by everyone at Mozilla and our community. We want to keep our projects and tasks open. We also need to have a single | ||
source of truth for information about a | source of truth for information about a task. For these tasks Kanban is the "when", Bugzilla is the "what".</p> | ||
<p>Kanbanery does have an issues tab, however we recommend that you do not use this for either storing the primary bug or any sub-tasks (more below).</p> | |||
<h3>Priority</h3> | <h3>Priority</h3> | ||
Line 125: | Line 143: | ||
<p>Owner can either be assigned manually or it can be assigned automatically. If you pull a card into a column it will be assigned to you.</p> | <p>Owner can either be assigned manually or it can be assigned automatically. If you pull a card into a column it will be assigned to you.</p> | ||
<h3> | <h3>Sub-tasks</h3> | ||
<p>A powerful feature of | <p>A powerful feature of Kanbanery is that cards can consist of multiple tasks. These will often have corresponding bugs in Bugzilla. The format | ||
for | for sub-tasks should be "Description #BUGID" when appropriate. </p> | ||
<h3>Deadline</h3> | <h3>Deadline</h3> | ||
Line 138: | Line 156: | ||
<p>Useful to communicate if a card is blocked by another card or another task.</p> | <p>Useful to communicate if a card is blocked by another card or another task.</p> | ||
==Workflow Overview== | |||
The following describes an example workflow for WebProd tasks. Sites are encouraged to develop a flow that fits their specific need. For example: [[Webdev/Web_Production/Kanban/Mozilla.org | mozilla.org]] | |||
1. '''Backlog''' | |||
* With some discussion tasks are added to the Backlog and prioritized. Only items that should actually be worked on should be added to this column. | |||
** Ready Flag: None. Tasks are assumed ready. | |||
2. '''Research & Design''' | |||
* Tasks that require additional steps before being actively coded are pulled to this column. | |||
** Ready Flag: Flag applied when task is ready. If no R&D needed task can skip this column. | |||
3. '''Coding & In Progress''' | |||
* Task is pulled into this column when actively being coded/worked on. | |||
** Ready Flag: Pull request filed or for non-coding ready for review. | |||
4. '''Code Review''' | |||
* Task is pulled into this column by whomever is doing the Pull Review. | |||
** Ready Flag: Task is merged (PR+), will be on dev at next automatic push. For non coding not used. | |||
5. '''Testing''' | |||
* Task is pulled into this column by whomever is doing the QA, either team members or QA. Non coding tasks may skip this column. | |||
** Ready Flag: Passed QA can go live at next push. | |||
6. '''Done''' | |||
* Pulled to this column upon deployment and verification in production environment. For non-coding the task is done. | |||
** Ready Flag: Not Used | |||
<h2>Future Documentation</h2> | |||
<h3>Reports & Informing Improvements</h3> | <h3>Reports & Informing Improvements</h3> | ||
<h3>Github integration</h3> |