A Practical Guide to Feature Driven Development

8/9/2019 A Practical Guide to Feature Driven Development

1/304

.. ;-:-Comb ine th e sp ee d andfle xibility of agile method swith e n te rp r i se -c l a s s sc a /a b ilit y !

--- Hands-on covera ge of th eent ir e proj e ct lifecycle

Modeling , f e atu re lists,pla nning , des ign, andsoftware co nstru ction

___ Adapt Fe a ture-D r ivenDeve lopm e nt to your ownorgan izati on and pr o jec ts


2/304

A Practical

Guide to

Feature-Driven

Development


3/304

The Coad SeriesPeter Coad, Series Editor

•

• Dave Astels, Granville Miller, Miroslav Novak A Practical Guid e to eXtreme Programmin g

• Andy Carmichael, Dan Haywood

Better Software Faster

• Donald Kranz, Ronald J . Norman A Pra ctical Guid e to Unified Process

• Jill Nicola, Mark Mayfield, Michael AbneyStreamlined Object Modeling: Patterns, Rules, and Implementation

• Stephen R. Palmer, John M. Felsing A Practical Guide to Featu re-Driven Develo pment

• Io Ellen Perry, Jeff Micke How to Get th e Most Out o f the Together ControlCenter


4/304

About the Series

The Coad Series' mission statement is: Improving the ways peoplework together. Eachbook in the series delivers 'practical keys for building lasting value into business by building people and their skills.

Peter Coad personally selects authors and books forthis series-andworks on a strategic level with each author during the developmentof his book.

About the Series Editor

Peter Coad is a business builder, model builder, and thought leader.As business builder, Peter leads TogetherSoft Corporation(www.togethersoft.com). growing the compa~y nearly 12 times

revenue in two years. As model builder, Peter has built hundreds of models for nearly every business imaginable, ever focusing on building competitive advantages into businesses. As thought leader,Peter writes books (six to date) and speaks at events worldwide.You can contact Peter at [email protected].

mailto:[email protected]:[email protected].


5/304


6/304

A PracticalGuide to

Feature-Driven

Development

Stephen R. Po/mer and John M . Fe/sing

Foreword by Peter Coed

Prentice Hall PTR

Upper Saddle River,NJ 07458www.phptr.com

http://www.phptr.com/http://www.phptr.com/


7/304

Library of Congress Cataloging-in-Publication Data is available.

Production Supervision D onn a C ullen-D olce Acquisitions Editor: P aul P etral iaManufacturing Buyer: A lexis H eydt-Long Cover Design N ino ScudenCover Design Director Jerry V otta

Marketing Manager: D ebby van D ijk Cover art "G ravity " by M C E sc her C opyri ght 200 J C ordo n A rt -B aasm -H olla nd. A ll ri ghts re se rv ed .

II Copyright © 2002 by TogetherSoft Corporation•• Prentice-Hall IncUpper Saddle River,Nj 07458The Coad Letter® is a registered trademark of Object International. Inc.Together® is a registered trademark of TogetherSoft CorporationTogetherSoft® and Together Controk'enter" are trademarks of TogetherSoft CorporationPost-It® is a trademark of 3MUML® is a trademark of Object Management Group

All other products mentioned in this book are the trademarks and servicemarks of their respective companies, organizations, or owners.

Prentice Hall books are widely used by corporations and governmentagencies for training, marketing, and resale.

The publisher offers discounts on this book when ordered in bulk quantitiesFor more information, contactCorporate SalesDepartment, Phone 800-382-3419; Fax. 201-236-7141;E-mail corpsales@prenhall com; or write Prentice Hall PTR,Corp. Sales Dept,One Lake Street, Upper Saddle River, NJ 07458

All rights reserved. No part of this book may be reproduced, in any form or by any means, without permission in writing from the publisher

Printed in the United States of AmericaISBN 0-13-067615-2

Pearson Education LTDPearson Education Australia PTY,LimitedPearson Education Singapore, Pte. Ltd.Pearson Education North Asia LtdPearson Education Canada, Ltd

Pearson Educaci6n de Mexico, SA de CVPearson Education-JapanPearson Education Malaysia, Pte. Ltd.


8/304

From Steve Palmer

T o Su m a n, M a rk , a nd J are d

F or evervth in g you give m e I don 't deserve you

From Mac Felsing

T o G ina , Alex, Em il ie , and D esi ree

You give m e determ ination, s trength , focus, and above a ll , Love.


9/304


10/304


11/304

Chapter 3 Feature-Driven Development-Practices 35

Integrating Best Practices 35

Domain Object Modeling 36

Developing by Feature 38Class (Code) Ownership 42

Feature Teams 46

Inspections 49

Regular Build Schedule 51

Configuration Management 52

Reporting/Visibility of Results 53

Summary 53

Chapter 4 Feature-Driven Development-Processes 55

The Scope of Feature-Driven Development (FDD) 55

FDD in Four Sentences 56

FDD in a Nutshell 57

FDD in Detail 59

Summary 73

Chap ter 5 Feature-Driven Development-Progress 75

Time: A Scarce Resource 75

Estimating Progress 76

Track by Feature 77

Reporting to the Development Team 78

Reporting to the Chief Programmersand Project Manager 80

Reporting to Sponsors and Upper Management 86

Chief Programmer Plans 87

Feature Kills 91

Contents Summary91

x


12/304

Chapter 6 Feature-Driven Development-Packages 93

Chie f P rogrammer Work Packages

When You Have to Producea M oun ta in o f Paper

Summary

93

100

101

PART2 Feature-Driven Development-The FiveProcesses in Practice 103

Chapter 7 Develop an Overall Object Model 105

The Form the Modeling Team Task 1 1 2

The Conduct a Domain Walkthrough Task 1 1 4

The Study Documents Task 1 1 8

The Develop Small Group Models Task 1 1 9

The Develop a Team Model Task 1 2 4

The Refine the Overall Object Model Task 1 2 6

The Write Model Notes Task 1 2 9

Verification 1 3 2

Exit C riteria 1 3 3

Chapter 8 Feature-Driven Development-Builda Features List 135

The Form the Features List Team Task

The Build the Features List Task

Verification

Exit Criteria

1 3 8

1 3 9

1 4 3

143

Chapter 9 Feature-Driven Development-PlanningFeature Development 145

The Form the Planning Team Task

The Determine the Development Sequence Task

145

14 7 C on ten tsxi


13/304

The Assign Feature Sets to Chief Programmers Task 150

The Assign Classes to Developers Task 152

Verification 154

Exit C riteria 154

Chap te r 10 Feature-Driven Development-Designing by Feature 159

The Form a Feature Team Task 161

The Conduct a Domain Walkthrough Task 164

The Study the Referenced Documents Task 166

The Develop the Sequence Diagram(s) Task 169

The Refine the Object Model Task 171

The Write Class and Method Prologue Task 173

Verification: Design Inspection 175

Exit C riteria 178

Chap te r 11 Feature-Driven Development-Build

by Feature 181

The Implement Classes and Methods Task 182

The Conduct a Code Inspection Task 185

The Unit Test Task 189

The Promote to the Build Task 191

Verification 192

Exit C riteria193

PART 3 Feature-Driven Development- Additional Topics 197

Chapter 12 Feature-Driven Development-Technical Architecture 199

Technical Architecture 199

C onte nts Technical Architecture in an FD D Project 203xii


14/304

The PD Layer 207

The SI Layer 207

The UI Layer 210

The DM Layer 213

Layers and the Build 214

Reducing Dependencies between Components 215

Chapter13 Feature-Driven Development-Testing:Failures, Faults, and Fixes 217

Kinds of Testing 218

Failures, Faults, and Fixes 218

FDD and Unit Testing 220

FDD and Integration Testing 222

FDD and System Testing 223

Customer/User Acceptance Testing 225

Finding Failures 226

Reporting Failures 229

Diagnosing Defects 230

Fixing Faults 230

The Defect Board 231

Summary 231

Chapter14 Feature-Driven Development-Other Surroundings 233

Requirements Change Management 233

User Documentation 237

Data Loading and Conversion 244

Deployment 246

Summary 247 C onten ts

xiii


15/304


16/304

Acknowledgments

W e need to thank all our friends, families, and colleagues past andpresent for their support, input. feedback and encouragement whilewriting this book.

We would especially like to thank Jeff De Luca and Peter Coad for

first writing about Feature-Driven Development in their book lava M odel-ing in Color w ith UML [Coad99]. Also Jefffor his ability, courage, and com-mitment in creating a project environment where this sort of innovationcould flourish, and Pete for so many insights, patterns, strategies, andtechniques that made 00 software analysis and design so accessible

Thanks to the original cast of the PowerLender software develop-ment team in Singapore, especially Tan Siow Boon,Yeo Sai Cheong, AjayKumar Rana, lu-Lia Tan. and lames Tan, first for their willingness toadopt a new way of working, and second for their help in learning toapply FODday after day for so many months. Too many to name individ-ually but you know who you are.

Thanks to all the mentors at TogetherSoft who have contributedideas, thoughts. and suggestions through countless discussions, e-mailexchanges and newsgroup threads. Special thanks to Lisa luliani. our old"Mentor Operations Manager (MOM)," for helping get this book projectstarted, and to Ken Ritchie, Greg Cathcart. Dan Massey, and ScottSchnier for their reviews, and continued encouragement and enthusiasm.

