Addison wesley agility and discipline made easy practices from OpenUP and RUP may 2006 ISBN 0321321308

Bravo!" --P hilippe Kruchte n, P ro fe sso r, Unive rsity o f British C o lum bia "The Unified Process and its practices have had, and continue to have, a great impact on the software in

By Per Kroll, Bruce MacIsaac

Publisher: Addison Wesley Professional

Pub Date: May 19, 2006

Print ISBN-10: 0-321-32130-8

Print ISBN-13: 978-0-321-32130-5

Pages: 448

T able of C ontents | Index

"The Japanese samurai Musashi wrote: 'One can win with the long sword, and one can win with the short sword Whatever the weapon, there is a time and situation in which it

is appropriate.'

"Similarly, we have the long RUP and the short RUP, and all sizes in between RUP is not a rigid, static recipe, and it evolves with the field and the practitioners, as

demonstrated in this new book full of wisdom to illustrate further the liveliness of a process adopted by so many organizations around the world Bravo!"

P hilippe Kruchte n, P ro fe sso r, Unive rsity o f British C o lum bia

"The Unified Process and its practices have had, and continue to have, a great impact on the software industry This book is a refreshing new look at some of the principles underlying the Unified Process It is full of practical guidance for people who want to start, or increase, their adoption of proven practices No matter where you are today in terms of software maturity, you can start improving tomorrow."

Iva r Ja co bso n, Iva r Ja co bso n C o nsulting

"Kroll and MacIsaac have written a must-have book It is well organized with new principles for software development I encounter many books I consider valuable; I consider this one indispensable, especially as it includes over 20 concrete best practices If you are interested in making your software development shop a better one, read this book!"

R ica rdo R Ga rcia , P re side nt, Glo ba l R a tio na l Use r Gro up C o uncil, www.ra tio na l-ug.o rg/inde x php

"Agile software development is real, it works, and it's here to stay Now is the time to come up to speed on agile best practices for the Unified Process, and this book provides

a great starting point."

Sco tt W Am ble r, pra ctice le a de r, Agile Mo de ling

"IBM and the global economy have become increasingly dependent on software over the last decade, and our industry has evolved some discriminating best practices Per and Bruce have captured the principles and practices of success in this concise book; a must for executives, project managers, and practitioners These ideas are progressive, but they strike the right balance between agility and governance and will form the foundation for successful systems and software developers for a long time."

W a lk e r R o yce , Vice P re side nt, IBM So ftwa re Se rvice s-R a tio na l

"Finally, the RUP is presented in digestible, byte-size pieces Kroll and MacIsaac effectively describe a set of practices that can be adopted in a low-ceremony, ad hoc fashion, suited to the culture of the more agile project team, while allowing them to understand how to scale their process as needed."

De a n Le ffingwe ll, a utho r a nd so ftwa re busine ss a dviso r a nd e x e cutive

"This text fills an important gap in the knowledge-base of our industry: providing agile practices in the proven, scalable framework of the Unified Process With each practice able to be throttled to the unique context of a development organization, Kroll and MacIsaac provide software teams with the ability to balance agility and discipline as appropriate for their specific needs."

Bria n G Lyo ns, C T O , Num be r Six So ftwa re , Inc

In Agility and Discipline Made Easy, R a tio na l Unifie d P ro ce ss (R UP ) a nd O pe n Unifie d P ro ce ss (O pe nUP ) e x pe rts P e r Kro ll a nd Bruce Ma cIsa a c sha re twe nty we

ll-de fine d be st pra ctice s tha t yo u a nd yo ur te a m ca n sta rt a do pting to da y to im pro ve the a gility, pre dicta bility, spe e d, a nd co st o f so ftwa re ll-de ve lo pm e nt

Kro ll a nd Ma cIsa a c o utline pro ve n principle s fo r so ftwa re de ve lo pm e nt, a nd supply a num be r o f suppo rting pra ctice s fo r e a ch Y o u'll le a rn wha t pro ble m s e a chpra ctice a ddre sse s a nd ho w yo u ca n be st le ve ra ge R UP a nd O pe nUP (a n o pe n-so urce ve rsio n o f the Unifie d P ro ce ss) to m a k e the pra ctice wo rk fo r yo u Y o u'll findpro a ctive , pre scriptive guida nce o n ho w to a do pt the pra ctice s with m inim a l risk a nd im ple m e nt a s m uch o r a s little o f R UP o r O pe nUP a s yo u wa nt

Le a rn ho w to a pply sa m ple pra ctice s fro m the Unifie d P ro ce ss so yo u ca n

Ex e cute yo ur pro je ct in ite ra tio ns

Em bra ce a nd m a na ge cha nge

T e st yo ur o wn co de

De scribe re quire m e nts fro m the use r pe rspe ctive

Archite ct with co m po ne nts a nd se rvice s

Mo de l k e y pe rspe ctive s

W he the r yo u a re inte re ste d in a gile o r discipline d de ve lo pm e nt using R UP , O pe nUP , o r o the r a gile pro ce sse s, this bo o k will he lp yo u re duce the a nx ie ty a nd co st

a sso cia te d with so ftwa re im pro ve m e nt by pro viding a n e a sy, no n-intrusive pa th to wa rd im pro ve d re sults witho ut o ve rwhe lm ing yo u a nd yo ur te a m

By Per Kroll, Bruce MacIsaac

Publisher: Addison Wesley Professional

Pub Date: May 19, 2006

Praise for Agility and Discipline Made Easy

The Addison-Wesley Object Technology Series

Foreword

Preface

About the Authors

Chapter 1 Leveraging Key Development Principles

Where Do the Practices Come From?

Using Practice Descriptions

Adopting the Practices: Iterative Development, Levels of Ceremony, and Agility

Key Development Principles

Unified Process Lifecycle

Chapter 2 Demonstrate Value Iteratively

Practice 1 Manage Risk

Practice 2 Execute Your Project in Iterations

Practice 3 Embrace and Manage Change

Practice 4 Measure Progress Objectively

Chapter 3 Focus Continuously on Quality

Practice 5 Test Your Own Code

Practice 6 Leverage Test Automation Appropriately

Practice 7 Everyone Owns the Product!

Chapter 4 Balance Stakeholder Priorities

Practice 8 Understand the Domain

Practice 9 Describe Requirements from the User Perspective

Practice 10 Prioritize Requirements for Implementation

Practice 11 Leverage Legacy Systems

Chapter 5 Collaborate Across Teams

Practice 12 Build High-Performance Teams

Practice 13 Organize Around the Architecture

Practice 14 Manage Versions

Chapter 6 Elevate the Level of Abstraction

Practice 15 Leverage Patterns

Practice 16 Architect with Components and Services

Practice 17 Actively Promote Reuse

Practice 18 Model Key Perspectives

Chapter 7 Adapt the Process

Practice 19 Rightsize Your Process

Practice 20 Continuously Reevaluate What You Do

Chapter 8 Making Practical Use of the Best Practices

Which Practices Should I Adopt First?

Start with the Basics

Adopt Related Practices

Practices Supporting Iterative Development

How Can RUP and EPF Help Me?

Choosing the Right Pilot Project

Conclusions

Appendix A The Eclipse Process Framework (EPF)

What Is EPF?

Potential Users of EPF

Extensible Process Content

Software Process Engineering Metamodel

Extensible Process Engineering Tools

Participating in the Development of EPF

Appendix B IBM Rational Method Composer (RMC)

Process for a Variety of Projects

Process for the Enterprise

How the Practitioner Uses RMC

How Process Managers Use RMC

Guiding Principles for Evolving IBM Rational Method Composer Glossary

Bibliography

Index

Ma ny o f the de signa tio ns use d by m a nufa cture rs a nd se lle rs to distinguish the ir pro ducts a re cla im e d a s tra de m a rk s W he re tho se de signa tio ns a ppe a r in this

bo o k , a nd the publishe r wa s a wa re o f a tra de m a rk cla im , the de signa tio ns ha ve be e n printe d with initia l ca pita l le tte rs o r in a ll ca pita ls

IBM, C le a rC a se , O bje cto ry, P urifyP lus, R a tio na l, R a tio na l Unifie d P ro ce ss, R e quisite P ro , R UP , SUMMIT , a nd SUMMIT Asce nda nt a re re giste re d tra de m a rk s o fInte rna tio na l Busine ss Ma chine s C o rpo ra tio n in the Unite d Sta te s, o the r co untrie s, o r bo th

Spe cia l pe rm issio n to use a nd re pro duce e x ce rpts a nd im a ge s fro m the R UP pro duct in Agility and Discipline Made Easy is gra nte d by Inte rna tio na l Busine ss Ma chine s

C o rpo ra tio n

Eclipse is a tra de m a rk o f Eclipse Fo unda tio n, Inc

So m e o f the m a te ria l in this bo o k is a da pte d fro m The Rational Unified Process Made Easy (P e r Kro ll a nd P hilippe Kruchte n, © 2003 P e a rso n Educa tio n).

Kro ll/Kruchte n, The Rational Unified Process Made Easy, p 146 Figure 8-3, p 302 Figure 15-5, © 2003 P e a rso n Educa tio n, Inc R e printe d by pe rm issio n o f P e a rso n

Educa tio n, Inc., publishing a s P e a rso n Addiso n-W e sle y All rights re se rve d

Ma te ria l in the intro ductio ns o f C ha pte rs 27 pre vio usly a ppe a re d in P e r Kro ll a nd W a lk e r R o yce , "Ke y P rinciple s fo r Busine ss-Drive n De ve lo pm e nt," The Rational Edge,

O cto be r 2005 Use d with pe rm issio n

T he a utho rs a nd publishe r ha ve ta k e n ca re in the pre pa ra tio n o f this bo o k , but m a k e no e x pre sse d o r im plie d wa rra nty o f a ny k ind a nd a ssum e no re spo nsibility

fo r e rro rs o r o m issio ns No lia bility is a ssum e d fo r incide nta l o r co nse que ntia l da m a ge s in co nne ctio n with o r a rising o ut o f the use o f the info rm a tio n o r pro gra m s

co nta ine d he re in

T he publishe r o ffe rs e x ce lle nt disco unts o n this bo o k whe n o rde re d in qua ntity fo r bulk purcha se s o r spe cia l sa le s, which m a y include e le ctro nic ve rsio ns a nd/o rcusto m co ve rs a nd co nte nt pa rticula r to yo ur busine ss, tra ining go a ls, m a rk e ting fo cus, a nd bra nding inte re sts Fo r m o re info rm a tio n, ple a se co nta ct:

U.S C o rpo ra te a nd Go ve rnm e nt Sa le s

(800) 382-3419

co rpsa le s@pe a rso nte chgro up.co m

Fo r sa le s o utside the Unite d Sta te s ple a se co nta ct:

Inte rna tio na l Sa le s

inte rna tio na l@pe a rso ne d.co m

Visit us o n the W e b: www.a wpro fe ssio na l.co m

Library of Congress Cataloging-in-Publication Data

C o pyright © 2006 P e a rso n Educa tio n, Inc

All rights re se rve d P rinte d in the Unite d Sta te s o f Am e rica T his publica tio n is pro te cte d by co pyright, a nd pe rm issio n m ust be o bta ine d fro m the publishe r prio r to

a ny pro hibite d re pro ductio n, sto ra ge in a re trie va l syste m , o r tra nsm issio n in a ny fo rm o r by a ny m e a ns, e le ctro nic, m e cha nica l, pho to co pying, re co rding, o rlik e wise Fo r info rm a tio n re ga rding pe rm issio ns, write to :

P e a rso n Educa tio n, Inc

Praise for Agility and Discipline Made Easy

"T he Ja pa ne se sa m ura i Musa shi wro te : 'O ne ca n win with the lo ng swo rd, a nd o ne ca n win with the sho rt swo rd W ha te ve r the we a po n, the re is a tim e

a nd situa tio n in which it is a ppro pria te '

"Sim ila rly, we ha ve the lo ng R UP a nd the sho rt R UP , a nd a ll size s in be twe e n R UP is no t a rigid, sta tic re cipe , a nd it e vo lve s with the fie ld a nd thepra ctitio ne rs, a s de m o nstra te d in this ne w bo o k full o f wisdo m to illustra te furthe r the live line ss o f a pro ce ss a do pte d by so m a ny o rga niza tio ns

a ro und the wo rld Bra vo !"

P hilippe Kruchte n, P ro fe sso r, Unive rsity o f British C o lum bia

"T he Unifie d P ro ce ss a nd its pra ctice s ha ve ha d, a nd co ntinue to ha ve , a gre a t im pa ct o n the so ftwa re industry T his bo o k is a re fre shing ne w lo o k a t

so m e o f the principle s unde rlying the Unifie d P ro ce ss It is full o f pra ctica l guida nce fo r pe o ple who wa nt to sta rt, o r incre a se , the ir a do ptio n o f pro ve npra ctice s No m a tte r whe re yo u a re to da y in te rm s o f so ftwa re m a turity, yo u ca n sta rt im pro ving to m o rro w."

Iva r Ja co bso n, Iva r Ja co bso n C o nsulting

"Kro ll a nd Ma cIsa a c ha ve writte n a m ust-ha ve bo o k It is we ll o rga nize d with ne w principle s fo r so ftwa re de ve lo pm e nt I e nco unte r m a ny bo o k s I

co nside r va lua ble ; I co nside r this o ne indispe nsa ble , e spe cia lly a s it include s o ve r 20 co ncre te be st pra ctice s If yo u a re inte re ste d in m a k ing yo ur

so ftwa re de ve lo pm e nt sho p a be tte r o ne , re a d this bo o k !"

R ica rdo R Ga rcia , P re side nt, Glo ba l R a tio na l Use r Gro up C o uncil, www.ra tio na l-ug.o rg/inde x php

"Agile so ftwa re de ve lo pm e nt is re a l, it wo rk s, a nd it's he re to sta y No w is the tim e to co m e up to spe e d o n a gile be st pra ctice s fo r the Unifie d

P ro ce ss, a nd this bo o k pro vide s a gre a t sta rting po int."

Sco tt W Am ble r, pra ctice le a de r, Agile Mo de ling

"IBM a nd the glo ba l e co no m y ha ve be co m e incre a singly de pe nde nt o n so ftwa re o ve r the la st de ca de , a nd o ur industry ha s e vo lve d so m e

discrim ina ting be st pra ctice s P e r a nd Bruce ha ve ca pture d the principle s a nd pra ctice s o f succe ss in this co ncise bo o k ; a m ust fo r e x e cutive s, pro je ct

m a na ge rs, a nd pra ctitio ne rs T he se ide a s a re pro gre ssive , but the y strik e the right ba la nce be twe e n a gility a nd go ve rna nce a nd will fo rm the

fo unda tio n fo r succe ssful syste m s a nd so ftwa re de ve lo pe rs fo r a lo ng tim e "

W a lk e r R o yce , Vice P re side nt, IBM So ftwa re Se rvice s-R a tio na l

"Fina lly, the R UP is pre se nte d in dige stible , byte -size pie ce s Kro ll a nd Ma cIsa a c e ffe ctive ly de scribe a se t o f pra ctice s tha t ca n be a do pte d in a lo

w-ce re m o ny, a d ho c fa shio n, suite d to the culture o f the m o re a gile pro je ct te a m , while a llo wing the m to unde rsta nd ho w to sca le the ir pro w-ce ss a s

ne e de d."

De a n Le ffingwe ll, a utho r a nd so ftwa re busine ss a dviso r a nd e x e cutive

"T his te x t fills a n im po rta nt ga p in the k no wle dge -ba se o f o ur industry: pro viding a gile pra ctice s in the pro ve n, sca la ble fra m e wo rk o f the Unifie d

P ro ce ss W ith e a ch pra ctice a ble to be thro ttle d to the unique co nte x t o f a de ve lo pm e nt o rga niza tio n, Kro ll a nd Ma cIsa a c pro vide so ftwa re te a m s withthe a bility to ba la nce a gility a nd discipline a s a ppro pria te fo r the ir spe cific ne e ds."

Bria n G Lyo ns, C T O , Num be r Six So ftwa re , Inc

The Addison-Wesley Object Technology Series

Gra dy Bo o ch, Iva r Ja co bso n, a nd Ja m e s R um ba ugh, Se rie s Edito rs

Fo r m o re info rm a tio n, che ck o ut the se rie s we b site a t www.a wpro fe ssio na l.co m /o tse rie s

Ahm e d/Um rysh, Developing Enterprise Java Applications with J2EE™ and UML

Arlo w/Ne usta dt, Enterprise Patterns and MDA: Building Better Software with Archetype Patterns and UML Arlo w/Ne usta dt, UML 2 and the Unified Process, Second Edition

Arm o ur/Mille r, Advanced Use Case Modeling: Software Systems

Be llin/Sim o ne , The CRC Card Book

Be rgströ m /R å be rg, Adopting the Rational Unified Process: Success with the RUP

Binde r, Testing Object-Oriented Systems: Models, Patterns, and Tools

Bittne r/Spe nce , Use Case Modeling

Bo o ch, Object Solutions: Managing the Object-Oriented Project

Bo o ch, Object-Oriented Analysis and Design with Applications, 2E

Bo o ch/Brya n, Software Engineering with ADA, 3E

Bo o ch/R um ba ugh/Ja co bso n, The Unified Modeling Language User Guide, Second Edition

Bo x e t a l., Effective COM: 50 Ways to Improve Your COM and MTS-based Applications

Buck le y/P ulsiphe r, The Art of ClearCase® Deployment

C a rlso n, Modeling XML Applications with UML: Practical e-Business Applications

C la rk e /Ba nia ssa d, Aspect-Oriented Analysis and Design

C o llins, Designing Object-Oriented User Interfaces

C o na lle n, Building Web Applications with UML, 2E

De nne y, Succeeding with Use Cases

D'So uza /W ills, Objects, Components, and Frameworks with UML: The Catalysis(SM) Approach

Do ugla ss, Doing Hard Time: Developing Real-Time Systems with UML, Objects, Frameworks, and Patterns

Do ugla ss, Real-Time Design Patterns: Robust Scalable Architecture for Real-Time Systems

Do ugla ss, Real Time UML, 3E: Advances in The UML for Real-Time Systems

Ee le s e t a l., Building J2EE™ Applications with the Rational Unified Process

Fo wle r, Analysis Patterns: Reusable Object Models

Fo wle r, UML Distilled, 3E: A Brief Guide to the Standard Object Modeling Language

Fo wle r e t a l., Refactoring: Improving the Design of Existing Code

Go m a a , Designing Concurrent, Distributed, and Real-Time Applications with UML

Go m a a , Designing Software Product Lines with UML

He inck ie ns, Building Scalable Database Applications: Object-Oriented Design, Architectures, and Implementations

Ho fm e iste r/No rd/Dilip, Applied Software Architecture

Ja co bso n/Bo o ch/R um ba ugh, The Unified Software Development Process

Ja co bso n/Ng, Aspect-Oriented Software Development with Use Cases

Jo rda n, C++ Object Databases: Programming with the ODMG Standard

Kle ppe /W a rm e r/Ba st, MDA Explained: The Model Driven Architecture™: Practice and Promise

Kro ll/Kruchte n, The Rational Unified Process Made Easy: A Practitioner's Guide to the RUP

Kruchte n, The Rational Unified Process, 3E: An Introduction

La Lo nde , Discovering Smalltalk

La u, The Art of Objects: Object-Oriented Design and Architecture

Le ffingwe ll/W idrig, Managing Software Requirements, 2E: A Use Case Approach

Ma na ssis, Practical Software Engineering: Analysis and Design for the NET Platform

Ma rsha ll, Enterprise Modeling with UML: Designing Successful Software through Business Analysis

McGre go r/Syk e s, A Practical Guide to Testing Object-Oriented Software

Me llo r/Ba lce r, Executable UML: A Foundation for Model-Driven Architecture

Me llo r e t a l., MDA Distilled: Principles of Model-Driven Architecture

Na iburg/Ma k sim chuk , UML for Database Design

O e ste re ich, Developing Software with UML, 2E: Object-Oriented Analysis and Design in Practice

P a ge -Jo ne s, Fundamentals of Object-Oriented Design in UML

P o hl, Object-Oriented Programming Using C++, 2E

P o llice e t a l Software Development for Small Teams: A RUP-Centric Approach

Q ua tra ni, Visual Modeling with Rational Rose 2002 and UML

R e cto r/Se lls, ATL Internals

R e e d, Developing Applications with Visual Basic and UML

R o se nbe rg/Sco tt, Applying Use Case Driven Object Modeling with UML: An Annotated e-Commerce Example

R o se nbe rg/Sco tt, Use Case Driven Object Modeling with UML: A Practical Approach

Schne ide r/W inte rs, Applying Use Cases, 2E: A Practical Guide

Sm ith, IBM Smalltalk

Sm ith/W illia m s, Performance Solutions: A Practical Guide to Creating Responsive, Scalable Software

T k a ch/Fa ng/So , Visual Modeling Technique

T k a ch/P uttick , Object Technology in Application Development, Second Edition

Unhe lk a r, Process Quality Assurance for UML-Based Projects

W a rm e r/Kle ppe , The Object Constraint Language, 2E: Getting Your Models Ready for MDA

W hite , Software Configuration Management Strategies and Rational ClearCasereg;: A Practical Introduction

The Component Software Series

C le m e ns Szype rsk i, Se rie s Edito r

Fo r m o re info rm a tio n, che ck o ut the se rie s we b site a t www.a wpro fe ssio na l.co m /csse rie s

C he e sm a n/Da nie ls, UML Components: A Simple Process for Specifying Component-Based Software Szype rsk i, Component Software, 2E: Beyond Object-Oriented Programming

Since tha t first da y whe n the first so ftwa re de ve lo pm e nt te a m co lla bo ra te d to de live r the first e co no m ica lly via ble so ftwa re -inte nsive syste m , the re ha s be e n a nd

co ntinue s to be a philo so phica l a s we ll a s a pra gm a tic ba ttle o ve r ho w be st to o rga nize a te a m a nd ho w to o rche stra te its wo rk At o ne e x tre m e a re tho se who

a dvo ca te high-ce re m o ny pro ce sse s invo lving rigidly de fine d a rtifa cts a nd a strict o rde ring o f a ctivitie s; a t the o the r e x tre m e a re tho se who e m bra ce lo w-ce re m o nypro ce sse s invo lving a fie rce fo cus o n co ding, with e ve rything e lse co nside re d irre le va nt o r inco nse que ntia l T he pe ndulum ha s swung be twe e n the se two e x tre m e s

fo r ye a rs

T he go o d ne ws is tha t, with de ca de s o f e x pe rie nce in de live ring so ftwa re -inte nsive syste m s be hind us, it is no w po ssible to ide ntify wha t ha s wo rk e d fo r succe ssful

o rga niza tio ns a nd re je ct wha t is co m m o n a m o ng unsucce ssful o ne s T his is the e sse nce o f the Unifie d P ro ce ss, in bo th the R a tio na l Unifie d P ro ce ss (R UP ) a nd itssim ple r o pe n-so urce ve rsio n, O pe n Unifie d P ro ce ss (O pe nUP ): R UP a nd O pe nUP a re bo th sim ply e la bo ra tio ns o f a sm a ll se t o f be st pra ctice s tha t ha ve pro ve dthe m se lve s in pra ctice

In this bo o k , P e r a nd Bruce e x pla in the six k e y principle s tha t se rve a s the fo unda tio n o f R UP a nd O pe nUP Fo r e a ch o f the se principle s, the a utho rs discuss the

po ints o f pa in tha t e a ch principle a ddre sse s, the co nte x t fo r tha t principle , a nd pra gm a tic a dvice o n a pplying it Since no single pro ce ss ca n wo rk in the sa m e

fa shio n fo r e ve ry co nce iva ble co m bina tio n o f do m a in a nd de ve lo pm e nt culture , the a utho rs go o n to de scribe ho w e a ch o f the se principle s ca n be a da pte d a cro ssthe full spe ctrum o f lo w- to high-ce re m o ny use

