Extreme Programming

C Sc 335November, 28 2005

2

Overview

Essence of Extreme Programming (XP)– Variables– Values– Principles– Practices

3

Waterfall Model

Waterfall was described by 1970 by W. W. RoyceUnderstood as– finish each phase– don’t proceed till done

Royce criticized this– proposed an iterative approach

4

Became Popular

Management liked phases to easily set deadlinesCustomers provide all requirements Analysts translate requirements into specificationCoders implement the specification Reviews ensure the specification is met Testing is performed by others (QA)Maintenance means modifying as little as possible – old code is good code

Change is hard (and costly)

5

Cost of change

Costof

change

time

Waterfall

XP

6

Sprial

Dr Barry Boehm proposed a spiral approach

7

Waterfall

It became popular– This process is still is used a lot

Craig Larman's book [1] provides proof that waterfall has proved to be a terrible way to develop software. – In his study, 87% of all projects failed. – The waterfall process was the "single largest contributing factor

for failure, being cited in 82% of the projects as the number one problem."

[1] Agile and Iterative Development: a Manager's Guide, Addison-Wesley Professional, 2003

8

Extreme Programming (XP)

Almost ten years of growthSet of SE practices that produce high-quality

software with limited effortMany books, first by Kent Beck:

Extreme Programming–Embrace Change, Addison-Wesley, 2000, ISBN 0-201-61641-6

http://www.extremeprogramming.org/

9

Extreme Programming

XP is – a disciplined approach to software development– code centric: no reckless coding, test-first– successful because it emphasizes customer

involvement and promotes team work– not a solution looking for a problem– One of several "agile" (can adapt to change)

software development processeshttp://www.agilealliance.org/

10

Fundamentals of XP

Distinguishes between decisions made by business stakeholders and developers– Both are good at their own thing things

Simplistic – keep design as simple as possible“design for today not for tomorrow”

Write automated test code before writing production code and keep all tests running (continually integrate)Pair programmingShort iterations with fast delivery

11

Management summary

Light-weight software development process– Replaces documentation with communication– Focuses on source code and testing

Controversial – “Hacking”?– 30-70% productivity improvement

Developed by industry practitioners– “..proven at cost conscious companies like Bayerische

Landesbank, Credit Swiss Life, DaimlerChrysler, First Union National Bank, Ford Motor Company and UBS.” XP Web Site

12

Essence of XP