Also thanks to Paul Petralia, Donna Cullen-Dolce. and the rest of theteam at Prentice Hall for the countless number of tasks, and their expert

help and advice in turning our rawword-processor files into a real book.(As well as putting up with the quirks, foibles, and delays associated withworking with two overworked, creative individuals.)

Finally, enormous thanks to our long-suffering wives for allowing usto neglect them for so many evenings and weekends to write thesepages

xv


17/304


18/304

Foreword

T o build an ything of lasting value- s oftware, syst e ms , companies-buildin g pe ople must be a t the he art-and -so ul of all your d o."P r ocess " is a ll about imp r ov ing the way s pe ople wor k together . Aprocess is the fami ly r ec ipe , the s e cr et sa uce , the c ompe titive edg e , of

hum a n en deavo r .Everyone h as his own collection of proces s es S o does ev e ry team .

Mak ing pr ocesses -good o r ba d-e xp licit is the first s tep to under s tand -ing w ha t is goi ng o n, see ing w ha t works a nd wh a t doesn 't, and looking

with eye s o f wisdo m as to wha t is going on in one of lif e 's m a ny s itua -tions . Cons ide ring a p r ocess -the ways yo u are wor king toget he r with

others-is ta king your thinkin g and g oing one level up Fe e l pre ss ure? G o

one l e vel up and take a look Things b eg in to calm d own right aw ay; y ou

beg in to see m or e c lea r ly Fee l pa nicked a bout wha t to do w hen , or whatis mos t impo r ta nt? Go one leve l up . Ha ving pr oblems w ith a pee r and

jus t don't kno w wher e to tur n? Go o ne l eve l up. Hav ing p r oblem s p r oduc -ing better so f twa re with other s? Go o ne l ev el up .

"Process" is a bout moving one level up, gaining n ew insights, invit-

ing other s to join you one l ev el up t o make str a teg ic moves that willma ke the da y-toda y r eal ities so much more effe ct ive , palatabl e , and

da re I sa y it: fun, rewardin g, and sati s f ying

Process , go mg on e level up, is h ow o ne begins t o under s ta nd what

one is d oing , what other s are doing, what the people i ss ues an d dynam-ics are , what the b ottlen ecks and accelerators are , wha t the ove rall con ;

te xt is, what the expa nded co nte xt is , and w ha t to d o about it all. One

lev el up

Pr ob lem s hap pen ing ? Go one lev el up and find out wha t to do.

Goodness happ e ning ? Go one level up and discover w ay s you can engen -

de r goo dne ss a ll the m or e

May we a ll ha ve t he c our a ge to r e ach o ne le vel up , that we m ight

be tte r con nec t with othe r s , bu ild m ean ing ful relat ions hips, bu ild peo ple ,

build las ting value -an d tr uly suc ce ed

