houston 2015 comfortable software development for teams feature-driven development tm

Houston 2015

COMFORTABLESOFTWARE DEVELOPMENT

FOR TEAMSFEATURE-DRIVEN DEVELOPMENT TM

Three reasons why FDD may not be for you…

Do you dothat voodoo that you do,

so well?

Copyright 1974 by Warner Brothers, Inc.

Hi, I’m Larry.This is my brother, Darryl.

And this is my other brother, Darryl.

And, our nephew, Steve Jobs.

•

•

•

•

•

…nothing more difficult……nor more doubtful of success…

…nor more dangerous to handle……has enemies in…the old order…

…lukewarm defenders…

i amcurtisschlak

how i present

ComfortThe premises and conclusions by which I entrust myself to FDD

Axiom

software is about people

1

Axiom

all methodologies provide anillusion of control

2

Corollary

participants’ belief in a process enable the success of a process

1

Corollary

participants’ belief in a process enables accurate reporting

2

believabilityfamiliaritysimplicity

FDD: Who/HowHigh-Level Review of Feature-Driven Development

project managerchief architect

development managerchief programmers

class owners*domain experts

Develop an Overall Model

Build a Feature

List

Plan by Feature

21 3

BUFD!

Design by Feature

Build by Feature

54

entry criteriatasks

verificationexit criteria

• People join the club to become members and get invoiced monthly a flat fee and participation fees for classes• Participation fees for classes consist of a prorated

amount of the instructor’s hourly rate and a percentage of the cost of the equipment used by participants in the class• Record member purchases of food and beverages

from the club for rewards• For every ten dollars spent on food and beverages

from the club, the member receives a one dollar credit on their next invoice• Members RSVP for classes and their arrival is recorded• Instructors schedule rooms and equipment for classes

Develop an Overall ModelPhase I

taskslearn the domain

develop the model

verification by team

outputdiagrams and notes

problem domainsystems integrationdata management

user interface

problem domainmodeling in color

systems integrationdata managementtraditional design

enterprise patternsblah blah blah

user interfacehand waving and unicorns

domain-neutral componentmoment-interval

moment-interval detailsrole

thingdescription

Build a Features ListPhase II

tasksbuild a features list

verification by domain experts

outputa categorized list of features by

business activity and feature type

feature: «action» «result» «object»

«calculate» the«total amount» of a «sale»

«determine» the «total quantity sold by a retail outlet» for an «item

description»

business activity:«action» «object»

«completing» a «sale»

«forecasting» «inventory»

subject area:«object» management

«sales» management

«inventory» management

Member Management

Rewarding a Member

«create» a «$1 credit» for a «member purchase»«create» an «invoice line item» for «every credit»

Plan by FeaturePhase III

tasksdetermine development sequenceassign business activities owners

assign class owners

Outputdevelopment ordercompletion dates

owners

intermezzofixed-cost estimates

Design by FeaturePhase IV

tasksform the team

review features and domainin-depth design

verification through inspection

outputthe “design package”

walkthrough 1%design 40%

inspection 3%

Build by FeaturePhase V

taskscode

verification through code inspections and unit tests

outputpromote to main

code 45%inspection 10%

promote 1%

Tracking and Reporting

walkthrough 1%design 40%

design inspection 3%code 45%

code inspection 10%promote 1%

Tracking by Feature

Oct Nov Dec Jan 06 Feb Mar Apr May0

200

400

600

800

1000

1200

# of Features Completed Total # of Features

Report Board

Member ManagementBilling a Member

(18)77%

March 2016

Rewarding a Member

(4)

April 2016

Invoicing a Member

(7)50%

January 2016

Houston 2015

fincurtis@curtissimo.com