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