P e r a nd Bruce a re we ll suite d to this ta sk : bo th ha ve e nga ge d in a m ultitude o f pro je cts o ve r the ye a rs, a nd bo th ha ve be e n de e ply invo lve d in the fo rm ula tio n o f

R UP a nd O pe nUP I ca n think o f no a utho rs be tte r qua lifie d to bring yo u the e sse nce o f the se pro ce sse s

Gra dy Bo o ch

IBM Fe llo w

T he go a l o f this bo o k is to de scribe a se t o f we ll-de fine d pra ctice s tha t yo u a nd yo ur te a m ca n sta rt a do pting to da y Y o u ca n cho o se to a do pt o nly o ne pra ctice o r

a do pt a ll o f the m o ve r a pe rio d o f tim e T he pra ctice s in this bo o k ha ve be e n sho wn to im pro ve the qua lity, pre dicta bility, spe e d, a nd/o r co st o f so ftwa re

de ve lo pm e nt

Why We Wrote This Book

During m o re tha n a de ca de o f a ssisting co m pa nie s in im pro ving the ir so ftwa re de ve lo pm e nt pra ctice s a nd le a ding the de ve lo pm e nt o f the R a tio na l Unifie d P ro ce ss(R UP ), we ha ve ha d the o ppo rtunity to se e wha t wo rk s a nd wha t do e sn't W e ha ve se e n the re wa rds o f succe ssful a do ptio n o f R UP , a nd we ha ve se e n the

cha lle nge s tha t pro je cts a nd te a m m e m be rs m a y e nco unte r a lo ng the wa y O ve r the la st fe w ye a rs, we ha ve a lso le a rne d a lo t fro m the a gile m o ve m e nt, with itsincre a se d fo cus o n pe o ple a nd lo w-ce re m o ny a ppro a che s to so ftwa re de ve lo pm e nt Mo re re ce ntly, we ha ve a lso be e n k e y drive rs o f a n o pe n so urce pro je ct, theEclipse P ro ce ss Fra m e wo rk (EP F), which include s the O pe n Unifie d P ro ce ss (O pe nUP )a n o pe n-so urce ve rsio n o f the Unifie d P ro ce ss O ne o f the o bje ctive s o f EP F is

to cre a te a re po sito ry o f industry pra ctice s, which a re custo m iza ble a nd ca n be a sse m ble d into a se t o f o ut-o f-the -bo x pro ce sse s re fle cting diffe re nt de ve lo pm e ntstyle s T hro ugh a ll o f this wo rk , we ha ve ga ine d va lua ble e x pe rie nce s in wha t wo rk s a nd wha t do e sn't, a s we ll a s ho w to pa ck a ge tha t k no wle dge into pra gm a ticpra ctice s tha t ca n be e a sily a do pte d

W e ha ve fo und tha t m a ny co m pa nie s vie w im pro ving the ir so ftwa re de ve lo pm e nt ca pa bilitie s a s a sta gge ring ta sk It se e m s to be lik e e a ting a n e le pha nt: whe re

do yo u sta rt, a nd ho w do yo u go a bo ut it? T he a nswe r? Y o u pick a te nde r spo t a nd ta k e o ne bite a t a tim e T he "te nde r spo t" is whe re yo u ha ve the m o st pa in; the

"o ne bite a t a tim e " is o ne o r two pra ctice s, o ne o r two so ftwa re discipline s, a nd/o r o ne o r two to o ls In o the r wo rds, ta k e "go o d bite s." Y o u do n't wa nt to cho k e o nthe m Y o u wa nt to be just a little bit hungry fo r the ne x t bite

T his bo o k de scribe s a num be r o f "go o d bite s" tha t will a llo w yo u to sta rt im pro ving yo ur so ftwa re de ve lo pm e nt ca pa bilitie s to da y Y o u ca n ta k e o ne bite o r a la rge rnum be r o f bite s, a ll ba se d o n yo ur a ppe tite

W e wa nt to re duce the initia l a nx ie ty a nd co st a sso cia te d with ta k ing o n a so ftwa re im pro ve m e nt e ffo rt by pro viding a n e a sy a nd unintrusive pa th to wa rd im pro ve d

re sults, witho ut o ve rwhe lm ing yo u a nd yo ur te a m At the sa m e tim e we wa nt to sho w e a rly re sults tha t k e e p the m o m e ntum go ing, thus m a inta ining the inte re st

a nd co m m itm e nt o f e ve ryo ne invo lve d

T he pra ctice s in this bo o k a re writte n inde pe nde ntly o f a ny o ne spe cific pro ce ss T a k e n to ge the r, ho we ve r, the y do co ve r m a ny k e y a spe cts o f R UP a nd O pe nUP

W e be lie ve tha t this bo o k will be a n a sse t fo r pro je cts a nd co m pa nie s inte re ste d in a do pting so m e o r a ll o f R UP o r O pe nUP Ea ch o f the pra ctice s de scribe d in this

bo o k distills k no wle dge fro m R UP , O pe nUP , a nd o the r so urce s to pro vide pra gm a tic guida nce o n ho w to so lve a pa rticula r so ftwa re de ve lo pm e nt pro ble m T he y he lp

yo u in yo ur so ftwa re im pro ve m e nt e ffo rt by a tta ck ing o ne pro ble m a t a tim e Ea ch pra ctice de scribe s ho w O pe nUP a nd R UP ca n he lp yo u a do pt the pra ctice a nd a lso

re fe re nce s o the r m e tho ds such a s e Xtre m e P ro gra m m ing (XP )[1] a nd Scrum , [2] so tha t yo u ca n unde rsta nd diffe re nce s a nd sim ila ritie s in re la tio n to o the r

m e tho ds T his bo o k ca n a lso be va lua ble fo r pro je cts a nd co m pa nie s with no inte re st in R UP o r O pe nUP Y o u ca n sim ply ta k e a ny num be r o f the pra ctice s in this

bo o k a nd a do pt the m o n the ir o wn

[1] 1 See Beck 2004

[2] 2 See Schwaber 2002

What Will You Learn from This Book?

T his bo o k will fa m ilia rize yo u with the fo llo wing:

A num be r o f k e y principle s fo r so ftwa re de ve lo pm e nt, which ha ve be e n va lida te d by tho usa nds o f succe ssful so ftwa re pro je cts o f diffe re nt size s in a va rie ty

o f industrie s

A num be r o f co ncre te pra ctice s tha t yo u a nd yo ur te a m ca n a do pt to da y tha t suppo rt the k e y principle s Ea ch o f the pra ctice s de scribe d pro vide s info rm a tio n

o n the fo llo wing ca te go rie s:

- T he pro ble m the pra ctice a ddre sse s

- Ho w yo u pra ctica lly go a bo ut a do pting the pra ctice

- R e la te d pra ctice s

- W he re to re a d m o re a bo ut the pra ctice

- Ho w to incre m e nta lly a do pt pra ctice s with m inim a l risk , a nd ho w to le ve ra ge R UP a nd O pe nUP

Who Should Read This Book?

T his bo o k is a im e d spe cifica lly a t the fo llo wing re a de rs:

All m e m be rs o f a so ftwa re de ve lo pm e nt te a m who wo uld lik e to le a rn so m e pra ctice s tha t ca n be a pplie d to da y

T e a m m e m be rs who wo uld lik e to le a rn R UP o r O pe nUP , o ne pra ctice a t a tim e T his bo o k do e s no t give yo u a n unde rsta nding o f the co m ple te R UP o r

O pe nUP , but if yo u ha ve unde rsto o d the pra ctice s de scribe d in this bo o k , yo u ha ve co m e a lo ng wa y in le a rning a bo ut R UP a nd O pe nUP

Ma na ge rs, pro ce ss e ngine e rs, a nd o the rs who wa nt to unde rsta nd how key practices can be adopted in the ir o rga niza tio n, o ne pra ctice a t a tim e

Structure and Content of This Book

T he bo o k is divide d into e ight cha pte rs C ha pte r 1 pro vide s a n o ve rvie w o f six k e y principle s fo r so ftwa re de ve lo pm e nt tha t a re use d a s a ba se fo r the structure o fthis bo o k C ha pte r 1 a lso pro vide s a n o ve rvie w o f R UP , O pe nUP , XP , a nd Scrum

C ha pte rs 2 thro ugh 7 re vie w e a ch o f the six k e y principle s in turn Fo r e a ch principle , we de scribe a num be r o f pra ctice s tha t suppo rt it Mo st pra ctice s ca n be

a do pte d individua lly, a llo wing yo u to unde rsta nd ho w to m a k e quick im pro ve m e nts in yo ur de ve lo pm e nt witho ut ha ving to im ple m e nt to o m uch cha nge C ha pte r 8

de scribe s ho w to a do pt a nd be ne fit fro m the se pra ctice s

How to Read This Book

T his bo o k ca n be re a d using a ny o f thre e a ppro a che s:

1 R e a d o nly the pa rts tha t m a k e se nse fo r yo ur te a m Sta rt by re a ding C ha pte r 1 De te rm ine which k e y principle yo u think wo uld a dd the m o st va lue to yo u

a nd yo ur te a m Go to the co rre spo nding cha pte r Lo o k thro ugh the pra ctice s liste d fo r tha t cha pte r, a nd re a d tho se yo u find o f m o st inte re st Do e s thepro ble m a ddre sse d by e a ch pra ctice co incide with a pro ble m yo u a re fa cing, a nd is it wo rth fix ing? If so , sha re tho se with yo ur te a m m e m be rs a nd ge t

a gre e m e nt to a do pt the o ne s tha t pe rta in to yo ur situa tio n

O nce yo u ha ve a do pte d the ide ntifie d pra ctice s, use the sa m e a ppro a ch to ide ntify the ne x t se t o f pra ctice s to re a d up o n T his a ppro a ch is de scribe d in

m o re de ta il in C ha pte r 8

2 R e a d the pa rts tha t a re re le va nt fo r yo ur ro le No te tha t since so ftwa re de ve lo pm e nt is a te a m e ffo rt, it is go o d to be a t le a st so m e wha t fa m ilia r with

- Archite ct: re a d C ha pte r 1 a nd P ra ctice s 1, 2, 1011, 1518, a nd 20.

- Ana lyst: re a d C ha pte r 1 a nd P ra ctice s 12, 710, 12, a nd 20

- De ve lo pe r: re a d C ha pte r 1 a nd P ra ctice s 12, 59, 1112, 1418, a nd 20

- T e ste r: re a d C ha pte r 1 a nd P ra ctice s 12, 49, 12, a nd 20

3 R e a d the bo o k fro m sta rt to finish to le a rn a s m uch a s po ssible a bo ut pra ctice s a pplica ble fo r a ll m e m be rs o n yo ur te a m

For More Information

T o le a rn m o re a bo ut o r to do wnlo a d EP F a nd O pe nUP , go to the Eclipse Fo unda tio n W e b site a t www.e clipse o rg/e pf/

R UP is de live re d thro ugh the pro duct IBM R a tio na l Me tho d C o m po se r (R MC ) Additio na l info rm a tio n a bo ut R UP o r R MC , including a da ta she e t a nd a pro duct de m o ,

ca n be o bta ine d fro m IBM a t http://www.ibm co m /so ftwa re /a wdto o ls/rm c/

Info rm a tio n a bo ut the R a tio na l So ftwa re Glo ba l Use r Gro up C o m m unity ca n be fo und a t http://www.ra tio na l-ug.o rg/inde x php.Aca de m ic institutio ns ca n co nta ct IBM

fo r info rm a tio n o n a spe cia l pro gra m fo r including R UP in a so ftwa re e ngine e ring curriculum a t http://www.ibm co m /unive rsity/

Acknowledgments

T he ide a s a nd tho ughts synthe size d in this bo o k ha ve be e n de rive d fro m m a ny so urce s W e ha ve le a rne d a lo t fro m the m a ny ta le nte d individua ls inside a nd

o utside IBM who ha ve he lpe d sha pe R UP a nd m a k e it wo rk in the tre nche s W e ha ve a lso le a rne d fro m the a gile co m m unity, Eclipse , a nd the va rio us pro ce ss

co m m unitie s W e e spe cia lly a ppre cia te tho se who cha lle nge d o ur ide a s, he lping us to e vo lve a nd sha rpe n wha t we pre se nt in this bo o k

T his bo o k wo uld no t ha ve be e n writte n if no t fo r the R UP pro duct a nd its curre nt pro duct te a m : Am a nda Brijpa ul, R ica rdo Ba lduino , T re vo r C o llins, C a rlo s Go ti,Micha e l Ha nfo rd, P e te r Ha um e r, Ma rga re t He dstro m , Ke lli Ho usto n, R usse ll P a nno ne , T hie rry P a ra da n, C e cile P e ra ire , Da n P o pe scu, Micha e l Ste rn, P a wa n R e wa ri,Jim R ue hlin, Je ff Sm ith, Jo hn Sm ith, a nd Go rdo n Schne e m a nn

O ve r the ye a rs, the R a tio na l fie ld te a m s a nd te chnica l e x pe rts ha ve a ccum ula te d a lo t o f e x pe rie nce in im ple m e nting a nd using R UP W e a re gra te ful fo r the m a ny

pe rce ptive re vie w co m m e nts a nd ide a s fro m the se e x pe rts, who ha ve a dde d m a ny insights into wha t do e s a nd do e s no t wo rk o ut in the tre nche s W e wo uld

e spe cia lly lik e to re co gnize Da vid Alve y, Kurt Bittne r, Bill C o ttre ll, P e te r Ee le s, Bill Higgins, Ke lli Ho usto n, Sa if Isla m , W a lk e r R o yce , a nd Jo hn Sm ith

O ur e x te rna l re vie we rs pro vide d inva lua ble fe e dba ck , fo rcing us to re think the structure a nd co nte nt o f the bo o k a nd ho pe fully he lping us to cre a te a bo o k tha t is

e a sie r to re a d a nd a ddre sse s the m o st re le va nt issue s fo r a bo o k a bo ut a gility a nd discipline T he se insights we re pro vide d by Sco tt Am ble r, Jo shua Ba rne s, Lisa

C rispin, Jim Dunio n, Iva r Ja co bso n, P hilippe Kruchte n, T o m P o ppe ndie ck , Da n R a wstho rne , C hris So sk in, C hristo ph Ste indl, Ga rth R ichm o nd, Da ve T ho m a s, Da vid

T re nt, a nd Micha e l Vizdo s

He a th Ne wburn, T e d R ive ra , a nd Sco tt W ill a ssiste d us thro ugh the ir de e p e x pe rtise in te sting, e a ch co ntributing a pra ctice to this bo o k , fo r which we a re m o stgra te ful

C a the rine So uthwo o d a nd De bo ra h Fo ge l de se rve spe cia l tha nk s fo r m a k ing a pro pe r m a nuscript o ut o f o ur scribble s, a s did Mik e P e rro w

W riting a bo o k a lwa ys ta k e s m o re tim e tha n yo u think it will, a nd we wa nt to tha nk o ur wive s a nd k ids, Susa n a nd Na ta sha Kro ll, a lo ng with Ka thy, Bla ise , a nd

C o urtne y Ma cIsa a c, fo r be ing pa tie nt with the m a ny we e k e nds a nd nights spe nt writing a nd re writing the bo o k

Fina lly, m a ny tha nk s to o ur e dito r, W illia m Zo brist, fo r co rra lling us thro ugh the writing pro ce ss; to Ma ry O 'Brie n, fo r ta k ing o n this bo o k ; a nd to the pro ductio n a nd

m a rk e ting te a m s a t Addiso n-W e sle y, no ta bly T yrre ll Alba ugh, Ste pha ne Na k ib, a nd Kim Silve stro , fo r he lping us to ge t this bo o k o ut

About the Authors

Per Kroll is the pro je ct le a de r o n the Eclipse P ro ce ss Fra m e wo rk P ro je ct, a n o pe n-so urce pro je ct, a nd de ve lo pm e nt m a na ge r fo r R UP a nd IBM R a tio na l Me tho d

C o m po se r He is re spo nsible fo r IBM R a tio na l's stra te gy in the pro ce ss a re a , including inte gra tio n be twe e n m e tho ds a nd to o ls, a nd m e tho d inte gra tio n within IBM

P e r ha s twe nty ye a rs o f so ftwa re de ve lo pm e nt e x pe rie nce in supply cha in m a na ge m e nt, te le co m , co m m unica tio ns, a nd so ftwa re pro duct de ve lo pm e nt He is the

co a utho r o f the highly a ccla im e d The Rational Unified Process Made Easy (Addiso n-W e sle y).

P e r live s in Lo s Ga to s, C a lifo rnia , with his wife , Susa n, da ughte r, Na ta sha , a nd go lde n re trie ve r, C o ppe r He e njo ys running, pla ying flo o rba ll (a co m m o n No rdicspo rt ce nte re d a ro und be a ting o the r m iddle -a ge d m e n o ve r the shins), hik ing, a nd a ny type o f bo a rd ga m e He is k no wn to ha ve a n o cca sio na l be e r, a nd he lo ve s

to da nce

Bruce MacIsaac is the te chnica l le a d a nd m a na ge r fo r R UP a nd O pe nUP co nte nt de ve lo pm e nt a t IBM R a tio na l O ve r the la st twe nty ye a rs, Bruce ha s se rve d in a

va rie ty o f m a na ge m e nt a nd te chnica l ro le s, le a ding bo th sm a ll a nd la rge so ftwa re de ve lo pm e nt te a m s Mo re re ce ntly, he de ve lo pe d the first ve rsio n o f IR UP , theIBM inte rna l-ta ilo re d insta nce o f R UP , co -de ve lo pe d the initia l ve rsio n o f O pe nUP , a nd le d the m igra tio n o f R UP to its m o st re ce nt inca rna tio n in R a tio na l Me tho d

C o m po se r He is no w re spo nsible fo r re a lizing IBM pro ce ss stra te gy, inte gra ting e x isting m e tho ds in a sca le a ble fra m e wo rk , a nd de ve lo ping ne w co nte nt to co ve rthe ne e ds o f diffe re nt k inds o f pro je cts a nd busine sse s

Bruce le ft the ra in o f Va nco uve r, British C o lum bia , in 2004 with his wife , Ka thy, a nd childre n, Bla ise a nd C o urtne y, to dry o ut in Sa n Jo se , C a lifo rnia He e njo ys

ro lle r-bla ding, sk iing, te nnis, a nd a ll style s o f da nce Altho ugh Bruce a nd P e r e njo y m a ny o f the sa m e things, the y a re e a sy to te ll a pa rtBruce ha s m o re ha ir a nd is

a be tte r da nce r

Chapter 1 Leveraging Key Development Principles

T his bo o k pro vide s a se t o f so ftwa re e ngine e ring be st pra ctice s tha t yo ur pro je ct ca n sta rt using right a wa y to im pro ve the wa y yo u de ve lo p so ftwa re T he pra ctice s

ca n be a do pte d individua lly, but the y a lso suppo rt e a ch o the r T his m e a ns tha t yo u ca n pick a se t o f pra ctice s to a do pt a nd be a ble to m a k e se nse o f the m witho ut

ha ving to a do pt a ll o f the pra ctice s As yo u a do pt m o re a nd m o re o f the pra ctice s, yo u will sta rt to no tice the syne rgy a m o ng the m Ea ch pra ctice be co m e s a pie ce

o f a puzzle , a nd ta k e n to ge the r, tho ugh no t co m ple te , the y co nstitute the ba ck bo ne o f a pro ce ss tha t is ite ra tive , a gile , a nd sca le s to yo ur pro je ct ne e ds Se e the

P re fa ce fo r ho w to use this bo o k

Practices can be adopted individually.

Where Do the Practices Come From?

W e ha ve cho se n the be st pra ctice s in this bo o k ba se d o n principle s gle a ne d fro m a huge num be r o f succe ssful pro je cts a nd distille d into a fe w sim ple guide line stha t we ca ll k e y de ve lo pm e nt principle s (se e the se ctio n Ke y De ve lo pm e nt P rinciple s la te r in this cha pte r) Gro uping the pra ctice s unde r the se k e y de ve lo pm e ntprinciple s a llo ws yo u to ide ntify pro ve n principle s tha t a ddre ss the issue s yo ur pro je ct is fa cing a nd re vie w the pra ctice s suppo rting e a ch principle to se e ho w yo u ca n

m a k e pro gre ss to wa rd a do pting the principle W e will discuss the to pic o f a do ptio n in m o re de ta il in C ha pte r 8, "Ma k ing P ra ctica l Use o f the Be st P ra ctice s."

T he se pra ctice s bo rro w fro m a la rge num be r o f ite ra tive a nd a gile pro ce sse s, a ll sha ring a fo cus o n ite ra tive de ve lo pm e nt; co ntinuo us inte gra tio n; e a rly a nd

co ntinuo us te sting; a ddre ssing custo m e r ne e ds; pe o ple a nd te a m co lla bo ra tio n; a nd m inim izing pro ce ss o ve rhe a d

OpenUp is an open-source version of the Unified Process.

T he pra ctice s ca pture m uch o f the tho ught tha t wa s fo rm a tive in the cre a tio n o f the Open Unified Process (OpenUP), e spe cia lly its m o st a gile a nd lightwe ight fo rm ,

O pe nUP /Ba sic, ta rge ting sm a lle r a nd co llo ca te d te a m s inte re ste d in a gile a nd ite ra tive de ve lo pm e nt O pe nUP is a pa rt o f the Eclipse Process Framework[1] (EPF),

a n o pe n so urce pro ce ss fra m e wo rk de ve lo pe d within the Eclipse o pe n so urce o rga niza tio n.[2] It pro vide s be st pra ctice s fro m a va rie ty o f so ftwa re de ve lo pm e nttho ught le a de rs a nd the bro a de r so ftwa re de ve lo pm e nt co m m unity tha t co ve r a dive rse se t o f pe rspe ctive s a nd de ve lo pm e nt ne e ds So m e o f the pra ctice s in the

EP F m a y diffe r fro m the o ne s yo u find in this bo o k , be ca use the y we re pro duce d by pe o ple with a diffe re nt vie w o f ho w to de ve lo p so ftwa re o r ta rge te d a diffe re nttype o f pro je ct T his is o ne o f EP F's stre ngths: a llo wing dive rsity o f ide a s, while e nco ura ging le a rning fro m e a ch o the r, the re by driving unifica tio n a nd e vo lutio n o f

be st pra ctice s W e be lie ve tha t re a ding this bo o k will he lp yo u ga in insights into k e y a spe cts o f O pe nUP /Ba sic a s we ll a s EP F; se e the se ctio n O pe nUP /Ba sic la te r inthis cha pte r a nd Appe ndix A fo r m o re de ta il

[1] www.eclipse.org/epf /

[2] www.eclipse.org

EPF is an open source process framework.

RUP is a continually evolving process framework that extends EPF.

T he k e y de ve lo pm e nt pra ctice s a lso ha ve a stro ng co nne ctio n to R UP R UP is a co ntinua lly e vo lving pro ce ss fra m e wo rk It sta rte d in 1987 a s the O bje cto ry

P ro ce ss[3], a use -ca se -drive n a nd o bje ct-o rie nte d pro ce ss, a nd in 1996 wa s inte gra te d with the R a tio na l P ro ce ss[4], a n ite ra tive a nd a rchite cture -ce ntric pro ce ss.Since 1996, it ha s inte gra te d be st pra ctice s fro m a bro a d se t o f so urce s, including pro ce sse s fo r te sting, co nfigura tio n m a na ge m e nt, a gile de ve lo pm e nt, se rvice -

o rie nte d a rchite cture , a nd busine ss e ngine e ring[5] R UP e x te nds EP F with in-de pth pro ce ss co nte nt fo r spe cific te chno lo gie s a nd to o ls, such a s J2EE a nd IBM to o ls;

fo r spe cific do m a ins, such a s pa ck a ge d a pplica tio n de ve lo pm e nt, syste m s e ngine e ring, a nd pro gra m m a na ge m e nt; a nd fo r pro ce ss m a turity sta nda rds a ndfra m e wo rk s, such a s SEI C MMI

[3] See Jacobson 1992

