eXtreme Programming

eXtremeeXtreme Programming Programming

Fad, Fall-back or Fail-safe Focus?

Fast Defect-Free Software Delivery!

Ian [email protected]

http://www.xp.co.nz

Tuesday, 24 April 2001

Confidential to Ian Mitchell, FNZCS

SW Delivery - SW Delivery - What do we want?What do we want?

Implement the business processes Deliver to “expectations” User-friendly, “Intuitive”, Just how I would do it! Reliable software - Defect-free On Time delivery Within budget Future proofed.



Software Development Software Development FailuresFailures

70% of projects result in failure (legal letters)

70% of these are not technology problems But are change management or communication

problems!

Can we continue with methodologies with a

chance of success of less than 1/3rd?



““Old Economy”Old Economy”

We know what we are doing – ‘cause we have done it a 1000 times before

Give our really bright programmers detailed specifications and they will do exactly what they are told (they won’t need to think!)

We managers cannot learn much useful from geeks (Programmers don’t know anything about business!).



““New Economy”New Economy”

I have not been here beforeThere are no roads on my mapHey, I’m off the map!Where are:

– the deserts (there is nothing there)

– the uncrossable ravines (we cannot go forward)

– the wild gorillas (what will get us out there?)

– the swamps? (Will we catch a disease?)



How to cross new territory!How to cross new territory!

Set strategic goals Take short day marches

– Record every thing you do– Make sure at least 2 people are familiar with the route

Look around – what can you see? Make a decision about where to go tomorrow Check against our strategic goals.



Some people say . . .Some people say . . .

Develop software iterativelyManage requirementsUse component-based architectureVisually model softwareVerify software qualityControl changes.



But we say . . .But we say . . .

Develop software incrementallyReview requirements after every small stepDeliver small incremental components into

production every three weeksDon’t visualise - See the real thingBuild in and prove it is defect freeReview all requests every three weeks.



To effect change . . .To effect change . . .

Hit the block . . .Admit the way we do it is not workingSeek another wayTry another wayIf it works . . .

Embed it as OUR way.



Common SenseCommon Senseto the Extreme!to the Extreme!

Everybody will design every day System will always be the simplest possible Review code all the time Test all the time Define and refine architecture all the time Integrate and test several times a day Iterate every hour; deliver every day.



What is XP?What is XP?

Early, concrete and continuing feedback to the user in short cycles

Incremental planning all the time Flexible implementation schedule responding to

business needs Automatic tests to allow customers to monitor

progress Communication: Oral, tests, source code Evolutionary design!



XP in ShortXP in Short

User Stories The Planning Game Small Releases Metaphor Simple Design Test every case Refactoring

On-site customer Pair programming Coding Standards Collective Ownership Continuous

Integration 40-hour week.



Basic AttitudesBasic Attitudes

Rapid FeedbackAssume simplicityIncremental changeEmbracing changeQuality workPlus . . .



Four ValuesFour Values

Communication – user management to coders

SimplicityFeedbackCourage.



Secondary PrinciplesSecondary Principles

Teach learning Small initial investment Play to win Concrete experiments Open, honest communication Work with people’s instincts, not against them Accepted responsibility Local adaptation Travel light Honest measurement.



Managers must:Managers must:

Make IT happenCo-ordinateReportReward.



My Experience My Experience (Large package)(Large package)

Hit the Block (1m lines of code)

Integration tests repeatedly fail– 3 tier – DB Mtce, SQL procs, COM objects, actual code– Multiple environments – Unix, Novell, MS 3.1,98,Me

Brilliant code does not “fit” anymore Cannot locate impact of a change Bottleneck in the general admin program Bottleneck: stored procedures, WISE, Documentation

Surfacing n-tier deep error messages.



My SolutionMy Solution

Break code into separate applications & “core”– Redesign Build scripts – 3 weekly releases

Coding– Inspection – Pre/Post-assertion– Standards and style guides– Best practice Friday sessions– Test harnesses– Coverage and performance tests– Paired programmers

Feature “razor”.



One pair in One dayOne pair in One day

Whiteboard with user; get the Story right, Design code unit, split into tasks, volunteer to deliver

Write Face – Pre/post-assertions– Write 50 lines of code– Write 50 lines of test harness– Inspect– Test including Coverage and Performance

Iterate for each test case – each path thru code Show user the tests that day.



Other Coding PracticesOther Coding Practices

As soon as Face is executable– Move to repository– Integrate– Build– Document– Pass to QA

Release to teamPart of next customer release.



Six is Too Many!Six is Too Many!

Project versus team size – 6 pairs plusdocumentation editor plus QA (2) plus Build Script controller plus Install Script controller

Time in communication If team requires 15 minutes per each two way pair then the

7th unit costs twice as much. So need to segment project into separately

manageable and deliverable projects Dev Environment, Build, database, menu, access

rights, etc.



A Year is Too Long!A Year is Too Long!

Keep focus, staff turnoverCost of changing staff mid-projectBut Netscape – 4 week bursts, 2 week re-setNow continuous releases – by a teamMay be 3 weeks for large packages Focus is on every day delivering completed proven

defect-free code and test harness and documentation Web-based systems have much smaller deliverables.



EconomicsEconomics

Pay only for what worksMinimise riskGet benefits earlyMaintainable codeMeasure cost, time, quality, scopeRisks are all made short-termComplex and irresolvable debates.



NZ ProgrammersNZ Programmers

Have good IS qualificationsLearn quickly from good conceptual baseOften have commerce qualificationsShow initiativeAre not into CYAWork well together: no internal competitionRespect common sense.



When to use XPWhen to use XP

Not on very large projects– My advice – avoid these because your chance of

winning is quite low!

Not for embedded software if the hardware is frozen

Not with data-driven apps – RAD for these Not with “Old Economy” management

– My advice – avoid these because your chance of winning is quite low!



Thank You!Thank You!

[email protected]://www.xp.co.nzPhone: +64 9 528-3350Mobile: +64 25 965-608

Documents

eXtreme Programming