Webdev/Web Production/Kanban: Difference between revisions

no edit summary
No edit summary
No edit summary
 
(15 intermediate revisions by the same user not shown)
Line 1: Line 1:
Last Updated 2013.2.22 <span style="color:red">Draft</span>
[[Category:Webdev|Processes]]
 
{{LastUpdated}}


<div class="toclimit-3">__TOC__</div>
<div class="toclimit-3">__TOC__</div>
Line 8: Line 10:
Production (WP) projects. WP uses kanbanery.com to host our Kanban boards
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 Kanban boards
<p>WP projects have the option to use Kanban methodology for organizing work. You can use Kanban boards
Line 29: Line 35:
<h2>Accounts</h2>
<h2>Accounts</h2>


<p>Please contact XXX@mozilla.com if you need account credentials on kanbanery or if you need to create a new baord.</p>
<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 49: Line 55:


<p>Columns reflect the life cycle of a task. WebProd projects are given default columns. You can adjust columns
<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 101: Line 107:


<p>
<p>
Estimates in Kanban are much less important than in Scrum. However you should still estimate tasks in the backlog as a reflection
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.  
of total effort. Estimates should be general.
</p>
</p>


Line 151: 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>


<h2>Workflow Overview</h2>
==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 &amp; 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 &amp; 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.


<p>The following describes an example workflow for a task. </p>


<ol>
   
<li><strong>Backlog</strong> : With some discussion tasks are added to the Backlog and prioritized.</li>
5. '''Testing'''
<li><strong>Research &amp; Design</strong> : Tasks that are being started are moved to this column.  
* Task is pulled into this column by whomever is doing the QA, either team members or QA. Non coding tasks may skip this column.
<ul><li>When research &amp; design phase is complete they are marked <strong>ready</strong> with the green checkmark</li>
** Ready Flag: Passed QA can go live at next push.      
<li>Cards that do not require research and design still go into this column and are marked <strong>ready</strong></li></ul></li>
<li><strong>Coding &amp; In Progress</strong> : Task is pulled into this column and worked on.
<ul><li>Bugzilla: Bug should be assigned to whomever is doing the work.</li></ul></li>
<li><strong>Code Review</strong> : Pull request filed
<ul><li>Non coding tasks or items not needing code review skip this column.</li></ul></li>
<li><strong>Testing</strong> : Waiting to be tested
<ul><li>Bugzilla: Task marked as resolved</li></ul></li>
<li><strong>Testing</strong>: When complete it is marked as <strong>ready</strong>
<ul><li>Bugzilla: Task marked as verified</li>
<li>Any task in the QA column marked 'ready' can go live</li></ul></li>
<li><strong>Done</strong>: For coding tasks this means live</li>
<li><strong>Archive</strong> : During cleanup phase live items can be moved to the archive.</li>
</ol>


<p>The above uses the Kanban 'pull' methodology. Tasks are marked as ready, signaling that it can be worked on. The task is then pulled
into the next column where work occurs. </p>


<p>There are two places where the <strong>ready</strong> flag is used.</p>


<ol>
6. '''Done'''
<li>Signaling a task is ready to be coded/worked on.</li>
* Pulled to this column upon deployment and verification in production environment. For non-coding the task is done.
<li>Signaling a task has passed QA and is cleared to go live.</li>
** Ready Flag: Not Used
</ol>


<p>Given the above workflow the only columns that should contain <strong>ready</strong> flags are <strong>research and design</strong> and <strong>testing</strong>.</p>


<h2>Future Documentation</h2>
<h2>Future Documentation</h2>
<h3>Reports &amp; Informing Improvements</h3>
<h3>Reports &amp; Informing Improvements</h3>
<h3>Github integration</h3>
<h3>Github integration</h3>
canmove, Confirmed users
2,745

edits