[4] See Devlin 1995

[5] See Appendix B and Kroll 2001 f or the history of RUP

So m e o f the pra ctice s in this bo o k a re m o re a ppro pria te fo r pro je cts tha t ne e d to fo llo w a highe r-ce re m o ny pro ce ss, m a k ing the m be tte r re fle ct R UP tha n thelighte r-we ight guida nce in EP F W e be lie ve tha t R UP use rs will find the pra ctice s in this bo o k va lua ble , be ca use the y a rticula te a cle a r se t o f principle s fo r de ve lo ping

so ftwa re Unfo rtuna te ly, to o m a ny R UP use rs do no t a dhe re to the se principle s (se e Ke y De ve lo pm e nt P rinciple s la te r in this cha pte r) a nd so m isinte rpre t theunde rlying spirit o f R UP

XP, Scrum, Agile Modeling, Crystal, Agile Data Method, and DSDM have influenced this book.

O the r ite ra tive a nd a gile pro ce sse s, including e Xtre m e P ro gra m m ing (XP ),[6] Scrum ,[7] Agile Mo de ling,[8] C rysta l,[9] Agile Da ta Me tho d,[10] a nd Dyna m ic Syste m s

De ve lo pm e nt Me tho d (DSDM)[11] ha ve influe nce d the pra ctice s in this bo o k , just a s the y ha ve influe nce d R UP a nd O pe nUP

Using Practice Descriptions

Ea ch k e y de ve lo pm e nt principle is discusse d in its o wn cha pte r a nd co nta ins the pra ctice s tha t suppo rt tha t principle Fo r e x a m ple , the principle De m o nstra te Va lueIte ra tive ly is suppo rte d by the pra ctice Ma na ge R isk , which give s co ncre te guida nce o n o ne o f se ve ra l pra ctice s tha t will he lp yo u to a dhe re to the principle

e ffe ctive ly Ea ch pra ctice de scriptio n discusse s the fo llo wing:

Problem: the pro ble m tha t the pra ctice a ddre sse s

Background: ba ck gro und info rm a tio n

A pplication: ho w to a pply the pra ctice

Comparison with other practices: ho w the pra ctice co m pa re s with pra ctice s fo und in m a jo r ite ra tive a nd a gile de ve lo pm e nt pro ce sse s, including XP a nd

Scrum

A doption: ho w to im ple m e nt the pra ctice a t diffe re nt le ve ls o f a do ptio n

Related best practices: a dditio na l suppo rting pra ctice s

A dditional information: a dditio na l re fe re nce info rm a tio n a va ila ble in O pe nUP a nd R UP , a nd in bo o k s re le va nt to the pra ctice

T he re m a y be pra ctice s tha t do no t fit yo ur pro je ct o r o rga niza tio n a t this tim e fo r te chnica l, cultura l, busine ss, o r o the r re a so ns Y o u m a y find tha t yo u a re a lre a dy

fo llo wing o the r pra ctice s Mo st pra ctice s ca n be a do pte d a t diffe re nt le ve ls, a llo wing yo u to a do pt m o re pra ctice s o ve r tim e a s we ll a s im ple m e nt the m a t a highe r

le ve l W e be lie ve tha t gra dua lly a do pting a distinct se t o f pra ctice s a t a le ve l a ppro pria te fo r yo ur o rga niza tio n will e na ble yo u to sta rt im pro ving to da y, a nd to

co ntinue im pro ving o ve r subse que nt pro je cts, witho ut re quiring tha t yo u cha nge e ve rything a t o nce Se e the fo llo wing se ctio n fo r m o re info rm a tio n o n the diffe re nt

le ve ls o f a do pting a pra ctice

Be fo re we dive into the pra ctice s, le t's discuss the pro ce ss o f a do pting the pra ctice s: ite ra tive de ve lo pm e nt, le ve ls o f ce re m o ny a nd a gility, fo llo we d by the k e y

de ve lo pm e nt principle s W e will the n pro vide a n o ve rvie w o f the Unifie d P ro ce ss life cycle , fo llo we d by a n o ve rvie w o f O pe nUP /Ba sic, R UP , XP , a nd Scrum in turn

Adopting the Practices: Iterative Development, Levels of Ceremony, and Agility

A k e y a spe ct o f this bo o k is to a llo w yo u to m o ve incre m e nta lly fro m whe re yo u a re to da y to whe re yo u wo uld lik e to be a co uple o f ye a rs fro m no w, a do pting thepra ctice s a t yo ur o wn pa ce

Levels of Adopting the Practices

Ea ch pra ctice ca n be a do pte d a t thre e diffe re nt le ve ls: ba sic, inte rm e dia te , a nd a dva nce d T he ba sic le ve l re pre se nts a le ve l o f a do ptio n we think m o st pro je cts ca n

a dhe re to with lim ite d inve stm e nts, tha t is, with a lim ite d sk ill se t a nd with no o r sm a ll a m o unts o f to o l inve stm e nts T his le ve l thus re pre se nts a re a so na blesta rting po int o n yo ur jo urne y to wa rd im pro ve d a bility to de ve lo p so ftwa re e ffe ctive ly, but it is no t ne ce ssa rily a n a cce pta ble e nd go a l As yo u m o ve to the

inte rm e dia te a nd a dva nce d le ve ls o f a do ptio n, yo u will ha ve to m a k e a dditio na l inve stm e nts in building sk ills a nd/o r to o ls Fo r so m e te a m s a nd pra ctice s, the ba sic

o r inte rm e dia te a do ptio n le ve l is pre fe ra ble O the r te a m s sho uld a im a t a do pting a dva nce d-le ve l pra ctice s fo r m a x im um pro ductivity

Each practice can be adopted at three levels: basic, intermediate, and advanced.

Process Map

T o unde rsta nd the le ve l tha t is a ppro pria te fo r yo ur te a m , we will use a pro ce ss m a p (se e Figure 1.1) cha ra cte rize d by two dim e nsio ns discusse d be lo w:[12][12] See Chapter 3 in Kroll 2003 f or an in-depth discussion on the process map

Low ceremony/High ceremony[13] dim e nsio n o n the ho rizo nta l a x is Low ceremony pro duce s m inim um suppo rting do cum e nta tio n a nd ha s little fo rm a lity

in the wo rk ing pro ce dure ; High ceremony ha s co m pre he nsive suppo rting do cum e nta tio n, tra ce a bility m a inta ine d be twe e n a rtifa cts, C ha nge C o ntro l Bo a rds,

a nd so o n

[13] Cockburn ref ers to "Ceremony" as "Methodology Weight." See page 123 in Cockburn 2002 f or an interesting discussion on this topic

Waterfall/Iterative dim e nsio n o n the ve rtica l a x is Waterfall is a line a r a ppro a ch with la te inte gra tio n a nd te sting; Iterative is a risk -drive n de ve lo pm e nt

a ppro a ch with e a rly a nd co ntinuo us im ple m e nta tio n, inte gra tio n, te sting, a nd va lida tio n o f so ftwa re tha t de live rs co ncre te va lue to the sta k e ho lde rs

Figure 1.1 Process Map for Process and Practice Comparison.

By organizing processes and practices along two dimensionsLow ceremony/High ceremony and Waterfall/Iterativeyou can compare them and analyze which are

more suitable for your proj ect or organization Agility translates to being in the lower-left quadrant on the map.

(Adapted from Kroll 2003.)

Agility and Ceremony

Agility is the ability to respond rapidly to risks and change.

W e de fine a gility a s the ability to respond to risks rapidly; changing requirements or stakeholders needs, or other changes impacting the application we are building.[14] Agilitytra nsla te s to be ing in the lo we r-le ft qua dra nt in o ur pro ce ss m a p Ite ra tive de ve lo pm e nt pro vide s us with the ra pid a nd tim e ly fe e dba ck we ne e d to unde rsta ndwhe n a nd wha t to cha nge , a nd the lo w ce re m o ny pro vide s us with the a bility to e x e cute cha nge s ra pidly

[14] Compare Larman 2004, page 25, "agilityrapid and f lexible response to change."

So , do we a lwa ys wa nt to be in the lo we r-le ft "a gility" co rne r? If yo u a re two de ve lo pe rs building a n a pplica tio n with a sho rt life spa n, yo u m a y cho o se to sa ve tim e

by no t do cum e nting m a ny o f the re quire m e nts o r the de sign T his m a y a llo w yo u to be m o re pro ductive a nd to m a k e ra pid cha nge s to the a pplica tio n Ho we ve r, if

m a p to ga in pro ductivity, while lo sing a gility By de plo ying the right to o ls, ho we ve r, yo u ca n co unte r this lo ss a nd re duce the co st o f cha nge , a llo wing yo u a lso to

m o ve do wn o n the sca le

Mo st pro je cts[15] be ne fit fro m be ing a s lo w a s po ssible o n the wa te rfa ll/ite ra tive a x is to e nsure ra pid fe e dba ck , but no t so lo w tha t the co st a sso cia te d with the

o ve rhe a d o f e a ch ite ra tio n be co m e s pro hibitive O ne o f the a im s o f ite ra tive de ve lo pm e nt is to re duce the o ve rhe a d co st o f e a ch ite ra tio n so tha t yo u ca n do m o re

ite ra tio ns, a nd m a ny o f the pra ctice s in this bo o k he lp yo u a chie ve tha t go a l As P ro fe sso r Ba rry Bo e hm po ints o ut in Get Ready for Agile Methods, with Care,[16] e a chpro je ct sho uld cho o se the a ppro pria te le ve l o f ce re m o ny to fit its spe cific ne e ds (Bo e hm use d the te rm "a gile " to m e a n ro ughly the sa m e a s wha t we re fe r to a s

"ce re m o ny.") T his m e a ns tha t e a ch pro je ct sho uld be a s a gile a s po ssible ba se d o n its spe cific cha ra cte ristics, but no t m o re a gile

[15] A f ew projects with very well understood requirements and architecture, f acing very limited risk, are exceptions to this rule and may benef it f rom waterf all development

[16] See Boehm 2002

Mo st, but no t a ll, a dva nce d pra ctice s le a d to highe r le ve ls o f ce re m o ny If your project is better off following a low-ceremony process, you should probably not adopt an advanced practice if it leads to higher level of ceremony O n the o the r ha nd, the re a re m a ny re a so ns why pro je cts m a y be ne fit fro m m o re ce re m o ny, including la rge

pro je ct size , re gula to ry re quire m e nts, distribute d de ve lo pm e nt, co m ple x pro je cts, lo ng a pplica tio n life spa n, o r co m ple x sta k e ho lde r re la tio ns In so m e ca se s a n

a dva nce d a do ptio n le ve l le a ds to le ss ce re m o ny a nd sho rte r a nd m o re fre que nt ite ra tio ns, which is pro ba bly be ne ficia l fo r m o st pro je cts tha t a re willing to ta k e o nthe inve stm e nt

Where Does a Level of Adoption Take You on the Process Map?

W e de scribe the le ve ls o f a do ptio n fo r e a ch pra ctice , a s we ll a s giving a n indica tio n o f the dire ctio n in which the a do ptio n le ve l will ta k e yo u o n the pro ce ss m a p

Le t's lo o k a t e x a m ple s o f so m e o f the sym bo ls we use :

If the a rro w go e s do wn a nd to the le ft, it m e a ns tha t a do pting the pra ctice a t this le ve l will le a d to , o r e na ble yo u to ha ve , sho rte r ite ra tio ns with a de cre a se d le ve l

o f ce re m o ny T his is typica l fo r m a ny o f the pra ctice s a t the ba sic le ve l but co uld a lso be true fo r the inte rm e dia te a nd a dva nce d le ve ls

If the a rro w go e s do wn a nd to the right, it m e a ns tha t a do pting the pra ctice a t this le ve l will le a d to , o r e na ble yo u to ha ve , sho rte r ite ra tio ns, while incre a sing the

le ve l o f ce re m o ny o r le a rning curve fo r ne w te a m m e m be rs T his o utco m e m a y be de sira ble if yo ur pro je ct ne e ds m o re ce re m o ny, o r if te a m m e m be rs ne e d tobuild m o re sk ills, but if tha t is no t the ca se , yo ur pro je ct sho uld co nside r no t a do pting the pra ctice a t this le ve l

If the a rro w go e s up a nd to the right, it m e a ns tha t a do pting the pra ctice a t this le ve l will incre a se the le ve l o f ce re m o ny yo u a re wo rk ing with, a s we ll a s the

o ve rhe a d a sso cia te d with do ing sho rte r ite ra tio ns, po te ntia lly fo rcing yo u to incre a se the ite ra tio n le ngth T he se a re typica lly no t go o d cha nge s fo r a pro je ct, but the

be ne fits o f im ple m e nting the pra ctice m a y be va lua ble e no ugh to co unte ra ct the dra wba ck s

Key Development Principles

T he pra ctice s in this bo o k a re o rga nize d a cco rding to six funda m e nta l principle s o bse rve d by IBM to cha ra cte rize the m o st succe ssful pro je cts in the so ftwa re

de ve lo pm e nt industry.[17] Ma ny o f the fo llo wing principle s (se e Figure 1.2) a re fo und to so m e de gre e in m o st ite ra tive a nd a gile pro ce sse s:

[17] These six principles are an evolution of what IBM Rational previously called the 6 Best Practices

1 A da pt the pro ce ss.

2 Ba la nce sta k e ho lde r prio ritie s.

3 Co lla bo ra te a cro ss te a m s.

4 De m o nstra te va lue ite ra tive ly.

5 Ele va te the le ve l o f a bstra ctio n.

6 Fo cus co ntinuo usly o n qua lity.

Figure 1.2 Principles for Business-Driven Development.

These six principles characterize the software development industry's best practices in the creation, deployment, and evolution of software-intensive systems They have been derived by IBM through workshops with thousands of development managers and executives and by synthesizing input from a large number of

technical leaders within IBM who are working with software development organizations across all industries.

Six fundamental principles characterize the most successful projects in the software industry.

Ea ch o f the se principle s is de scribe d in a se pa ra te cha pte r giving a n o ve rvie w o f the principle , o utlining the pa tte rns o f be ha vio r tha t be st e m bo dy e a ch principle ,

a nd listing the m o st re co gniza ble a nti-pa tte rns tha t ca n ha rm so ftwa re de ve lo pm e nt pro je cts T he prim a ry fo cus o f e a ch cha pte r is a se t o f suppo rting pra ctice s tha twill he lp yo ur te a m to a dhe re to the principle T o pro vide a m o re lo gica l se que nce fo r the bo o k , we ha ve cho se n to pre se nt the cha pte rs in a diffe re nt o rde r fro mthe a lpha be tica l o rde r in which the principle s a re liste d a bo ve T he re is no pa rticula r significa nce to the o rde ring o f pra ctice s within a cha pte r T he principle s a ndthe ir suppo rting be st pra ctice s a re liste d be lo w in the o rde r in which the y a ppe a r in the bo o k

Each principle and supporting practices is described in a separate chapter.

Demonstrate value iteratively.

Ea ch ite ra tio n sho uld de live r incre m e nta l ca pa bilitie s tha t a re a sse sse d by sta k e ho lde rs T his e na ble s yo u to ge t fe e dba ck fro m sta k e ho lde rs a s we ll a s o npro gre ss m a de so tha t yo u ca n a da pt yo ur pla ns a s re quire d Ite ra tive de ve lo pm e nt a lso a llo ws yo u to fo cus e a ch ite ra tio n o n a ddre ssing the k e y risk s tha tthe pro je ct is curre ntly fa cing, a llo wing yo u to incre a se pre dicta bility

P ra ctice 1 Ma na ge risk

P ra ctice 2 Ex e cute yo ur pro je ct in ite ra tio ns

P ra ctice 3 Em bra ce a nd m a na ge cha nge

P ra ctice 4 Me a sure pro gre ss o bje ctive ly

Focus continuously on quality.

C o ntinuo usly im pro ving qua lity re quire s m o re tha n just te sting to va lida te fitne ss fo r use R a the r, it invo lve s a ll te a m m e m be rs thro ugho ut the

life cycle ha ving the m build qua lity into the pro ce ss a nd the pro duct An ite ra tive a ppro a ch fo cuse s o n e a rly te sting a nd te st-a nd-build a uto m a tio n thro ugho utthe life cycle a s a m e a ns to re duce the num be r o f de fe cts, pro vide fa ct-ba se d qua lity m e trics e a rly o n, a nd a llo w yo u to pla n a nd a da pt yo ur pro duct m o re

e ffe ctive ly ba se d o n re a lity

P ra ctice 5 T e st yo ur o wn co de

P ra ctice 6 Le ve ra ge te st a uto m a tio n a ppro pria te ly

P ra ctice 7 Eve ryo ne o wns the pro duct

Balance stakeholder priorities.

T he re will a lwa ys be m a ny co m pe ting sta k e ho lde r prio ritie s, such a s pro ducing a so lutio n ra pidly a nd ine x pe nsive ly ve rsus a ddre ssing a ll the busine ss

re quire m e nts W e ne e d to wo rk clo se ly with the sta k e ho lde rs to m a k e sure tha t we unde rsta nd the ir prio ritie s a nd to prio ritize the right pro je cts a nd thepro je ct re quire m e nts W e a lso ne e d to strik e the right ba la nce be twe e n le ve ra ging e x isting a sse ts a nd building custo m so ftwa re , a ck no wle dging tha t in

so m e ca se s the fo rm e r m a y re quire co m pro m ising o n wha t re quire m e nts to a ddre ss

P ra ctice 10P rio ritize re quire m e nts fo r im ple m e nta tio n.

P ra ctice 11Le ve ra ge le ga cy syste m s

Collaborate across teams.

W e ne e d to e na ble pe o ple to wo rk a t the ir be st T his m e a ns tha t we ne e d to e quip ta le nte d pe o ple with the right sk ills, bre a k do wn wa lls tha t pre ve nt apro je ct te a m fro m co lla bo ra ting e ffe ctive ly, a nd put in pla ce the right e nviro nm e nts to fa cilita te m e a ningful co lla bo ra tio n As so ftwa re be co m e s incre a singlycritica l to ho w we run o ur busine ss, we a lso ne e d to m a k e sure tha t we wo rk we ll to ge the r a cro ss busine ss, so ftwa re , a nd o pe ra tio na l te a m s

P ra ctice 12Build high-pe rfo rm a nce te a m s

P ra ctice 13O rga nize a ro und the a rchite cture

P ra ctice 14Ma na ge ve rsio ns

Elevate the level of abstraction.

C o m ple x ity is a m a jo r e ne m y to pro je ct succe ss, a nd m inim izing the a m o unt o f co de , da ta structure s, co m po ne nts, m o de l e le m e nts, o r o the r co nstructshum a ns pro duce during a pro je ct is crucia l to re ducing co m ple x ity Y o u ca n a chie ve this go a l by re using e x isting a sse tssuch a s busine ss m o de ls,

co m po ne nts, pa tte rns, a nd se rvice sinste a d o f custo m -building ne w o ne s Y o u ca n a lso le ve ra ge highe r-le ve l la ngua ge s, fra m e wo rk s, a nd to o ls tha t ca n

ge ne ra te co de fro m highe r-le ve l m o de ls; a uto m a te unit te sting; a nd m a na ge the co m ple x ity o f co nfigura tio n m a na ge m e nt Ano the r a ppro a ch to re ducing

co m ple x ity is to pro m o te im plicity Y o u ca n do this by re fa cto ring, k e e ping co de a nd m o de ls cle a n, a nd im ple m e nting k e y a spe cts o f the a rchite cture first inwha t we ca ll a rchite cture -drive n de ve lo pm e nt

P ra ctice 15Le ve ra ge pa tte rns

P ra ctice 16Archite ct with co m po ne nts a nd se rvice s

P ra ctice 17Active ly pro m o te re use

P ra ctice 18Mo de l k e y pe rspe ctive s

A dapt the process.

Mo re pro ce ss is no t ne ce ssa rily be tte r R a the r, yo u ne e d to a da pt the pro ce ss to the spe cific ne e ds o f yo ur pro je ct, ba se d o n size , co m ple x ity, ne e ds fo r

co m plia nce , a nd so o n In a dditio n, yo u ne e d to a da pt the pro ce ss to diffe re nt life cycle pha se s, so yo u m a y, fo r e x a m ple , use le ss ce re m o ny a t the sta rt o f

a pro je ct a nd m o re ce re m o ny to wa rd the e nd Y o u m ust a lso co ntinuo usly im pro ve the pro ce ss, fo r e x a m ple by a sse ssing ho w we ll it wo rk s a t the e nd o f

e a ch ite ra tio n

P ra ctice 19R ightsize yo ur pro ce ss

P ra ctice 20C o ntinuo usly re e va lua te wha t yo u do

Unified Process Lifecycle

T hro ugho ut this bo o k yo u will se e re fe re nce s to the Unified Process lifecycle T his is the life cycle use d in R UP a nd O pe nUP , a nd a ll o the r pro ce sse s pa rt o f the

Unified Process fa m ily It is o ne o f se ve ra l life cycle s suppo rte d in the EP F Eve n tho ugh the pra ctice s in this bo o k typica lly a pply to a ny ite ra tive life cycle , the y wo rk

pa rticula rly we ll with the Unifie d P ro ce ss life cycle

The Unified Process lifecycle divides a project into four phases: Inception, Elaboration, Construction, and Transition.

T he life cycle de scribe s the tim e dim e nsio n o f pro je ct, tha t is, ho w a pro je ct is divide d into pha se s a nd ite ra tio ns It divide s a pro je ct into fo ur phases: Inception,

Elaboration, Construction, a nd Transition, e a ch e nding with a we ll-de fine d m ile sto ne [18] Ea ch pha se ha s spe cific o bje ctive s:

[18] See Kroll 2003 f or an in-depth overview of what is done in each phase

1 Inception Esta blish the sco pe o f the syste m , including a go o d unde rsta nding o f wha t syste m to build, by re a ching a high-le ve l unde rsta nding o f the

re quire m e nts Mitiga te m a ny o f the busine ss risk s a nd pro duce the busine ss ca se fo r building the syste m a nd a visio n do cum e nt to ge t buy-in fro m a ll

sta k e ho lde rs o n whe the r o r no t to pro ce e d with the pro je ct T his is sim ila r to wha t m a ny a gile pro ce sse s re fe r to a s Iteration 0.

2 Elaboration R e duce m a jo r risk s to e na ble co st a nd sche dule e stim a te s to be upda te d a nd to ge t buy-in fro m k e y sta k e ho lde rs Mitiga te m a jo r te chnica l

risk s by ta k ing ca re o f m a ny o f the m o st te chnica lly difficult ta sk s De sign, im ple m e nt, te st, a nd ba se line a n e x e cuta ble architecture, including subsyste m s,

the ir inte rfa ce s, k e y co m po ne nts, a nd a rchite ctura l m e cha nism s such a s ho w to de a l with inte rpro ce ss co m m unica tio n o r pe rsiste ncy Addre ss m a jo r busine ssrisk s by de fining, de signing, im ple m e nting, a nd te sting k e y ca pa bilitie s, which a re va lida te d with the custo m e r Do no t de fine a nd a na lyze a ll re quire m e nts

a t this tim e , a s do ing so wo uld le a d to wa te rfa ll de ve lo pm e nt De ta il a nd a na lyze o nly the re quire m e nts re quire d to a ddre ss the a bo ve risk s

3 Construction Unde rta k e a m a jo rity o f the im ple m e nta tio n a s yo u m o ve fro m a n e x e cuta ble a rchite cture to the first o pe ra tio na l ve rsio n o f yo ur syste m

De plo y se ve ra l inte rna l a nd a lpha re le a se s to e nsure tha t the syste m is usa ble a nd a ddre sse s use r ne e ds End the pha se by de plo ying a fully functio na l

be ta ve rsio n o f the syste m , including insta lla tio n a nd suppo rting do cum e nta tio n a nd tra ining m a te ria l (a ltho ugh the syste m will lik e ly still re quire fine -tuning

o f functio na lity, pe rfo rm a nce , a nd o ve ra ll qua lity)

