extreme programming. past methodologies systems analysissystems analysis –60s and 70s –waterfall...

eXtreme ProgrammingeXtreme Programming

Past MethodologiesPast Methodologies

• Systems AnalysisSystems Analysis– 60s and 70s60s and 70s

– Waterfall MethodologyWaterfall Methodology

• Structured DesignStructured Design– 70s and 80s70s and 80s

• Object-orientedObject-oriented– Rational Unified Process, UMLRational Unified Process, UML

Lightweight Lightweight MethodologiesMethodologies

• Reaction to the Big MethodologiesReaction to the Big Methodologies– To avoid Analysis ParalysisTo avoid Analysis Paralysis

• Extreme ProgrammingExtreme Programming

• The Agile AllianceThe Agile Alliance

AgendaAgenda

• IntroductionIntroduction

• MotivationMotivation

• FoundationsFoundations

• XP PracticesXP Practices

• (Managing & Adopting XP)(Managing & Adopting XP)

IntroductionIntroduction

XP evolved from an unusually successful project at Daimler-Chrysler (C3 Project). It is a lightweight, effective, code-centric, efficient and enjoyable discipline for teams of 2 - 10 developers.

But beware -- it really is extreme...

Going to ExtremesGoing to Extremes

• Code reviews ==> Pair ProgrammingCode reviews ==> Pair Programming

• Testing ==> Automated tests, run many Testing ==> Automated tests, run many times per daytimes per day

• Design ==> Refactor MercilesslyDesign ==> Refactor Mercilessly

• Integration ==> Continuous IntegrationIntegration ==> Continuous Integration

• Simplicity ==> Simplicity ==> TheSimplestThingThatCouldPossiblyWork TheSimplestThingThatCouldPossiblyWork (YoureNotGonnaNeedIt)(YoureNotGonnaNeedIt)

Evil PracticesEvil Practices

• ““Premature Optimization is the Root Premature Optimization is the Root of All Evil” (-- Don Knuth)of All Evil” (-- Don Knuth)

• Premature Generalization is cause Premature Generalization is cause of Doomed Projects (-- Me)of Doomed Projects (-- Me)– Wait until you really need itWait until you really need it

• Only wimps fail to refactorOnly wimps fail to refactor

The Promises of XPThe Promises of XP

• For Developers:For Developers:– work on things that really matterwork on things that really matter

– have a say in schedulinghave a say in scheduling

– don’t have to work alonedon’t have to work alone

• For Managers:For Managers:– get maximum value out of each dev. Weekget maximum value out of each dev. Week

– see regular, concrete, observable progresssee regular, concrete, observable progress

– can change requirements affordablycan change requirements affordably

The Claims of XPThe Claims of XP

• Reduces RiskReduces Risk

• Increases Project ResponsivenessIncreases Project Responsiveness

• Improves ProductivityImproves Productivity

• Adds Fun to a ProjectAdds Fun to a Project

(Quit Laughing!)(Quit Laughing!)

The Features of XPThe Features of XP

• Early, concrete, frequent feedbackEarly, concrete, frequent feedback

• Evolutionary Project PlanningEvolutionary Project Planning

• Flexible Scheduling of TasksFlexible Scheduling of Tasks

• Automated TestingAutomated Testing

• CommunicationCommunication– orally or in codeorally or in code

• Collaborative ProgrammingCollaborative Programming– supermen not required!supermen not required!

MotivationMotivation

Project RiskProject Risk

• Schedule SlipsSchedule Slips

• Project CanceledProject Canceled

• High Defect RateHigh Defect Rate

• System Misses the MarkSystem Misses the Mark

• Business Requirements ChangeBusiness Requirements Change

• Staff TurnoverStaff Turnover

How XP Mitigates RiskHow XP Mitigates RiskSchedule SlipsSchedule Slips

• Short Release CyclesShort Release Cycles

• Reduces scope of slipReduces scope of slip

• Higher priority tasks done firstHigher priority tasks done first– ““worst things first”worst things first”

How XP Mitigates RiskHow XP Mitigates RiskProject CanceledProject Canceled

