page 1 copyright © 1999, rolemodel software, inc. an introduction to extreme programming ken auer...
TRANSCRIPT
Page 1 Copyright © 1999, RoleModel Software, Inc.
An Introduction toExtreme
Programming
http://www.rolemodelsoft.comRoleModel Software, Inc.
5004 Rossmore Dr.Fuquay-Varina, NC 27526
919-557-6352
©
Page 2 Copyright © 1999, RoleModel Software, Inc.
The Joy of Software
To change Hardware Soldering Iron Screwdrivers Change PCB
To change Software Just change some symbols
Page 3 Copyright © 1999, RoleModel Software, Inc.
The Reality? of Software
Changing Software is Hard Dependencies
Cost of MakingChanges
Time
Page 4 Copyright © 1999, RoleModel Software, Inc.
The Promise of Specifications
Examples from Traditional Engineering Do the Drawings first Design work is done on the
drawings Construction is a separate act
(at least in theory)
In Software Capture Requirements up front Do design up front Hand over to coders
Page 5 Copyright © 1999, RoleModel Software, Inc.
BDUF (Big Design Up Front)
Cost of Making Changes
Time
Analysis Design Coding Testing
Find errors faster
Almost all method(ologie)s focus on this assumption no matter what they say about the evils of waterfalls!
Page 6 Copyright © 1999, RoleModel Software, Inc.
The Uncomfortable Reality
The Customers change requirements Customers believe software is easy to
change Real requirements hard to nail down They’re learning, conditions change
Hard to get costs of features Materials keep changing Productivity of people/teams vary widely Later development tasks hard to estimate
Developers learn as they program Too much flexibility costs
Cannot design for unanticipated changes Often anticipate wrong changes ...
Page 7 Copyright © 1999, RoleModel Software, Inc.
Design Decisions
In the moment Consider current needs Patch code when new needs appear…
is this really design???
Up front design Consider current needs and possible
future needs Design to minimize change with future
needs Patch code if unforeseen need appears
Evolutionary design Consider current needs and possible
future needs Trade off cost of current flexibility
versus cost of later refactoring Refactor as changes appear
Page 8 Copyright © 1999, RoleModel Software, Inc.
Object Orientation
Object-orientation helps manage the complexity of software and reduce dependencies…
Why don’t methods reflect this?
Why don’t methods exploit this?
Many have tried but failed because they threw out the baby (discipline) when they threw out the bathwaterfall...
Page 9 Copyright © 1999, RoleModel Software, Inc.
Another Approach
Cost of Making Changes
Time
Reduce cost of later change
The flatter this is, the less... Benefit of up-front design Cost of up-front design Cost of maintaining design artifacts
Page 10 Copyright © 1999, RoleModel Software, Inc.
Extreme Programming
“Recognizing that the cost of changing a program no longer grows exponentially over time, XP relies on the complex interactions between simple development practices to reduce project risk, improve responsiveness to business and technical learning, and make programming more fun”
- Kent Beck
©
Page 11 Copyright © 1999, RoleModel Software, Inc.
Playing to Win
Don’t just “survive” Tackle problems aggressively Tackle only the problems that you
KNOW exist in the current context Communicate to expose and
reduce risk Be confident in what you’ve done and
are doing based on feedback
Page 12 Copyright © 1999, RoleModel Software, Inc.
The Four Values
Simplicity Communication Feedback Aggressiveness
Page 13 Copyright © 1999, RoleModel Software, Inc.
Simplicity
What is the simplest thing that will possibly work?
No code duplication Don’t look too far ahead…
Simple things are easier to change You may not need it
Page 14 Copyright © 1999, RoleModel Software, Inc.
Communication
People talk to people People work with people People are honest when they don’t
know People share what they’ve learned! Code communicates with people No documentation for documentation’s
sake
Page 15 Copyright © 1999, RoleModel Software, Inc.
Feedback
Measure things that matter Look at the measurements Share the measurements Believe the measurements tell
you something Change what you can,
accept what you can’t
Page 16 Copyright © 1999, RoleModel Software, Inc.
Aggressiveness
You’ve got to believe that you can do it
Jump into the problem, don’t be frozen by all the things that can go wrong
Believe that when things do go wrong, you can fix them
Page 18 Copyright © 1999, RoleModel Software, Inc.
XP Iterations Limited Up Front Design
Detailed work in iterations Up front work for estimates and risk
assessment
Planning Game Customers develop stories (use
cases) Development estimates stories Joint scheduling based on customer
value and development risk
Disciplined development Write tests first Only focus on story in hand Short development episodes in pairs Continuous Integration Always working, always clean
Page 20 Copyright © 1999, RoleModel Software, Inc.
A Day In The Life
Stand up meeting Load latest stuff Identify tasks Pair up Test first, code second
What exists? Does it support what we need to
do? Gotta test for that? Do the tests work? Is the code clean (enough)?
If it’s working, integrate it Do the tests work?
Next task?
Page 22 Copyright © 1999, RoleModel Software, Inc.
Split Business & Technical
Customer chooses scope sets priorities
Developers estimate time required to
implement requirements schedule within a release...
Page 23 Copyright © 1999, RoleModel Software, Inc.
Small Releases
Customer chooses smallest, most valuable
set of requirements to put into production next
Developers keep design simple to get
requirements met as fast as possible
Page 24 Copyright © 1999, RoleModel Software, Inc.
Metaphor
Everyone tells the story of the system consistent with a central metaphor
Validate the metaphor quickly with a concrete design
Often 5-20 CRC level concepts
Page 25 Copyright © 1999, RoleModel Software, Inc.
Simple Design
At all times the system has simplest design that runs all test
cases no code duplication no unnecessary classes or methods
Constantly evolved through refactoring
Page 26 Copyright © 1999, RoleModel Software, Inc.
Having Tests
Developers write and satisfy unit tests for all
development write the tests first
Customers/Testers write functional tests for each
requirement
Ensure all tests can be run with one command
Test often… every change to a line of code??
Run all tests with every build Tests should be about 1/3 of
production code
Page 27 Copyright © 1999, RoleModel Software, Inc.
Pair Programming
All Production Code… written with two people sitting at one
machine pass the keyboard and mouse back and forth
Refactoring code wherever it needs clean up
Write tests Everyone knows a little about the whole
system
Page 28 Copyright © 1999, RoleModel Software, Inc.
Refactoring
Pair brings code back to simplicity the instant they see it drifting away
Short episodes...
Page 29 Copyright © 1999, RoleModel Software, Inc.
Continuous Integration
System is built and successfully tested several times a day each time a pair gets the test
cases for a simple development task running
integration machine
Page 30 Copyright © 1999, RoleModel Software, Inc.
Collective Code Ownership
Code is fixed wherever it is found to be deficient
Tests verify you haven’t broken anything New tests verify it doesn’t happen
again
Page 32 Copyright © 1999, RoleModel Software, Inc.
Playing to Win
Reality of Power, Power of Reality Cards as Weapons
Planning Game Exploration Phase Commitment Phase Iterations
Having Tests
Page 33 Copyright © 1999, RoleModel Software, Inc.
Reality of Power; Power of Reality
Four Variables Scope Quality (internal, external) Cost Time
Technical people can’t run the business
Business people can’t program
Page 34 Copyright © 1999, RoleModel Software, Inc.
Cards as Weapons
The Planning Game Business moves Developer moves
Exploration Phase Commitment Phase Iterations
Page 35 Copyright © 1999, RoleModel Software, Inc.
Exploration Phase
Write a story (Business) Estimate a story (Developer) Split a story (Business, often
prompted by Developer)
Page 36 Copyright © 1999, RoleModel Software, Inc.
Commitment Phase Sort by Value (Business)
Sort by Risk (Developer) Set Velocity (Developer w/
Business) Choose Scope (Business)
Choose date, OR Choose stories
Create the Plan (Developer)
Page 37 Copyright © 1999, RoleModel Software, Inc.
Iterations
During Iteration Planning Cards can be shifted Time cannot
During Iteration Clarification as we learn That’s another iteration
Page 38 Copyright © 1999, RoleModel Software, Inc.
Having Tests
Take the confidence of the moment, and preserve it
When did it break? Allows
refactoring collective code ownership feedback trust...
Page 39 Copyright © 1999, RoleModel Software, Inc.
Final Thoughts Undisciplined coding leads to a
steep cost of change curve BDUF doesn’t change the curve
It attempts to reduce number of times you are bitten by the curve
It adds up front cost that may never be recovered
XP focuses on pushing the “cost of change” curve down
Any of the XP practices might help your project
Adopting all of the practices will allow you to attain a high level of productivity and produce high quality product at a sustained rate over an extended period of time
Page 40 Copyright © 1999, RoleModel Software, Inc.
To Learn More...
Books from AW-L: Extreme Programming Explained: Embrace
ChangeKent Beck
Refactoring: Improving the Design of Existing Code Martin Fowler
Extreme Programming Applied: Playing to Win(not yet available) Auer, Cunningham, Beck, Fowler, Jeffries
http://www.rolemodelsoft.com http://www.XProgramming.com http://c2.com/cgi/wiki?
ExtremeProgrammingRoadmap
©