4 Transition Ensure tha t so ftwa re a ddre sse s the ne e ds o f its use rs by te sting the pro duct in pre pa ra tio n fo r re le a se a nd m a k ing m ino r a djustm e nts ba se d o n

use r fe e dba ck At this po int in the life cycle , use r fe e dba ck fo cuse s m a inly o n fine -tuning, co nfigura tio n, insta lla tio n, a nd usa bility issue s; a ll the m a jo rstructura l issue s sho uld ha ve be e n wo rk e d o ut m uch e a rlie r in the pro je ct life cycle

Each phase contains one or more iterations, each producing a product increment.

Ea ch pha se co nta ins o ne o r m o re iterations (se e Figure 1.3), which fo cus o n pro ducing a pro duct incre m e nt, tha t is, the wo rk ing co de a nd o the r de live ra ble s

ne ce ssa ry to a chie ve the busine ss o bje ctive s o f tha t pha se T he re a re a s m a ny ite ra tio ns a s it ta k e s to a de qua te ly a ddre ss the o bje ctive s o f tha t pha se , but no more If o bje ctive s ca nno t be a de qua te ly a ddre sse d within the pla nne d pha se , a no the r ite ra tio n sho uld be a dde d to the pha se , but this will de la y the pro je ct T o

a vo id such a de la y, m a k e sure tha t e a ch ite ra tio n is sha rply fo cuse d o n just wha t is ne e de d to a chie ve the busine ss o bje ctive s o f tha t pha se , but no le ss Fo r

e x a m ple , fo cusing to o he a vily o n re quire m e nts in Ince ptio n is co unte rpro ductive ; so is no t invo lving sta k e ho lde rs

Figure 1.3 The Unified Process Lifecycle.

Each of the four phases in the Unified Process lifecycle consists of one or several iterations Each iteration builds on the result of previous iterations, delivering a product increment one step closer to the final release Product increments should include working software, with a possible exception being the product increments

produced in the Inception phase for new applications.

T he Unifie d P ro ce ss life cycle pro vide s a gre a t de a l o f fle x ibility P ro duct incre m e nts m a y be inte rna l o nly a nd m a y be de m o nstra te d o r de plo ye d o nly to se le ctpro je ct sta k e ho lde rs O the r pro duct incre m e nts m a y a lso be re le a se d fo r use by custo m e rs Fo r e x a m ple , so m e pro je cts be ne fit fro m the de plo ym e nt o f se ve ra lpro duct incre m e nts to the pro ductio n e nviro nm e nt, which a llo ws e nd use rs to a do pt the m o st critica l ca pa bilitie s m o re ra pidly Y o u ca n do this by ra pidly m o ving intothe T ra nsitio n pha se a nd ha ving se ve ra l T ra nsitio n ite ra tio ns, e a ch de plo ying a re le a se into the pro ductio n e nviro nm e nt (se e Figure 1.4)

Figure 1.4 Incremental Delivery Using the Unified Process Lifecycle.

Proj ects that deliver product increments into the production environment often rapidly move into the Transition phase Once in Transition, they deliver a new product increment to production at the end of each iteration The milestone at the end of the Construction phase aims at ensuring that all pieces are together so that

the system can be deployed You should pass this management milestone before undertaking deployments into the production environment.

O pe nUP is a n o pe n-so urce pro ce ss fra m e wo rk tha t o ve r tim e is e x pe cte d to co ve r a bro a d se t o f de ve lo pm e nt ne e ds [19] O pe nUP /Ba sic is a subse t o f O pe nUP ,

a nd pro vide s a sim plifie d se t o f a rtifa cts re la tive to R UP a nd a m uch sm a lle r se t o f ro le s, ta sk s, a nd guide line s Le t's lo o k brie fly a t the k e y a rtifa cts, the e sse ntia ls

o f the pro ce ss, a nd ho w the se re la te to the pra ctice s in this bo o k

[19] At the time of this book's printing, OpenUP is almost equivalent to OpenUP/Basic, and we have chosen to primarily ref er to OpenUP/Basic f or the remainder of this book OpenUP is expected togrow over time, while OpenUP/Basic will continue to be a small process

OpenUP/Basic is an agile and iterative process focusing on the needs of small collocated teams.

T he pro je ct te a m m a inta ins a work item list[20] o f a ll wo rk tha t ne e ds to be do ne , including re quire m e nts a nd cha nge re que sts to be a ddre sse d a nd ra ndo m

ta sk s, such a s de live ring tra ining At the be ginning o f e a ch ite ra tio n, the te a m prio ritize s which wo rk ite m s sho uld be a ddre sse d within tha t ite ra tio n, a nd tha t

subse t o f the wo rk ite m list is ca lle d the Iteration Plan (se e Figure 1.5) T he te a m prio ritize s wo rk ite m s to drive do wn risk s a nd to de live r high-prio rity e nd-use r

ca pa bilitie s in e a ch ite ra tio n

[20] Work item list corresponds to product backlog in Scrum; see Schwaber 2002

Figure 1.5 Managing an OpenUP/Basic Project.

The proj ect manager is responsible for producing a high-level proj ect plan, maintaining a work item list of all things to be done, prioritizing work items into an

iteration plan, and assessing the result of the iterations The entire team is typically involved in producing each of these artifacts.

See Practice 19.

See Practices 1 and 10.

An ite ra tio n is typica lly a fe w we e k s lo ng, a nd e a ch ite ra tio n will de live r a n e x e cuta ble tha t is o ne ste p clo se r to the fina l pro duct, with the po te ntia l e x ce ptio n o f thefirst ite ra tio n During a n ite ra tio n, the te a m will wo rk o n de fining, de signing, im ple m e nting, a nd te sting the re quire m e nts liste d in the ite ra tio n pla n, a s we ll a s a ny

o the r pla nne d wo rk ite m s At the e nd o f e a ch ite ra tio n, the te a m will a sse ss wha t wa s a cco m plishe d a nd de m o nstra te the e x e cuta ble to sta k e ho lde rs T he re sulting

fe e dba ck will e na ble the te a m to im pro ve upo n the so lutio n a nd unde rsta nd wha t a re the m o st im po rta nt wo rk ite m s fo r the ne x t ite ra tio n Le sso ns le a rne d duringthe re tro spe ctive im pro ve the pro ce ss fo r the ne x t ite ra tio n

See Practices 2, 3, 4, and 20.

A vision o utline s sta k e ho lde r ne e ds a nd high-le ve l fe a ture s, e sta blishing a co m m o n unde rsta nding o f the do m a in Functio na l re quire m e nts a re do cum e nte d a s use

ca se s a nd sce na rio s, a nd o the r re quire m e nts a re do cum e nte d a s supple m e nta ry re quire m e nts T he re quire m e nts a re incre m e nta lly im ple m e nte d by gro wing the

de sign a nd im ple m e nta tio n in sta ge s, while co ntinuo usly te sting a nd inte gra ting the co de into builds A stro ng e m pha sis is pla ce d o n te st-a nd-build a uto m a tio n to

e na ble fre que nt a nd high-qua lity builds

See Practices 56, 810, 14, and 18.

O pe nUP /Ba sic is ste e pe d in the be lie f tha t the te a m ne e ds to ta k e re spo nsibility fo r the e nd pro duct, to which e ve rybo dy chips in a s ne e de d T o im pro ve

pro ductivity a nd qua lity, the te a m sho uld re use e x isting a sse ts, such a s pa tte rns a nd co m m o n co m po ne nts, a s a ppro pria te O pe nUP /Ba sic a lso puts a stro ng

e m pha sis o n the a rchite cture ; a sta ble a rchite cture is e sta blishe d e a rly in the pro je ct a nd e vo lve s co ntinuo usly a lo ng with the a pplica tio n C o m po ne nts a nd se rvice s

a re le ve ra ge d a s a ppro pria te , a nd the a rchite cture a lso im pa cts ho w re spo nsibilitie s a re divide d within the te a m

See Practices 7, 1113, and 1517.

O pe nUP /Ba sic is a subse t o f O pe nUP , a nd is de live re d thro ugh the EP F (se e Appe ndix A) It is a lso the ba sis fo r R UP

Rational Unified Process (RUP)<title/>

RUP extends EPF with additional process content.

R UP is a wide ly a do pte d pro ce ss fra m e wo rk use d by te ns o f tho usa nds o f pro je cts ra nging fro m te a m s o f two to te a m s with hundre ds o f m e m be rs, in a bro a d

va rie ty o f industrie s wo rldwide It e x te nds EP F with a la rge vo lum e o f a dditio na l pro ce ss co nte nt, a llo wing de ve lo pm e nt te a m s to sca le the ir pro ce ss to do the

fo llo wing:

C a rry o ut distribute d o r la rge -sca le de ve lo pm e nt re quiring m o re ce re m o ny, such a s re quire m e nts tra ce a bility, a na lysis m o de ls, m o de l-drive n a rchite cture(MDA), o r co m pre he nsive te sting o f lo a d a nd pe rfo rm a nce

De ve lo p syste m s using IBM to o ls, pro viding spe cific guida nce o n re le va nt te chno lo gie s such a s J2EE a nd NET , a nd using IBM a nd pa rtne r to o ls

De ve lo p syste m s a dhe ring to industry sta nda rds such a s ISO 9001, SEI C MMI, o r SO X

Sca le fro m pro je ct-o rie nte d pro ce sse s to e nte rprise pro ce sse s, such a s pro gra m a nd po rtfo lio m a na ge m e nt; syste m s e ngine e ring; e nte rprise re use ;busine ss m o de ling a nd sim ula tio n; o r e nte rprise -sca le SO A

R UP fo llo ws the Unifie d P ro ce ss life cycle a nd a dhe re s to the k e y principle s de scribe d a bo ve R UP e m pha size s the im po rta nce o f a da pting the pro ce ss to the ne e ds

o f yo ur pro je ct R a the r tha n pro viding o ne pro ce ss, such a s O pe nUP /Ba sic, R UP pro vide s a co lle ctio n o f pro ce sse s tha t ca n e ithe r be use d o ut-o f-the -bo x o r furthe rcusto m ize d T he se pro ce sse s a re va ria tio ns built o n O pe nUP /Ba sic a nd include pro ce sse s fo r La rge -Sca le C usto m Applica tio n De ve lo pm e nt, C o m m e rcia l-O ff-T he -She lf (C O T S) P a ck a ge d De live ry (se e Figure 1.6), Se rvice -O rie nte d Archite cture De ve lo pm e nt, Syste m s Engine e ring, Sm a ll P ro je cts, Ma inte na nce P ro je cts, P o rtfo lio

Ma na ge m e nt, a nd so o n Mo re pro ce sse s a re co ntinua lly be ing a dde d R UP a llo ws yo u to custo m ize the se pro ce sse s o r build yo ur o wn pro ce ss thro ugh the pro ductIBM R a tio na l Me tho d C o m po se r, which is the de live ry ve hicle fo r R UP T he pro duct is de scribe d in m o re de ta il in Appe ndix B

Figure 1.6 RUP for Commercial-Off-The-Shelf (COTS) Packaged Application Delivery.

RUP provides many out-of-the-box processes for different types of proj ects, including COTS packaged application delivery For COTS development, RUP provides specific guidance on how to evaluate commercial components or packages, how to deal with a Request for Information (RFI) and a Request for Proposals (RFP), and

how to make trade-offs to balance the many conflicts between stakeholder needs, architecture, program risk, and market concerns.

[View full size image]

RUP provides a collection of processes that can either be used "out of the box" or further customized.

O ne o f the k e y ide a s be hind R UP is tha t a pro ce ss is m uch m o re va lua ble whe n a uto m a te d by to o ls T he re fo re , a funda m e nta l a spe ct o f R UP is the tight

inte gra tio n with de ve lo pe r to o ls thro ugh co nte x t-se nsitive pro ce ss guida nce a va ila ble within the to o ls a nd to o l-spe cific guida nce a va ila ble in the pro ce ss, which

m a k e s R UP a n inte gra l pa rt o f the de ve lo pm e nt e nviro nm e nt R UP is a lso tightly inte gra te d with to o ls tha t a llo w te a m s to insta ntia te the ir pro ce ss, e na bling

a da ptive pla nning o f pro je cts a nd co lla bo ra tive so ftwa re de ve lo pm e nt (se e Appe ndix B fo r m o re info rm a tio n) Eve n tho ugh R UP is inte gra te d with IBM a nd o the r

to o ls, it do e s no t re quire the use o f a ny o ne se t o f to o ls

R UP is de scribe d in a va rie ty o f white pa pe rs a nd bo o k s.[21] T he m o st co m pre he nsive info rm a tio n ca n be fo und in the R a tio na l Me tho d C o m po se r (R MC ) pro duct,which co nta ins de ta ile d guide line s, e x a m ple s, a nd te m pla te s co ve ring the full pro je ct life cycle Ho we ve r, R UP unde rwe nt e x te nsive m o de rniza tio n in 2005, a nd

m a te ria l o r pro duct ve rsio ns pre da ting 2006 m a y use diffe re nt te rm ino lo gy

[21] See Kruchten 2003 and Kroll 2003

eXtreme Programming (XP)

eXtreme Programming (XP) is o ne o f the be st-k no wn a gile pro ce sse s C re a te d by Ke nt Be ck ,[22] it is co nside re d by m a ny to be "glo rifie d ha ck ing," but tha t is fa rfro m the ca se XP is a discipline d a ppro a ch, re quiring sk ille d pe o ple who a re co m m itte d to a dhe ring clo se ly to a co re se t o f principle s

[22] Beck 2004

XP is a disciplined approach, requiring skilled people adhering to a core set of principles.

XP a rticula te s five va lue s to guide yo u in yo ur pro je ct: communication, simplicity, feedback, courage, a nd respect Furthe r, it pre scribe s a se t o f pra ctice s to m a k e the se

va lue s co ncre te Altho ugh it m a y be uncle a r whe the r so m e bo dy re a lly a dhe re s to a va lue , yo u ca n e a sily te ll whe the r so m e bo dy a dhe re s to the pra ctice XP

pra ctice s a re divide d into primary a nd secondary T he prim a ry pra ctice s a re liste d be lo w.

Sit together he lps yo u to co m m unica te m o re e ffe ctive ly by be ing physica lly co llo ca te d in the sa m e ro o m o r o ffice spa ce

Whole team ta lk s a bo ut the im po rta nce o f building a co he sive te a m with a dive rse se t o f sk ills re quire d to co m ple te the pro je ct.

Informative workspace te lls yo u tha t if a n o utside r spe nds 15 se co nds in yo ur wo rk spa ce , he o r she sho uld be a ble to ge t a ge ne ra l ide a o f ho w the pro je ct is

go ing W ha t a re the issue s yo u a re fa cing a nd ite m s yo u a re wo rk ing o n?

Energized work guide s yo u in a djusting yo ur wo rk ho urs so tha t yo u functio n e ffe ctive ly whe n wo rk ing a nd a vo id burno ut.

Pair programming te lls yo u to write a ll pro ductio n co de in pa irs, with e a ch pe rso n ta k ing turns wa tching a nd a ssisting the o the r pro gra m m e r write co de Stories a llo w yo u to spe cify, in o ne o r two se nte nce s, ca pa bilitie s tha t typica lly ta k e o ne o r two da ys to im ple m e nt T he custo m e r prio ritize s which sto rie s to

im ple m e nt a nd in wha t o rde r

Weekly cycle m e a ns tha t a t the be ginning o f e a ch we e k yo u pla n wha t sho uld be a cco m plishe d fo r tha t we e k by a sse ssing sta tus, prio ritizing use r sto rie s,

a nd dividing use r sto rie s into ta sk s tha t pro gra m m e rs sign up fo r

Quarterly cycle a llo ws yo u to ste p ba ck a nd de te rm ine ho w to im pro ve pro ce ss, re m o ve bo ttle ne ck s, fo cus o n the big picture o f whe re to ta k e the pro je cts,

a nd do co a rse -gra ine d pla nning fo r the ne x t qua rte r

Slack is built in to the sche dule a s ta sk s tha t ca n be dro ppe d o r by a ssigning ce rta in tim e slo ts a s sla ck tim e

Ten-minute build fo rce s yo u to trim yo ur a uto m a te d build a nd a uto m a te d te sts so tha t the y ta k e no m o re tha n 10 m inute s.

Continuous integration a im s a t re ducing the o ve ra ll co st o f inte gra tio n by fo rcing it to ha ppe n a t le a st o nce e ve ry co uple o f ho urs.

Test-first programming te lls yo u to write a uto m a te d te sts be fo re writing the co de to be te ste d.

Incremental design guide s yo u in do ing a little bit o f de sign e ve ry da y, but de signing o nly fo r wha t yo u ne e d to da y ra the r tha n fo r future po ssibilitie s.

XP a lso a rticula te s a se t o f fo urte e n principle s tha t functio n a s the bridge be twe e n va lue s a nd pra ctice s, guiding yo u in ho w to a pply the pra ctice s e ffe ctive ly in o rde r

to a dhe re to the va lue s T he principle s a re hum a nity, e co no m ics, m utua l be ne fit, se lf-sim ila rity, im pro ve m e nt, dive rsity, re fle ctio n, flo w, o ppo rtunity, re dunda ncy,

fa ilure , qua lity, ba by ste ps, a nd a cce pte d re spo nsibility

Scrum[23] wa s intro duce d in 1996 by Ke n Schwa be r a nd Je ff Suthe rla nd.[24] T he te rm scrum is de rive d fro m rugby, in which it re fe rs to re sta rting pla y a fte r the

ga m e is stuck in a so -ca lle d m a ul Scrum fo cuse s o n the m a na ge m e nt o f a pro je ct witho ut de scribing the spe cifics o f ho w to unde rta k e de sign, im ple m e nta tio n, o r

te sting C o nse que ntly, it ca n be co m bine d with a num be r o f diffe re nt pro ce sse s, such a s XP o r R UP

[23] Schwaber 2002

[24] Scrum was f ormalized and presented at OOPSLA'96

Scrum focuses on the management of a project.

Ea ch ite ra tio n is 30 da ys lo ng a nd is re fe rre d to a s a sprint T he sprint sta rts with a ha lf-da y pla nning m e e ting to de te rm ine wha t sho uld be do ne within the sprint

During the pla nning m e e ting, the P ro duct O wne r pro vide s a prio ritize d Product Backlog, which is a n e vo lving list co nta ining a ll re quire m e nts, de fe cts, ta sk s, a nd cha nge re que sts T he de ve lo pm e nt te a m will the n de te rm ine ho w m a ny o f the high-prio rity ite m s the y ca n ta k e o n within tha t sprint, which co nstitute s the Sprint

Backlog, a nd a sprint go a l is cra fte d T he sprint go a l pro vide s the te a m with a cle a r fo cus by e sta blishing a n o bje ctive tha t will be m e t by im ple m e nting the

ba ck lo g

Afte r the pla nning m e e ting, the te a m spe nds 29 da ys de ve lo ping a n e x e cuta ble tha t de live rs incre m e nta l functio na lity T he sprint e nds with a ha lf-da y Sprint

R e vie w Me e ting, a t which the te a m a nd m a na ge m e nt inspe ct the pro duct incre m e nt to ge the r a nd ca pture le sso ns le a rne d T he te a m will the n sta rt the ne x t sprint,

de live ring a n e x e cuta ble e ve ry 30 da ys tha t is o ne ste p clo se r to the fina l pro duct

During a sprint the te a m will ge t to ge the r fo r a da ily 15-m inute m e e ting, a lso ca lle d scrum During the scrum , e a ch te a m m e m be r will brie fly a nswe r thre e (a nd only

thre e ) que stio ns:

1 W ha t ha ve yo u do ne since la st m e e ting?

2 W ha t will yo u do be twe e n no w a nd ne x t m e e ting?

3 W ha t o bsta cle s sto o d in the wa y o f do ing wo rk ?

T he "scrum m a ste r" m a k e s sure tha t the m e e ting is k e pt o n tra ck , m a k e s de cisio ns a s a ppro pria te , a nd is a lso re spo nsible fo r e nsuring tha t ide ntifie d o bsta cle s

a re a ddre sse d a s so o n a s po ssible As issue s a rise tha t ne e d furthe r discussio n, the scrum m a ste r se ts up a dditio na l m e e tings with invo lve d pa rtie s to co ntinue thediscussio n, to e nsure tha t the da ily scrum is k e pt to 15 m inute s T he scrum m a ste r a lso m a k e s sure tha t no o utside cha nge s a re im po se d o n the pla n during asprint, so tha t the te a m ca n fo cus o n e x e cuting the pla n witho ut a ny distra cting inte rruptio ns

T he te a m in scrum sho uld ha ve se ve n (give o r ta k e two ) m e m be rs If yo ur te a m ha s m o re , split the te a m into se ve ra l te a m s a nd divide the ir wo rk so tha t the y ca n

o pe ra te se m i-inde pe nde ntly Scrum te a m s sho uld be cro ss-functio na l so tha t e a ch te a m ca n do the ne ce ssa ry a na lysis, de sign, im ple m e nta tio n, te sting, a nd

do cum e nta tio n

Scrum te a m s a re se lf-o rga nize d, m e a ning tha t the te a m is le ft lo o se during the sprint to use wha te ve r a ppro a ch is co nside re d a ppro pria te to co nve rt the Sprint

Ba ck lo g to a pro duct incre m e nt Ma na ge m e nt sho uld no t inte rve ne At the e nd o f the sprint, m a na ge m e nt ca n a sse ss wha t wa s do ne a nd m a k e cha nge s a s

ne ce ssa ry

Scrum fo cuse s o n co lla bo ra tio n O pe n wo rk spa ce s a re pre fe rre d, a nd e a ch te a m m e m be r sho uld a tte nd the da ily scrum m e e ting in pe rso n No title s o r jo b

de scriptio ns a re use d, a nd pe o ple a re a sk e d to le a ve the ir e go s a t ho m e

Scrum focuses on collaboration Each team member attends the daily scrum meeting.

T his cha pte r intro duce s k e y principle s a nd pra ctice s tha t suppo rt the m It a lso pre se nts the fra m e wo rk fo r this bo o k , a s o utline d be lo w:

Comparison with other methods Fo r e a ch pra ctice , we de scribe ho w the pra ctice is sim ila r to , o r diffe re nt fro m , o the r m e tho ds.

Levels of adoption Ea ch pra ctice ca n be a do pte d a t thre e le ve ls: ba sic, inte rm e dia te , a nd a dva nce d T he a dva nce d le ve l typica lly re quire s a co m bina tio n o f

m o re a dva nce d sk ills, m o re a dva nce d to o ling, o r a highe r-ce re m o ny pro ce ss

Process map Fo r e a ch le ve l o f a do ptio n o f a pra ctice , we indica te whe the r the pra ctice e na ble s a gility o r discipline a nd whe the r it e na ble s sho rte r ite ra tio ns.

Information in the Unified Process Fo r e a ch pra ctice , we de scribe ho w O pe nUP /Ba sic a nd R UP suppo rt the se pra ctice s.

T o e na ble yo u to m a k e be tte r use o f this fra m e wo rk , this cha pte r pro vide s a sum m a ry o f the Unifie d P ro ce ss life cycle , O pe nUP /Ba sic, a nd R UP a nd e x pla ins ho wthe y fit to ge the r in the fa m ily o f Unifie d P ro ce ss m e tho ds built o n EP F a nd R MC T his cha pte r a lso sum m a rize s Scrum a nd XP , be ca use we ha ve cho se n to fo cus o nthe se m e tho ds a s pa rt o f the "co m pa riso n with o the r m e tho ds" se ctio n in e a ch pra ctice

W ith this ba ck gro und, we ho pe yo u ca n no w pick a nd cho o se a pra ctice cha pte r o f inte re st a nd ga in va lua ble insight into ho w to im pro ve yo ur pro ce ss W e

re co m m e nd tha t yo u sta rt with the ba sic le ve l o f a do ptio n a nd incre m e nta lly a do pt so m e inte rm e dia te a nd a dva nce d pra ctice s ba se d o n whe the r yo u ne e d to be