• Plan smallest release that makes Plan smallest release that makes business sensebusiness sense

• Principle:Principle: “A complex system that “A complex system that works evolves from a simple system works evolves from a simple system that works” (Grady Booch)that works” (Grady Booch)

How XP Mitigates RiskHow XP Mitigates RiskHigh Defect RateHigh Defect Rate

• Daily Automated TestsDaily Automated Tests

• Catch defects earlyCatch defects early

How XP Mitigates RiskHow XP Mitigates RiskSystem Misses the MarkSystem Misses the Mark

• Customer is part of the Customer is part of the development teamdevelopment team

• Requirements are continually Requirements are continually refined and brought into focusrefined and brought into focus

How XP Mitigates RiskHow XP Mitigates RiskBusiness Requirements ChangeBusiness Requirements Change

• Iterative DevelopmentIterative Development

• Do a little bit at a timeDo a little bit at a time

• Tasks easily shuffled in priorityTasks easily shuffled in priority

How XP Mitigates RiskHow XP Mitigates RiskStaff TurnoverStaff Turnover

• Programmers less frustrated Programmers less frustrated because they do meaningful work, because they do meaningful work, togethertogether

The XP WayThe XP Way

do

{

perform an engineering task

unit test

integrate

functional test

} while (!done);

The XP WayThe XP Waycontinuedcontinued

• Developers work in pairsDevelopers work in pairs– Siamese keyboard twinsSiamese keyboard twins

• Write unit tests first, then codeWrite unit tests first, then code

• Refactor as neededRefactor as needed

• Integrate immediatelyIntegrate immediately

A Development EpisodeA Development Episode

(pp. 7-9)(pp. 7-9)

Did You Notice?Did You Notice?

• Pairs of programmers program Pairs of programmers program togethertogether

• Development is driven by tests.Development is driven by tests.– Test first, then codeTest first, then code

• Pairs evolve the design of the systemPairs evolve the design of the system

• Integrate/test immediatelyIntegrate/test immediately

FoundationsFoundations

The Four VariablesThe Four VariablesCan’t all vary independently!Can’t all vary independently!

• ScopeScope– the most fluid variable - can be the difference between the most fluid variable - can be the difference between

success and failuresuccess and failure

• ResourcesResources– but too much is as bad as not enoughbut too much is as bad as not enough

• TimeTime– too much time can be a liability tootoo much time can be a liability too

• QualityQuality– not much of a variablenot much of a variable

– excellent vs. insanely excellentexcellent vs. insanely excellent

The Four ValuesThe Four Values

• CommunicationCommunication

• SimplicitySimplicity

• FeedbackFeedback

• CourageCourage

CommunicationCommunication

• Verbal or in CodeVerbal or in Code– very few written documentsvery few written documents

– teams work within spitting distanceteams work within spitting distance

• Pair ProgrammingPair Programming– continuous communication!continuous communication!

• User StoriesUser Stories– on index cards!on index cards!

Story CardStory Card

101 Union Dues

Bargaining Unit EEs have union dues withheld from thefirst pay period of the month. The amount varies byunion, local, and in some cases varies by the individual.

If dues cannot be taken in the first pay period, theyshould not be taken until a UD30 transaction isreceived.

Priority High Risk Low Jan

SimplicitySimplicity

• Do just today’s work todayDo just today’s work today– TheSimplestThingThatCouldPossiblyWorkTheSimplestThingThatCouldPossiblyWork

– YoureNotGonnaNeedItYoureNotGonnaNeedIt

– say “no” to Analysis Paralysissay “no” to Analysis Paralysis

• Don’t fear tomorrowDon’t fear tomorrow– you’ll be just as successful as you are todayyou’ll be just as successful as you are today

– the process gives you resiliencethe process gives you resilience

– tests give you confidencetests give you confidence

FeedbackFeedback

• Tasks take hours and minutesTasks take hours and minutes– not days and weeksnot days and weeks

• Ask the SystemAsk the System– i.e., run testsi.e., run tests

• Do hard stuff firstDo hard stuff first

CourageCourage

• Don’t be afraid to redesign, refactor, Don’t be afraid to redesign, refactor, throw away codethrow away code

