DAVID STOTTS DEPT. OF COMPUTER SCIENCE UNIV. OF NORTH CAROLINA AT CHAPEL HILL Extreme Programming.

14
DAVID STOTTS DEPT. OF COMPUTER SCIENCE UNIV. OF NORTH CAROLINA AT CHAPEL HILL Extreme Programming

Transcript of DAVID STOTTS DEPT. OF COMPUTER SCIENCE UNIV. OF NORTH CAROLINA AT CHAPEL HILL Extreme Programming.

Page 1: DAVID STOTTS DEPT. OF COMPUTER SCIENCE UNIV. OF NORTH CAROLINA AT CHAPEL HILL Extreme Programming.

DAVID STOTTS

DEPT. OF COMPUTER SCIENCEUNIV. OF NORTH CAROLINA AT CHAPEL HILL

Extreme Programming

Page 2: DAVID STOTTS DEPT. OF COMPUTER SCIENCE UNIV. OF NORTH CAROLINA AT CHAPEL HILL Extreme Programming.

In Reaction to…

“Big Process”

SEI Capability Maturity Model (CMM)

“Heavy” development practices

Hard to steer, unresponsive

Can we do better for smaller efforts?

Page 3: DAVID STOTTS DEPT. OF COMPUTER SCIENCE UNIV. OF NORTH CAROLINA AT CHAPEL HILL Extreme Programming.

Extreme Programming

Kent Beck, late 90’s

One of several “Agile” processes

Small teams (2 to 8 people)

Modest projects

Emphasis on customer as project driver

Page 4: DAVID STOTTS DEPT. OF COMPUTER SCIENCE UNIV. OF NORTH CAROLINA AT CHAPEL HILL Extreme Programming.

“Change Happens”

Embrace change as normal

Not an aberration whose cause needs to be found

Process must be lightweight and agile to respond to change

“Steer”able

Page 5: DAVID STOTTS DEPT. OF COMPUTER SCIENCE UNIV. OF NORTH CAROLINA AT CHAPEL HILL Extreme Programming.

XP Core Values

CommunicationSimplicityFeedbackCourage (fearlessness)

Page 6: DAVID STOTTS DEPT. OF COMPUTER SCIENCE UNIV. OF NORTH CAROLINA AT CHAPEL HILL Extreme Programming.

XP Practices

Pair programmingTest-first developmentSimple design: Add no function

before its timeRe-factoringThe planning gameUser/client on-site

Page 7: DAVID STOTTS DEPT. OF COMPUTER SCIENCE UNIV. OF NORTH CAROLINA AT CHAPEL HILL Extreme Programming.

XP Practices

Small releasesContinuous integrationCollective code ownershipCoding standards (and self-

documenting code)No overtimeSystem metaphor

Page 8: DAVID STOTTS DEPT. OF COMPUTER SCIENCE UNIV. OF NORTH CAROLINA AT CHAPEL HILL Extreme Programming.

Why Agile Methods?

Why is change inevitable?People…People are noisy and unpredictableProcess involving people needs

small steps, constant measurement to be steerable

Page 9: DAVID STOTTS DEPT. OF COMPUTER SCIENCE UNIV. OF NORTH CAROLINA AT CHAPEL HILL Extreme Programming.

eXtreme Programming

Try it …

Further reading: “XP” by J. Highsmith

Page 10: DAVID STOTTS DEPT. OF COMPUTER SCIENCE UNIV. OF NORTH CAROLINA AT CHAPEL HILL Extreme Programming.

Test-first development

If a class does not have automatic tests, you must assume it does not work

Regression testing … tests retain value

JUnit (Beck & Gamma): industrial-strength regression testing for the common man

Page 11: DAVID STOTTS DEPT. OF COMPUTER SCIENCE UNIV. OF NORTH CAROLINA AT CHAPEL HILL Extreme Programming.

JUnit

Small, easy to learn, easy to use, effective

Java classes

TestCase, Suite, runners

15 other language implementations

http://www.junit.orghttp://www.xprogramming.com/software.htm

Page 12: DAVID STOTTS DEPT. OF COMPUTER SCIENCE UNIV. OF NORTH CAROLINA AT CHAPEL HILL Extreme Programming.

JUnit Test Class

One test method per target method

“test anything that can break” …

“don’t test anything that can’t”

Can we give better guidance?

Can we systematically produce consistent and complete test classes?

Page 13: DAVID STOTTS DEPT. OF COMPUTER SCIENCE UNIV. OF NORTH CAROLINA AT CHAPEL HILL Extreme Programming.

The Planning Game

Informal brainstorming… few hours to a few days

Customer talks about what he/she wants

Engineers listen, ask questions, make “user stories”

Each story is a card, a few sentences, describes some function of the system

Page 14: DAVID STOTTS DEPT. OF COMPUTER SCIENCE UNIV. OF NORTH CAROLINA AT CHAPEL HILL Extreme Programming.

The Planning Game

Engineers “cost” each story

Customer “values” each story

Rank order of cards

Customer selects top 4 or 5 items…

Engineers produce Release One