Kanban Process

What is this article about?

This document gives information about the tools we use in the software development life cycle, the methods we use and the steps to explain the methods.

What does this document cover?

• Terms and services
• JIRA
• The kanban process

Terms and services:

JIRA

The project management software to keep track of the development. You should have access to https://your_company.atlassian.net/

Every project has it’s own space and issues, for example for YOUR PROJECT looks like https://your_company.atlassian.net/projects/YP/issues

You can see the issues listed on the left sidebar. Every issue has a type, you can tell by the small icon next to each item. Since we are using agile development, the types are regarding to agile development terms. These terms are:

• Epic: An epic is a huge component of a project. An example epic can be “Content” for a drupal project. As you can imagine, this epic will include every feature that a content is involved. Content types, blocks, views etc. are all going to be a part of an epic. An epic will have a purple icon next to it.
• User story: A smaller part of an epic. For example, if your project has a film listing page which can be filtered with different components, this can be a user story. A user story generally can be formatted as a sentence. In this case “As an anonymous user, I should be able to list all the movies and filter them by year, genre, director and cast.” would be a good example.
• Analysis: Every user story has an analysis to define the subtasks and the requirements. After the analysis, subtasks will be created under each story. The developers will not start building the project until the analysis finish and pass.
• Task: “There is no true difference between a Story or a Task in JIRA Agile”. We also respect to this.
• Subtask: A smaller part of a user story. This will be an atomic unit of the user story, every part of the user story after it’s division will become a subtask. If we use the above example, we are going to have the subtasks:
  • Film content type
  • Film page view
  • Featured films (imagine there is a block of featured movies in a page)

In support, we generally don’t have the budget to invest time in analysis tickets, especially for small tasks. In regard to epics, epic size is discretionary - we tend to use them as huge buckets like “YOUR PROJECT Support”, but epics generally correspond to a complete feature and hold all the stories describing the atomic units of work. We could consider putting more thought into our epic usage for support if anyone doesn’t like the “X Support” approach.

• Bitbucket: The git repo service. You should have access to: https://bitbucket.org/your_company
• Teamwork: To keep time tracking and client {C} communication, we are also using Teamwork project management service. https://your_company.teamwork.com
• Kanban: The methodology to keep track of the development. Every project in Jira has a development board. You can see the board on https://your_company.atlassian.net/secure/RapidBoard.jspa. The board is divided into smaller columns. When a developer start working on a subtask/task, the ticket is moved to the first column and it starts moving to the right as the development continues.

Things to keep in mind about the kanban process:

• Analysis tickets are the ones to pass the code review.
• A ticket first needs to be in “Selected for development” status. When a developer decides to start working on a ticket, they change the status to Slated for it to appear on board.
• Every ticket should have:
  • A clean description explaining the ticket
  • Epic label filled.
  • Requirements field filled for the testing purposes.
  • An assignee when the ticket starts it’s life cycle in the development board.

The kanban process:

• The client explain their request.

• The project manager {PM} creates a story for that request on Jira and moves it to the backlog. As an example view for a {PM}, you can visit https://your_company.atlassian.net/secure/RapidBoard.jspa?rapidView=37

• {PM} creates an analysis ticket for the user story. Shares all the information and documentation in the analysis ticket.

• When {PM} decides to start to build the feature request, they move it to the selected for development column.

• After the {PM} and the developer {D} agrees that {D} has sufficient information to build the feature request, {PM} moves the analysis ticket to the slated column. Slated is the hand-off from {PM} into the {D}. It is a parking space waiting for {D} to pick up.

• After this point {D} can start moving the analysis ticket to the In progress column. {D} should assign the ticket to themselves.

• When the analysis ticket is on In progress column, {D} starts creating subtasks under the related user story.

• When the creation of subtasks is done, {D} moves analysis ticket under the Code review queue column. For analysis tickets, there usually won’t be a code review, it will be a sanity check by another developer to double check {D}’s approach. The other developer {OD} will assign the ticket to themselves at this stage.

• {OD} moves the ticket to the Code review column while they are checking the ticket.

• If it looks good, {OD} states Code review passed, so the ticket will move to the Integration queue. If it fails, {OD} comments why it failed and the ticket will go back to the slated column.

• Since the analysis ticket will not contain any commits, it will be moved to the Done column by {OD}.

• When the analysis ticket is on done column, {D} can start pulling the subtasks under the user story to the In progress queue and assign the ticket to themselves.

• At this point, {D} creates a git branch for the subtask. The branch name should include the ticket number, followed by a descriptive title. For example, if the subtask ticket number is DEMO-3 and the title is “Install super duper module”, the branch name will be DEMO-3-install-super-duper-module. {D} double checks the testing instructions are defined properly. Here is an example test instruction for a subtask:

  Go to the environment

  git remote update
  git fetch origin DEMO-3-installsuper-duper-module
  git checkout DEMO-3-installsuper-duper-module
  drush en super_duper_module
  drush cc all
  

  ce completed: 
  `sh
  t checkout 7.x-0.64-rc-1
  

If there is custom code, {D} needs to use code sniffer. You can find more information about how to install phpcs here and how to use it here

• {D} pushes the branch

• {D} creates a pull request {PR} for that branch to the dev branch in bitbucket. Pastes the ticket url in jira to the description field of the {PR}.

• {D} edits the Jira ticket and paste the {PR} link into the Pull Request field. Adds a comment to inform others that the {PR} has been created and submitted.

• {D} moves the ticket to the Code review queue column.

• {OD} assigns the ticket to themselves and moves the ticket to Code review column.

• {D} now can pull another sub ticket from the Slated column and start working on it.

• {OD} follows the instructions to test the subtask.

• {OD} pulls the branch to their local:

  git remote update
  git checkout origin/DEMO-3-install-super-duper-module
  drush en super_duper_module
  drush cc all
  

• {OD} do 3 reviews here:

  • Semantic review
  • Running code sniffer
  • Functional review
  • Best practices review

• If everything is good, they move it to the In progress column. If it fails, the ticket goes back to the slated column. {OD} must indicate why the test has failed in that case.

• A release master {RM} assigns the tickets on the Integration queue column to themselves and move it to the Integration column.

• {RM} goes to their local environment

	git checkout dev
	git merge DEMO-3-install-super-duper-module
	git push origin dev

• If there are any conflicts, {PR} will not be merged to the dev branch and kicked back. The sub ticket will be moved to the Slated column and {D} is responsible for fixing the conflict.
• When the code is merged to dev branch, {RM} moves the ticket to the QA review column.
• {PM} or the person responsible for the QA follows the instructions on the testing requirement field. If it passes, the ticket moves to UAT column.
• The client {C} reviews the work at this stage.
• Once the {C} approves, the ticket moves to the release ready column and stays there until there is a release window open.