• Tests will keep you on trackTests will keep you on track

Remember:Remember: “All (big) methodologies “All (big) methodologies are based on fear.”are based on fear.”

Basic XP PrinciplesBasic XP Principles

• Rapid FeedbackRapid Feedback

• Assume SimplicityAssume Simplicity

• Incremental ChangeIncremental Change

• Embrace ChangeEmbrace Change

• Quality WorkQuality Work

Rapid FeedbackRapid Feedback

• Get going!Get going!– So we don’t forget the questionSo we don’t forget the question

– Momentum is crucialMomentum is crucial

• For Developers:For Developers:– minutesminutes, not months, not months

• For Managers:For Managers:– weeksweeks, not years, not years

Assume SimplicityAssume Simplicity

• 98/2 Rule98/2 Rule– the time you save on 98% of the tasks the time you save on 98% of the tasks

more than compensates for the 2% more than compensates for the 2% where raw simplicity doesn’t workwhere raw simplicity doesn’t work

• ““Sufficient to the day are the tasks Sufficient to the day are the tasks thereof”thereof”

Incremental ChangeIncremental Change

• Translate big changes into a series of Translate big changes into a series of small changessmall changes

• Design & plan as you goDesign & plan as you go

• This applies to adopting XP tooThis applies to adopting XP too– start with what you feel comfortable withstart with what you feel comfortable with

– but have a little courage!but have a little courage!

Embrace ChangeEmbrace Change

• Possible because we Assume Possible because we Assume SimplicitySimplicity

• Solve the most pressing problem Solve the most pressing problem firstfirst

• Trust your testsTrust your tests

Quality WorkQuality Work

• Quality really isn’t a variableQuality really isn’t a variable

• Otherwise software development is Otherwise software development is no funno fun– Assume developers are quality-mindedAssume developers are quality-minded

– Choices: Excellent vs. Insanely Choices: Excellent vs. Insanely ExcellentExcellent

The Basic ActivitiesThe Basic Activities

• CodingCoding

• TestingTesting

• ListeningListening

• DesigningDesigning

CodingCoding

• Use code for as many Software Use code for as many Software engineering purposes as possibleengineering purposes as possible

• Code isn’t impressed by degrees, Code isn’t impressed by degrees, salaries, or fancy talksalaries, or fancy talk

• Eschew Documentation BulkEschew Documentation Bulk

TestingTesting

• Unit tests flesh-out/refine requirementsUnit tests flesh-out/refine requirements– ““I think this is what you said.”I think this is what you said.”

• The Untested does not existThe Untested does not exist

• ““Programming + Testing” is faster than just Programming + Testing” is faster than just “Programming”“Programming”

• Unit tests make programmers happyUnit tests make programmers happy

• Functional tests make users happyFunctional tests make users happy

• Both must be happy!Both must be happy!

ListeningListening

• Programmers don’t know anythingProgrammers don’t know anything– about the business, that isabout the business, that is

• Ask questionsAsk questions– then listen to the answersthen listen to the answers

– give feedback (what is hard, easy,…)give feedback (what is hard, easy,…)

• Corollary: Programmers shouldn’t design Corollary: Programmers shouldn’t design GUIs!GUIs!

DesigningDesigning

• Creating a clean internal structureCreating a clean internal structure– modular (cohesion/coupling)modular (cohesion/coupling)

• maintainable, extensiblemaintainable, extensible

– one-definition ruleone-definition rule

• A daily activityA daily activity

• Refactoring fights EntropyRefactoring fights Entropy

XP PracticesXP Practices

4 ValuesBasic

PrinciplesBasic

ActivitiesXP

Practices+ +

PracticesPractices

• The Planning GameThe Planning Game

• Small releasesSmall releases

• MetaphorMetaphor

• Simple designSimple design

• TestingTesting

• RefactoringRefactoring

• Pair ProgrammingPair Programming

• Collective OwnershipCollective Ownership

• Continuous IntegrationContinuous Integration

• 40-hour week40-hour week

• On-site customerOn-site customer

• Coding standardsCoding standards

