Selecting a Development Process

Mike CohnMountain Goat Software

[email protected]

Selecting a Development Process:

Choosing Among theLeading Alternatives

1

Founding member and director of Agile Alliance, Scrum Alliance, and Agile Project Leadership Network

Founder of Mountain Goat Software

Consultant, author, and speaker

Mike Cohn - background

© Mountain Goat Software, LLC

2


ConsiderationsTeam Software ProcessScrumExtreme ProgrammingOpenUP/BasicFeature-Driven Development

Today’s agenda

3


CeremonyThe amount of formalism in a process

Documentation, method weight, reviews

Few documentsFew steps

Many documentsFormal steps

4


CyclesNumber and length of iterations



Sequential

Many short iterations(5 days)

5


Placing the processes



Sequential

Many short iterations(5 days)

Extreme Programming

Scrum

Team Software Process

OpenUP

6



Today’s agenda

7


Team Software Process (TSP)Created by Watts Humphrey

Of Software Engineering Institute and Capability Maturity Model (CMM)

Builds on his Personal Software Process

A “cyclic development strategy”

Another way of saying “iterative and incremental”

8


Goals of the TSP1. Build on the Personal Software Process2. Develop products in cycles3. Establish standard measures for quality and

performance4. Provide precise measures5. Use role and team evaluations6. Require process discipline7. Provide guidance on teamwork problems

9


Team Software Process (TSP)

Strategy 1Plan 1

Requirements 1Design 1

Implementation 1Test 1

Postmortem 1

Cycle 1 Launch

Strategy 2Plan 2



Postmortem 2

Cycle 2 Launch

Strategy 3Plan 3



Postmortem 3

Cycle 3 Launch

10


Cyclic developmentA testable version is produced at the end of each cycle

it

Defects should be removed during the cycle

11


Designed to solve team problems

Tom DeMarco

“The success or failure of a project is seldom due to

‘has the state of the art advanced far enough so that this program can be written?’ Of course it has. If the project goes down the tubes, it will be non-technical, human interaction problems that do it in. The team will fail to bond, or the developers will fail to gain

interminably over meaningless methodological issues.”

12


Teams, members, roles and goals

A team has one or more members

Goals are assigned throughout this hierarchy

Team, member, role

Team leader Quality/process manager

Development manager

Planning manager

Support manager

13


Goals and goals and...Team goals

Produce a quality productRun a productive and well-managed projectFinish on time

Team member goals

Be a cooperative and effective team memberDo consistently disciplined personal workPlan and track all your personal workProduce quality products

14


...more goals

Dev manager goals

Produce a superior productFully use the team members’ skills and abilities

Some of these goals point out some underlying beliefs of TSP, such as:

You can’t control what you can’t measureManagers “use the team members’ skills”

15


Scripts and forms

a software system

21 activity scripts

10 role scripts

Often quite detailed

Scripts prescribe completing 21 supporting forms

16


The inspection scriptPurpose To help engineers produce quality products

Entry criteria aA completed and reviewed product with available materials

Step Activities Description

1Plan the inspection

The developerArranges with the quality/process manager or

moderatorHandles the mechanics of setting up and running…

2Hold the inspection

The moderator describes the inspection processThe producer familiar the inspection team with the product.

... ... ...

Exit c criteria

17


Choose TSP if...…you have the discipline to follow all of its

…are already using the complementary Personal Software Process (PSP)

…team members need this level of guidance

…you do not have emergent requirements

18



Today’s agenda

19


Scrum characteristics30-day iterations called “sprints”

Self-organizing teams

But many Scrum teams are adopting much of XP

Uses generative rules to create an agile environment for delivering projects

20


Scrum roles

Not quite the project managerRemoves impedimentsEnforces Scrum values

ScrumMaster

Scrum team7–9 full-time individualsSelf-organizingIdeally full-time on project

Product ownerCustomer or user of the projectMakes prioritization decisions

21


Scrum

Cancel

Gift wrap

Return

Sprint2-4 weeks

Return

Sprint goal

Sprint backlog

Potentially shippableproduct increment

Productbacklog

CouponsGift wrap

Coupons

Cancel

24 hours

22


Scrum roles and responsibilities

Prioritizes features according to market valueCan change features and priority every sprintAccepts or rejects work results

ProductOwner

Ensures that the team is fully functional and productiveEnables close cooperation across all roles and functions and removes barriersShields the team from external interferencesEnsures that the process is followed.

ScrumMaster

Cross-functional, seven plus/minus two membersSelects the sprint backlogHas the right to do everything within the boundaries of the project guidelines to reach the sprint goalOrganizes itself and its workDemos work results to the Product OwnerTeam

23


Scrum meetingsSprint

planning

Team selects product backlog items to complete during sprint

Daily scrumWhat did you do yesterday?What will you do today?What’s in your way?

Team demonstrates working software built in the sprintSprint review

Sprint retrospective ways to improve

24


Scrum of scrums of scrums

25


A sprint burndown chart

0

200

400

600

800

1,0004/

29/0

2

5/6/

02

5/13

/02

5/20

/02

5/24

/02

26


Choose Scrum if...…requirements are changing or emergent

…you’re willing to let the team self-organize

…you need a management framework more than a set of engineering practices

…you want to better manage risk

…you need a proven, scalable agile process

27



Today’s agenda

28


Extreme Programming

project management approach

