Who Am I?

Developer/Evangelist at LaunchKey

Founder/Co-Organizer of Las Vegas PHP UG

Co-Organizer of Las Vegas Developer UG

#vegastech enthusiast

Overview

Why Driven Development?

Business goals are a moving target and speed to market pressures are immense

Development iteration cycles cannot degrade as a products feature set grows and evolves

Documentation must be accurate and extensive to prevent tribal knowledge hindering growth

Quality is a product differentiator

The Mashup

Lean software development at its core

Scrum for requirements gathering and project management

Behavior-driven development for quality assurance, acceptance testing, and documentation

Domain-driven design for code style and quality

The Result

Build only what is necessary

Deliver the highest possible quality

Deliver quickly and regularly

Empower the team

Empower change

The Drivers

Lean/Scrum keeps everyone focused

Ubiquitous language gets everyone speaking the same language

Real language tests ensure business requirements are met today and tomorrow

Test driven development keeps quality high

Domain driven development makes code easier to refactor

Evolution of a Feature

Business Owner

Brings a very general idea as a requirement.

Hopefully they have an idea of business priority and

impact.

This general idea is represented as a product

backlog item

From: Big Boss

To: Project Manager

Proj,

We need a TODO list ASAP! This is top priority. Could

mean billions in revenue. Get me an estimate

tomorrow!

Big

Scrum Master/BSA

Works with the business owner to flesh out

requirements.

Requirements are very general and generic. They

are only used to determine scope and assist with

sizing during sprint planning.

TODO list

In order to keep on track with tasks, as a user, I can manage

my tasks in a TODO list. This will be accomplished by adding

tasks to a task list and being able to update the completion

status of those tasks.

User Experience Designer

Defines the actual user experience

Takes the very generic business requirements and

creates very specific scenarios for each feature

Scenarios are analogous to use cases

Feature: Task List

As an application user, in order to see my tasks, I will be

presented a task list.

Scenario: No pre-existing tasks

As a user with no existing tasks, I will see an input field with a

placeholder value of “What needs to be done”. The footer will

not be visible.

Scenario: Pre-existing tasks

As a user with pre-existing tasks, I will see the task input fields

and below it a list of tasks in the order in which they were

entered.

Test Automation

Takes the User Experience requirements and builds

“feature” files utilizing Gherkin, the Cucumber DSL

for writing test scenarios

Scenarios will be standardized to promote ubiquitous

language conformity and step definition re-use

Missing step definitions identified

Feature: Task List

As an application user, in order to see my tasks, I will be

presented a task list.

Background:

Given I am on the homepage

Scenario: Pre-existing tasks shows list and add input

Given the “Do first” task exists

And the “Do next” task exists

Then the “Do first” task is the first item in the task list

And the “Do next” task is the second item in the task list

Feature/Scenario

Acceptance

The Feature files with their scenarios act as acceptance criteria for development

Once the tests pass, the story is considered complete and ready for demo to the product owner.

Any features/scenarios that cannot be immediately tested in automation are tagged as such but are added regardless.

Code Example

100% JavaScript

Node.js

Express.js

Cucumber.js

Available on GitHub at

https://github.com/aenglander/driven-development-

example

https://www.slideshare.net/AdamEnglander/driven-

development

https://github.com/aenglander/driven-development-

example

@adam_englander

#launchkey on freenode.net

#vegastech on freenode.net

adam@launchkey.com

LV Dev, LV PHP, VegasJS, LV Python, etc.

PyCon 2015 in Montreal