Four variables in software development: – Cost, Time, Quality, Scope (# features)

Four Values– Communication, Simplicity, Feedback, and Courage

Five Principles– Provide feedback, assume simplicity, make incremental

changes, embrace change, quality work12 Practices (or fewer)– Planning game, small releases, simple designs, automated testing,

continuous integration, refactoring, pair programming, collective ownership, 40-hour week, on-site customer, coding standard, metaphor

13

Overview

Essence of Extreme Programming (XP)– Variables– Values– Principles– Practices

14

Managing Variables

Managers: "You are going to get all of these requirements done by THE DATE"When this is the only consideration– "… quality goes out the window … Also likely to go

out of control is time. You get crappy software late.", from Extreme Programming Explained, Kent Beck

15

Four Variables: Cost

Increase cost and you can do a bit morePouring money into a project won't solve the problem– "I've been on two infinitely funded projects and both

were utter disasters. Money does corrupt."

Reduce the budget for the project– won't be able to solve the customer's problem

16

Four Variables: Time

Increase time and you improve quality and scope (more features)Too much time can hurt With too little time, quality suffers– and scope, time, and cost not far behind

17

Four Variables: Quality

Quality is a terrible control variable– Can make progress by sacrificing quality (write code

solo or without tests) – But to cost--human, business, and technical-- can be

enormous

18

Four Variables: Scope

Scope is the primary control – If you reduce scope (fewer features), you can

increase quality, reduce time and cost– You can deliver the most important features

sooner and cheaper

19

The Values

Essence of Extreme Programming (XP)– Variables– Values– Principles– Practices

20

Four Values: Communication

Communication– Customer centric

• Write "Stories", always available– Pair programming– Task estimation– Iteration planning– Design sessions

The Agile Manifesto

21

Four Values: Simplicity

Simplicity– Choose the simplest thing that will work– Choose the simplest design, technology,

algorithm, technique

22

Four Values: Feedback

Feedback very important

– Small Iterations– Frequent deliveries– Pair programming– Constant code review – Continuous integration (add often to the build)– automated unit tests (JUnit, for example)

23

The Principles

Essence of Extreme Programming (XP)– Variables– Values– Principles– Practices

24

Five Principles: Rapid Feedback

Rapid Feedback– (From psychology) The time between an action and

its feedback is critical to learning– In an XP project, developers provide and get

feedback as soon as possible, interpret it, and put what is learned into the system

25

Feedback

Compiler feedback: secondsPair programming feedback: half minutesUnit test feedback: few minutesAcceptance testing: half hours– Customer write these system level tests

• The developers need adapters (test fixtures) to make these pass

Customer feedback: dailyIteration feedback: weekly– Feedback: Priceless

26

Four Values: Courage

Courage– Courage to refactor– Estimate: On a scale of 1 to 5, we can do that in 2– Throw away bad code – Iteration planning– Automated testing breeds courage to change code

27

Five Principles: Assume Simplicity

Assume Simplicity– Only design for current iteration

• this is not the same as skipping design• this is counterintuitive to most developers

– Can save time on 98% of the problem and devote that time to the really difficult 2%, Beck

– Plan for changes and design the system to handle change

– Do a quality job (tests, refactoring, communication) and trust you can add complexity later

28

Five Principles: Incremental Change

Incremental Change– Problems are solved with a series of the smallest

changes that make a difference– In XP, design changes a little at a time, the plan

changes a little at a time, the team changes a little at a time

– and adoption of XP must be taken in little steps

29

Five Principles: Embracing Change

Embracing Change– Preserve the most options while solving the most

pressing problems

30

Five Principles: Quality Work

Quality work– People like to do a good job– Quality should be either excellent or extremely

excellent (lives at stake)– Without quality

• you don't enjoy work• you don't work well• the project goes down the drain

31

12 Practices: On-site customer

Many software projects fail because they do not deliver software that meets business needsReal customer has to be part of the team– Defines business needs– Answers questions and resolves issues– Prioritizes features

32

The Practices

Essence of Extreme Programming (XP)– Variables– Values– Principles– Practices

33

12 Practices: Planning Game

The planning game involves story cards, which are short descriptions of a feature– Provide value to customer– Independent of each other– Testable

Customer writes story cards and prioritizes themDevelopers estimate how long a story takes

34

12 Practices: The planning game

Business decisions (customer)– Scope: which “stories” should be developed– Priority of stories (features)– Release dates

Technical decisions (developers)– Time estimates for features/stories– Elaborate consequences of business decisions– Team organization and process– Scheduling

35

12 Practices: Estimation

Based on similar stories from the past (“yesterday’s weather”)Team effortGet good at estimation simply by doing itIdeal Engineering Time (IET)– could be points

Velocity = IET/Calendar Time– we can do 20 points each week– "Customer, which 20 points do you want next week?"

36

12 Practices: Small Releases

Releases should be as small as possibleShould make sense as a wholePut system into production ASAP– Fast feedback

Deliver valuable features firstShort cycle time– Planning 1-2 months rather than 6-12 months

37

12 Practices: Simple design

The “right” design– Runs all tests– No code duplication, No code duplication– Fewest possible classes – Short methods– Fulfills all current business requirements

Design for today not the future– But design so the system can change

38

12 Practices: Metaphor

How does the whole system work?What is the overall idea of the system?This is the least favorite or least misunderstood practice

39

12 Practices: Testing

Software should be tested, but it is often spotty or overlookedAutomatic testing (JUnit, for example) help us know that a feature works and it will work after refactoring, additional code, and other changesProvides confidence in the program

40

Testing

Write tests at the same time as production code– Unit tests developer– Feature/acceptance tests customer

Don't need a test for every methodTesting can be used to drive development and design of codeAllows for regression testing– Do changes break previously working code

41

SIM/SQS http://www.simgroup.com/Consultancy/regression.html

Regression Testing – re-testing of a previously tested program following

modification to ensure that faults have not been introduced or uncovered as a result of changes.

– Regression tests are designed for repeatability, and are often used when testing a second or later version of the system under test.

– Regression testing can be carried out on all applications, including e-Commerce and web-based systems .

42

Testing

Strong emphasis on regression testing– Unit tests need to execute all the time– Tests for completed features need to execute all the time

Unit tests pass 100%Acceptance tests (we haven't seen these) show progress on which user stories are workingOther testing frameworks include– JMeter, HttpUnit, JProbe, OptimizeIt, CPPUnit

43

12 Practices: Refactoring

Restructure code without changing the functionalityGoal: Keep design simple– Change bad design when you find it– Remove dead code

Examples at Martin Fowler's Web site: http://www.refactoring.com/ see online catalog

44

12 Practices: Pair programming

Write production code with 2 people on one machine– Person 1: Implements the method– Person 2: Thinks strategically about potential improvements, test

cases, issuesPairs change all the time. Has advantages such as– No single expert on any part of the system– Continuous code reviews, fewer defects– Cheaper in the long run, and more fun

Problems:– Not all people like it – Pairs need to be able to work together

45

12 Practices: Collective ownership

All code can be changed by anybody on the teamEverybody is required to improve any portion of bad code s/he seesEveryone has responsibility for the systemIndividual code ownership tends to create experts

46

12 Practices: Continuous integration formerly known as the 40 hour work week

Integration happens after a few hours of development

1. Checkout build with your changes, 2. Make sure all tests pass (green bar)3. In case of errors:

• Do not put changes into the build• Fix problems

4. Checkin the system to the integration machine5. Go to 1

47

Continuous Integration

Find problems earlyCan see if a change breaks the system more quickly -- while you remember the detailsSmall increments

48

Continuous Integration

Developing full speed only works with fresh peopleWorking overtime for two weeks in a row indicates problemWorking overtime can help the first week, and hurt the next weekAn XP day can be more exhausting, but you can get more done in 40 hours than 60

49

12 Practices: Coding standards

Coding Standard– Naming conventions and style– Least amount of work possible: Code should exist

once and only once

Team has to adopt a coding standard– Makes it easier to understand other people’s code– Avoids code changes because of syntactic

preferences

50

Project Size

XP was designed for small teams: 2-20Case studies show it can scalePractical advice and modifications are presented in Jutta Eckstein's new book– Agile Software Development in the Large http://jeckstein.com/agilebook/index.html

51

Become Agile

Become Part of the Agile movement– Rick is student volunteer chair for Agile 2006– July 23-28 2005 in Minneapolis MN– http://www.agile2006.org/