m o re ite ra tive , a gile , o r discipline d

Chapter 2 Demonstrate Value Iteratively

Benefits Ea rly risk re ductio n.

Highe r pre dicta bility thro ugho ut the pro je ct

T rust a m o ng sta k e ho lde rs

Patterns 1 Ena ble fe e dba ck by de live ring incre m e nta l use r va lue in e a ch

ite ra tio n

2 Ada pt yo ur pla ns using a n ite ra tive pro ce ss.

3 Em bra ce a nd m a na ge cha nge

4 Atta ck m a jo r te chnica l, busine ss, a nd pro gra m m a tic risk s

e a rly

Anti-Patterns P la n the who le life cycle in de ta il, tra ck va ria nce s a ga inst pla n

(ca n a ctua lly co ntribute to pro je ct fa ilure )

Asse ss sta tus in the first two thirds o f the pro je ct by re lying o n

re vie ws o f spe cifica tio ns a nd inte rm e dia te wo rk pro ducts,

ra the r tha n a sse ssing sta tus o f te st re sults a nd

de m o nstra tio ns o f wo rk ing so ftwa re

T he principle o f de m o nstra ting va lue ite ra tive ly e x pla ins why so ftwa re de ve lo pm e nt gre a tly be ne fits fro m be ing ite ra tive [1] An ite ra tive pro ce ss m a k e s it po ssible

to a cco m m o da te cha nge e a sily, to o bta in fe e dba ck a nd fa cto r it into the pro je ct, to re duce risk e a rly, a nd to a djust the pro ce ss dyna m ica lly

[1] Material appearing in the introductions of Chapters 27 adapted f rom Kroll 2005 Used with permission

Se ve ra l im pe ra tive s unde rlie this principle T he first is tha t we m ust demonstrate incremental value to enable early and continuous feedback W e a chie ve this go a l by

dividing o ur pro je ct into a se t o f ite ra tio ns In e a ch ite ra tio n we pe rfo rm so m e re quire m e nts, de sign, im ple m e nta tio n, a nd te sting o f o ur a pplica tio n, thus pro ducing

a de live ra ble tha t is o ne ste p clo se r to the fina l so lutio n T his pro ce ss a llo ws us to de m o nstra te the a pplica tio n to e nd use rs a nd o the r sta k e ho lde rs, o r ha ve the muse the a pplica tio n dire ctly, e na bling the m to pro vide e a rly fe e dba ck o n ho w we a re do ing Are we m o ving in the right dire ctio n? Are sta k e ho lde rs sa tisfie d with wha t

we ha ve do ne to da te ? Do we ne e d to cha nge the fe a ture s im ple m e nte d so fa r? And fina lly, wha t a dditio na l fe a ture s ne e d to be im ple m e nte d to a dd busine ss

va lue ? If we ca n a nswe r the se que stio ns sa tisfa cto rily, we a re m o re lik e ly to build trust a m o ng sta k e ho lde rs tha t the syste m we a re de ve lo ping will a ddre ss the ir

ne e ds W e a re a lso le ss lik e ly to o ve re ngine e r o ur a ppro a ch o r to a dd ca pa bilitie s tha t a re no t use ful to the e nd use r.[2]

[2] According to the Standish Group's Chaos Report (2003), 45 percent of f eatures implemented on the average project are never used

T he se co nd im pe ra tive is to le ve ra ge de m o nstra tio ns a nd fe e dba ck to adapt our plans R a the r tha n re lying o n a sse ssing spe cifica tio ns, such a s re quire m e nts

spe cifica tio ns, de sign m o de ls, o r pla ns, we ne e d inste a d to a sse ss ho w we ll the co de de ve lo pe d thus fa r a ctua lly wo rk s W e m ust the re fo re use te st re sults a nd

de m o nstra tio ns o f wo rk ing co de to sta k e ho lde rs to de te rm ine ho w we ll we a re do ing Fo llo wing this pro ce dure pro vide s a go o d unde rsta nding o f whe re we a re , ho w

fa st the te a m is pro gre ssing, a nd whe the r we ne e d to m a k e co urse co rre ctio ns to co m ple te the pro je ct succe ssfully W e ca n the n use this info rm a tio n to upda te the

o ve ra ll pla n fo r the pro je ct a nd de ve lo p de ta ile d pla ns fo r just the ne x t ite ra tio n, ra the r tha n fo r the e ntire pro je ct

T he third unde rlying im pe ra tive is to embrace and manage change T o da y's a pplica tio ns a re to o co m ple x fo r the re quire m e nts, de sign, im ple m e nta tio n, a nd te sting to

a lign pe rfe ctly the first tim e thro ugh Inste a d, the m o st e ffe ctive a pplica tio n de ve lo pm e nt m e tho ds e m bra ce the ine vita bility o f cha nge T hro ugh e a rly a nd

co ntinuo us fe e dba ck , we le a rn ho w to im pro ve the a pplica tio n, a nd the ite ra tive a ppro a ch pro vide s us with the o ppo rtunity to im ple m e nt tho se cha nge s

incre m e nta lly By ha ving the pro ce sse s a nd to o ls in pla ce , we ca n e ffe ctive ly m a na ge a ll this cha nge witho ut co nfining de sire d cre a tivity

T he fo urth im pe ra tive unde rlying this principle is the ne e d to drive out key risks early in the life cycle , a s illustra te d in the dia gra m in Figure 2.1 W e m ust a ddre ss

the m a jo r te chnica l, busine ss, a nd pro gra m m a tic risk s a s e a rly a s po ssible , ra the r tha n po stpo ning risk re so lutio n to wa rd the e nd o f the pro je ct T his sta ge is

a cco m plishe d by co ntinuo usly a sse ssing wha t risk s we a re fa cing a nd a ddre ssing the to p re m a ining risk s in the ne x t ite ra tio n In succe ssful pro je cts, k e y busine ssrisk s a re m itiga te d in e a rly ite ra tio ns by invo lving sta k e ho lde rs to e nsure buy-in to a visio n a nd high-le ve l re quire m e nts, a nd k e y te chnica l risk s a re m itiga te dthro ugh de sign, im ple m e nta tio n, a nd te sting o f k e y a spe cts o f the a rchite cture It is a lso im po rta nt to re ta in info rm a tio n re quire d to fo rce de cisio ns a bo ut wha t

m a jo r re usa ble a sse ts o r co m m e rcia l-o ff-the -she lf (C O T S) so ftwa re to use

Figure 2.1 Risk Reduction Profiles for Waterfall and Iterative Developments.

A maj or goal with iterative development is to reduce risk early on by analyzing, prioritizing, and attacking top risks in each iteration.

(Adapted from Royce 1998.)

T he a nti-pa tte rn to fo llo wing this principle wo uld be to pla n the who le life cycle in de ta il up fro nt a nd the n tra ck va ria nce s a ga inst pla n Ano the r a nti-pa tte rn wo uld be

to a sse ss sta tus in the first two thirds o f the pro je ct by prim a rily re lying o n re vie ws o f spe cifica tio ns, ra the r tha n a sse ssing sta tus o f te st re sults a nd de m o nstra tio ns

o f wo rk ing so ftwa re

T his cha pte r will wa lk yo u thro ugh a num be r o f be st pra ctice s tha t will a ssist yo u in de m o nstra ting va lue ite ra tive ly

Practice 1: Manage Risk e x pla ins ho w to ide ntify a nd prio ritize k e y risk s T he se risk s a re use d to de te rm ine the fo cus o f the ne x t ite ra tio n.

Practice 2: Execute Your Project in Iterations de scribe s ho w to pla n ite ra tive de ve lo pm e nt a nd ho w to divide yo ur pro je ct into a se rie s o f ite ra tio ns in which e a rly

ite ra tio ns a ddre ss high risk s

Practice 3: Embrace and Manage Change sugge sts wha t cha nge s to e nco ura ge a nd disco ura ge a t e a ch sta ge o f a pro je ct, a s we ll a s te chnique s to m a x im ize

Practice 1 Manage Risk

Per Kroll

Identifying and addressing top risks in each iteration increases predictability and lowers overall cost.

Problem

A risk is a va ria ble with a n unk no wn o r unce rta in va lue tha t co uld e nda nge r o r je o pa rdize a pro je ct's succe ss.[3] T he k e y ide a in risk m a na ge m e nt is no t to wa it

pa ssive ly until a risk m a te ria lize s a nd be co m e s a pro ble m o r k ills the pro je ct, but ra the r to se e k o ut a nd de a l with risk s

[3] 3 See Concept: Risk in the Rational Unif ied Process product

Igno ring o r pro cra stina ting in this a re a m a y le a d yo u to inve st in the wro ng te chno lo gie s, a ba d de sign, a nd/o r a se t o f re quire m e nts tha t m a y no t m e e t

sta k e ho lde r ne e ds Una ddre sse d risk s m a y m e a n tha t yo u run yo ur pro je ct with sta ff tha t do no t ha ve the sk ills re quire d to do the jo b, o r tha t yo u build a n

a pplica tio n diffe re nt fro m the o ne tha t sta k e ho lde rs e x pe ct T his is ba d so ftwa re e co no m ics Fa ilure to a ddre ss risk e a rly in the pro je ct m e a ns spe nding m o re o n

re wo rk do wn the ro a d, a s m a ny risk s be co m e m a jo r issue s

Background

I gre w up in a ve ry sm a ll to wn, a nd o nce a ye a r a fa ir ca m e to to wn fo r the we e k e nd My fa vo rite ga m e ha d a bunch o f gre e n fro gs tha t k e pt po pping up, the o bje ct

o f which wa s to k no ck do wn the fro gs with the ha m m e r pro vide d a s ra pidly a s po ssible Ma na ging risk e ffe ctive ly is ve ry m uch lik e tha t ga m e Ne w risk s a lwa ys k e e p

po pping up As a te a m , yo u ne e d to drive the m do wn a s fa st a s yo u ca n, fo cusing o n the m a jo r risk s first

As a team, you need to drive down risk as fast as you can.

Just a s tho se gre e n fro gs k e pt co m ing, yo u will ne ve r be finishe d de a ling with risk Be ca use risk s a re vo la tile , yo u ne e d to m o nito r a nd re a sse ss yo ur situa tio n

co nsta ntly Are the re a ny ne w risk s tha t yo u ne e d to a ddre ss? W hich risk s a re m o re se rio us tha n o the rs? Just a s yo u ge t m o re po ints fo r k no ck ing do wn so m e fro gstha n o the rs, in re a l life so m e risk s a re m o re se rio us tha n o the rs W e wa nt to rig the ga m e o f so ftwa re de ve lo pm e nt to e na ble us to k no ck do wn the bigge st fro gs

e a rly, so tha t we m a x im ize o ur po ints e ve n if we run o ut o f tim e

Ma ny risk s be co m e a pro ble m due to la ck o f co m m unica tio n: pe o ple do no t spe a k up o r, wo rse , re m a in sile nt be ca use the y fe a r re ta lia tio n o r be ing igno re d by

m a na ge rs o r pe e rs I re m e m be r m y first m a jo r ite ra tive de ve lo pm e nt pro je ct W e we re building a huge sche duling syste m tha t co ntro lle d bro a dca sting distribute d

a cro ss a se rie s o f sa te llite s O ur pro je ct wa s divide d into two subpro je cts; m ine wa s re spo nsible fo r building a syste m tha t sche dule d a ll the bro a dca sting, while the

o the r wa s building a re a l-tim e syste m fo r fe e ding the sche duling info rm a tio n fro m o ur syste m to a se rie s o f sa te llite s T he pro ble m wa s tha t a Sunda y fo o tba llbro a dca st, fo r e x a m ple , m ight re quire la st-m inute cha nge s to the sche dule if the ga m e wa s running la te W e ha d to de cide whe the r to do la te cha nge s in theupstre a m sche duling syste m a nd ha ve the info rm a tio n tra nsfe rre d to the do wnstre a m re a l-tim e syste m thro ugh a ve ry fa st inte rfa ce , o r pro vide the functio na lity fo r

m a k ing sche duling cha nge s dire ctly in the re a l-tim e syste m Unfo rtuna te ly, we didn't re so lve the se issue s until la te in the pro je ct, be ca use e ve n tho ugh se ve ra l o f

us we re a wa re o f the risk e a rly o n, we ne ve r e sca la te d the risk to e nsure tha t it re ce ive d the right le ve l o f a tte ntio n O nce we e ve ntua lly de cide d ho w to pro ce e d, we

ha d to re wo rk pa rts o f the a rchite cture , which to o k us se ve ra l m o nths

So m e risk s, such a s sta ff turno ve r a nd sche dule slip, a re a re a lity in m o st pro je cts a nd sho uld be ta k e n into a cco unt in a dva nce , fo r e x a m ple by putting in buffe rs

in the sche dule O the r issue s a re o utside the co ntro l o f the pro je ct If yo u ha ve no wa y o f influe ncing so m e thing o r its co nse que nce s, it is no t a risk , but ra the r a

co nstra int tha t yo u ha ve to live with

No w tha t we ha ve discusse d the na ture o f risk s, the ne e d to a tta ck the m e a rly o n, a nd the im po rta nce o f co ntinuo usly re a sse ssing wha t risk s yo u a re fa cing, le t's

lo o k a t so m e co ncre te guide line s fo r m a na ging risk

Applying the Practice

Ma na ging risk re quire s a m ultifa ce te d a ppro a ch invo lving the e ntire te a m

Ide ntify the risk s yo u a re fa cing

Do cum e nt se rio us risk s

O pe nly discuss the m inside a nd o utside yo ur te a m

De ve lo p pla ns fo r ho w to a ddre ss the m o st se rio us risk s, tha t is, tho se tha t a re de e m e d the m o st ha rm ful to the pro je ct

Fo cus yo ur e x te nde d te a m o n a ddre ssing risk s

Le t's e x plo re e a ch o f the se a ctivitie s a nd discuss so m e o f the be ne fits o f e ffe ctive risk m a na ge m e nt

Identify Risks

At the be ginning o f e a ch ite ra tio n, a ll te a m m e m be rs sho uld jo intly co nside r wha t risk s the y a re fa cing a nd m a k e a list o f to p risk s (o r re vise a n e x isting list) But

ho w do yo u find risk s? It is go o d to lo o k fo r risk s by type Y o u m a y, fo r e x a m ple , lo o k fo r risk s re la te d to re so urce s, busine ss, te chnica l issue s, a nd sche duling

Y o u ca n the n wa lk thro ugh a sta nda rd se t o f risk s tha t o fte n o ccur in e a ch o f the se ca te go rie s

Make a list of top risks at the beginning of each iteration.

Finding risk s sho uld be e ve rybo dy's re spo nsibility, a nd e a ch te a m m e m be r sho uld m a k e co ntributio ns to the risk list to e nsure tha t a ll se rio us risk s ha ve be e n

fo und It is, ho we ve r, im po rta nt to invo lve pe o ple with the right e x pe rie nce fro m the do m a in whe re the risk o rigina te s O the rwise , yo u will ha ve pro ble m s bo thfinding a nd a ddre ssing the risk Fo llo wing is a pa rtia l list o f risk s fo und in R UP

Document Serious Risks

R isk s ca n be do cum e nte d in m a ny wa ys: o n white bo a rds, o n a W ik i,[4] in a spre a dshe e t, o r in a risk m a na ge m e nt to o l Fo r e a ch risk spe cify:

[4] 4 A Wiki is a Web site that can be edited by the viewers through their Web browser; see www.wiki.org

A name o r la be l fo r the risk

A brief description o f the risk

T he impact o f the risk , tha t is ho w se rio usly its o ccurre nce will a ffe ct yo ur pro je ct o utco m e

T he probability o f the risk o ccurring.

T he magnitude o f the risk , tha t is, its im pa ct tim e s pro ba bility T his fie ld is typica lly use d to so rt the risk list, e nsuring tha t risk s o f the gre a te st m a gnitude

a re a ddre sse d first

T he owner o f the risk , tha t is, the pe rso n re spo nsible fo r e nsuring tha t the risk is m itiga te d (m itiga ting a risk is typica lly a te a m e ffo rt, but so m e bo dy ne e ds

to m a na ge tha t e ffo rt)

T he management strategy o r plan fo r a ddre ssing the risk T his co uld include ste ps to mitigate, avoid, o r transfer the risk W e will discuss tho se thre e risk

stra te gie s m o re be lo w

Ba se d o n yo ur ne e ds, yo u m a y cho o se a subse t o f the a bo ve a ttribute s, o r a num be r o f a dditio na l a ttribute s, such a s whe the r it is a te chnica l, no nte chnica l,

a rchite ctura lly significa nt, o r le ga l risk

Prioritize the risk list and address the top three to five risks.

Y o u sho uld prio ritize the risk list a cco rding to m a gnitude a nd the n de te rm ine wha t yo u ne e d to do to a ddre ss, typica lly, the to p thre e to five risk s T a ble 2.1pro vide s a n e x a m ple o f ho w to co m pile a risk list As yo u prio ritize the list ba se d o n m a gnitude , it is im po rta nt to unde rsta nd tha t yo ur e nd go a l is to ide ntify whichrisk s the te a m ne e ds to fo cus o n first R e sist the urge to a rgue a bo ut whe the r the pro ba bility is 65 pe rce nt o r 70 pe rce nt, o r whe the r the im pa ct sho uld be a 2 o r a

3 Just cho o se a va lue tha t is in the right ba llpa rk (fo r m o st pro je cts, this is no t a ve ry e x a ct scie nce ); if the risk is a m o ng the to p 15, a sse ss whe the r yo u co nside r

it prio ritize d a ppro pria te ly, a nd if no t, a djust the pro ba bility a nd/o r im pa ct to m a k e sure tha t yo ur to p 5 o r 10 risk s re pre se nt the o ne s yo u sho uld fo cus o n

Table 2.1 Sample Risk List.

Key risks are listed with name, description, impact, probability, magnitude, and owner Impact represents the seriousness of the risk occurrence on the proj ect outcome; probability represents the likelihood of the risk occurrence; magnitude is the impact times probability More columns, such as category and status, may be

added if useful.

[View full size image]

(Adapted from Kroll 2003.)

T a ble 2.1 sho ws sugge ste d co lum n he a dings, but yo u ca n use whiche ve r he a dings a re use ful fo r yo ur pro je ct, o r a dd m o re co lum ns a s a ppro pria te Additio na l

co lum ns tha t co uld be use ful include risk ca te go ry a nd sta tus It is ge ne ra lly wo rth sta rting with le ss info rm a tio n to m inim ize o ve rhe a d, a nd a dding m o re a s

ne ce ssa ry La te r in this pra ctice we 'll a dd a m a na ge m e nt pla n fo r e a ch o f the se risk s

Openly Discuss Risks

Addressing risks should be a priority for everyone.

Addre ssing risk s sho uld be a prio rity fo r e ve ryo ne thro ugho ut the pro je ct, but fo r tha t to ha ppe n, e ve ryo ne first ne e ds to be a wa re o f the risk s to be fa ce d Ma nypro je ct m a na ge rs a vo id e x po sing the e x te nde d pro je ct te a m to the risk list o r a re in de nia l a bo ut the e x iste nce o f the risk T he y a re a fra id tha t re ve a ling it will lo o k

ba d to sta k e ho lde rs a nd te a m m e m be rs a nd will indica te tha t the y a re m a na ging the pro je ct po o rly And unfo rtuna te ly, m a ny co m pa ny e x e cutive s do m o re re a dilycriticize tha n pra ise pro je ct m a na ge rs who a re o pe n a bo ut risk s

T his is whe re the XP va lue "co ura ge " be co m e s crucia l.[5] It sho uld be e a ch te a m m e m be r's re spo nsibility to be bo th bra ve e no ugh to spe a k up a nd re spo nsible

e no ugh no t to criticize o the rs who do so , e ve n tho ugh the risk m a y po int to a fla w in the ir a re a o f re spo nsibility T o be succe ssful with ite ra tive de ve lo pm e nt (o r a nypro je ct), yo u ne e d to fo ste r a culture in which yo u ca n o pe nly discuss risk s a nd ho w to a ddre ss the m Eve ry pro je ct fa ce s risk s, a nd living in de nia l by a vo iding the

to pic o f risk m a k e s yo ur pro je ct m o re lik e ly to fa il

[5] See Beck 2004

An e x a m ple o f a ve ry e ffe ctive m e cha nism fo r incre a sing risk visibility to e nsure tha t risk s a re pro pe rly discusse d is to put up a huge sign in a co m m o n pla ce such

a s the lunchro o m o r te a m ro o m , a so -ca lle d info rm a tio n ra dia to r,[6] listing the to p te n risk s o n the pro je ct a nd who is re spo nsible fo r a ddre ssing e a ch o ne As a

re sult, e ve rybo dy k no ws wha t risk s the pro je ct is fa cing a nd fe e ls e nco ura ge d to discuss the be st wa y to de a l with the m

[6] 6 See Cockburn 2002

Develop a Plan for Addressing the Most Serious Risks

T ypica lly, risk s ne e d to be a ddre sse d fro m m ultiple pe rspe ctive sfo r e x a m ple , busine ss pe rspe ctive s such a s sco pe , funding, a nd re so urce s a s we ll a s te chnica l

pe rspe ctive s such a s re quire m e nts, de sign, a nd te sting Fo r e a ch o f the se pe rspe ctive s, sta rt with a co a rse so lutio n a nd succe ssive ly re fine it to dim inish the risk

T a ble 2.2 sho ws e x a m ple s o f a ctio ns in the risk m a na ge m e nt pla n tha t yo u ca n ta k e to de a l with the risk s ide ntifie d in T a ble 2.1

Table 2.2 Example of Risk Management Plans.

Each risk should have an associated action in the risk management plan that articulates how to

manage the risk There are three basic management strategies to choose from: risk

mitigation, risk avoidance, and risk transfer.

m a y no t unde rsta nd o r a gre e to

the re quire m e nts the ir o wn

re pre se nta tive s ha ve spe cifie d,

a nd a s a re sult will re que st m a jo r

cha nge s after be ta so ftwa re is

im ple m e nta tio ns Se t up a

m e e ting with k e y sta k e ho lde rs in

De pa rtm e nt X a nd wa lk the mthro ugh use ca se s a s the y a re

co m ple te d, using the UIpro to type a nd pa rtia l

im ple m e nta tio ns a s a sto rybo a rd

Ma k e sure tha t yo u ge t

m e a ningful fe e dba ck fro m k e ysta k e ho lde rs T hro ugho ut thepro je ct, k e e p De pa rtm e nt X in the

lo o p o n pro gre ss a nd pro videthe m with e a rly pro to type s a nd/o r

a lpha re le a se s

Integration

with system Y

W e do no t unde rsta nd ho w we ca n

inte gra te with le ga cy syste m Y

A lternative A Strategy: Risk Mitigation

Ha ve a "tige r te a m " o f o ne o r two

sk ille d de ve lo pe rs build a n a ctua lpro to type tha t va lida te s ho w tointe gra te with le ga cy syste m Y

T he inte gra tio n m a y be athro wa wa y, but the pro to type

De sign, im ple m e nt, a nd te st

a ppro pria te use -ca se sce na rio sthro ugho ut the pro je ct to va lida tethe inte gra tio n with le ga cy syste m

Y

A lternative BStrategy: Risk

A voidance (Mo dify pro je ct to

pre ve nt risk o ccurre nce )

C ut the sco pe o f the pro je ct sotha t yo u do no t ha ve to inte gra tewith le ga cy syste m Y

tha t so m e o the r o rga niza tio n

o wns the risk )

O utso urce de ve lo pm e nt o ftra ining m a te ria l to e x te rna l

o rga niza tio n (No te tha t this

a ctio n m a y intro duce a no the r se t

o f risk s.)

Lack of NET

experience

W e risk de ve lo ping a te chnica lly

infe rio r so lutio n due to la ck o f

e x pe rie nce with the Micro so ft NET

pla tfo rm

Strategy: Risk Mitigation

Se nd a co uple o f pe o ple fo rtra ining o n Micro so ft NET , a ndfind the budge t to bring in a NET