Before we Continue...Before we Continue...

• Keep in mind that the Practices Keep in mind that the Practices work togetherwork together

• The weakness of one is covered by The weakness of one is covered by the strengths of othersthe strengths of others

The Planning GameThe Planning Game

• ““Quickly determine the scope of the next Quickly determine the scope of the next release by combining business priorities and release by combining business priorities and technical estimates. As reality overtakes the technical estimates. As reality overtakes the plan, plan, update the planupdate the plan.”.”

• ““Neither business considerations nor technical Neither business considerations nor technical considerations should be paramount. Software considerations should be paramount. Software development is always an development is always an evolving dialogevolving dialog between the possible and the desirable.”between the possible and the desirable.”

• Customer owns the planCustomer owns the plan

The Planning GameThe Planning Game~ continued ~~ continued ~

• Business people decide about:Business people decide about:– scopescope

– prioritypriority

– releasesreleases

• Technical people decide about:Technical people decide about:– estimatesestimates

– processprocess

– detailed schedulingdetailed scheduling

Short ReleasesShort Releases

• ““Put a simple system into production Put a simple system into production quickly, then release new versions on a quickly, then release new versions on a very short cycle.”very short cycle.”

• Plan a month or two at a timePlan a month or two at a time

• Focus only on the current releaseFocus only on the current release

• Implement the highest priority features Implement the highest priority features firstfirst

MetaphorMetaphor

• A simple, shared story that guides A simple, shared story that guides developmentdevelopment– architecture from 30,000 feetarchitecture from 30,000 feet

• ““The system is…The system is…– a spreadsheet”a spreadsheet”

– like a desktop”like a desktop”

– like a pension calculation system”like a pension calculation system”

Simple DesignSimple Design

• The system should be as simple as The system should be as simple as possible at any given moment.possible at any given moment.

• Extraneous complexity is removed as Extraneous complexity is removed as soon as it is discoveredsoon as it is discovered– fewest possible classes, methodsfewest possible classes, methods

– no duplication of logicno duplication of logic

– attitude:attitude: when you can’t delete any more, the when you can’t delete any more, the design is rightdesign is right

TestingTesting

• The key to confidenceThe key to confidence

• Programmers continually write and run Programmers continually write and run automated unit testsautomated unit tests– for things that could possibly breakfor things that could possibly break

• They must pass 100% for work to They must pass 100% for work to continuecontinue

• Customers write functional tests to Customers write functional tests to validate each user storyvalidate each user story

RefactoringRefactoring

• Restructuring a system without changing its Restructuring a system without changing its behaviorbehavior– to remove duplication (e.g., combine methods, objects)to remove duplication (e.g., combine methods, objects)

– simplify design, etc.simplify design, etc.

– promotes reliability, reusepromotes reliability, reuse

– the “long term” takes care of itselfthe “long term” takes care of itself

• Difficult without automated testsDifficult without automated tests

• Do it when you’re rested and freshDo it when you’re rested and fresh– which should be often!which should be often!

Pair ProgrammingPair Programming

• All production code is written with two All production code is written with two programmers at one machineprogrammers at one machine– discourages interruptionsdiscourages interruptions

• Take turns drivingTake turns driving– the driver implements (thinks tactically)the driver implements (thinks tactically)

– the observer thinks strategically (i.e., does the the observer thinks strategically (i.e., does the worrying:-)worrying:-)

• Teams can change oftenTeams can change often

Collective OwnershipCollective Ownership

• ““Whoever finds a snake, kills it”Whoever finds a snake, kills it”– (apologies to the Sierra Club)(apologies to the Sierra Club)

• Anyone can change code anywhere, Anyone can change code anywhere, anytimeanytime– to add value (not to change curly braces)to add value (not to change curly braces)

• Pair programming makes this feasiblePair programming makes this feasible– always 2 brains making a joint decisionalways 2 brains making a joint decision

Continuous IntegrationContinuous Integration

• Integrate/build many times dailyIntegrate/build many times daily– every time a task is completedevery time a task is completed

• Consider having a separate Consider having a separate integration machineintegration machine