Th a t brings us to the topic o f this book, the topi c of Featu r e-DrivenDeve lopme nt (FOO l FOD is a co llec tion of be s t pr actices, s et into the

co ntex t of an ove r a ll pr oce s s , one le vel up fr om the da y-to-da y urgenc y-e -xvi i


19/304

F o re w o rd

xviii

at times even panic-experienced by business people and developersworking together on mission-critical software-development projects

A P ract ical Guide to F eature-Driven Development reveals the process, thesecret recipe, that TogetherSoft and its clients use to produce world-class

software. Jeff De Luca and I first described the recipe two years ago, in ashort chapter in the book lava M odel ing in Color w i th UML. Steve and Machave gone far and beyond that initial description. FDD, as describedherein, is significantly advanced by these two I am most grateful for thework they have done and the many insights they chose to share.

FDD itself is one level up

Read the book Consider the recipe. Try it out. Adapt it as you wouldwith any family recipe, making it your own, making it best fit the ingredi-

ents you have on hand. Read. Enjoy. And treasure the insights fromPalmer and Felsing, one level up

Sincerely,

Peter Coad

CEO and President, TogetherSoft Corporationpeter [email protected]

mailto:[email protected]:[email protected]


20/304

Preface

Feature-Driven Developme nt (FDD) is a process designed and p r oven tode liver frequent, tangible, working resu lts repea tedly. This is the first bookto spell out theday-to -day details of using FDDon a realprojec t. giving de-ve lopment team leaders all the information they need to apply FDDsuc -

cessfully to their situationsFDD is a straightforward approach to produc ing systemsthat usessim-

ple.easy -to-understand andeasy-to-i mpl eme nt met hods; problem-so lvingtec hn iques; a nd repo r ting gu ide lines p r ov iding e ve r y stakeho lde r of a proj-ec twith the information they need to ma kesound, time ly decisio ns .

Programmers are provided with the i nformation and supporting in-frastructure they need to produce app lications. Team leaders a nd man-agers get timely information about their teams and projects that al lowsthem to reduce the project ris k . Project manage r s a nd executive sponsorsseethe current project status and tro ubl e areas so that they ca n act ua llyma ke time ly, informed decis ions i n a c on tr olled , planned ma nn e r (noknee-jerk reactions) . Re por ting beco mes eas y, r e lat ive ly pai nless, time ly,a nd accurate!

Users (customers, sponsors, end users ) can actually see areas of the ir business automated as t he project progresses and give ea rly, con-str uctive feedback about the system w hile it is being developed . At thesametime, the development team has t he too ls and informatio n it needsto co ntrol "scope creep!"

What FDD Is!

FDDis no t yet another processthat takes up reso urces, time, and moneybut just doesn't produce the needed resu lts . It is not anothe r methodwhereby administrators , bureaucrats, and process-centric fanatics canfocus everyone's time and energy on produ cing reams of printo uts andsig natures w ith nothing to show for it . FDDis not another set of processvo lumes that will sit o n your s he lf . co llec ting du st and impress ing your s up er visor. co-workers, and sig nifican t others with your know le dge of a n-other less-than- usefu l se t of d irectio ns f or p rodu cing sys tems

What FDDIs Not!

xix


21/304

Why ShouldI Read thisBook?(Whafs in itfor Me?)

If any of the f ollowing que s tions ap ply to you, y ou will find t he ans we r syou a r e look ing f or on the f ollowing pages

• Are y ou in cha r ge of a gr oup ass igne d to de liver a c ritica l sys-

tem with l imited res our ces and sh or t dea dlines , and n ee d h e lpto organize th e project ?

• Are y ou tired of filling o ut so man y proce s s f orms a nd r ev ie wingso man y docum ent s that you do n't ha ve t ime to do yo ur r eal

wo r k?

• Are you frustr a ted at th e unfulfilled pr omise s of pro cess initia-tives that cl aim to pr ov ide a way to deliver quality re s ults re-peatedl y?

• Ar e yo u look ing f or a m ore e fficie nt way to o rgan ize you r tea m

to s tream line p r oductivity, cu t dow n on unne cessar y inte rru p-tions , and improve the ac curac y of r epo rting f or your pr o jects ?

• Are y ou curr e ntly wor king on a pr o ject that i s in trouble be -

cau s e th e tea m ha s f ai led t o p roduc e a sys te m?

• Do yo u wan t to a dd t o the too ls an d tech nique s in your pr ojec tman ag e me nt or team le ader too lbox?

Prego (It's in

There!)

Preface

Althoug h FOO was f ir s t intr od uce d in print in la v a M od el ing in C olor w it hUML [Coa d 99 ]. we give a more th orough cov erag e of th e topic . We po int

out the critica l tips for s uc cess , as w e ll as the p itfa lls that ma y not be ap-pa r e nt f rom a cur sor y glan ce Co nten ts include .

.• Who should us e FO O

• The rol es, a rtifac ts, goa ls , an d time line s

• Why FOO includ e s the pr ac tices and t ech niques th at it does

• The dri ving for ces behind the developm e nt of FOD

• Adapting th e us e o f FDD to differen t s tyles of pr oject s

FDD blend s a num be r of indus tr y-r e cognized best p r a ctices us ed suc-

cessfu lly by Pete r Coad. leff De Luca . and othe r s in thei r cons ultanci e sTh ese practice s are a ll driven f rom a c lient-v a lued featur e per spe ctive . II is

the pote nt c ombin a tion of the se technique s and p rac tices that ma ke s FDDso c omp elling .

J ohn M. Fe lsing (mfelsiO l@s prin tspec trum c om)

Stephen R Palmer (sp@ togethersoftc omj

December 200 I

xx


22/304

Introduction

Answers: Why this book?

For e n te rp rise -c o m p o n e n t m o d e lin g to & e su c c e ss fu l.

i t m u st l iv e a n d b re a th e w ith in a la rg e r c o n te x t , a so ftw a re d e v e lo p m e rlt p ro c e ss.Coad. LeFebvre, De Luca ICoad .991

Published in 1999, J a v a M o d e lin g in C o lo r w ith UML [Coad 99 L often re-ferred to as the "coloring book," devotes the first five of its six chapters toa discussion of a truly significant new object modeling technique called

m o d e lin g in coror Those first five chapters are almost, but not quite, totallyirrelevant to the discussion in the rest of this book More relevant here-much more relevant-are the contents of that sixth chapter. hidden awayat the back of the book Chapter 6 of the coloring book was the first at-

tempt to describe in print a particularly successful way of building com-plex software systems by significantly large development teams with

members of varying talent, experience, background, and culture The

software development process that it described is called F e a tu re -D r iv e n D e v e lo p m e n t (FDD), for want of a better name.

What has become known as FDD was derived from work done on a large

software development project in Singapore where leff De Luca was Proj-

ect Manager. Peter Coad was Chief Architect. and Stephen Palmer (au-thor) was Development Manager. The project was very ambitious, with a

highly complex problem domain spanning three lines of business, fromfront office automation to backend legacy system integration

The bank had already made one attempt at the project and failed.The project had inherited a skeptical user community, supportive butwary upper management. and what was left of a demoralized develop-ment team

One of the key areas of risk that Jeff identified was the complexity of the problem domain. This demanded a level of ability and experience indomain object modeling beyond that of the current team. To mitigate

A Project inTrouble

xxi


23/304

Introduction

xxii

this r isk , le ff pe r sua ded Peter Coa d to come to S ingapor e and wor k withthe t ea m to pr odu ce a resilient and flexibl e domain objec t model f or theprojec t.

To make a long s tory short , the result of Je ff , Peter , a nd others w ork-ing together on this project was the disc over y of the m odeling in c olor techni que and th e creati on of the FDD pr oc e ss -an agi le , adaptive s oft-warede velopm en t pr ocess th a t:

• Is highly ite r a tive

• Emphasiz es quality at e a ch step

• Delivers frequent, tangible , working results

• Provides accurateand meaningful pr ogre s s and sta tus informa-tion with th e minimum of overhead and disru ption for the d e -veloper s

• Is liked b y clients , man a ger s , and developer s

Client s like FDD becau s e they get t o s ee real re s ults earl y andprogress reports written in term s that they understand

Ma nagers like FDD because it gives th e m a complete and accuratepicture of proje ct progress and status-the inform a tion they need t os teerthe proje ct appropriatel y

Dev eloper s like it becau s e the y get t o wo rk in sm al l teams on sma llite ra tions and get to use the word fi ni shed frequently ; the y get to wor k on

s om e thing ne w ev er y few da ys It involves them in anal ys is , design , andimplementation Analysis and de s ign are n ot dictated b y one or two elit eanalyst s or architects . Developer s also like FDD because it makes it easyto supply their managerswith the status information the y want with theminimum of effort and disrupti on.

Paul Szego , a Chief Pro gr a mmer on the S inga por e project. whilesigning auth or Ste ve Palmer 's copy of the coloring b ook , wrote , "Whosa id s oftware isn 't f un ? The be s t time I ha veh a d in a long time ."

FDD answer s po s itively the question , "What 's in it f or me>." for eachrole in the project This contrasts with someprocesses usedby manager sto control developers because they feel the developer s are not compe -tent en ough to be trusted ; it als o contrasts with proces s e s used by de vel-oper s to prevent themselve s fr om being c ontrolled bec a us ethey do n otfee l their manag e r s are compet e nt enough t o be truste d

Since its i ntr oduction in the publicat ion of the c olo r ing book , FDDha s pr oven effe ctive within a gr owing numb e r of development orga niza -tions It s value is n ot restricted to salvaging projects in trouble; it is justas applicable to projects that are starting out. projects enhancing exist-ing code , and projects tasked with creation of the second version of as ystemthat was thrown together in a hurry la s t year


24/304

FDD's underlying focus on producing frequent, tangible, working re-sults at each level of the project (from developers to Chief Programmers,Chief Architects, Project Managers, Project Sponsors, and end users)makes it worthy of serious consideration by any software developmentorganization that needs to deliver quality, business-critical software sys-tems on time.

Although a number of the Singapore project team members contributedto the development of FOO,there is no doubt that the main pair of vil-lains involved were Jeff De Luca and Peter Coad.

Peter Coad is an industry-renowned object modeler. consultant. au-thor. speaker, teacher, and wearer of Hawaiian shirts. Peter has designedhundreds of component and object systems, within nearly every industryimaginable

Jeff De Luca. on the other hand, was schooled in the deep, dark artsof AS/400 operating system development at IBM's lonely laboratories inRochester, Minnesota and is a highly successful. innovative, and experi-enced technical consultant and Project Manager. Petehas described himas "the best Project Manager I've everworked with."

Why are they not writing this book?The simple answer is that theyare both too busy building companies that build successful software ap-plications Jeff leads Nebulon Pty. Ltd. (wwwnebuloncom) and is suc-cessfully using FDO to produce business systems for major clients inand around Melbourne, Australia. Pete is CEO of TogetherSoft (wwwtogethersoft.com), the company that produces the award-winning To-gether software development platform All of the Unified Modeling Lan-guage (UML) diagrams in this book are constructed using TogetherSoft'sTogether ControlCenter software development platform.

Until now, people wanting information about FOOhave been limitedto the introduction in Chapter 6 of the coloring book [Coad 991.a littlemore discussion on the Nebulon Website, and a few issues of the C aad Let te r [Palmer], a monthly newsletter archived at www.togethercommunitycom and currently edited by Steve. Theaims of this book are:

• To provide people with the in-depth information they haveasked for about FOO

• To provide many practical hints and tips for applying FOD

• To discuss its development since the publication of the color-ing book

If you are a developer or team leader,are involved in software devel-opment management in any way and need to make FOOwork for you, or are simply interested in the whys and wherefores behind FDD, you are

reading the right book

ThoseResponsible

Introduction

xxiii

http://www.togethercommunity/http://www.togethercommunity/


25/304

Few , if an y, of the ide a s d iscussed are ou r own . Many of the ide a scome fr om note s made by Jeff or Peter. M a ny of the ide as a r e ins pir e d b ythe work of Fred Br ooks IBr oo ksL Tom De Marco IDe Marco L LukeHohmann IHohmann L and GeraldWeinberg [Weinberg 92 ,Weinberg 98) .In turn, much of their work build s o n the w ork of Harlan M ills [Mills], Vir-

ginia Satir [Satir] , Philip Crosb y [Cr os by ], and others.

To attr ib ute a n id ea to sole ly one perso/1 is naive t e: to attribut e an id ea solel yt o one self is ar ro g ance

The principle of multiple minds taking a good ide a and turning itinto a great result per vades this book and FDD .

Reading ThisB o o k

The b ook is split into three secti ons

1. Part 1 looks at some of the underl ying principle s and the im -portant characteristics of any software development processand askswhy it is so important. It then goes on t o introduce

. the people, practices , and pr ocesse s tha t comprise FDD . Thesection f inishe s with a n introducti on to track ing an d rep ort-ing pr ogre ss a nd work, a nd sug ge s tions for r epor t f ormat s ,design , and work pac kages

2. Part 2 e xplore s each proce ss within FDD and pr ovid es extrahints , tips , and techn ique s to use whe n applyin g FDD

3. Part 3 widen s the discussion to answer the most frequentlyasked que s tions about FDD and t o explore its impact onother import a nt activities within a softwar e de velopmentproject that lie outsi de the process 's t argeted s cop e

Making anExample

In tr o d u c tio n

xxiv

Writing a book about process is almost a s mind-numbingly borin g as

reading one. In an attempt to keepyou, the reader, awakeuntil the end of the book , you 'll find the authors suddenly bur s ting into r ole- play discu s-s ions a t various p oints . We a polo gize , but it co uld be w orse! Auth or MacFels ing is a keen a mateur op era s inger ; f ortunately , printed media d oe snot enable him t o bur s t into so ng within the s e pages ©

We use the s e r ole-play disc us s ion s to illustrate p oints within t hecont ex t of a specifi c , small bu t r e alistic e xample project at Gary's Gar ag e ,a car dealership and servicing and repair shop.

Other books within this series are also using a similar example sothat you can more readil y compare the different appr oaches andpr oce ss es de s cribed in the different books . We have ch ose nthis examp lefor two reason s :


26/304

l. It is large enough to present solid, real-world challenges.

2. We wanted to be able to present the contents of this bookusing a tangible, believable setting-one that you might re-late to easily.

So, welcome to Gary's Garage Gary owns the regional dealershipfranchise for a popular car manufacturer. At Gary's Garage, you can buy anew or quality used car, have your car serviced, and if unfortunately nec-essary, repaired As the main dealer in the region, Gary also sellsbranded spare parts and accessories to other garages and to the generalpublic Gary and his team have volunteered to help specify and pilot a

new sales and servicing management software system for the car manu-facturer's dealerships

Introducing ...

The Development Team

• Lisa, the Project Manager. She is an experienced Project Man-ager for a small systems integrator and custom programming

shop

• Steve, a Senior Developer. He is experienced, intelligent, eru-dite, and British

• Mac, a Senior Developer. He is just as experienced and intel-ligent as Steve but more handsome.

• Various other extra staff as needed. Don't you wish thatstaffing of projects was really this easy?

The Client Domain Experts

• Mike the Mechanic. As chief mechanic, Mike runs the servic-ing and repair workshop and a team of mechanics.

• Stuart the Salesman. He is in charge of the new and used car sales team and showrooms.

• Sandy the Storeman (Parts Manager). He is the parts man-ager, in charge of the spare parts inventory

• Rachel the Reception Manager. She is in charge of schedul-ing services and repairs, and she handles customer relation-

ships.

• Anita the Accountant. She runs a back office team, doing thebooks and payroll and managing the administrative side of the

running a dealership franchise.

Steve: . Hey M ac, I'm told I'm going to be w orking w ith yO Ll on that car dealership

pro ject star ting ne xt w eek . W ha t can yo u te ll me ab out it?In tro d u c tio n

xxv


27/304

Introduction

xxvi

M a c : Y e a h I F ro m in itia l d isc u ssio n s I 'v e h a d w ith th e P ro je c t M a n a g e r, a s sm a ll a jo b a s ~ o u 'd first th in k , a n d w o u ld n ' t y o u k n o w it , th e y w an in g in 9 m o n th s A t le a st th e y 'v e g iv e n u s o u r p ic k o f d e v e lo p e rs a n d L is a to ld m e sh e w a n ts a " p ro p e r p ro c e ss" u se d . 1 g u e ss sh e d o e s n o t w a n t u s e x p e ri-m e n tin g w ith so m e th in g lik e E x tre m e P ro g ra m m in g o n su c h a h ig h -

te a m is l ik e ly to b e to o v ig fo r XP a n y w a y . .. b u t th e o v e rh e a d o f a re a l ly h e p ro c e ss w il l m a k e th e sc h e d u le im p o ssih le . Y o u 'r e fa m il ia r w ith a p ro c e ss, a re n 't y o u ? S te v e : Y o u m e a n F e a tu re ~ D riv e n D e v e lo p m e n t? Y e s, I w a s th e d e v e lo p m e n t m a n a g e r o n a n im p o r ta n t p ro je c t w h e re i t w a s u se d v e ry su c c e ssfu l ly . W e cFD D . H ow a b o u t g ra b b in g a m e e tin g ro o m , a n d I'll w a lk y o u th ro u g h th e id e a s a n d c o n c e p ts? ... M a c : O k a y . I k n o w Room 8 is fr e e n o w . Let's g ra b a c o ffe e o n th e w a ~ . M a c : .. . J u st a s 1 th o u g h t, R o o m 8 is fre e It 's a n ic e , q u ie t c o n fe re n c e ro o m w

w h ite b o a rd , fiip c h a rts, p ro je c to r a n d p ro je c tio n sc re e n , d e c e n t~ size d c o m fo rta b le c h a irs. W e sh o u ld h a v e a ll w e n e e d . S te v e : M o re th a n e n o u g h ! I d o n 't th in k w e 'll n e e d th e p ro je c to r; th e w h ite v o a rd fin e I'v e p ic k e d u p a c o u p le o f m y fa v o rite h o o k s o n th e to p ic , in c a sh a rd q u e s t io n s , a n d w e c a n g ra b a n y th in g e lse a s w e n e e d i t . R ig h t sta rt? M a c : F i r s t I w o u ld lik e y o u to g iv e m e so m e g e n e ra l b a c k g ro u n d so w e c a n se t a th e o -re tic a l fra m e w o rk w ith in w h ic h w e c a n v u ild a n d e la b o ra te a s w e w T h a t w a y , I w ill h a v e a g o o d u n d e rsta n d in g o f w h a t F D D is a n d h o w it w o rk s, a n d th a t w ill m a k e it m u c h e a sie r to a p p l~ to o u r p ro je c t. S te v e : E rr O k a y l


28/304

T his section define s the roles, practices, proces s es, and progress re -porting capabilities of Feature-Driven Deve lopment (FDDl . It pro-vides practical . useab le answers to the following questions :

• Whydo we have to manage software development?

• Whodo we haveto manage in software development?

• What do we haveto manage in software development?

• How do we managesoftware development ?

• Howdo we measureand track progress in software development?

• How do we document low -level design and implementation work?

Chapter I examines the current confusion , hype, and hysteria sur-

rounding software development processes and asks why we need aformalized software development process .

Chapter 2 considers the influence of people and technology on asoftware development process and introduce s the roles t hat peopleplay in FDD .

Chapter 3 describes the collection of industry-recognized best prac-tices that under lie FDD,why they are so va luab le , and how t hey com-bine a nd support eachother w ithin FDD.

Chapter 4 defines t he scope of F DD, ide ntifying the processes withina development project that FDDcovers and those it does not . Thefive processes within FDD are defined . 1

Featu re-D rivenDevelopment-

.. Concepts


29/304

A P ractical G uideto Fea ture-D riven

D eve lopm ent

2

Chapter 5 shows how FDD cap tu res data that makes accurate tr ack-ing and report ing of progress on the project relat ively easyChapter 6 demonstrates how to organize, p lan , document. and auditth e da y-to -d ay d esig n a nd i m p le m en ta tio n w ork b ein g d on e o n a pro ject


30/304

Process Pride:The Pain and Relief

Answers Why d o we ha ve to manage s oftware development?

W e th in k m o st pr ocess init iative s ar e sil ly W e I / -intentioned m anager s and t eam s get so w r a pp ed u pin e xe cu ting pr ocess t hat t he y forg et t hat they are

being paid f or result s , not proce s s ex ecution.Coad. Le febvr e , De Luca [Coad 9 9 1

The majo r ity of nontr ivia l sof tware pr o ject s f ail to live up to expe ctatio ns ;they a re lat e, ove r bud ge t, a nd d o n ot delive r all the needed fun ctional -ity Many soft wa re pr o jects f a il altogeth e r

Developing com plex software systems in teams of any significantsize is hard, and when an important software proj e ct fails badly, p a in andfrus tration ar e felt thr oug hout an organ iza tion . Use r s, customer s , e xecu-tive s ponso r s , man a ger s, dev elopers , ma rketer s, a nd sales and tr a ining

s ta ff are all aff e cted in s ome way or an other

Whe n conf r on ted with th is pain , orga nizat ions ofte n look to formal. pr oce s se s , met hodo logies , an d mea su r e ment s ys tems f or relief . Impos -

ing a "pr oper proc e ss " is se e n as a means for cr ea ting o rder out of the

s of tware d e velopment cha os :

I f onl y w e ha d t he ul t imate p lan-a compr ehen sive set of st e ps that w e could foll ow t hat w oul d g uar ant ee succ e ss. I f only w e had a bett er w a y o f doing t hin g s , a bett er pr ocess. T hen w e w ould succeed ... w ouldn' t w e?

This be tte r pr oc e ss is see n as a silver bullet th a t will sla y all the o r-ga nization 's softw a r e de velo pment w oe s . A working g roup or committe eis se t up and w orks f or months to define , doc ument, and deliver the newmir a cle-making pr oce ss

Process

Pride

3


31/304

A P ractical G uideto Feature-D riven

D eve lopm ent

4

The Heavy BrigadeMany teams and organizations try to define a single, all-encompassing

software development process for their organization After all. if everyonein that organization created software in the same way, using the same

process and producing the same types of documents, it would all be-come so much easier to manage Wouldn't it?

The trouble is that software systems, technology, and organizationsdiffer so much that any generalized approach to software developmentthat truly spans the full spectrum of all the variations becomes far toogeneral to be of practical use unless it then goes on to descr ibe every possible role, activity, output, and step in detail. The resulting processesare usually documented in hundreds or even thousands of pages of activ-ities and tasks, preconditions and postconditions, rules and guidelines,document templates and formats, and roles and responsibilities

Some organizations have gone even further and have tried to definea single, all-encompassing software development process for an entireindustry! Some companies even sell such processes!

Once these detailed, bulky processes are defined within an organiza-tion, a decree is usually issued, stating that all software development ef-forts, both big and small. must follow the new process. When problemsin following these processes appear, the answer is to add more detail toimprove the process, write down more information, and impose moreorder onto the chaos. However, the procedures used to review and ap-

prove suggested improvements to the new process are often difficult anddrawn-out affairs. The result is a software development process that isinflexible and slow to adapt Very quickly, more and more of the processis ignored, and its definition documents are left gathering dust on theshelf . Everyone goes back to what they were doing before the processwas imposed, except that they may refer to the activities by differentnames to fool either themselves or their management into thinking thatthe new process is still being followed

When successfully implemented, these processes are heavy on cere-mony and administrative activity Everyone looks busy doing something

Everyone has tasks to do, forms to fill out, meetings to attend, and statusto report Often, activity becomes a substitute for productivity. Commu-nication between teams is achieved through the writing and reading of large, beautifully formatted documents. The result is an enormous vol-ume of documentation, files, and records that rapidly become an over-whelming burden to read, fully understand, and keep up to date . Theoriginal desired end resu lt-a software system-often becomes lostsomewhere amidst all the activity and documentation

Heavy, regimented processes make our project managers feel com-fortable because they have something to hold on to, a guaranteed recipe

for success: Their teams are "following the process." When they strikefailure, they cannot be at fault because their teams were following the


32/304

process ; it is the pr oce s s that failed , not the manager or the team obvi-ously, a better proce ss is needed so that another working group or committee is set up to define, do cument. and deliver the next newmira cle-making pr oc e ss.

When we, as de velopers, are f or ced to foll ow one o f these many uni-

fied processes, it feel s as though ou r every step is dictated by the will of the all- pow erful pr ocess. W e no l onge r have t o think, nor d o we have thefreedom to think- a lmos t as th ough the pr oce ss were wielding somesort of "Ruling Ring ," such as that de s cribed in The Lord o f the RingsITolk ienl

O ne Ring to rule them aU , O ne Ring to find them,O ne R in g to b rin g t hem aU and in the d arkne ss bind themIn the Land of M or d or w here the S hadow s l ie.

)RRTolkien [ 'Iolkien]

Repla ce Rin g with P r oce s s and M ord or with the name of your f avoritethousand-page so ftwa re developm e nt proce ss Go on: Try it! Doesit fit ?

Even when the se processes w or k, they fail to deli ver so ftware fastenou gh to ma tch the ev er -qu ickenin g pa ce of cha nge in toda y's busine s senvir onment s.

We needan a ltern a tive to the he avy proce s s approach .

The L ight BrigadeRe centl y, the re has b een a gr owing reb ellion again s t hea vy, high -

ceremony pr oces s e s O ut go the lar ge docum e nts . Out g o the organiza-tional walls separatin g customers , analysts , designers , and program-mers Out go the end less li s ts of detailed tasks , report s , and longmeeting s. However , as o ften happen s in a rebellion , we swing from oneextreme to another. and the baby, if not thrown out completely with thebath water.is left wobbling precari ous ly on the edgeof the b a th .

If weare not ca r e ful. we lose th e thinking bef ore coding (analysis anddesign) Wecan also rapidly lose sight of the original scope and goals for the pr oje ct. Th e r es ult is a pr o ject ou t of contr ol. bu ilding and r e building

the wr ong things , inab ility to deli ve r to a schedule , and a gener a l lack of direction and c oordination-in fact , all the very things th a t the heavyproce s se s were inten de d to provid e .

On Oc tobe r 25, 185 4, at the ba ttle of Bala clava , a mis understoodorder sent 673 Britis h light cavalrymen charging down a narrowing valleyto mak e a fr ontal assa ult on a b at te r y of Russ ia n cann ons . Also c omingunder f ir e f r om cann on and inf antr y on bo th side s of the valley , they werecut t o ribbons; l es s tha n 200, almo st a ll of them w ounded, returned.

If not car eful. in our eager ness to thr ow o ff the burden of hea vy-weight pr oc e s se s , we c ha r ge headl ong , s tra ight into code an d cha os , our very own Charg e of t he Lig ht Brigade ITe nny so n I.

Process Pride:The Pain and Relief

5


33/304

A P ractica l G uideto Fea ture-D riven

D evelop m ent

The Charge of the Light Brigade

Half a league, h al f a l eag ue,Half a l eague onw ard ,

AI! in the v alley of Deat hRode the six hundred ."Forward, the Light Brigade! Charge for the guns! " he said :Into the v olley of DeathRode t he six hundred.

Flash' d al l t heir sabr es bore,Flash' d as they tum' d in a i r ,Sabring the gunners ther e,Charging an army, whIle

All th e world wonder'd :Plunged in the battery-smokeRight ttuo' the line they br oke;Cassoc k and RussianReel ' d from the sabre-strokeShottet ' d and sunder'd .Then they rode bock, but not,Not the six hundred.

"For w ard , the Light Brigade! " Was there a man dismoy'd?Not tho' the soldier knew Some one had blunder ' d :Theirs' not to make repl y ,Theirs' n ot to reason w hy ,Their s' but to do and die:Into the volley of DeathRode the six hundred .

Cannon t o the right of t hem,Cannon t o the left of them,Cannon behind themVolley'd and thunder'd ,·Storm'd at with shot and shell While horse and hero fell They that had fought so w el l Came thro' the Jaws of Death,Bock from the mouth of Hen

All th at was le ft of th emLeft of six hundred.

Cannon t o the right of them,Connon t o t he left of them,

.Connon i n front of themVolley ' d and thunder ' d,·Storm'd at with shot and shell Boldl y they r ode and wel l Into the J aws of Deat h,Int o the mouth of H el l Rode t he six hundred .

When con t heir glory fade?o the wi ld c harge they mod e!

All th e w orld wonder ' d .Honour the charge they mode! Honour the Light Brigade,Noble six hundred!

Alfred, Lord Tennyson (7809-7892) [Tennyson]

The courage , good intentions, effort, and skill of those who took par tin the o rig inal cha rge is no t in any doubt. but t he cos t was appallinglyhigh " W ha t d o you m ean , w e ar e ver y la t e and very over budget ? W e delivered it,didn' t w e?"

Althoug h the L ight Brigade did ca ptu re so me R ussian guns, they hadcharged the wrong ones: "W h at d o y ou m ean , w e f 1C l ven' t built w f w t you w ant ed?"

No one was able to fo llow the Lig ht Brigade and se cure the captu redguns, so they had to be lef t for the enemy to recover:

" W f w t do you m ean , w f 1al w e' v e b uil t is no t H se ful ?"

" W hat do you m ean , you' r e g oin g b ack to the old s y st em ?"

M ilita ry h is to rians s till debate the cha in o f events that led to theheroic but insanely fooli sh charge of the Light Br igade.

" O ur developm ent t eam can' t d eliver even the s im pl est project s! T l 1e~ ar e alw ay sla t e and never produce the s y st em s w e need !"

6


34/304

"The executive sponsors keep changini] their minds ' W e never have the resources or t ime to produce w hat they ask! They change the requirements a t leas t tw o or three t imesbefore w e can ever deliver anytning! I t' s a w onder tnat w e can deliver anything at aU !"

The search for the ultimate process, the one and only true way to do The Searchsoftware development, continues: high ceremony, low ceremony, heavy-weight, lightweight. agile, iterative, incremental. full-lifecycle, user-centric. architecture-centric, feature-centric, and on and on Process wars

have replaced the method wars of the previous decade.

' ''P lay i t again, Sam.' . . only this t ime, call it something slightly different."

Ask yourself the following questions:

• Has executing a particular software development process be-come more important to you, your team, or your organization

than achieving tangible, working results?

• Has executing a particular process in the name of quality be-come more important to you, your team, or your organizationthan producing quality results?

• Has following the "right process" become more important toyou than delivering software on time, within budget, and withall the expected function?

• Does your current process encourage innovation and creativity

or does it stifle them?

• Do you feel as though the process is in control of you, rather than you in control of the process?

• Do you spend more time arguing about process on object tech-nology discussion forums than you do producing useful soft-ware?

• Do you feel that you no longer have to think to produce soft-ware, just follow a recipe, and everything will come out allright?

• 2 weeks gathering requirements

• 3 hours a week meeting to discuss status

• 2 weeks designing

• 4 weeks building and testing

• 2 analysts, 15programmers, 3 testers, I manager, and a par-tridge in a pear tree!

• Mix well. put in small room together for the length of proj-ect, give it an impossible deadline, and let simmer for Process Pride:

The Pain and Relief

7


35/304

lf we can answer yes to these questions, we are suffering the effectsof process pride

We must, m ust remember that a process is only a means to an end.Producing software is the ultimate goal of any software development ef-

fort The process is only the set of tools used to achieve that goal:Process pride occurs when doing things the "right way" becomes moreimportant than achieving the right results.

We need to beware of falling into that trap when talking about FDD

At the end of the day, we are being paid to produce software systems, not

to follow some particular process, no matter how good we may think it is

We tend to forget that the process we follow-whether formal or infor-mal. heavyweight or lightweight-is nothing more or less than a means

to accomplish the goal of creating a software system.

So, with this warning ringing in our ears, let's look at some funda-

mental concepts of a software development process

Communi-cation, C om -munication,and Commu-nication


D evelop m ent

When we examine two developers writing a software application in their spare time, we see little that we would call a formal process However,

when we examine a project with hundreds of developers distributedacross multiple locations working to develop a large software system,process often seems to be all we can see Both examples do haveprocess, but the first is much simpler and very informal. It is most likely

maintained wholly within the minds and interactions of the two develop-

ers who, over time, have learned to communicate very effectively witheach other In larger projects, the processes tend to be both much morevisible and much more formal, although you will still find many small"processes" in a large organization that are hidden, "understood," or part

of the tribal knowledge and not recorded anywhere In fact, the processes(not necessarily productive processes) that last the longest are thosethat become habit: "It's just the way we do things here." One goal for aprocess designer is to make the process straightforward to learn and re-

member so that following it becomes habit as quickly as possible

So what are the fundamental differences between two developers

writing software in a garage and thousand-person, multimillion-dollar software development efforts?

Those who work in the real estate industry tell us that the three mostimportant aspects of real estate are location, location, and location. Thesoftware development process equivalent is communication, communi-cation, and communication Communication is taking place constantlywithin a software development process at every level. In fact, no process

(work) can occur without it! In failed projects, communication or failureof it at some level is usually a major contributor to the project's downfall.

8


36/304

If we consider developers as nodes in a communication network. allpotentially linked to each other by communications channels, there isonly one channel between our two developers in their garage .

However,as we add more developers, the number of potential com-munication channels grows dramatically (Figure 1-1).

Between four developers, there are six potential communicationlinks (Figure 1-2) Between 10, there are 45 potential links, and there are4,950 potential communication links between 100 individuals on a team.

If not managed, there will be either too much time spent communi -cating, and nothing will get done, or too little communication, and re-sults will not integrate and work together '

As a team grows larger, managing communication becomes increas-ingly difficult

LanguageCommunication requires language. Within a development team, dif-

ferent subteams use different languages Some of these languages aretextual. others are graphical, and others are more mathematical in na-ture. There are languages for expressing requirements, defining inter-faces, defining database tables, communicating analysis and designmodels, describing algorithms, and describing patterns; and there is amyriad of different programming languages for communicating instruc-

Figure 1-1The number of poten-

tial communication

channels grows dra-matica Ily as developersare added

P ro ce ss P rid e:

The P ain an d R elief

9


37/304

Figure 1-3Translating from one

"language" to another

A Practical G uideto Fea ture-D riven

D evelop m ent

10

Figure 1-2Mow developers means many more potential communication paths

tions to a computer Much of the work of a development team involvestranslating from one language to another (Figure 1-3)

Then, of course, to add to the mix, there are communication chan-nels and languages required to communicate with customers, users, andsponsors of the project

Each time we translate from one language to another, there is a po-tential for loss of information or for communicating the wrong informa-tion Errors can occur when converting statements made during verbalinterviews to structured requirements and diagrammatic models, addingdocumentation to the models, developing persistent storage models,and even creating the code If information is not accurately transferred at

each of these "interfaces," we have the potential for building the wrongsystem Therefore, we want to keep the number of translations of infer-


38/304

mat ion to a minimum an d to autom a te a s many of the translation s aspossible to redu ce the chance that information is lo s t

To further complicate matters, at each step along the way , the peopleinvolved in transferring the information may not know what they need tocommunicate . For example , users defining the system may not know

what it is that they really need . They ma y end up de s cribing task steps or sy mptoms of a larger pr ob le m with out actually communicatin g theneeded fun ctiona lity. So , not on ly can we make err ors i n translatin g theinf ormation fr om one form or me dium t o a nother. we m a y even be tran s-la ting the wr ong informa tion I Therefore , a good pr ocess uses numer ousf e edback lo ops to provid e validation and verificati on as often and asearly as possible

Another big pr oblem pr eve nting c ommunication is the fear of beingwr ong . If a us er. m a nag e r , ana lys t. or de ve loper is s o a fr a id of being seento h a ve mad e a mistake th a t the y withh old informat ion, clear c ommuni -

cat ion is obvious ly compr omise d, and th e error i s oft en comp oundedove r time lt.i s pro per that we s hould ha ve accountabilit y within a pr ojectbut our s oftwa r e devel opmen t proces ses s hould en co urage and suppor ta n environmen t of trust and r e sponsibi lity, rather th a n one of suspicionand fear of recrimination .

A so ftwa re de velopment pr oces s de s cribes what t o commun icate,whe n to communi cate, h ow to co mmu nica te , and with whom to c ommu-nica te (mo s t pr oces s d esc riptions will not tell you why; this is n ormall y

left f or so me one to write a bo ok about ! )

M ac :.W FlC lt sorts o f communica tio n w ill { w p pen on thi s pro ject? O & viou sl y , thecl ient s need to com m u nic ate their r equirement s t o the development team

Steve: U h, hu hl The t eam need s t o f ind out w hat the cl ient r eally w ants the s ystem tod o vut gat herin g r eqldrements is hard & ecause ..

• Client s of t en have on ly a va g ll e id ea of w hat tne y w ant or w nat is po s sibl e• The d evel opment team o f ten d oe s no t k now t he problem dom ain in d e pt h.• Development a nd b u sine ss people oft en have very d i ff er ent personalities and

sty l e s o f communication.• T he cl ient s , analyst s , and d eveloper s of t en l a c k a common languag e and

terms, w h ic { l aggravat es mi scommunication• A nd so OIL

M ac : ... A nd th o se w or k ing w i th t he clie nt o n r equirements w il l al so have to tak e g r eat car e in w mmunicatil 1g tno se r equirement s to t he r est of the d evelopment t eam. W it hout clear communicat ion of r equir ements , w e cannot buil d the r i ght svstem.

Steve: In ret urn , t f 1 e client s , manager s , u ser s , and s po nso r s ar e going to w ant to seet he pr o g r es s b eing mad e. If w e d o not g ive them t he right l evel of d et ail ed, accurat e , al 1d timely progr e ss r ep ort s, they w ill not ve ab l e to int er vene appr o priate ly t o r esolve is suesand s teer the pr o ject W orse s ti li . t{1el j might int ervene inappropr ia te ly, w hich could bedi sa strous.

M ac : W ha t about co mmunicat ing anall jsi s , de si g n , and im pl ementation?

Process Pride:

The Pain and Relief 11


39/304

Steve: W hat about it?

M ac : W ell , w e generally split the developm ent of softw are into four activities. In analysis , w e try to understand the problem w i th l it tle thought to the particular set onologie s that w e are going to use to build the solution (technical architecture). In de-

sign, w e m ap th e re sul ts of our analysi s to our intended technical ar chitectur e , m ak ing trad e-of fs and addin g m ore d etail as necessar y. In im pl em entation , w e build our design , and in testing, w e verify that the solution does, indeed, solve the problem

Steve: O kay , I see w hat you m ean! T he U nified M odeling Language (UML). despiteall it s problem s, has becom e the de facto standard graphical language for com ming object-oriented anal ysis and desi gn re su lts. D esign patterns, pr og r am m in g l an- gua ge idiom s, and codin g stand ard s hel p devel o per s to com m !-4nicat e and veri f y th at anim plem entation m atches its desi gn. And test cases, t est results, de f ect reports , and f ixescom m unicate quality and com pleteness to m anagers and the client .

M ac: We m ustn ' t forget that the team responsible for deploying the new system

to know the various softw are com ponents that m ake up the system , w hat dat a n e ed s tobe lo aded be fo r e t he s y st em can be used, and th e e xact f orm at of th at data. T he y ar e r e-l iant on the developm ent team to com m unicate al l thi s to th em .

Steve: And existing data m ay need to be " cleaned" and converted to the form at of thenew system . T his involves com m unicat ing w i th the ow ners of . the existing m achines and netw ork l inks m ay be needed, so the deploym ent team al so has to com -m unicat e w ith the operators and u ser s at t he sit e of the new equip m ent

Mac: F inall y, but not l east im portant-although it often seem s to be t reated that w a yin m y experience-the users of the new system w ill need to learn how to use it. T he proj-ec t team needs to com m unica te how to use the new sys tem through online , context- se nsi tive help , use r m anuals , train in g courses , dem onstrations, tips-of-the day m essages,and so on.

Steve: H m m m , it's al ready st ar ting to sound com pl ex. W e w il/ need to br eak the prob-lem dow n and attack it a chunk at a t im e. T hat rem inds m e ..

C om plexity

A Practical G uideto Feature-D riven

D evelopm ent12

There is a limit to t h e amount o f com plexity mer e humans can holdwithin their heads.

As the size of a software system grows, the complexity of that soft-ware system grows "at least as fast as toe square of the size of the pro-gram" IWeinberg 92] and quickly outstrips the relatively fixed capacity of a human brain. Ger ald Weinberg calls this law of softwar e developmentthe si ze/c om pl exit y d ynam ic

The best strategy that we have for dealing with such large pr ob lem sis decomposition. We break the problem down into smaller and smaller prob lems until we have reduced the size of the prob lems to somethingwe can manage We then go a bout solving each small pr ob lem, integrat-ing the solutions to for m the solution for the bigger problem.

Given enough time, our two friends in their garage could produce

very large and complex software systems by solving one small problemafter another . Adding more people to the team allows us to solve many


40/304

of the small p roblem s in parallel and deliver larges yst ems m ore quickly .The m ore people we add, the m ore we can do in parallel.

Her e 's the catch T he m ore pe op le we ha ve wo r king in para llel. themore l ike ly it is that we will bum p into co mmuni cat ion and coo rd inationproblem s . If there ar e s ignificant depe ndenc ie s be twe en the pr oblem s

being solved , we h av e to work hard at p utting the r ight com municat ionchannels in p lace s o tha t ever yone h as the inf ormation they ne edat th eright tim e

S o wea r e back t o ma na ging c omm unicat ion again .

Mac: Steve, W hat if w e coul d arra nge t hin g s so that the d ecom posed problem s arecom pl et el~ ind ependent o f each other ? W ould that reduce the need f or com m unica tionbet w een g ro u p s of devel opers w orkin g on tho se probl em s and avoid having to m ana g ethe overhead of those com m unication s?

Steve: T hat ' s a good point I t is an id ea t o con sid er w hen w e d i scu ss arc hit ectu r e IinChapter 1 2,"Redu cing Dependen cies between C omp onents "]

Acc or ding to Philip Cr os by 's d e finition [Cr osb y], qua lity can be s imp lydefined as c onf orm ance to r e qu ir eme nts-h ow of te n th e s oftware b e-hav es as r eq uir ed The q uesti on, as G er a ld Wei nber g [Wei nberg 921point s o ut, is , whos e r e quirements?

We ca n talk o f qua lity in so ftware dev elopm e nt ha ving b oth a n ex ter-nal and inter na l f ace . A us er ta lking about the qu a lity of a sys te m di s -cus ses the u s e r inte rface , the r es pons e time , the r e liabili ty, and the ea s eof us e of the s yst e m. A de veloper t a lking ab out qualit y dis cus s es ele-gan ce of de sign; ea s e of maint e nan ce a nd enh a ncem e nt ; and compli a nceto st a nda rds, patter ns, and c onven tions.

Th ese two face s a r e , of co ur s e , r ela ted . Low in te r na l quality mak es i tmuch , mu ch harder to mai nta in high ex terna l qua lity. This is e s pec iallytrue f or inc r e ment a l or iter a tive d eve lopme nt whe r e , a fte r the f ir s t iter a-tion or incr em ent. we a reconst a ntly building on what we buil t before .

Rec ognizi ng when a de s ign f or an iterati on is goo d enough is a ve r yvaluabl e s kill. If we m a ke the desi gn too si mple , we a dd t o the rework

tha t we mu s t do in late r iter at ions when w e n eedt o e xtend th a t funct ion-a lity and whe n time p r ess ure m a y be mor e inte nse . If we se lect a m or egen e r a l and co mpl ex desi gn, we c oul d be sp e nd ing t ime bui lding in flexi-bility that will never be used .

It ofte n s ee ms tha t de ve lope r s hav e a n a tur a l comple xity leve l. so mede ve lope r s a lwa ys se e m to make the ir des igns too c omp le x, an d othe rsa lwa ys s e emt o o ver s implif y. Rec ogn izing the s e t ende ncies in t he mse lve shelp s de ve lop ers m a ke t he appropriat e trad e- off decis ion s , as does agoo d knowl e dge of the probl e m d oma in. Wh a tever the tr a de- off de ci-s ion s , it is impo r ta nt that they a r e made v is ible to o ther s on th e te a m-

tha t comm uni ca tion word aga in'

Quality

P roces s P ride:The P ain and R elief

13


41/304


42/304

One of the most documented problems with a waterfall approachover the last couple of decades has been that mistakes made early in theprocess are often not found until very late in the process. The cost infinding an error later. rather than sooner, varies from study to study but isalways much higher. "Observe that it is perhaps 100 times as costly to

make a change to the requirements during system testing as it is to makethe change during requirements definition "[Fairley]

One way to ease this problem is to split the project into iterations or increments so that the distance in time between analysis and test is re-duced. i f we test something earlier. we will find the problem earlier, and

the cost of fixing it is reduced.

A complementary approach is to use practices that increase qualitythroughout the four activities In other words, broaden the concept of quality so that it is more than just the testing of running code. Inspec-tions are one such technique Audits and metrics tools are another

Mac: So w (w t y o u 're sa y in g IS th a t , in e a rlie r m e th o d s, th e y trie d to im p ro v e q u a li tyb y p ro v id in g sh o rte r i te ra t io lls trlro u g h th e l ife c y c le a n d b ro a d e n in g th e d e fin it io n q u a lity to in c lu d e m o re th a n jL IS t c o d e w ith o u t b L lg s

Steve: E x a c tly l B o th stra te g ie s a tte m p t to p ro v id e e a rlie r fe e d h a c k o n th e c o rre c tn e ss oW {1 C lt h a s b e e n d o n e so fa r

Mac: So , by e x p a n d in g th e " d e fin it io n " o f q u a l i ty to in c lu d e th in g s su c h a s c o d in g sta n d a rd s a n d m e a su rin g a u d it s a n d m e tric s in th e c o d e , so ft w a re m a n a g e rs a re a h lto in c re a se th e q u a lity o f t(le d e liv e re d c o d e b e c a u se th e y a re g e ttin g g o o d fe e d b a c k e

lie r in th e life c y c le ?Steve: Y e s, b u t re m e m b e r th a t d e v e lo p e rs g e n e ra lly e n jo y d e liv e rin g q u a lity w o rk , to o

People typically want to do "quality" work. Each individual developer

has his or her own idea about the acceptable level of quality of a systemand that is usually approximately the best quality that they have

achieved in the past.

It is better to ask those developers who have a lower idea of qualityto reach for a higher standard than to ask those with higher standards toreduce their ideas of acceptable quality Our self-esteem is linked to the

quality of what we produce If we are consistently forced to produce whatwe consider to be low-quality work, we will lose self-esteem, resulting in

lower morale and decreased productivity. On the other hand, if recog-nized as such, asking developers to produce a higher quality productthan they would naturally do actually enhances their self-esteem-if they

can do it

Even if an organization standardizes on a level of acceptable internalquality, It may well be lower than that of the individual developers ideasof acceptable quality So, at the beginning of a project, the developmentteam needs to agree on what is an acceptable level of internal qualityand what IS not. Obviously. this level cannot be lower than that of the or- .

P roce ss P ride:

The P ain and R elief 15


43/304

A Pr actical Guideto Feature-Driven

Development

gan iza tion (excep t in unu s ual circums tan ces ) but m a y be se t highe r Thisleve l of qua lity is ma de pu blic in published d e s ign and coding standard sand enforced prim a rily by som e sort of d es ign and cod e ins pecti on (au-tomat e d s ource c ode audits an d s ource c ode formatter s he lp to enf or cecode -na min g an d layo ut standa r ds) .

M ac: I f , as according t o Cro sb y' s w or kin g d ef il 1ition [Crosby}. " quality is conf or -mance to the r equir ement s ," w e c ou ld s p ecify thing s such a s co d ing standard s and t heu se o f var iou s al go r ithms and patt ern s , w he re a p pr op riat e , a s requ irement s and coul d use t echniques such a s cod e inspections t o d et ec t and enf or ce tnese requir ement s In otne r w ord s , a so ftw ar e team can d eal w i th important i ssues on a softw are project bycreat ing a constra int in the form of a r equirement for t he project .

Steve: Y es. theor et ically. In pr actice . I find t hat t his u se o f t he ter m requirementlead s to contu sion I pre f er to r eserve it to mean t{1 e feature s and performance t ha t t he

u se r s de sire in a softw ar e s ystem J pr e f er to ta lk of int erna l qual it y requirements a scom pl yin g w ith st andards , co nvent ions , and p ract ice s.

Also, requirement s such a s " The syst em w ill ship w it f l no crit ical bu gs" a re u sel ess be-cause w e ca nn ot p r ove w hether a sy st em s atisfie s t hat requirement ; w e certainly cannot te ll if a bug w e do not know about is critical .

M ac: O k ay W ha t a bou t a req uirement that sa ys t he s ys t em w ill shi p w ith no k now ncr it ical bug s? W e can mea sur e t ha t .

Steve: Yes w e call , but it sa ys ve ry littl e about t { t e q ua lity o f t ne s y st em In fact , theonl y th ing w e ca n say abou t the qual it y of s y st em b y thi s measure is that i t is pr obablylow in qu ality i f w e have a l on g l ist of k now n critica l bu g s. If thi s re al ly w as a mea su reof qualit ~ , w e coul d " improve qual it y" b y not t est ing at all , w e w ould f ind no cr it ical bugs and could ship w hatev er c om piled cle an ly becau se it w ould sat i s fy that 50-call ed requirement . Even i f w e t ested , how d o w e know w nether our t ester s ar e any good? Thi sis complete non sen se; it ' s ju st playin g w ith figur es and d e fini tion s.

M ac: Hmmm , 110t entirely convinced , but ok a y H ow ever , I r eser ve t he r i gh t to di scu s st his a b it mor e w nen talr ? about t e st ing ..

In iterati ve , obj e ct-orient ed so ftwa r e deve lopment whe r e we w a nt tor e use result s , we n e e d to en s ur e that int e rna l quality is b uilt in earl y so

that we have Qualit y to build on later If we allow low-qu a lity result s atthe start , we will find ourselves in a viciou s cycle o f low quality resultin g

in mor e low qua lity

A word of ca ution. Be c are ful not to confuse qu a lity with opt imiza-tion . Great re sult s can be m a de f r om co mb ina tions of su boptimal part s .Opt imizing a sma ll pa r t ma y make no signifi ca nt differe nc e to the whole An overly complica ted. bug-ridden part or an incorrect implement a tion

of a r e quirement , on the other h a nd . can be the cause of many problem sin other parts.

16


44/304

In lanuary 2000 , a numbe r of people , including P eter Co ad an d leff De

Luca , were sittin g i n a r oo m, discu s sin g the purpo se of a s oftware d ev el-opment proce ss The result of that dis cuss ion was a sta tement s imilar to

the following:

The purpo se o f a so f t w are d ev elo pm en t process is to enabl e an d e n f or ce t he r e- peatable d eliver y of w orkil 1g sof tw are in a tim ely and c os t -e ffect iv e m a nn er , supplying accur at e and m eanin g ful information to all k e y ro les in side and out sid e a pro ject w i th the minimum o f disrupt ion to d evelo per s ,

When a pr ocess em phas izes onl y e nforcem en t, it stifles cr ea tivity

and innovation, and cause s frustration for the devel ope rs who fe e l their idea s are con sid ered of n o wo rth , On the other sid e of the coi n, whe n apro cess emp has izes only en ablin g, c r ea tivity and in nova tion ar e a llowe d

to r e ign unbridl ed , cau sing frus trati on fo r mana gers a nd te a m lea der s

be ca use e ver yon e is do ing the ir own thing, and re sults do not inte gr ateThis i s a constan t bala nci ng act . Any pr oce ss should be monitored a nd

rev ie wed for effec tiven ess a nd va lue , and s hould be modi f ied whe n nec -ess ar y to maint ain its value to the or ganiz ation,

Similarly, having hundred s of pag es o f steps t o exe cute in an overly

s pe cified pr ocess de mor aliz e s the tea m me mbers t o the p oint tha t the y

s witch of f their mind s an d b lindly f ollow the st ep s At the o ther ext r e me ,pr oc e ss descriptions that are too vague, abs tra ct. or gene r al cau s e eac h

one o f us to ma ke up our own wa y o f doing thing s and to work har der

than ne cessar y to achie ve the des ir e d resu lts ,

The ma in me chani s m for co mmu nica tion within the develop me nttea m and bet wee n a devel op ment team and its clien t is often lar ge d ocu-

ments , In a pr oc ess that emphasizes th e production of document s, care

mu s t be take n that the f oc us is not pu t on rec or ding resul ts w he n it

s hould be on gettin g the re s ults righ t-that th e e mpha sis is p ut on

a chiev ing q uality r e sul ts inst e a d of quali ty formatt ing of re s ults

If the overhea d of pr od ucing pr og r ess and st at us r e po rts is too high,it will no t be don e well. and t he inform at ion the y contai n is more l ikely

to b e ina ccur a te o r irr e leva nt. Without ac cur a te and mea ningful inf orma -

tion, the feed back that m an a ge r s get fr om the soft ware p roces s is use less

or, even wors e, late or inaccurate, Man ag er s cannot t ak e appr opria te ac-tion i f the y do not know w hat is ac tuall y happeni ng o n a pr o ject Wo rse

s till . they may t ake ina pp r opriate a ction that incr eases rath e r tha n re -duc es th e pain ,

Process Painand Relief

P roces s P ride:The P ain a n d R elie f

17


45/304

Sum m ary


D evelop m ent

18

A good process is w ell bounded; it provides enough structure to guide innovationand creativity, constraining it to appropriate times and places

A good process clearly defines tasks. Trle tasks are focused 01 1 results without specifyingminutia, so that we progress efficiently but still have the freedom to adapt

to unusual events or changes in circumstances.

A good process produces accurate progress and status information for team leaders,project managers, upper management, and the client, while minimizing the

impact on the developer's time

A good process quickly becomes a matter of {w vit , rather than a set of consciousacts. Developers do not want to have to consult a 3,OOO-pageprocess man-

ual every time they reach a new step in an activity

A good process heips a team to maintain quali ty and manage complexity

A good process optimizes communication w i thin and outside t r1e team.


46/304

Feature-Driven

Development-Projects and People

Answers: Who do we haveto manage in software development?

N o a m o u n t o f p ro c e ss o v e r-sp e c if ic a tio n w i l l m a k e u p fo r b a d p e o p le . F a r b e tte r: S ta ff y o u r p ro je c t w ith g o o d p e o p le , d o w h a te v e r it ta k e s to k e e p th e m h a p P lJ ,a n d u se sim p le , w e ll-b o u n d e d p ro c e sse s to g u id e th e m

a lo n g th e w a lJ ·Coad.LeFebvre, De LucaICoad 991

In Chapter 1,we considered process from a relatively detached perspec-tive. However, a software process must function within a context. That

context is a software development project. Any project of any sort is littlemore than a collection of activities, resources, andcommunication chan-nels, with at least one specific purpose or goal to achieve within a giventime frame However, this is a very general definition and could define aproject for building a bridge, constructing an ocean liner, or landing amission on Mars. Therefore, more specifically, what are the componentsof a software development project? They certainly include:

• S o m e sta te m e n t o f p u rp o se , problem statement, or list of goals or very high-level requirements describing what the system needs

to do. Without this, there is no reason for the project to exist.• A lis t o f th e ro le s that people play on the project. When written

down, this usually takes the form of an abstract organizationalchart. Each different role requires a set of skills and a level of experience. Each role defines responsibilities and accountabil-

ity

• P e o p le w ith tf1 e re q u isite skills a n d e x p e ri e n c e to play the roles in theabstract organizational chart. Assigning people to the roleswithin the abstract organizational chart produces a concrete or-

ganization chart for the project. 19


47/304

A Practical G uideto Fea ture-D riven

D evelop m ent20

• A set of w el l -bound ed p roces se s des cribing how the s e peop le playingtheir r oles interact with each other to produce the desired soft-waresystem .

• A set of technol ogies: pr ogramming la nguages, development tools,ready-built components , modules, and product s.

• An architecture , a f ramework within which to const r uct t he soft -wa r esystem . The pr ojec t may reuse a n ex is ting arc hitec tur e. A l-ternatively, an appropriate framework may not exist, and one of the first activities of the project needs to produce and prove thearchitecture .

The statement of purpose does need to be sensib le It is no nse nse todefine a statement of pu r pose for a project that is not achievable withina reasonable time frame . For very ambitious programs , it is often be tter to identi fy severa l pr ojects t hat can be r un conc urr e ntly or as fo llow-onefforts . As we'll see, Fea ture-Driven Development (FDD) supports thisneed very nicely, indeed . The statement of purpose may a lso start off somewhat vaguely . Chapter 7, "Develop the Overa ll Mode l-Tips for theChief Architec t/Faci lita tor ," suggests a usef ul exerc ise to he lp r e fine thestatement of purpose

The list of roles of a project team is like the players ' positions in as ports teamor the part s in a p lay or symphony Weneed t he software devel -opmen t equiva le nt of playe r s ,actors, and m usic ia ns to cast in those r oles .

The processes describe the rules of the game,the acts of t he p lay, or

the movements in a symphony . They describe the framework th r oughwhic h all wo r k is perfor med .

The technologies are the players' equi pme nt. the p r ops used in theplay, or the musicians ' instrument s .

Likewise , the architec tural framework is the marked pitch, the play -ing area, or the stage a nd sce nery .

M ac: W hat roles do w e n eed on this project?

Steve: W el l , obviously, th e key rol es are peopl e re present ing the user or cust om er , de-vel opers, and testers. W e alr ead y have Lisa as P ro ject M ana ge r t o ow n it and st eer it ,but she w il l probabl y nee d so m e secr eta rial su pport .

Mac: G ary and his team are availabl e to us as custom er reps. T he devel opers w i/! need so m e su pport too, w on' t t l1ey? T he IT depa rtm ent w i/ ! pr ovide the usual generic support but w e'll need to pr ovide m ore pro jecH pec i f ic su pport .

Steve: Yes. Servers, netw ork, databases, buil d sys tem , con f iguration m anagem ent .W e need to try to cover the sup port of all tl1ese areas. A n d t l 1en there is m anaging theactual depl oym ent , too.

M ac: Can w e d raw up an ab st ract organizational chart l ist ing the r ol es w e think w eneed?Steve: O kay. I have an exam ple from a previous project w e can u se as a sta r tin g poin t . (Figure 2-1 )


48/304

N-


49/304


50/304


51/304


52/304

Attracting, Recognizing, and Keeping Good People

An entir e book could be written on each topic , so we willrestrict ourselves toonl y a handful of ba sic idea s per topic.

Attracting Good People Attract in g good peopl e means more than offering competitive sal aries, stan-dard benefits , and challeng ing wor k on the latest technologie s. N earl y all or - ganizat ions can pramise t hese.

So, all other things being equal, what is i t that attract s developers? Here are so me of the additio nal ben ef its from one co mpany' s jo b adver tisemen ts*(with some of the authors' thoughts):

Weekly "Pizza Day",..Thi s company seems to have a sense of fun, and welike pizzo.

F r ee Starbucks C o f fee and Soda ...This compan y k now s th at developer strad itionally live on fat , sugar, and caffeine.

M on th ly Book Allowance ...Thi s company k now s t hot good d eveloper sr ead book s on technol o gy and softwar e devel opment to k eep t hem- selves up to dote.

Paid Certification P r ogr a m s ...P r afessional d ev el opment is im por tant t o thiscom pan y.

No Cubicles...This co m pan y k now s that a good wor kin g envir onment i simportant.

Health Club M ember ships . ..Thi s company values t he health of it s emplo y-

ee s ( and know s th at its developer s Itke foe sugar, and caffeine toomuchO·

Understanding how good developers think and what motivates them is key.

It so unds like th is company unders tands developers and may be a cool pla ce to work .

Anot her attraetor i s t he core value s of an organi za tion or a team. Strong core values will a tt ract people with similar core values. Together soft'score va lues a r e li sted e x plicitl y on i t s career s W eb page , http' // www.tog etherso ftcom / wor k _ here. jsp , and N ebulon' s are st r ongly implied on i t sWeb site , ht tp . // wwwnebulon.coml

H owever, wr iting d own core values on a W eb pag e is no good if other vi si-bl e qualities of t he company do not r ef lect tho se cor e values. I f a co re valueof a compan y is " al wa y s d eliver quality" but that compan y' s pr oducts are full o f bu gs , people ar e repelled instead o f att ra cted b y t hat core value.

" T he c om pany that ad vert i ses t hese benef i ts is Di g i tal Focus (htt p. // wv v w .dig Jt al -focus.com), the home of C li ff Ber g, author of Advanced Java: Deve lopment for Enter -pr ise Applications [Ber g], s ever o l Dr D obbs articles [Dobbs], and the Jav a languag eguru on [he pro jec t in Sing a por e, desc nbed in the I nt rod uc t ion to this book

Feature-DrivenDevelopment--Projects and People

2 5


53/304

A P ractical G uideto F ea ture-D riven

D evelop m ent26

Recognizing Good People

T he n e xt chall enge i s to reco gnize good people In t he swa rm of t hoseat tracted to our team or organization. It is important that strategies are de-vi sed for inter viewing to help identify good people. Ident i fy th e characte ri s-tic s yo u e x pect in the per son you wont for the job and develop an int er viewtechnique that willtest for these characteristics. It sounds so obvious , but in

pra ctice , it is rarely dane well , and on inappropriate Human Resources( HR )-d evi se d defa ult in te r vi

A Practical Guide to Feature Driven Development

Documents

Transcript of A Practical Guide to Feature Driven Development