m e nto r two da ys pe r we e k fo r thefirst thre e we e k s o f the pro je ct

R e cruit a te a m m e m be r with a nunde rsta nding o f the NETpla tfo rm

(Adapted from Kroll 2003.)

As with a ll so ftwa re de ve lo pm e nt a ctivitie s, it is im po rta nt to fo cus m o re o n e x e cutio n tha n pla nning P la n e no ugh a bo ut ho w to a ddre ss the m o st se rio us risk s sotha t yo u ca n e ffe ctive ly m itiga te the to p risk s If yo u a re a ble to fo cus o n o nly thre e to five risk s a t a tim e , the re is no po int in do ing de ta ile d pla nning o f the to p

15 risk s

Focus the Extended Team on Risk Management

No w tha t yo u a re a wa re o f the risk s yo u fa ce a nd ha ve a pla n fo r a ddre ssing e a ch risk , ho w ca n yo u fo cus yo ur e x te nde d te a m , including pro je ct spo nso rs a nd

e x te rna l e x pe rts, o n using this info rm a tio n to bring a bo ut cha nge s in be ha vio r? He re a re so m e co nside ra tio ns:

Alwa ys k e e p in m ind wha t T o m Gilb[7] sa id: "If yo u do n't a ctive ly a tta ck the risk s, the y will a ctive ly a tta ck yo u."

[7] 7 Gilb 1988

As yo u pla n a n ite ra tio n, lo o k a t wha t yo u wo uld "no rm a lly" do fo r the ite ra tio n a t ha nd a nd the n slightly m o dify the pla n to m a k e sure tha t yo u de a l with

yo ur risk s Sche dule a ctivitie s tha t will m itiga te risk T his pro vide s the right fo cus o n risk m itiga tio n, a s we ll a s a llo wing yo u to unde rsta nd ho w m uch tim e isspe nt o n it

In yo ur da ily sta tus m e e tings (scrum s) o r we e k ly sta ff m e e tings, use the risk list to he lp de te rm ine wha t a ctio ns to ta k e a nd wha t co de to de ve lo p a nd te st

ne x t Be ca use the risk list re pre se nts issue s tha t m a y m a k e o r bre a k the pro je ct, it de se rve s a lo t o f a tte ntio n in yo ur sta ff m e e tings Ma k e sure to includeupda te s o n k e y risk s a s yo u re po rt risk sta tus

Ma k e sure tha t e a ch te a m m e m be r ha s a cce ss to a curre nt ve rsio n o f the risk list As ne ce ssa ry, use la rge , visible cha rts to e nsure tha t a ll te a m m e m be rs

a re a wa re o f a nd re a ct to the m o st se rio us risk s Invo lve e x te nde d te a m m e m be rs who m a y be a ble to he lp the te a m m itiga te risk sbusine ss spo nso rs,highe r-le ve l m a na ge m e nt, e x te rna l e x pe rts, a nd m e m be rs fro m o the r te a m s yo u a re co lla bo ra ting with, such a s de ve lo pm e nt te a m s fo r syste m s tha t yo u

a re inte gra ting with

O ne thing to k e e p in m ind is tha t the risk list co ntinua lly cha nge s Atta ck ing risk is a co nsta nt ba ttle ; in e a ch ite ra tio n yo u will be a ble to re duce o r re m o ve so m erisk s, a s o the rs gro w a nd ne w o ne s a ppe a r

Attacking risk is a constant battle.

Make Your Ability to Manage Risk a Key Differentiator

O ne o f the k e y po ints De Ma rco (2003) m a k e s is tha t if yo u ca n e ffe ctive ly m a na ge a nd m itiga te risk , yo u ca n ta k e o n highe r-risk pro je cts, tha t is, yo u ca n a ssum ethe risk o f be ing m o re inno va tive , le ve ra ge ne we r te chno lo gie s, unde rta k e m o re co m ple x pro je cts, ta k e o n m o re cha lle nging busine ss e nviro nm e nts, a nd so o n.Effe ctive risk m a na ge m e nt thus no t o nly a llo ws yo u to e x e cute yo ur pro je cts m o re e ffe ctive ly but a lso e na ble s yo u to go do wn ro a ds tha t o the rs a re una ble o runwilling to ta k e

If you can effectively manage and mitigate risk, you can take on higher-risk projects.

Other Methods

W a te rfa ll pro ce sse s diffe r fro m ite ra tive pro ce sse s in tha t the y de fe r inte gra tio n a nd te sting a ctivitie s to the la tte r ha lf o f the pro je ct, which re sults in fe we r risk s

be ing ide ntifie d e a rly o n, a s we ll a s m a k ing it m o re difficult fo r the te a m to ve rify tha t a n ide ntifie d risk ha s be e n sufficie ntly a ddre sse d

All agile and iterative processes focus on the need to manage risk.

All a gile a nd ite ra tive pro ce sse s fo cus o n the ne e d to m a na ge risk , but with so m e va ria tio ns As a n e x a m ple , in Planning Extreme Programming Ke nt Be ck a nd Ma rtin

Ma k e risk s wide ly visible to the te a m , fo r e x a m ple by de dica ting white bo a rd spa ce fo r a risk list.

Use sho rt o ne - to two -we e k ite ra tio ns with co ntinuo us inte gra tio n a nd te sting to pro vide quick fe e dba ck lo o ps

Ma k e custo m e rs a pa rt o f the pro je ct te a m to e nsure tha t bo th busine ss a nd te chnica l pe o ple e vo lve a nd va lida te the a pplica tio n to ge the r

O ne diffe re nce be twe e n the Unifie d P ro ce ss a nd XP is tha t the Unifie d P ro ce ss life cycle puts gre a te r e m pha sis o n prio ritiza tio n ba se d o n risk , e spe cia lly te chnica lrisk , whe re a s XP e m pha size s le ss e a rly inve stm e nt in m itiga ting te chnica l risk in fa vo r o f custo m e r prio ritiza tio n o f wha t pro ble m s to a ddre ss Ea ch o f the fo urpha se s in the Unifie d P ro ce ssInce ptio n, Ela bo ra tio n, C o nstructio n, a nd T ra nsitio nca rrie s a distinct fo cus o n m itiga ting a diffe re nt type o f risk Fo r e x a m ple , risk s

a sso cia te d with unde rsta nding the o ve ra ll pro je ct sco pe , busine ss ca se , a nd ga ining sta k e ho lde r buy-in a re the prim a ry fo cus o f the Ince ptio n pha se

Scrum do e s no t e m pha size risk m a na ge m e nt a s a discipline ; it do e s, ho we ve r, pla ce a stro ng e m pha sis o n re m o ving im pe dim e nts thro ugh the da ily scrum

m e e tings, a t which e a ch te a m m e m be r ide ntifie s issue s sta nding in the wa y o f pro gre ss o n the pro je ct It is the scrum m a ste r's jo b to e lim ina te the se issue s

ra pidly Scrum a lso e m pha size s m itiga tio n o f the spe cific risk o f churn within a n ite ra tio n by stro ngly disco ura ging ne w cha nge re que sts to be a ddre sse d within a nite ra tio n Inste a d, cha nge re que sts a re co nside re d fo r im ple m e nta tio n in the ne x t o r o the r future ite ra tio n

Levels of Adoption

T his pra ctice ca n be a do pte d a t diffe re nt le ve ls:

Basic W o rk o n risk y a re a s e a rlie r ra the r tha n la te r Do n't igno re risk s a s the y sho w up De te rm ine which risk s to fo cus o n in e a ch ite ra tio n.

P rio ritizing yo ur wo rk a cco rding to risk m a k e s it e a sie r to ha ve sho rte r ite ra tio ns by pro viding a structure fo r dividing yo ur wo rk into sm a lle r chunk s tha t ca nfit within a n ite ra tio n As a n e x a m ple , ide ntify the m inim um ste ps yo u ne e d to ta k e to a ddre ss yo ur to p thre e risk s, a nd use tha t a s a sta rting po int fo r wha t

to do within the ne x t ite ra tio n

Intermediate Upda te the risk list fo r e ve ry ite ra tio n, a nd m a k e sure tha t yo u list a t le a st a ha ndful o f risk s Ma k e the risk list cle a rly visible to a ll

te a m m e m be rs W a lk thro ugh a nd upda te the list in te a m m e e tings, a nd m a k e it a prim a ry to o l fo r discussing sta tus a nd wha t a ctio ns to ta k e

At this le ve l, sta rt to intro duce m o re fo rm a lity o r discipline T he e m pha sis o n risk s e na ble s yo u to de te rm ine e ffe ctive ly just wha t yo u ne e d to fo cus o n in the

ne x t ite ra tio n, a nd thus a lso wha t yo u do not ne e d to fo cus o n T his e m pha sis typica lly le a ds to the a bility to ha ve sho rte r ite ra tio ns.

A dvanced Use a risk m a na ge m e nt to o l a nd a risk m a na ge m e nt pla n to a llo w a m o re co m pre he nsive a nd co nsiste nt tre a tm e nt o f risk within yo ur

o rga niza tio n Ma inta in tra ce a bility link s be twe e n risk s a nd re la te d a rtifa cts a nd a ctivitie s tha t will e ithe r he lp m itiga te the risk o r a re a ffe cte d by it As a n

e x a m ple o f tra ce a bility, if yo u ha ve sche dule d five diffe re nt ta sk s a ll re la te d to m itiga ting a risk , yo u sho uld be a ble to find tho se ta sk s a nd the ir sta tus by

ca lling up the risk o n the risk m a na ge m e nt to o l

As yo u intro duce ye t m o re fo rm a lity a nd to o ling, yo u will incre a se the le a rning curve fo r ne w te a m m e m be rs, he nce m o ving yo u to the right o n the pro ce ss

m a p T he o ve rhe a d with the pra ctice is lim ite d, ho we ve r, a nd do e s no t significa ntly a ffe ct the le ngth o f ite ra tio ns T his le ve l is a ppro pria te fo r la rge r pro je cts

a nd pro je cts tha t ne e d m o re ce re m o ny

Related Practices

Practice 2: Execute Your Project in Iterations de scribe s ho w to pla n ite ra tive de ve lo pm e nt a nd divide a pro je ct into a se rie s o f ite ra tio ns R isk drive s the a ctio ns

ta k e n in e a ch ite ra tio n

Practice 3: Embrace and Manage Change de scribe s wha t cha nge s to e nco ura ge a nd disco ura ge a t wha t tim e within a pro je ct Disco ura ging ce rta in type s o f

cha nge s la te in the pro je ct is e sse ntia l to m a na ge risk e ffe ctive ly

Practice 10: Prioritize Requirements for Implementation sho ws ho w to de te rm ine which re quire m e nts to a ddre ss in e a rly ite ra tio ns to drive the a rchite cture a nd to

m itiga te k e y risk s

Additional Information

Information in the Unified Process

T he pro je ct m a na ge m e nt discipline in O pe nUP /Ba sic de scribe s ho w to ide ntify a nd m a na ge risk s a nd ho w to use risk to drive ite ra tio n pla nning It a lso pro vide s

ba sic te m pla te s fo r risk m a na ge m e nt T he pro je ct m a na ge m e nt discipline in R UP e x pa nds o n this co nte nt by a dding m o re e la bo ra te te m pla te s a nd guide line s, a s

we ll a s e x a m ple s o f risk lists Fo rm a l pro je cts m a y a lso le ve ra ge the risk m a na ge m e nt pla n in R UP to e nsure tha t risk is pro pe rly ide ntifie d, a na lyze d,

do cum e nte d, m itiga te d, m o nito re d, a nd co ntro lle d

Additional Reading

T he fo llo wing bo o k pro vide s a go o d unde rsta nding o f ho w risk ca n be use d a s a co m pe titive diffe re ntia to r:

T o m De Ma rco a nd T im o thy Liste r Waltzing with Bears: Managing Risk on Software Projects Do rse t Ho use , 2003.

T he fo llo wing bo o k s pro vide a go o d o ve rvie w o f the discipline o f risk m a na ge m e nt:

Ba rry W Bo e hm "So ftwa re R isk Ma na ge m e nt: P rinciple s a nd P ra ctice s." IEEE Software, Ja nua ry 1991, pp 3241.

Ma rvin C a rr e t a l Taxonomy Based Risk Identification So ftwa re Engine e ring Institute , 1993.

R o be rt C ha re tte Software Engineering Risk Analysis and Management McGra w-Hill, 1989.

C a pe rs Jo ne s Assessment and Control of Software Risks Y o urdo n P re ss, 1994.

Da le Ka ro la k Software Engineering Risk Management IEEE C o m pute r So cie ty P re ss, 1996.

Practice 2 Execute Your Project in Iterations

Per Kroll

Iterative development cycles give rapid and timely feedback so that the software can be continually improved along the development lifecycle.

Problem

T o da y's so ftwa re a pplica tio ns a re to o co m ple x to a llo w yo u to se que ntia lly de fine the re quire m e nts, co m e up with a n a rchite cture a nd de sign, do a n

im ple m e nta tio n, ca rry o ut te sting, a nd ge t it a ll right W he the r yo u use wa te rfa ll o r ite ra tive de ve lo pm e nt a ppro a che s, yo ur initia l re quire m e nts, a rchite cture ,

de sign, a nd co de will be subo ptim a l W ith wa te rfa ll de ve lo pm e nt, yo u typica lly do no t ge t m e a ningful fe e dba ck o n wha t im pro ve m e nts ca n be m a de until it is so

la te in the pro je ct tha t it is to o co stly to m a k e the m By co ntra st, dividing the pro je ct into a se rie s o f tim e -bo x e d ite ra tio ns a llo ws yo u to de live r incre m e nta lly

ca pa bilitie s tha t ca n be a sse sse d by sta k e ho lde rs a t the e nd o f e a ch ite ra tio n T his a ppro a ch pro vide s ra pid a nd tim e ly fe e dba ck lo o ps e na bling issue s to be

a ddre sse d a nd im pro ve m e nts m a de a t a lo we r co st while budge t a nd tim e still a llo w, a nd be fo re the pro je ct ha s go ne so fa r a he a d tha t m a jo r re wo rk is re quire d

Background

Assum e tha t yo u wa nt to write a bo o k Ho w wo uld yo u go a bo ut it? Y o u co uld sta rt by writing pa ge 1 a nd the n co ntinue pa ge by pa ge until yo u ha ve co m ple te d the

e ntire bo o k Y o u co uld the n give it to pe o ple to re a d a nd re vie w

But wha t m ight ha ppe n if yo u fo llo we d such a pro ce ss? Y o ur publishe r m ight sa y tha t the re is no m a rk e t fo r yo ur bo o k , a t le a st no t witho ut a m a jo r re write ; yo ur

re vie we rs m ight po int o ut tha t the bo o k ne e ds m a jo r re structuring to be re a da ble ; a nd yo ur e dito r m ight a sk yo u to write in a diffe re nt style a lto ge the r In the e nd

yo u m ight ne e d to scra p ha lf o f the m a nuscript o r m o re a nd do it a ll o ve r a ga in

T his so unds lik e a cra zy a ppro a ch, right? But m a ny te a m s de ve lo p so ftwa re this wa y Le t's lo o k a t a n a lte rna tive a ppro a ch to writing a bo o k the o ne we use d whe nwriting this o ne T he m a in ide a wa s to ge t ra pid fe e dba ck o n k e y e le m e nts o f the bo o k so tha t we co uld re think a nd im pro ve it W e wa nte d to ge t this fe e dba ck

before we inve ste d the tim e re quire d to write the co m ple te te x t W e the re fo re divide d the writing into a num be r o f succinct ite ra tio ns, e a ch o f which re sulte d in a

we ll-de fine d de live ra ble tha t co uld re a dily be a sse sse d, to e nsure tha t we a ll unde rsto o d the sta tus o f o ur bo o k pro je ct a nd to ge t m e a ningful fe e dba ck o n ho w to

im pro ve the bo o k T he ite ra tio ns include d the fo llo wing:

Iteration 1 Ge t buy-in o n the ide a tha t this bo o k is wo rth writing W rite the pre fa ce , a brie f o utline o f e a ch cha pte r with a n e num e ra tio n o f po te ntia l

pra ctice s, a nd a sa m ple pra ctice Ge t O K fro m publishe r

Iteration 2 Ge t initia l buy-in o n wha t pra ctice s to include a nd ho w to structure a pra ctice W rite a co uple o f pa ra gra phs fo r e a ch po te ntia l pra ctice Ha ve e a ch

a utho r la y o ut o ne o r two pra ctice s in de ta il to e nsure a gre e m e nt o n o ve ra ll style Ma k e a pre lim ina ry se le ctio n o f which pra ctice s to include in the bo o k

Iteration 3 Va lida te tha t we ha ve a sta ble bo o k o utline a nd structure Dra ft ha lf o f the m o st funda m e nta l pra ctice s, e nsuring tha t re vie we rs o bta in a go o d

unde rsta nding o f wha t the e nd re sult m a y lo o k lik e Se nd fo r inte rna l te chnica l re vie w

Iteration 4 Va lida te k e y m e ssa ge s a nd unde rsta nd wha t a dditio na l fine tuning a nd re wo rk a re ne e de d C o m ple te a dra ft o f 75 pe rce nt o f the bo o k

Addre ss co m m e nts fro m first re vie w Se nd fo r e x te rna l te chnica l re vie w

Iteration 5 P ro duce a co m ple te ve rsio n o f the e ntire bo o k Inco rpo ra te e x te rna l re vie we rs' sugge stio ns fo r im pro ve m e nts, a m o ng o the r things a ligning the

bo o k m o re clo se ly with o the r writing in the a gile co m m unity P ro duce a sta ble ve rsio n o f the e ntire bo o k Do initia l e dit o f the bo o k Se nd fo r se co nd

e x te rna l re vie w

Iteration 6 P o lish the bo o k Addre ss re vie w co m m e nts Edit the bo o k Fina lize a rtwo rk , inde x , biblio gra phy, a nd a ny o the r re m a ining wo rk Se nd to

pro ductio n te a m fo r co m ple tio n

Iteration 7 R e vie w fina l e diting o f the bo o k a nd a ddre ss fe e dba ck fro m pro ductio n te a m Se nd o ut fo r pro ductio n a nd publica tio n.

As yo u ca n se e , e a ch ite ra tio n ha s a we ll-de fine d de live ra ble tha t ca n be re a dily a sse sse d Ba se d o n tha t a sse ssm e nt, we m a y scra p so m e o f the wo rk do ne a ndthe n de te rm ine wha t cha nge s we sho uld m a k e to the o ve ra ll pro je ct, including m o difying the tim e line o r sco pe o f the bo o k Y o u ca n a lso se e tha t we first fle sh o ut

a bro a d so lutio n a nd the n k e e p de ta iling a nd re fining it Fina lly, we k e e p spe a rhe a ding the e ffo rt by pick ing critica l, but na rro w, a re a s whe re we pro vide de ta ile d

so lutio ns to drive o ut risk a nd to unde rsta nd wha t the o ve ra ll so lutio n will lo o k lik e

T he a bo ve ite ra tio ns m a p we ll to the Unifie d P ro ce ss life cycle , whe re Ince ptio n is ite ra tio n 1; Ela bo ra tio n is ite ra tio ns 2 a nd 3; C o nstructio n is ite ra tio ns 4 a nd 5;

a nd T ra nsitio n is ite ra tio ns 6 a nd 7

Ma ny so ftwa re te a m s, ho we ve r, a re in e ffe ct still writing the bo o k stra ight thro ugh fro m the first pa ge to the e nd by using a waterfall pro ce ss fo r de ve lo pm e nt

pro je cts T he y co m ple te e a ch pha se in strict se que nce : re quire m e nts a na lysis, the n de sign, the n im ple m e nta tio n/inte gra tio n, a nd the n te sting O r, m o re

co m m o nly, the y use a m o difie d wa te rfa ll a ppro a ch, with fe e dba ck lo o ps a dde d to the ba sic o ve ra ll flo w de scribe d a bo ve Such a ppro a che s de fe r inte gra tio n a nd

te sting until the e nd o f the pro je ct life cycle , whe n pro ble m s te nd to be to ugh a nd e x pe nsive to re so lve , a s we ll a s po sing se rio us thre a ts to re le a se de a dline s a ndpro je ct budge ts

Each iteration has a well-defined set of objectives and produces a partial working implementation of the final system.

By co ntra st, a n ite ra tive a ppro a ch divide s a pro je ct into a se que nce o f ite ra tio ns, e a ch o f which e vo lve s thro ugh the re quire m e nts, a na lysis, de sign,

im ple m e nta tio n, a nd te sting a sse ts, a s yo u ca n se e in Figure 2.2 Ea rly ite ra tio ns pla ce a gre a te r e m pha sis o n re quire m e nts, a na lysis, a nd de sign; la te r ite ra tio ns

fo cus m o re o n im ple m e nta tio n a nd te sting Ea ch ite ra tio n ha s a we ll-de fine d se t o f o bje ctive s a nd pro duce s a pa rtia l wo rk ing im ple m e nta tio n o f the fina l syste m Furthe r, e a ch succe ssive ite ra tio n builds o n the wo rk o f pre vio us ite ra tio ns to de ve lo p a nd re fine the syste m until the fina l pro duct is co m ple te

Figure 2.2 Iterative Development.

Each iteration involves some requirements, analysis, design, implementation, and testing Each iteration builds on the work of the previous one to produce an

executable that is one step closer to the final product.

Advantages of the Iterative Approach

[8] This section adapted f rom Kroll 2003

So m e pro je ct m a na ge rs re sist the ite ra tive a ppro a ch, se e ing it a s a k ind o f e ndle ss a nd unco ntro lle d ha ck ing T he risk -drive n ite ra tive a ppro a ch is, ho we ve r, ve rydiscipline d: the ite ra tio n le ngth is fix e d; the o bje ctive s o f ite ra tio ns a re ca re fully pla nne d; a nd the ta sk s a nd re spo nsibilitie s o f pa rticipa nts a re we ll de fine d.Additio na lly, o bje ctive m e a sure s o f pro gre ss a re ca pture d So m e re wo rk ing ta k e s pla ce fro m o ne ite ra tio n to the ne x t, but this to o is do ne in a structure d fa shio n

More than 45 percent of features are never used, while another 19 percent are used rarely.

T he ite ra tive a ppro a ch ha s pro ve d itse lf supe rio r to the wa te rfa ll a ppro a ch fo r a num be r o f re a so ns:[9]

[9] For comprehensive coverage of the motivation and evidence that iterative development is more ef f ective than waterf all development, see Larman 2004, Chapters 5 and 6

You are more likely to build an application that addresses user needs Ea rly spe cifica tio n o f re quire m e nts o fte n le a ds to unuse d fe a ture s T he Sta ndish

Gro up ha s re se a rche d tho usa nds o f a pplica tio n de ve lo pm e nt pro je cts a nd ha s fo und tha t m o re tha n 45 pe rce nt o f fe a ture s a re ne ve r use d, while a no the r 19

pe rce nt a re use d ra re ly [10] (se e Figure 2.3) In o the r wo rds, typica lly m o re tha n ha lf o f the de ve lo pm e nt e ffo rt is wa ste d o n de ve lo ping no ne sse ntia l

ca pa bilitie s T o a vo id this pro ble m , yo u ne e d to invo lve the custo m e r in the de ve lo pm e nt pro je ct a nd use a n ite ra tive a ppro a ch tha t a llo ws yo u to im ple m e nt

a nd va lida te the ca pa bilitie s de e m e d m o st e sse ntia l in e a ch ite ra tio n T his a ppro a ch a llo ws no t o nly e a rly va lida tio n o f k e y ca pa bilitie s but a lso a dditio n o f

ne w ca pa bilitie s la te in the pro je ct

[10] 10 Chaos 2003

Figure 2.3 Most Features Implemented Are Never or Rarely Used.

An amazing 45 percent of features implemented are never used, while another 19 percent are used only rarely If features never used were not implemented

in the first place, development time would be cut in about half Further, since productivity is typically measured in the form of lines of code or functionality

