Outline. Agile Methods. Converse of Conway s Law. The Silver Bullet Fantasy (Brooks, 1986)

(1)

Barry Boehm, USC

CS 510 Lecture

Fall 2001

([email protected]) (http://sunset.usc.edu)

Agile Methods

©USC-CSE 2

Outline

• Silver bullets and lead bullets

• Information technology trends

–

The dwindling lead-bullet niche

–

Underlying world-view trends

• Agile methods

–

Example: eXtreme Programming (XP)

–

Counterpoint: A skeptical view

• Relations to CMM and CMMI

–

How much planning is enough?

©USC-CSE 3

University of Southern California Center for Software Engineering

C S E

USC

• Even if we can’t define what the “software problem” werewolf is,

• And we’ve seen that lead, bronze, iron, and steel bullets can’t kill it,

• We’re sure there’s a silver bullet that can

******

• Fallacy: We canfix things we understand

– “Accidental” software problems

• But we can’tfix things we don’t understand

– “Essential” software problems

The Silver Bullet Fantasy

(Brooks, 1986)

©USC-CSE 4

C S E

USC

Example: Conway’s Law and its Converse

• Conway’s Law (Datamation, 1968), extended

The structure of a computer program ...

C S E

USC

Example: Conway’s Law and its Converse

• Conway’s Law (Datamation, 1968), extended

The structure of a computer program ...

reflects the structure of the organizations that build and use it

C S E

USC

Converse of Conway’s Law

• We will learn how to build perfectly

functioning software

(2)

©USC-CSE 7

Converse of Conway’s Law

• We will learn how to build perfectly

functioning software

• As soon as we learn how to build

perfectly functioning organizations

©USC-CSE 8

The Lead Bullet Expectation

• If a lead bullet can kill a software-problem wolf this year,

• It will be able to do it next year too

• Counterexamples

–Waterfall model of the software process

–Pre-WYSIWYG word processing architecture

–Pre-Web book sales management applications

• Key drivers: technology, economics,

humanization

©USC-CSE 9

C S E

USC

Information Technology Trends

Traditional Development

• Standalone systems

• Stable requirements

• Rqts. determine capabilities

• Control over evolution

• Enough time to keep stable

• Value-insensitive process models

Current/Future Trends

• Everything connected

• Rapid requirements change

• COTS capabilities determine rqts.

• No control over COTS evolution

• Ever-decreasing cycle times

• Value-oriented process models

©USC-CSE 10

C S E

USC

Lead Bullets with Dwindling Niches

• Complete, consistent, traceable, testable

snapshot requirements

• Static domain architectures and enterprise

architectures

• Heavyweight formal methods

• Fixed contract models of software

management

• COTS- and value-insensitive

object-oriented methods

©USC-CSE 11

C S E

USC

Core Niches for Current Lead Bullets

- Still very important

• High-assurance,

• Real-time,

• Autonomous control systems

©USC-CSE 12

C S E

USC

Underlying World-View Trends

• Universalism → Situationalism

–Stephen Toulmin, Cosmopolis, U. Chicago Press, 1990

• Reductionism →Emergence

–Stuart Kauffman, At Home in the Universe, Oxford U. Press, 1995.

–W. Brian Arthur, “Increasing Returns and the New World of Business,” Harvard Business Review, Jul/Aug 1996, pp. 100-109.

–James Highsmith, Adaptive Software Development, Dorset House, 1999.

• Software Focus →System Focus

(3)

©USC-CSE 13

Cosmopolis: The Erosion of Modernist Philosophy

• Dominant since 17th_century

• Formal, reductionist

–Apply laws of cosmos to human polis

• Focus on written vs. oral; universal vs. particular; general vs. local; timeless vs. timely

–one-size-fits-all (lead bullet) solutions

• Strong influence on focus of computer science

• Weak in dealing with human behavior, rapid

change

©USC-CSE 14

Reductionism vs. Emergence

• Order is not imposed on complex adaptive

systems; it emerges (Kauffman)

• Knowledge-based industries have increasing

vs. decreasing returns (Arthur)

–Network effects, up-front costs, customer groove-in

–Adaptation succeeds better than optimization • Adaptive model best fits future software

projects (Highsmith)

–Balance of discipline and flexibility

©USC-CSE 15

C S E

USC

Outline

• Silver bullets and lead bullets

• Information technology trends

–

The dwindling lead-bullet niche

–

Underlying world-view trends

• Agile methods

–

Example: eXtreme Programming (XP)

–

Counterpoint: A skeptical view

• Relations to CMM and CMMI

–

How much planning is enough?

©USC-CSE 16

C S E

USC

The Agile Manifesto - I

• Individuals and interactionsover processes and tools • Working softwareover comprehensive documentation • Customer collaborationover contract negotiation • Responding to changeover following a plan

We are uncovering better ways of developing software by doing it and helping others do it.

Through this work we have come to value:

That is, while there is value in the items on the right, we value the items on the left more.

C S E

USC

The Agile Manifesto – II

• Our highest priority is to satisfy the customer

through early and continuous delivery of valuable software.

• Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.

• Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

• Business people and developers must work together daily throughout the project.

C S E

USC

The Agile Manifesto – III

• Build projects around motivated individuals. Give

them the environment and support they need, and trust them to get the job done.

• The most efficient and effective method of conveying information to and within a

development team is face-to-face conversation.

• Working software is the primary measure of progress.

• Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

(4)

©USC-CSE 19

The Agile Manifesto – IV

• Continuous attention to technical excellence and

good design enhances agility.

• Simplicity – the art of maximizing the amount of work not done – is essential.

• The best architectures, requirements, and designs emerge from self-organizing teams.

• At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

©USC-CSE 20

Various Agile Methods Available

• Adaptive Software Development (ASD)

• Agile Modeling

• Crystal methods

• Dynamic System Development

Methodology (DSDM)

* eXtreme Programming (XP)

• Feature Driven Development

• Lean Development

• Scrum

©USC-CSE 21

C S E USC

eXtreme Programming (XP)

• Principles

• The 12 Practices

• Early Adopters

©USC-CSE 22

C S E

USC

XP Principles – I

• Philosophy: Take known good practices

and push them to extremes

• “If code reviews are good, we’ll review

code all the time”

• “If testing is good, we’ll test all the time”

• “If design is good, we’ll make it part of

everybody’s daily business”

©USC-CSE 23

C S E

USC

XP Principles – II

• “If simplicity is good, we’ll always leave

the system with the simplest design that

supports its current functionality”

• “If architecture is important, everybody

will work defining and refining the

architecture all the time”

• “If integration testing is important, then

we’ll integrate and test several times a

day”

©USC-CSE 24

C S E

USC

XP Principles – III

• “If short iterations are good, we’ll

make the iterations really, really short

– seconds and minutes and hours, not

weeks and months and years”

• “If customer involvement is good,

we’ll make them full-time participants”

(5)

©USC-CSE 25

XP: The 12 Practices

• The Planning Game

• Small Releases

• Metaphor

• Simple Design

• Testing

• Refactoring

• Pair Programming

• Collective Ownership

• Continuous Integration

• 40-hour Week

• On-site Customer

• Coding Standards

-Used generatively, not imperatively

©USC-CSE 26

The Planning Game

• Use stories to facilitate knowledge

transfer

• Put decisions in the hands of the person

with the best knowledge:

–

business decisions Customer

–

software decisions Developer

• Plan only as far as your knowledge

allows

–

next iteration or next release

©USC-CSE 27

C S E

USC

Small Releases

• Supports quick feedback from users

• Simplify the tracking of metrics

–

stories per iteration project velocity

• Increase the manageability of the

project for the customer

–

But complicate user conservation of

familiarity

©USC-CSE 28

C S E

USC

Metaphor

• Ground all discussions in a single

shared story of how the whole system

works

• Provide an overarching view of the

project

• Connect program to work process

C S E

USC

Simple Design

• Design Embodies only the needed

complexity and no more

–emphasis on top-down or bottom-up design as needed to meet this iteration’s stories

–extra complexity removed when discovered

• Simpler designs are easier to modify,

maintain, and describe

–decreases the cost of design changes

–But no notion of product line architecture

C S E

USC

Testing

• Unit tests verify the programmer’s work

–

must be done by programmer

–

constant testing makes finding new bugs

faster and easier

• Functional tests verify that a story is

complete

–

developed by customer

(6)

©USC-CSE 31

Refactoring

• Procedure for implementing iterative

design

–behavior-preserving

–improves communication among developers

–adds flexibility to the programming process

• Design is important – do it all the time

–software development process is a design process

–But redesign much more expensive for large systems

©USC-CSE 32

Pair Programming

• All code is written by two

programmers at a single machine

• Inspections are important, so do them

all the time

• Increase implicit knowledge transfer

• Decrease cycle time, but increase

effort

©USC-CSE 33

C S E

USC

Collective Ownership

• Everyone owns all of the code

–anyone can change any code anywhere

–no personal ownership of modules

–no egoless programming either

• Everyone is permitted access to all the

code so everyone has a stake in knowing

all of the code (that they will work with)

• Requires deserved trust

–But still has scalability problems

C S E

USC

Continuous Integration

• The system always works

–

there is always something to be released

• Similar to rapid releases

–

fast feedback to developers on problems

–

no ‘big bang’ integration disasters

C S E

USC

40-hour Week

• No heroes

• Knowledge can only be transferred at

a limited rate

• Work for sustained speed, not a

single sprint

–

never work overtime a second week in a

row

C S E

USC

On-site Customer

• A real, live user available full-time to

answer questions as they occur

• Programmers don’t know everything

• Business knowledge is the key to a

successful business project

(7)

Coding Standards

• Communication occurs through the

code

• Common standard promotes

understanding of other developers’

code

• Helps promote team focus

Counterpoint: A Skeptical View – I

Letter to Computer, Steven Rakitin, Dec. 2000 “individuals and interactions over processes and tools”

Translation: Talking to people gives us the flexibility to do whatever we want in whatever way we want to do it. Of course, it’s understood that we know what you want - even if you don't.

“working software over comprehensive documentation”

Translation: We want to spend all our time coding. Real programmers don’t write documentation.

C S E

USC

Counterpoint: A Skeptical View – II

Letter to Computer, Steven Rakitin, Dec. 2000 “customer collaboration over contract negotiation”

Translation: Let's not spend time haggling over the details, it only interferes with our ability to spend all our time coding. We’ll work out the kinks once we deliver something...

“responding to change over following a plan”

Translation: Following a plan implies we would have to spend time thinking about the problem and how we might actually solve it. Why would we want to do that when we could be coding?

C S E

USC

Outline

• Silver bullets and lead bullets

• Information technology trends

–The dwindling lead-bullet niche

–Underlying world-view trends

• Agile methods

–Example: eXtreme Programming (XP)

–Counterpoint: A skeptical view

• Relations to Software CMM and CMMI

–The planning spectrum

–Agile and Plan-Driven home grounds

–How much planning is enough?

C S E

USC

The Planning Spectrum

Hackers XP Adaptive Sw Devel. Milestone Risk- Driven Models … … Milestone Plan-Driven Models Inch- Pebble Ironbound Contract Software CMM Agile Methods CMMI

C S E

USC

Agile and Plan-Driven Home Grounds

• Plan-oriented developers;

mix of skills

• Mix of customer capability levels

• requirements knowable early; largely stable • Architected for current and

foreseeable requirements • Refactoring expensive • Larger teams, products • Premium on high-assurance • Agile, knowledgeable, collaborative developers • Dedicated, knowledgeable, collaborative, representative, empowered customers • Largely emergent requirements,

rapid change • Architected for current

requirements

• Refactoring inexpensive • Smaller teams, products • Premium on rapid value

(8)

How Much Planning Is Enough?

- A risk analysis approach

• **Risk Exposure RE = Prob (Loss) * Size**

(Loss)

–“Loss” – financial; reputation; future prospects, …

• For multiple sources of loss:

sources

RE =

Σ

**[Prob (Loss) * Size (Loss)]**

_source

Example RE Profile: Planning Detail

- Loss due to inadequate plans

Time and Effort Invested in plans RE =

P(L) * S(L)

high P(L): inadequate plans high S(L): major problems

(oversights, delays, rework)

low P(L): thorough plans low S(L): minor problems

C S E

USC

Example RE Profile: Planning Detail

-

Loss due to inadequate plans

- Loss due to market share erosion

Time and Effort Invested in Plans RE =

P(L) * S(L)

low P(L): few plan delays low S(L): early value capture

high P(L): plan breakage, delay high S(L): value capture delays high P(L): inadequate plans

high S(L): major problems (oversights, delays, rework))

C S E

USC

Example RE Profile: Time to Ship

- Sum of Risk Exposures

Time and Effort Invested in Plans

RE = P(L) * S(L)

low P(L): few plan delays low S(L): early value capture

high P(L): plan breakage, delay high S(L): value capture delays Sweet Spot

high P(L): inadequate plans high S(L): major problems

(oversights, delays, rework)

C S E

USC

Comparative RE Profile:

Plan-Driven Home Ground

Time and Effort Invested in Plans RE = P(L) * S(L) Mainstream Sweet Spot Higher S(L): large system rework

Plan-Driven Sweet Spot

C S E

USC

Comparative RE Profile:

Agile Home Ground

Time and Effort Invested in Plans RE = P(L) * S(L) Mainstream Sweet Spot Lower S(L): easy rework Agile Sweet Spot