Dofinity

Work Process

Dec 2014

Motivation

  • Documentation
    less docs, better documentation
  • Quality assurance
    wider & deeper coverage, deductive process
  • Standardization
    Across the team, With Drupal, With the industry
  • Traceability
    Budget, Scope

What is it that we want to improve:

User Story As a shopper I want to be able to select the product size

Technical Task  Add validation at form_validate

Test Scenario Given I am authenticated shopper, when I add a product to the cart,

Unit Code Manual Code, Generated Code (Features), Config Changes (dofinity change log)

Feature Shopping Cart

Epic As a shopper I want to add a product to the cart (so that...)

when no size was selected, then a message requiring that will popup and the product will not be added to the cart.

Terminology

Deliverables Diagram

Feature Lifecycle

Approval Required

In Analysis

In Graphics

In Coding

In QA

QA Done

In Acceptance

Accepted

Requirements Needed

Issue Lifecycle

Open

In Progress

In QA

Resolved

Graphics Tasks Mng

  • Custom 'graphics tasks' field at the issue
  • Custom 'graphics status' at the issue (Pending , Completed)
  • x / v signs per bullet
  • Graphic dashboard

 

Epics & Stories on Jira

Persistent yet Transient

  • Some fields are persistent: Summary, Scenarios
  • Some fields transient: Status, Version, *Billing Code*

Epics are persistent

  • All fields are used.
  • Custom 'story status' field: Active , Retired
  • When there is a change to the story:
    • Retire the former story and create new one
  • Transient fields should be ignored (billing code - eliminated)

Stories are persistent and transient

Stories subtasks

Always use subtasks

  • Allows story to become persistent object 
  • Allows tracking on further work classification

Subtasks Types

  • Frontend
  • Backend
  • Configuration
  • Graphics?

Stories Tests on Jira

  • Tests cases <=> Scenarios
  • Defined per story -> Use the scenarios field
  • Story Test means testing the story according its scenarios
  • Story can be resolved only if all scenarios tests have passed successfully

Quality Assurance

Simple Feature

Functional Test

Visual Test

How: Exploratory Test

How: Comaprison

When: Always , Who: Developer

Who: Developer

Who: Developer

In QA

Resolved

Quality Assurance

Complex Feature

Story Test

Code Review

How: Jira

How: Pull Request?

When: EQAed Feature ; Who: Developer

Design Review

How: Meeting

Who: Dev + TM

Who: Dev

Who: TM

In QA

Resolved

In Analysis

Code Review

Pull Requests + LAN / ngrok

Reviewer should focus on:

- Logic Errors

- Syntax Errors

- Semantic Errors (e.g. using an entity for the wrong purpose)

- Counter architecture implementation (e.g. (logic at the theme)

- Anti design patterns (e.g. no DI)
- Software engineering principals break down (e.g. no reuse)

- Bad Standards (Language, Drupal, Per Project, etc)

- Missing Documentation

- ...

Quality Assurance

Sprint QA

Stories / Features Test

How: Features List 

Non Functional Test

How: Test Plan

Visual Review

How: Invision

When: Sprint Completion ; Who: Dev Lead

Who: Dev Lead -> Graphic Designer

Who: Dev Lead

Who: Dev Lead

Create Three Tasks:

Bi-Daily Sprints

  • Increase focus
  • Remove dependencies

 

Does it work? How to make it work better?

Off-Sprint Planning

  • Add Epics + Stories from features list
    • Add all approved and analyzed features (* Mark)
    • Mark as 'Added' the features which their stories were added to Jira (V Mark)
  • Allocate to the relevant version
  • Write test scenarios per EQA story
  • Breakdown of graphic tasks
  • Estimate stories
  • Prioritize the stories at the backlog

Backlog Prep

Sprint Planning

  • Retrospective on last sprint
  • Assign stories to the sprint
  • Breakdown to sub-tasks (technical)
  • Estimation on each sub-task 
    • Remove estimation from story
  • Balance resource allocation to sprint estimate

 

Start the sprint and enjoy the ride... :-)

Next Sprint Prep

Sprint Planning 

  • Last Sprint:
    • Demo stories
    • Retrospective
      • Burn down graph
      • Planning issues
      • Execution issues
  • Next Sprint
    • Stories review
    • Prioritization
    • Estimate vs Allocated resources
    • Release planning

Sprint Planning Meeting

Developer Profile (Chrome)

How to use and maintain

TODO:

  • Feature Labels / Tags
  • Burn down charts
  • Burndown charts
  • Feature  labels
  • Testing of non EQA features - use the sub-tasks
  • Not using sub-tasks
  • No story / requirement / issue without estimation in jira (otherwise the version estimation is wrong) 
  • Documentation generation
  • Support Regression Tests (per story test)
  • Check bamboo
  • Check Behave Pro

Work Process

By dofinity

Work Process

Dofinity's work process enhancements Q4 - 2014

  • 252