delivered, this improvement would not register as a productivity increase using standard productivity measures.

Integration is not one "big bang" at the end of a project Le a ving inte gra tio n to the e nd re sults in tim e - a nd budge t-co nsum ing re wo rk T o a vo id this, a n

ite ra tive a ppro a ch bre a k s a pro je ct do wn into sm a lle r ite ra tio ns, e a ch e vo lving e x e cuta ble co de tha t is co ntinuo usly inte gra te d to e na ble ra pid fe e dba ck a nd

m inim ize la te r re wo rk

Risks are usually discovered or addressed during early iterations W ith the ite ra tive a ppro a ch, risk s a re m o re lik e ly to be ide ntifie d a nd a ddre sse d in e a rly

ite ra tio ns As a n e x a m ple , if the re is a risk tha t a sta k e ho lde r will no t be ha ppy with the functio na lity yo u a re de ve lo ping, ite ra tive de ve lo pm e nt will

e nco ura ge yo u to im ple m e nt the m o st e sse ntia l ca pa bilitie s pa rtia lly a nd de m o nstra te the m to k e y sta k e ho lde rs to m a k e sure tha t yo u a re o n the righttra ck

Your ability to work effectively is fine-tuned During e a rly ite ra tio ns, te a m m e m be rs a re wa lk ing thro ugh a ll life cycle a ctivitie s, fro m re quire m e nts ca pture

a nd te st de finitio n to de ve lo pm e nt, im ple m e nta tio n, a nd te sting C o nse que ntly, the y ca n m a k e sure the y ha ve the to o ls, sk ills, o rga niza tio na l structure ,

to work effectively.

Management has a way of making tactical changes to the product Ma na ge m e nt ca n m a k e cha nge s to the pro duct a lo ng the wa yto co m pe te with o the r ne w

pro ducts, fo r e x a m ple Ite ra tive de ve lo pm e nt a llo ws yo u to e vo lve pa rtia l im ple m e nta tio ns o f the e nd pro duct quick ly a nd use the se fo r quick re le a se o f a

re duce d-sco pe pro duct to co unte r a co m pe tito r's m o ve

Reuse is facilitated It is e a sie r to ide ntify co m m o n pa rts a s the y a re be ing pa rtia lly de signe d o r im ple m e nte d in ite ra tio ns tha n to re co gnize the m a t the

be ginning Discussio ns a nd re vie ws o f the de sign in e a rly ite ra tio ns a llo w te a m m e m be rs to spo t po te ntia l o ppo rtunitie s fo r re use a nd the n de ve lo p a

m a ture co m m o n co de fo r the se o ppo rtunitie s in subse que nt ite ra tio ns.[11]

[11] A lot of reuse also happens cross-project

Defects can be found and corrected over several iterations T his ca pa bility re sults in a ro bust a rchite cture a nd a high-qua lity a pplica tio n Fla ws a re de te cte d

in e a rly ite ra tio ns, ra the r tha n during a m a ssive te sting pha se a t the e nd P e rfo rm a nce bo ttle ne ck s a re disco ve re d while the y ca n still be a ddre sse d inste a d

o f cre a ting pa nic o n the e ve o f de live ry

Project personnel are better used Ma ny o rga niza tio ns m a tch the ir use o f a wa te rfa ll a ppro a ch with a pipe line o rga niza tio n: the a na lysts se nd the

co m ple te d re quire m e nts to de signe rs, who se nd a co m ple te d de sign to pro gra m m e rs, who se nd co m po ne nts to inte gra to rs, who se nd a syste m to te ste rs

T he se m a ny ha ndo ffs a re so urce s o f e rro rs a nd m isunde rsta ndings a nd m a k e pe o ple fe e l le ss re spo nsible fo r the fina l pro duct; se e Practice 7: Everyone Owns the Product! fo r m o re info rm a tio n An ite ra tive pro ce ss e nco ura ge s wide ning the sco pe o f e x pe rtise o f the te a m m e m be rs, a llo wing the m to pla y m a ny

ro le s a nd thus e na bling a pro je ct m a na ge r to m a k e be tte r use o f the a va ila ble sta ff a nd sim ulta ne o usly re m o ve pro ble m a tic ha ndo ffs.[12]

[12] 12 Ambler 2002

Team members learn along the way T he pro je ct m e m be rs ha ve se ve ra l o ppo rtunitie s within a de ve lo pm e nt cycle to le a rn fro m the ir m ista k e s a nd im pro ve

the ir sk ills fro m o ne ite ra tio n to a no the r Mo re tra ining o ppo rtunitie s ca n be disco ve re d a s a re sult o f a sse ssing the e a rlie r ite ra tio ns

The development process itself is improved and refined along the way T he e nd o f ite ra tio n a sse ssm e nt no t o nly lo o k s a t the pro je ct sta tus fro m a pro duct

o r sche duling pe rspe ctive but a lso a na lyze s wha t ca n be im pro ve d in the ne x t ite ra tio n in bo th the o rga niza tio n a nd the pro ce ssthe a gile co m m unity o fte n

re fe rs to this a s "re tro spe ctive "[13] Se e Practice 20:Continuously Reevaluate What You Do fo r m o re info rm a tio n.

[13] 13 Kerth 2001

Applying the Practice

T o build yo ur pro je ct e ffe ctive ly in ite ra tio ns, yo u ne e d to (1) de cide ho w m a ny ite ra tio ns yo u ne e d a nd the a ppro pria te le ngth o f the ite ra tio ns; (2) de te rm ine wha trisk s yo u a re fa cing a nd ho w the y co uld im pa ct yo ur ite ra tio ns; (3) figure o ut wha t e x e cuta ble s a nd de live ra ble s sho uld be pro duce d in e a ch ite ra tio n; a nd (4)

a sse ss the ite ra tio ns a nd le ve ra ge the e x pe rie nce s ga ine d during the e x e cutio n to fine -tune yo ur pla n fo r the ne x t ite ra tio n Le t's e x plo re e a ch o f the se a ctivitie s

Decide the Number of Iterations and Their Length

T o de cide o n the num be r o f ite ra tio ns a nd the ite ra tio n le ngth suita ble fo r yo ur pro je ct, yo u ne e d to ha ve a n ide a o f the sta ffing le ve l a nd dura tio n o f the pro je ct.First, size the pro je ct using the e stim a tio n a ppro a ch o f yo ur cho ice , such a s functio n po ints, C O C O MO , [14] o r e x pe rt o pinio n, whe re pa st e x pe rie nce s fro m sim ila rpro je cts a re use d to e stim a te future pro je cts T he n de te rm ine a ro ugh sta ffing pro file , a nd use this info rm a tio n to a sse ss the a ppro x im a te pro je ct dura tio n.[14] COCOMO is a Sof tware Cost Estimation Model; see Boehm 2000

Ne x t, yo u ne e d to de te rm ine wha t is a n a ppro pria te ite ra tio n le ngth fo r yo ur pro je ct W e re co m m e nd using fo ur we e k s (this is the de fa ult re co m m e nda tio n by R UP

a nd Scrum , while XP re co m m e nds o ne o r two we e k s) a s a sta rting po int fo r yo ur discussio n a ro und ite ra tio n le ngth T he n a na lyze fa cto rs tha t will im pa ct theite ra tio n le ngth T a ble 2.3 pro vide s a n o ve rvie w o f m a ny o f the se fa cto rs

Table 2.3 Factors Impacting Iteration Length.

The appropriate iteration length is influenced by a large number of factors, including team size

and organization, the sophistication of the supporting tool environment, the experience of team

members, and the complexity of the domain and architecture.

Factors Leading to Reduced Iteration

Stro ng co nfigura tio n m a na ge m e nt syste m P o o r co nfigura tio n m a na ge m e nt syste m

De dica te d, full-tim e re so urce s Ma trix e d o r pa rt-tim e re so urce s

Inte gra te d to o l e nviro nm e nt Abse nce o f go o d a uto m a tio n a nd to o l

inte gra tio n

T e a m e x pe rie nce d with ite ra tive

Uncle a r o r brittle a rchite cture W e ll-de fine d a nd sta ble a rchite cture

Ne w a nd po o rly unde rsto o d te chno lo gy W e ll-unde rsto o d te chno lo gy

Y o u a lso wa nt to k e e p the to ta l num be r o f ite ra tio ns to a re a so na ble num be r P ro je ct te a m s ne w to ite ra tive de ve lo pm e nt m a y ha ve pro ble m s ha ndling a pro je ctwith m o re tha n thre e to fo ur ite ra tio ns, whe re a s pro je ct te a m s e x pe rie nce d in ite ra tive de ve lo pm e nt m a y ha ve pro je cts with te n o r m o re ite ra tio ns

Ba se d o n the a bo ve fa cto rs, yo u co uld find tha t the a ppro pria te ite ra tio n le ngth is two we e k s fo r a fo ur-m o nth lo ng pro je ct with fo ur co llo ca te d, e x pe rie nce d te a m

m e m be rs with a go o d to o l e nviro nm e nt Me a nwhile , a two -ye a r, te chnica lly co m ple x , distribute d pro je ct with six ty te a m m e m be rs, ine x pe rie nce d in ite ra tive

de ve lo pm e nt a nd with a po o r to o l e nviro nm e nt, m a y re quire a n ite ra tio n le ngth o f six we e k s La rge pro je cts sho uld, ho we ve r, co nside r bre a k ing up the pro je ct into

se ve ra l sm a lle r pro je cts, e a ch de live ring a pa rt o f the e nd so lutio n Se e a lso the se ctio n Ite ra tio n P ro file s fo r Ve ry Lo ng P ro je cts o n pa ge 53

Determine What Risks Need to Be Addressed and in What Order

wha t tim e ? Y o u wa nt to a ddre ss the m o st se rio us risk s firsttho se tha t will m o st se ve re ly im pa ct the pro je ct o utco m e But ho w do yo u ha ndle risk tha t is no t k no wn

e a rly in the pro je ct? T his is whe re the fo ur pha se s in the Unifie d P ro ce ss life cycle co m e in ha ndy

Address the most serious risks first.

The Unified Process lifecycle phases are coupled to risk mitigation.

T he Unifie d P ro ce ss life cycle pro vide s a co nsiste nt a ppro a ch to m a na ging pro je cts whe n the pha se s a re co uple d to risk m itiga tio n T he se pha se s a re a lso po we rful

to o ls in ite ra tio n pla nning T he y a re , in o rde r:

1 Inception phase Mitiga te busine ss risk s, unde rsta nd the sco pe o f the pro je ct, build the busine ss ca se , a nd ge t sta k e ho lde r buy-in to m o ve a he a d T his

pha se co rre spo nds to Ite ra tio n 0 in m a ny a gile a ppro a che s No te tha t the Unifie d P ro ce ss life cycle a llo ws yo u to ha ve m o re tha n o ne ite ra tio n in theInce ptio n pha se if ne e de d

2 Elaboration phase Mitiga te m a jo r pro je ct risk s Ma jo r te chnica l risk s a re m itiga te d by cre a ting a ba se line e x e cuta ble a rchite cture , a llo wing yo u to unde rsta nd

wha t it ta k e s to build the syste m Ma jo r busine ss risk s a re , a m o ng o the rs, m itiga te d by de live ring the m o st im po rta nt e nd-use r ca pa bilitie s

3 Construction phase Mitiga te risk s re la te d to the a bility to pro duce a co m ple te pro duct Build the first o pe ra tio na l ve rsio n o f the pro duct.

4 Transition phase Mitiga te risk s re la te d to whe the r the pro duct is a cce pta ble to the custo m e r Build the fina l ve rsio n o f the pro duct a nd de live r to the

custo m e r

Using the ite ra tio n le ngth a nd num be r o f ite ra tio ns, yo u ca n no w de te rm ine ho w m a ny ite ra tio ns yo u ne e d in e a ch pha se to a ddre ss the type o f risk s a nd pro ducethe type o f re sults e x pe cte d fro m e a ch pha se If yo ur pro je ct is fa cing a lo t o f risk a sso cia te d with the busine ss ca se , sco pe , a nd sta k e ho lde r buy-in, pla n fo r m o reite ra tio ns in the Ince ptio n pha se If yo ur pro je ct is fa cing a lo t o f a rchite ctura l risk , pla n fo r m o re ite ra tio ns in the Ela bo ra tio n pha se , a nd so o n

It co uld be tha t the fo ur-m o nth pro je ct with two -we e k ite ra tio ns will ha ve a n ite ra tio n pro file o f 1, 1, 4, 2, tha t is, o ne ite ra tio n in Ince ptio n, o ne in Ela bo ra tio n, fo ur

in C o nstructio n, a nd two in T ra nsitio n (se e T a ble 2.4) T his pro file wo uld indica te tha t the pro je ct pla nne rs e x pe ct to pro duce sta ble re quire m e nts, a busine ss ca se ,

a nd a ba se line d a rchite cture ve ry quick ly O n the o the r ha nd, the two -ye a r pro je ct with six -we e k ite ra tio ns m a y ha ve a n ite ra tio n pro file o f 2, 4, 8, 2, m e a ning tha tthe pla nne rs e x pe ct to ne e d a lo t o f tim e to ge t the a rchite cture right a nd e x pe ct to m a k e ste a dy pro gre ss o nce tha t is do ne

Table 2.4 Examples of Iteration Profiles for Different Projects.

This table shows an example of different iteration profiles We see that higher architectural risk

drives up the number of iterations in the Elaboration phase The number and length of iterations

depend on many different factors.

Number of Iterations Per Phase

Inception Elaboration Construction Transition

Determine a Series of Executables and Deliverables That Will Take You to the End Point

Outline at a high level the expected end result of each iteration.

O nce yo u ha ve e sta blishe d the initia l ite ra tio n pro file (which yo u will ha ve o ppo rtunitie s to re think la te r in the pro je ct ba se d o n pro gre ss m a de ), o utline a t a high

le ve l the e x pe cte d e nd re sult o f e a ch ite ra tio n, prim a rily e x pre sse d a s wha t ca pa bilitie s sho uld be im ple m e nte d a nd te ste d with fa vo ra ble fe e dba ck fro m custo m e r

re pre se nta tive s T he se a re sim ila r to Sprint Go a ls in Scrum (Schwa be r 2002) It is o fte n e no ugh just to do cum e nt a fe w bulle ts T he Ba ck gro und se ctio n a t the

be ginning o f this cha pte r pro vide d a go o d e x a m ple o f such a brie f list in re la tio n to o ur bo o k pro je ct, sho wing wha t sho uld be a cco m plishe d in e a ch ite ra tio n T his is

a pa rt o f wha t the Unifie d P ro ce ss ca lls the P ha se P la n,[15] a nd the re is one such pla n fo r the e ntire pro je ct T he P ha se P la n is purpo se ly k e pt a t a high le ve l,

typica lly o nly o ne o r two pa ge s lo ng, fo r sm a ll pro je cts

[15] 15 Phase Plan was previously ref erred to as a Coarse Project Plan in RUP

Assess Iteration and Plan the Next Iteration

P ro je ct m a na ge rs who pro duce de ta ile d ite ra tio n pla ns fo r e ntire pro je cts a t the sta rt o f a pro je ct a re usua lly wa sting e ve rybo dy's tim e co nve ying fa lse pre cisio nwhe re the re ca n be no ne Inste a d, de ta ile d pla nning sho uld be ca rrie d o ut incre m e nta lly, whe n sufficie nt info rm a tio n is a va ila ble [16] T o wa rd the e nd o f e a chite ra tio n, the te a m pro duce s a de ta ile d pla n o f the ne x t ite ra tio n a nd o utline s wha t ca pa bilitie s sho uld be im ple m e nte d a nd te ste d, including ho w to a sse ss theite ra tio n thro ugh, a m o ng o the r m e a ns, te st ca se s, a nd de m o nstra tio ns to k e y sta k e ho lde rs

[16] See Chapters 12 in Kroll 2003 f or more inf ormation on how to plan using two levels of detail, coarse project planning, and iteration planning

At the e nd o f e a ch ite ra tio n, a sse ss the ite ra tio n by a na lyzing te st re sults, re vie wing wha t wa s pro duce d, a nd co lle cting fe e dba ck fro m custo m e r re pre se nta tive s

T he ite ra tio n a sse ssm e nt give s yo u a n o bje ctive a nd pre cise re a ding o f whe re yo u a re Y o u ca n no w co m pa re whe re yo u a re with whe re yo u e x pe cte d to be a ndwhe re yo u ne e d to go ; a nd yo u ca n the n use this info rm a tio n to upda te the P ha se P la n a s ne e de d T he P ha se P la n is he nce use d a s a high-le ve l a nd e vo lving

ro a dm a p, sho wing whe re yo u e x pe ct to be a t the e nd o f e a ch ite ra tio n a nd whe re yo u ne e d to e nd up a t the co m ple tio n o f the who le pro je ct Using a P ha se P la n in

co m bina tio n with ite ra tio n a sse ssm e nts is a ve ry po we rful to o l tha t a llo ws yo u to unde rsta nd o ve ra ll pro je ct pe rfo rm a nce a nd he lps yo u de cide whe the r yo u ne e d to

m a k e cha nge s to the pro je ct, o r e ve n to k ill it a lto ge the r

Using a Phase Plan in combination with iteration assessments allows you to understand overall project performance.

Iteration Profiles for Very Long Projects

So m e la rge o r lo ng pro je cts m a y be difficult to bre a k up into sm a lle r pro je cts Fo r the se pro je cts, we use the no tio n o f supe ite ra tio ns a nd m ini-ite ra tio ns A supe ite ra tio n is typica lly se ve ra l m o nths lo ng a nd pro vide s a we ll-de fine d inte gra tio n po int fo r the e ntire pro je ct tha t is fo rm a lly a sse sse d, re se m bling wha t XP ca llsqua rte rly cycle s In co ntra st, m ini-ite ra tio ns a re typica lly a fe w we e k s lo ng a nd pro vide sub-te a m s with the be ne fits o f sho rt ite ra tio ns with quick fe e dba ck lo o ps

r-Le t's lo o k a t a n e x a m ple : A 100-pe rso n pro je ct la sting two ye a rs m a y ha ve supe r-ite ra tio ns tha t a re thre e m o nths lo ng: e ve ry thre e m o nths the re is a ve ry we

ll-de fine d a nd we ll-te ste d ll-de live ra ble inte gra ting e ve rything tha t ha s be e n do ne a nd ll-de live ring so m e thing o f ta ngible va lue to the e nd use rs T he se supe r-ite ra tio ns

e a ch supe r-ite ra tio n Ea ch m ini-ite ra tio n is te ste d a nd va lida te d with the sta k e ho lde rs spe cifica lly inte re ste d in tha t se t o f ca pa bilitie s T he subte a m thus re ce ive squick a nd tim e ly fe e dba ck o n wha t it is do ing, a s we ll a s ga ining incre a se d m a ne uve ra bility by be co m ing le ss de pe nde nt o n the wo rk o f o the r te a m s.

P ro je cts sho uld a im to inte gra te a nd te st a ll co de fre que ntly, ide a lly cre a ting a build a nd a uto m a tica lly te sting it a fte r e a ch che ck -in, a s re co m m e nde d by XP In o ur

e x pe rie nce , this m e tho d is no t fe a sible fo r m a ny la rge r o r le ga cy pro je cts, due to la ck o f sk ills, la ck o f te st a uto m a tio n, po o r build pro ce sse s,[17] o r the co m ple x ity

o f la rge r pro je cts in which m e a ningful a uto m a te d te st suite s m a y ta k e to o lo ng to run O the r e x a m ple s include distribute d de ve lo pm e nt, o r de ve lo pm e nt do ne

a cro ss o rga niza tio na l bo rde rs, le ve ra ging diffe re nt infra structure s, o r ca se s whe re so m e subpro je cts de ve lo p co m po ne nts, such a s ha rdwa re co m po ne nts, tha t

ca nno t be e vo lve d co ntinuo usly a s so ftwa re ca n T he m ini- a nd supe r-ite ra tio ns pro vide a fra m e wo rk fo r m a na ging the se situa tio ns by ha ving subte a m s dofre que nt inte gra tio n a nd te sting o f the ir se t o f co m po ne nts, while do ing inte gra tio n a nd te sting o f the la rge r syste m s le ss fre que ntly C o m pre he nsive te sting, such

a s lo a d a nd pe rfo rm a nce te sting, m a y be ca rrie d o ut prim a rily to wa rd the e nd o f supe r-ite ra tio ns, with the la st fe w we e k s fo cusing so le ly o n sta bilizing the build a nd

m a k ing qua lity im pro ve m e nts

[17] 17 The cost of changing the basic environment and retraining people is of ten too prohibitive to be carried by one project and makes it necessary to implement the change over a series of projects.The time, however, is well worth the investment, at least if the system will be maintained f or some time

Other Methods

A strict wa te rfa ll pro je ct runs a pro je ct a s o ne ite ra tio n, with a strict se que nce o f re quire m e nts, de sign, im ple m e nta tio n, a nd te sting O fte n, such a pro je ct is fo rce d

to a dd o ne o r se ve ra l bug-fix ing ite ra tio ns a t the e nd to de a l with une x pe cte d inte gra tio n a nd qua lity issue s

In pra ctice , fe w pro je cts do strict wa te rfa ll de ve lo pm e nt Inste a d, m a ny a pply m ini-ite ra tio ns a s pa rt o f a la rge r wa te rfa ll pro je ct As issue s a re ide ntifie d, te a m s a re

a sse m ble d to do a m ini-ite ra tio n to drive o ut a spe cific risk At a ny give n tim e ze ro to se ve ra l te a m s m a y be do ing m ini-ite ra tio ns, o fte n witho ut synchro niza tio n in

te rm s o f co m m o n ite ra tio n e nds

In 1988 P ro fe sso r Ba rry Bo e hm[18] intro duce d the spira l m o de l, which is a n incre m e nta l a nd risk -drive n de ve lo pm e nt a ppro a ch In this m o de l a pro je ct is divide dinto a num be r o f ite ra tio ns, e a ch o f which go e s thro ugh pla nning, re quire m e nts, de sign, im ple m e nta tio n, inte gra tio n a nd te sting, a nd so o n se que ntia lly Ea chite ra tio n is he nce a m ini-wa te rfa ll pro je ct, de live ring a pro duct incre m e nt

[18] 18 Boehm 1988

In the spiral model, each iteration is a mini-waterfall project.

Ite ra tive a nd a gile m e tho ds such a s R UP , Scrum , XP , a nd O pe nUP /Ba sic a pply a n ite ra tive a ppro a ch in which e a ch ite ra tio n co ntinuo usly de ve lo ps the re quire m e nts,

de sign, im ple m e nta tio n, a nd te sting witho ut a se que ntia l o rde r So m e tim e s yo u do a little co ding to unde rsta nd ho w to im pro ve the de sign, o nly to do m o re co dingthe ne x t da y, fo llo we d by so m e te sting, a nd the n so m e re quire m e nts wo rk R UP , Scrum , XP , a nd O pe nUP /Ba sic va ry, ho we ve r, in the ir re co m m e nda tio ns fo rite ra tio n le ngths a nd ho w individua l ite ra tio ns a re e x e cute d

RUP, Scrum, XP, and OpenUP/Basic apply an iterative approach in which requirements, design, implementation, and testing evolve without a sequential order.

XP re co m m e nds sho rt o ne - to two -we e k ite ra tio ns with co ntinuo us inte gra tio n a nd te sting to pro vide quick fe e dba ck lo o ps T he wo rk o f e a ch ite ra tio n is prio ritize d

by the custo m e r o r custo m e r re pre se nta tive , a nd sho uld de live r wha t is de e m e d m o st im po rta nt to the custo m e r Appro a che s using the Unifie d P ro ce ss life cycle , o nthe o the r ha nd, prio ritize ba se d o n a co m bina tio n o f risk a nd custo m e r im po rta nce Ea ch ite ra tio n de live rs a n e x e cuta ble tha t m a y be put into pro ductio n.Scrum re co m m e nds fo ur-we e k ite ra tio ns Scrum pro je cts fo cus o n co ntinuo us co m m unica tio n, with a sho rt da ily sta nd-up m e e ting with the e ntire pro je ct te a m a twhich e a ch pe rso n brie fly re vie ws sta tus a nd discusse s a ny ro a dblo ck s tha t ne e d to be re so lve d Ea ch ite ra tio n ha s a we ll-de fine d o bje ctive , a nd no cha nge s to the