• Test/debug until the system is 100% Test/debug until the system is 100% correctcorrect

40-hour Week40-hour Week

• Work no more than 40 hours a week as a Work no more than 40 hours a week as a rulerule– never work overtime a second week in a rownever work overtime a second week in a row

• Overtime is a symptom of a project in Overtime is a symptom of a project in serious troubleserious trouble– and the overtime won’t fix itand the overtime won’t fix it

• Tired programmers make bad codeTired programmers make bad code

• Take a 2-week vacation every yearTake a 2-week vacation every year

On-site CustomerOn-site Customer

• Have a real, live user on the team, available to Have a real, live user on the team, available to answer questionsanswer questions– someone who will really use the system in practicesomeone who will really use the system in practice

– they can write functional tests, and make small-they can write functional tests, and make small-scale decisionsscale decisions

• Isn’t the system important enough to dedicate Isn’t the system important enough to dedicate a real user to it?a real user to it?– if not, don’t build itif not, don’t build it

– they can still get some real work donethey can still get some real work done

Coding StandardsCoding Standards

• A tool of communicating through A tool of communicating through codecode

• Avoids “curly brace” warsAvoids “curly brace” wars

• Developers will give up their Developers will give up their religious tenets for an enjoyable, religious tenets for an enjoyable, successful projectsuccessful project

XP RolesXP Roles

• Programmer Programmer (knows “how”)(knows “how”)

• Customer Customer (knows “what”)(knows “what”)

• Tester Tester (verifies quality)(verifies quality)

• Tracker Tracker (the “conscience”, “historian”)(the “conscience”, “historian”)

• Coach Coach (the calm, responsible, manager)(the calm, responsible, manager)

• Consultant Consultant (rarely needed)(rarely needed)

• Big Boss Big Boss (leader, instills courage, insists on (leader, instills courage, insists on completion)completion)

Adopting XPAdopting XP

• Incrementally of courseIncrementally of course– 1. Pick your worst problem1. Pick your worst problem

– 2. Solve it the XP way2. Solve it the XP way

– 3. When it’s no longer the worst, go to 1.3. When it’s no longer the worst, go to 1.

• Starting PlacesStarting Places– TestingTesting

– Planning GamePlanning Game

Agile DevelopmentAgile Development

• Evolved from XPEvolved from XP

• A little broader, easier to graspA little broader, easier to grasp

• The Jury is “still out”The Jury is “still out”

The Agile ManifestoThe Agile Manifesto

We are uncovering better ways of developing We are uncovering better ways of developing software by doing it and helping others do it. software by doing it and helping others do it. Through this work we have come to value: Through this work we have come to value:

Individuals and interactions over processes and tools Individuals and interactions over processes and tools Working software over comprehensive documentation Working software over comprehensive documentation Customer collaboration over contract negotiation Customer collaboration over contract negotiation Responding to change over following a plan Responding to change over following a plan

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

Read the BookRead the Book

• We’ve covered about 50%We’ve covered about 50%

• Kent Beck, Kent Beck, eXtreme Programming eXtreme Programming ExplainedExplained, A-W, 1999., A-W, 1999.

• http://www.XProgramming.comhttp://www.XProgramming.com

• http://c2.comhttp://c2.com– Extreme Programming RoadmapExtreme Programming Roadmap

Developer’s SummaryDeveloper’s Summary

• Pairs of programmers work togetherPairs of programmers work together

• Development is driven by testsDevelopment is driven by tests– test first, then codetest first, then code

• Pairs make tests run, and evolve the Pairs make tests run, and evolve the system (refactor)system (refactor)– don’t let sun set on bad codedon’t let sun set on bad code

• Integration immediately follows Integration immediately follows developmentdevelopment

The Real SummaryThe Real Summary

• Best Practices are Good ThingsBest Practices are Good Things

• XP takes them to the MAXXP takes them to the MAX

• XP is extremeXP is extreme– but extreme measures are often called forbut extreme measures are often called for

• Evidence in favor of XP is mountingEvidence in favor of XP is mounting

• Adopt what you likeAdopt what you like

• Good luck!Good luck!