A tough target to hit but highly productive if you do

29


XP’s customer practices

On-site customer

Small releases

30


XP’s quality practices

Metaphor

Testing

Simple design

Refactoring

Pair programming

31


XP’s quality practices

The Planning Game

Sustainable pace

Collective ownership

Coding standards

Continuous integration

32


Choose Extreme Programming if...

requirements

…you have or can develop strong engineering skills and practices

…customers can be involved on a daily (hourly) basis

…it’s important you hit the bull’s eye right off and you think you can

33



Today’s agenda

34


OpenUP/Basic

Delivered through the Eclipse Process Framework

Targeted at teams of 3-6 people

Targeted at projects 3-6 months long

35


Comparison with RUP

OpenUP/Basic RUP

Pages 190 ~2000

Roles 6 ~45

Tasks 23 ~150

Artifacts 17 ~80

Source: What is the Eclipse Process Framework, Per Kroll and Scott Ambler, IBM Rational Software Development Conference 2006.

36


OpenUP rolesAnalyst

Architect

Developer

Tester

Project manager

37


Roles, tasks, and artifacts

Plan theproject

Assessresults

Prioritizework

Monitorandcontrolproject

InitiateIteration

PlanIteration

Projectmanager

Performs

Projectplan

Statusassessment

Iterationplan

Workitems list

Responsible for

38


Open UP phases

Establish scope and produce business caseMitigate business risksGet buy-in and decision to undertake project

Inception

Reduce major risks to enable cost and schedule estimatesMitigate major technical risksImplement a baseline architectureImplement key capabilities

Elaboration

39


Majority of implementationEnds with deployment of a beta version

Construction

Ensure software meets users’ needsPrepare for releaseSolicit user feedback and make minor adjustments

Transition

40


Iterate within each phase

Inception

Prel

imin

ary

itera

tion(

s)

Elaboration

Iter

atio

n #

1

Iter

atio

n #

2

Iter

atio

n #

n

Iter

atio

n #

n+1

Construction

Iter

atio

n #

n+2

Transition

Iter

atio

n #

m

Iter

atio

n #

m

41


Choose OpenUP/Basic if...You like RUP but want something lighter

You want an open source version of RUP

You have a small project (3-6 people; 3-6 months)

You want a semi-agile process based on role, task and artifact guidance

42



Today’s agenda

43


Feature-Driven Development Originates in Java Modeling in Color with UML by Coad, Lefebvre and De Luca in 1999

Jeff DeLuca is main advocate

A Practical Guide to Feature-Driven Development by Palmer and Felsing in 2002

44


Features and feature setsFeatures

Serve as primary unit of work

Similar to XP stories or Scrum backlog items

Small enough to do in two weeks

Feature SetCollection of features

Assigned to a Chief Programmer and her team

Major Feature SetA domain area, one or more Feature Sets

45


Example featuresA short description of an action of value to users of the system

Format<action> the <result> <by|for|of|to> a(n) <object>

Estimate the closing price of a stockCalculate the total cost of an orderChange the password for a userRetrieve the room number of a guest

Examples

46


Five processes

Developan overall

model

Build a features

list

Plan by feature

Design by feature

Build by feature

Sequential Iterative

47


Sample development planMajor feature

set Feature set Feature Chief programmer Date

Interfacing ReservationsMake a reservation for a guest

Chris December

Interfacing ReservationsCancel a reservation for a guest

Chris December

Interfacing ReservationsUpdate a reservation for a guest

Chris January

Reporting Future reservations

View future reservations of competitors

James December

Reporting Rates View internet rates for a hotel Kristy February

48


Eight best practices

Feature teams

Domain object

modeling

Regular progress

Regular builds

Individual class

ownership management

InspectionsDeveloping by feature

Need all eight to be doing FDD

49


Tracking progress

Reservations(3)

65%

December

Chris Chiefprogrammer

Feature set nameNumber of

features in set

Percentage complete

Target completionmonth

Work in progress

Completed

Attention

Not started

50


Choose FDD if...…you are willing to trade some agility for a

…your organization has solid UML skills

…most requirements are knowable in advance or somewhat stable

…you do not view self-organizing teams as a critical success factor

51


Where to go nextTeam Software

Process

Scrum

Extreme Programming

Introduction to the Team Software Process by Watts S. Humphrey

www.mountaingoatsoftware.com/scrumAgile Software Development with Scrum by Ken Schwaber and Mike BeedleAgile Project Management with Scrum by Ken Schwaber

www.xprogramming.comc2.com/cgi/[email protected]

52


Where to go next

OpenUP

FDD

Agile in Generalwww.agilealliance.orgwww.mountaingoatsoftware.com

www.featuredrivendevelopment.com

www.eclipse.org/epfAgility and Discipline Made Easy by Per Kroll and Bruce MacIsaac

53


Upcoming public classesDate What Where

Oct 18-19 Denver

Oct 23-24Oct 25 Agile Estimating and Planning San Diego

Jan 15-16Jan 17 Agile Estimating and Planning Atlanta

Feb 26-27Feb 28 Agile Estimating and Planning

Santa Clara

Other classes s in London and Oslo if you’re up for a longer trip.

More info atwww.mountaingoatsoftware.com

54


[email protected]

www.mountaingoatsoftware.com

(303) 810-2190 (mobile)

Mike Cohn contact info

55

Business

Selecting a Development Process