o bje ctive s a re a llo we d during the ite ra tio n Scrum m a na ge s la rge pro je cts thro ugh a "scrum o f scrum s," in which re pre se nta tive s o f e a ch subte a m ge t to ge the r da ily

to re so lve cro ss-te a m issue s

T he Unifie d P ro ce ss ha s m a ny sim ila ritie s to Scrum It re co m m e nds fo ur-we e k ite ra tio ns but a dvise s yo u whe n to co nside r lo nge r o r sho rte r o ne s Ite ra tio ns in bo thScrum a nd Unifie d P ro ce ss sho uld be e x e cute d witho ut cha nge s to the o bje ctive s, e x ce pt in e x tra o rdina ry circum sta nce s T he re a re a lso so m e no ta ble diffe re nce s

be twe e n the two m e tho ds, tho ugh T he Unifie d P ro ce ss life cycle de fine s fo ur distinct pha se s, e a ch ha ving a we ll-de fine d busine ss o bje ctive a nd co nta ining o ne o r

se ve ra l ite ra tio ns Ano the r k e y diffe re nce is tha t the Unifie d P ro ce ss inte gra te s the m a na ge m e nt life cycle with a pro ce ss fo r ho w to ca rry o ut the te chnica l wo rk , to

fa cilita te pra ctica l im ple m e nta tio n o f the m a na ge m e nt pro ce ss, a nd e nsure tha t the m a na ge m e nt pro ce ss wo rk s we ll with the te chnica l pro ce ss Scrum , o n the o the r

ha nd, a ddre sse s o nly the m a na ge m e nt a spe ct, a llo wing inte gra tio n with a va rie ty o f pro ce sse s

Levels of Adoption

T he ite ra tive de ve lo pm e nt pra ctice ca n be a do pte d a t thre e le ve ls:

Basic At the ba sic le ve l, m o ve to wa rd incre m e nta l de live ry o f ca pa bilitie s, a nd re pla n yo ur pro je ct to re fle ct le sso ns le a rne d a lo ng the wa y.

In m a ny pro je cts the e a sie st wa y to m o ve to wa rd incre m e nta l de live ry is first to do o ne o r two ite ra tio ns prim a rily fo cusing o n re quire m e nts a nd high-le ve l

a rchite cture , a nd the n to divide the pro je cts into chunk s o f functio na lity, whe re e a ch functio na lity se t is de ta ile d, de signe d, im ple m e nte d, inte gra te d, te ste d,

a nd va lida te d in e a ch ite ra tio n

Using the Unifie d P ro ce ss life cycle , this a ppro a ch co uld be tra nsla te d a s prim a rily do ing wa te rfa ll de ve lo pm e nt thro ugh Ela bo ra tio n (still trying to build so m epro to type s during Ince ptio n a nd Ela bo ra tio n) while a do pting the ite ra tive a ppro a ch in C o nstructio n a nd T ra nsitio n In o ur e x pe rie nce , it is no rm a lly e a sie r fo r

ne w te a m s to do ite ra tive de ve lo pm e nt in the C o nstructio n pha se , since the y ha ve a sta ble a rchite cture a nd a go o d unde rsta nding o f the re quire m e nts,

a llo wing fo r a n e a sie r discussio n a bo ut wha t to do in which ite ra tio n.[19] T his le ve l sho uld be se e n a s o nly a n inte rim ste p to wa rd the inte rm e dia te le ve l, a nd

ne ve r a s a n e nd go a l P ro je cts a ble to go dire ctly to the inte rm e dia te le ve l sho uld do so

[19] Note that many of the earlier iterative processes f ollowed this pattern, such as HP's Fusion, early versions of DSDM, and many homegrown iterative processes we have run into

Intermediate Use risk a s a prim a ry drive r fo r yo ur ite ra tio n pla nning P ro duce a n e x e cuta ble a rchite cture e a rly in the pro je ct to m itiga te te chnica l

risk s T his m e a ns tha t e a rly o n yo u sho uld de sign, im ple m e nt, a nd te st so m e o f the m o st e sse ntia l co m po ne nts, the inte rfa ce s o f yo ur subsyste m s, a nd

re le va nt a rchite ctura l pa tte rns De live r high-prio rity ca pa bilitie s in e a rly ite ra tio ns to e nsure tha t yo u de live r co ntinuo us va lue to e nd use rs All pro je ctssho uld try to re a ch this le ve l

A dvanced At the a dva nce d le ve l, ve ry la rge o r lo ng pro je cts m a y intro duce the co nce pt o f supe r-ite ra tio ns a nd m ini-ite ra tio ns T his a ppro a ch will

a llo w yo u to ha ve sho rte r ite ra tio ns, since the m ini-ite ra tio ns ha ve a m inim um o f o ve rhe a d It do e s, ho we ve r, a lso intro duce so m e a dditio na l m a na ge m e nt

co m ple x ity, incre a sing the re quire d sk ill le ve l o f yo ur m a na ge rs a nd thus m o ving yo u to the right o n the pro ce ss m a p

P ro je cts o f a ll size s fine -tune the ir a bility to do sho rte r ite ra tio ns by, fo r e x a m ple , im pro ving build a nd te st a uto m a tio n, a cce le ra ting de cisio n

m a k ing, incre a sing high-ba ndwidth co m m unica tio n o r o the r m e a ns o f re ducing ce re m o ny, a nd he nce re ducing the co st o f do ing ite ra tio ns

Related Practices

Practice 3: Embrace and Manage Change de scribe s wha t cha nge s to e nco ura ge a nd disco ura ge a t wha t tim e within a pro je ct Disco ura ging ce rta in type s o f

cha nge s la te in the pro je ct is e sse ntia l to m a na ge risk e ffe ctive ly

Practice 4: Measure Progress Objectively sho ws ho w to a sse ss pro gre ss be tte r thro ugh ite ra tive de ve lo pm e nt.

Practice 6: Leverage Test Automation Appropriately de scribe s ho w a uto m a ting a ppro pria te a m o unts o f the te st e ffo rt ca n re a lize im pro ve d pro duct qua lity a nd

sho rte r pro duct de ve lo pm e nt sche dule s, including wha t te sts to a uto m a te in e a rly ite ra tio ns a nd the be ne fits o f a uto m a te d re gre ssio n te sting

Practice 7: Everyone Owns the Product! a ddre sse s ho w a ll te a m m e m be rs ne e d to o rie nt the ir m indse t to e na ble e ffe ctive ite ra tive de ve lo pm e nt.

Practice 10: Prioritize Requirements for Implementation sho ws ho w to de te rm ine which re quire m e nts to a ddre ss in e a rly ite ra tio ns to de live r high-prio rity

ca pa bilitie s e a rly, drive the a rchite cture , a nd to m itiga te k e y risk s

Practice 14: Manage Versions de scribe s ho w to k e e p tra ck o f cha nge s a nd va rio us ve rsio ns o f a sse ts T his is crucia l in ite ra tive de ve lo pm e nt, since yo ur a sse ts

will go thro ugh a la rge a m o unt o f churn, a nd yo u ne e d to be a ble to cre a te builds e a sily

Additional Information

Information in the Unified Process

O pe nUP /Ba sic guide s yo u in ho w to divide yo ur pro je ct into ite ra tio ns, a nd ho w to pla n ite ra tio ns by ba la ncing the co ntinuo us ne e d to de live r e nd-use r ca pa bilitie swith the ne e d to m itiga te risk R UP pro vide s m o re in-de pth guida nce o n ite ra tio n pla nning, issue , a nd e x ce ptio n m a na ge m e nt a nd ho w to de a l with pro ble m

re so lutio n R UP a lso pro vide s guida nce o n fo rm a l re vie ws, P ro je ct R e vie w Autho ritie s, a nd m o nito ring a nd co ntro l pro ce sse s a ppro pria te fo r la rge r o r m o re co m ple xpro je cts o r pro je cts co nce rne d with co m plia nce Future ve rsio ns o f R UP will pro vide e x plicit guida nce o n m ini- a nd supe r-ite ra tio ns

Additional Reading

T he fo llo wing bo o k s pro vide guida nce o n ite ra tive de ve lo pm e nt le ve ra ging the Unifie d P ro ce ss life cycle :

P e r Kro ll a nd P hilippe Kruchte n The Rational Unified Process Made Easy: A Practitioner's Guide to the RUP Addiso n-W e sle y, 2003.

Sco tt Am ble r, Jo hn Na lbo ne , a nd Micha e l Vizdo s The Enterprise Unified Process: Extending the Rational Unified Process P re ntice Ha ll, 2005.

W a lk e r R o yce Software Project Management: A Unified Framework Addiso n-W e sle y, 1998.

T he fo llo wing bo o k s pro vide guida nce o n o the r ite ra tive a ppro a che s:

C ra ig La rm a n Agile and Iterative Development: A Manager's Guide Addiso n-W e sle y, 2004.

Alista ir C o ck burn Agile Software Development Addiso n-W e sle y, 2002.

Ke n Schwa be r a nd M Be e dle Agile Software Development with SCRUM P re ntice Ha ll, 2002.

Ke nt Be ck with C ynthia Andre s Extreme Programming Explained: Embrace Change, Second Edition Addiso n-W e sle y, 2004.

Practice 3 Embrace and Manage Change

Per Kroll

Embracing change helps you to build a system that addresses stakeholder needs, and managing change allows you to reduce costs and improve predictability.

Problem

P hysica l syste m s, lik e bridge s a nd sk yscra pe rs, a re ve ry difficult to cha nge Adding a la ne to a bridge o r e x pa nding a building is e x tre m e ly co stly o nce co nstructio n

ha s be gun Fo r this re a so n, de ta ile d pla nning is critica l to the succe ss o f physica l e ngine e ring pro je cts

So ftwa re , ho we ve r, ca n be cha nge d fa r m o re e a sily So ftwa re ca n be de signe d to be co nfigure d Ea rly pro to type s ca n de m o nstra te be ha vio r, which ca n the n be

m o difie d fo r the fina l syste m R a the r tha n try to de sign so ftwa re in de ta il up fro nt, it is o fte n fa r be tte r to build so m e so ftwa re a nd use the wo rk ing pro duct a s a

co m m unica tio n m e dium to he lp de te rm ine wha t is re a lly ne e de d

Use the working product as a communication medium to help determine what is really needed.

Ne ve rthe le ss, a ltho ugh the a bility o f so ftwa re to suppo rt cha nge s pro vide s a gre a t o ppo rtunity to e vo lve it to m e e t cha nging sta k e ho lde r re quire m e nts, co ntinuo uscha nge pre se nts a cha lle nge to so ftwa re de ve lo pm e nt te a m s C ha nge s ca n intro duce co sts tha t ne e d to be m a na ge d T he y ca n a lso ca use de ve lo pe rs to thra sh

a ro und, una ble to pro gre ss with the so ftwa re be ca use the re quire m e nts a re cha nging fa ste r tha n the y ca n k e e p up

T his pra ctice de scribe s ho w to m a na ge cha nge a nd k e e p cha o s a t ba y while e m bra cing ne ce ssa ry a nd im po rta nt cha nge s

Background

My wife a nd I a re curre ntly in the m iddle o f a ga rde n a nd ho use re no va tio n pro je ct W e sta rte d by writing do wn a ro ugh sk e tch o f wha t we wa nte d to ha ve do ne a

ne w de ck , a la rge ba lco nya nd so m e ro ugh ide a s fo r la ndsca ping o ur ga rde n W e discusse d the pro je ct with a fe w diffe re nt co ntra cto rs, a sk ing e a ch to co m e up with

a de sign W e pick e d o ne de sign (with a n a sso cia te d price ta g), a nd wo rk e d with tha t co ntra cto r to re fine it to o ur e x a ct re quire m e nts T he co ntra cto r wa s ve ry o pe n

to m a k ing wha te ve r cha nge s we wa nte d to e nsure tha t we wo uld be ha ppy with the e nd re sult, a nd we thre w a ro und a lo t o f ide a s, while stick ing to the o ve ra ll

a gre e d-upo n price

As the pro je ct pro gre sse d, we ra n into une x pe cte d pro ble m s W e did no t ge t a pe rm it fo r building a s la rge a ba lco ny a s we wa nte d, so we ne e de d to cha nge thepla ns a nd de sign a sm a lle r o ne T he n, o nce we cha nge d the structure o f the ba lco ny, we de cide d to a lte r slightly the dim e nsio ns a nd pla ce m e nt o f o ur de ck At a

la te r sta ge , o ur ne ighbo rs insiste d we pla nt a fe w tre e s a s a co nditio n fo r the ir a ppro va l o f the co nstructio n o f o ur ba lco ny All the se cha nge s we re re a so na ble , a sthe y did no t a lte r the funda m e nta l pa ra m e te rs o f wha t we we re trying to a chie ve , but so m e re sulte d in cha nge s tha t ne e de d to be a ppro ve d by a ll sta k e ho lde rs,tha t is the co ntra cto r, m y wife , a nd m e Fo r the se the co ntra cto r pro duce d a "cha nge o rde r," de scribing in o ne o r two se nte nce s wha t re visio ns we re be ing m a de tothe o rigina l pla n, which we a ll signe d So m e tim e s the cha nge o rde r m e a nt a re visio n to the o ve ra ll co st o f the pro je ct, so m e tim e s it did no t; but it e nsure d tha t we

a ll a gre e d o n wha t ne e de d to be cha nge d

As the co nstructio n a nd la ndsca ping pro je ct pro gre sse d, o the r, m o re m ino r issue s ne e de d to be re so lve d, such a s wha t flo we rs to pla nt, e x a ctly whe re to put pla nts,wha t type o f sta in to use o n the de ck , a nd so o n Mo st o f the se de cisio ns co uld be ha ndle d witho ut a cha nge o rde r, but fo r a ll m a jo r re visio ns we use d a cha nge

o rde r, no t o nly to m a k e sure tha t we a ll a gre e d o n the cha nge s but a lso to a llo w us to go ba ck la te r a nd unde rsta nd the e nd re sult

So m e tim e s m y wife a nd I wa nte d cha nge s tha t wo uld ha ve be e n ve ry e x pe nsive W he n we first sa w the size o f the de ck , a fte r it wa s a lm o st co m ple te d, we fe lt tha t

we ha d go ne o ve rbo a rd with the size Ma ybe we sho uld ha ve m o re gra ss, a nd le ss de ck A quick discussio n with the co ntra cto r m a de us re a lize the co st o fintro ducing such a cha nge so la te in the pro je ct W e de cide d tha t we sho uld m o ve a he a d with the pla ns a s the y we re P ro je ct m e m be rs ne e d to ha ve the guts toinfo rm a custo m e r ho ne stly o f the im pa ct o f a cha nge (se e Figure 2-4)

Figure 2.4 Some Changes Can Be Very Costly.

The Swedish navy launched a new grand royal flagship, Vasa, in 1628 The Swedish king asked the builder to add a second gun deck after the proj ect was initiated Nobody dared to tell the king about the associated risk, even though those involved knew that this change would make the ship too top-heavy to be seaworthy The Vasa sank on its maiden voyage Always remember to provide your customer with reliable information about the potential impact of a change.

Major changes can be made early in a project at a very limited cost.

R unning a pro je ct lik e the o ne a bo ve is sim ila r in m a ny wa ys to running a so ftwa re pro je ct So wha t ca n we le a rn fro m the a bo ve ?

in this pra ctice sho wing why this a sse rtio n is untrue Agile te chnique s, including the o ne s intro duce d in this bo o k , a im a t re ducing the co st o f m a k ingcha nge s, but the y will no t co m ple te ly e lim ina te the co st o f m o st cha nge s, no r will the y a llo w yo u to m a k e a ny type o f cha nge a t a ny give n sta ge in a pro je ctwitho ut po te ntia lly se rio us ne ga tive e ffe cts.

T o sa tisfy custo m e r ne e ds, yo u typica lly ne e d to intro duce a fa ir a m o unt o f cha nge to the o rigina l pla ns Y o u a lso ne e d to info rm the custo m e r fully o f the

co st a nd sche dule im plica tio ns o f ca rrying o ut cha nge s (e spe cia lly la te in the pro je ct) a nd a llo w the custo m e r to use this info rm a tio n to de te rm ine whe the rthe cha nge is re a lly ne ce ssa ry o r no t

Fo r ce rta in pro je cts, such a s tho se with a co ntra ct, a s in the co nstructio n a nd la ndsca ping e x a m ple a bo ve , yo u m a y ne e d to fo rm a lize the cha nge s; in o the r

ca se s, info rm a l discussio n with k e y sta k e -ho lde rs m a y be e no ugh In ge ne ra l, le ss fo rm a lity is ne e de d re ga rding cha nge s a t the be ginning o f a pro je ct, but

a s the pro je ct pro gre sse s, yo u sho uld do cum e nt re que ste d cha nge s with a ppro pria te fo rm a lity to e nsure tha t the ir im pa ct is pro pe rly unde rsto o d a nd a gre e d

o n by a ll sta k e ho lde rs

Applying the Practice

In this pra ctice we will wa lk thro ugh co ncre te guide line s a llo wing yo u to e m bra ce a nd m a na ge cha nge m o re e ffe ctive ly W e will first lo o k a t diffe re nt type s o f cha nge

a nd the ir a sso cia te d co st pro file a nd the n e x a m ine ho w the Unifie d P ro ce ss life cycle ca n he lp yo u to m a na ge cha nge W e will de scribe ho w to a da pt the pro ce ss o f

m a na ging cha nge to the cha ra cte ristics o f yo ur pro je ct a nd the pha se yo u a re in W e will the n re vie w so m e te chnique s to m a x im ize cha nge fre e do m , pro videguide line s fo r re ducing thra shing by m inim izing cha nge within a n ite ra tio n, a nd e x pla in ho w to incre a se pro ductivity by fix ing de fe cts a s the y a re fo und, ra the r tha n

m a inta ining a ba ck lo g o f de fe cts to be fix e d so m e tim e in the future Le t's ta k e a clo se r lo o k a t the se to pics!

Understand the Cost Profile of Different Types of Changes

Understand cost profiles to avoid costly changes at a late stage.

Diffe re nt type s o f cha nge s ha ve a diffe re nt co st ba se d o n whe n in the pro je ct the y o ccur, a nd it is im po rta nt to unde rsta nd the co st pro file s whe n prio ritizing pro je ct

wo rk to a vo id co stly cha nge s a t a la te sta ge Le t's lo o k a t so m e e x a m ple s

Major changes to the business solution Ma jo r cha nge to the busine ss so lutio n invo lve s e x te nsive re wo rk o f re quire m e nts to a ddre ss a diffe re nt se t o f use rs

o r use r ne e ds As a n e x a m ple , le t's a ssum e tha t yo u pla n to re pla ce thre e e x isting a pplica tio ns with o ne ne w a pplica tio n T he co st o f re pla cing e a ch

a pplica tio n is $25,000 If o n da y 1 o f the pro je ct yo u de cide no t to re pla ce o ne o f the a pplica tio ns, the co st is clo se to $0 If inste a d yo u m a k e tha t de cisio n

o n the la st da y o f the pro je ct, the co st is $25,000 (a ssum ing yo u ca nno t re use the co de la te r o n) T he re is thus a fa ir a m o unt o f fle x ibility in m a k ing thistype o f m o difica tio n e a rly in the pro je ct, be fo re yo u ha ve sta rte d to inve st in re quire m e nts, de sign, im ple m e nta tio n, a nd te sting o f a spe cific busine ss

so lutio n

Major changes to the architecture Ma jo r a rchite ctura l re wo rk is fre que ntly ve ry e x pe nsive whe n do ne la te in the pro je ct Ex a m ple s o f such cha nge s include

switching fro m a rich-clie nt to a thin-clie nt, m a k ing a buy-ve rsus-build de cisio n fo r a m a jo r co m po ne nt, o r cha nging stra te gy fo r re co ve ry o f a sa fe ty-critica lsyste m If yo u de cide to m a k e such a cha nge la te in the pro je ct, yo u m a y ha ve to re wo rk va st a m o unts o f co de , po te ntia lly de la ying the pro je ct It isthe re fo re im po rta nt to va lida te a rchite ctura l de cisio ns by pa rtia lly im ple m e nting the a pplica tio n e a rly o n By re a lizing e a rly wha t a rchite ctura l de cisio ns m a y

be subo ptim a l, yo u ca n m o dify the m e a rly o n a nd a vo id la te r re wo rk O the r m o difica tio ns to the a rchite cture ca n be m a de ine x pe nsive ly Fo r e x a m ple , byiso la ting pe rsiste ncy to be ha ndle d by a pe rsiste ncy la ye r in yo ur a rchite cture , yo u ca n cha nge ho w to de a l with pe rsiste ncy with m inim a l im pa ct to yo ur

a pplica tio n a t a re a so na bly la te sta ge O ne go a l o f a rchite cture s is to m inim ize the co st o f future cha nge s R e fa cto ring ca n a lso re duce the co st o f cha nge ,but it o nly go e s so fa r, a s discusse d in the se ctio n T e chnique s Ma x im izing C ha nge Fre e do m o n pa ge 68

Change to the design and implementation If yo u do co m po ne nt-ba se d de ve lo pm e nt, le ve ra ge se rvice -o rie nte d a rchite cture s, o r use o the r we ll-structure d

de sign a ppro a che s tha t lo ca lize the im pa ct o f cha nge , yo u ca n m a k e lim ite d cha nge s to yo ur de sign a nd im ple m e nta tio n a t fa irly lo w co st up until the e nd

ga m e o f the pro je ct, whe n yo u ne e d to sta bilize a nd fine -tune yo ur a pplica tio n

Reduction of scope T he co st o f cutting sco pe a nd he nce po stpo ning fe a ture s to the ne x t re le a se ca n be re la tive ly ine x pe nsive thro ugho ut the pro je ct T his

m e tho d a ssum e s tha t yo u use a n ite ra tive a ppro a ch whe re by yo u de ve lo p the m o st e sse ntia l ca pa bilitie s first, a nd tha t yo u cut sco pe by de -sco ping the

le a st e sse ntia l ca pa bilitie s first P ro je ct te a m s sho uld use de -sco ping a s a k e y to o l to e nsure o n-tim e pro je ct de live ry o f the m o st e sse ntia l ca pa bilitie s

Fo cusing e a rly ite ra tio ns o n building the pro to type s, de ve lo ping a nd te sting k e y ca pa bilitie s, a nd a chie ving clo se co lla bo ra tio n with sta k e ho lde rs will re duce thelik e liho o d o f co stly shifts in dire ctio n la te in the pro je ct

Focusing early iterations on prototypes and collaboration with stakeholders will reduce the likelihood of costly shifts late in the project.

The Unified Process Lifecycle and Change

T he pha se s in the Unifie d P ro ce ss life cycle a re de signe d to fo rce the co stly cha nge s discusse d in the pre vio us se ctio n to o ccur e a rly (se e Figure 2.5), while a llo wing

yo u to m a k e critica l de cisio ns a s la te a s sa fe ly po ssible , a s discusse d in the se ctio n T e chnique s Ma x im izing C ha nge Fre e do m

Figure 2.5 Phases Are Optimized to Minimize Overall Cost of Change.

The cost of introducing a change varies according to the lifecycle phase, and each type of change has its own cost profile The Unified Process lifecycle is optimized

to minimize overall cost of change, while maximizing the freedom to make changes In general, as the proj ect progresses, you should be more careful about

introducing change, especially to the overall business solution and the architecture.

T he Inception pha se a im s to drive o ut risk s a sso cia te d with m a jo r cha nge s to the busine ss so lutio n Its purpo se is not to fo rce de ta ile d spe cifica tio n o r

pre ve nt la te r cha nge s to re quire m e nts