Transcript Essence of Extreme Programming

Extreme Programming
C Sc 335
November, 28 2005
Overview
Essence of Extreme Programming (XP)
–
–
–
–
Variables
Values
Principles
Practices
2
Waterfall Model
Waterfall was described by 1970 by W. W. Royce
Understood as
– finish each phase
– don’t proceed
till done
Royce criticized this
– proposed an
iterative approach
3
Became Popular
Management liked phases to easily set deadlines
Customers provide all requirements
Analysts translate requirements into specification
Coders 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)
4
Cost of change
Waterfall
Cost
of
change
XP
time5
Sprial
Dr Barry Boehm proposed a spiral approach
6
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
7
Extreme Programming (XP)
Almost ten years of growth
Set of SE practices that produce high-quality
software with limited effort
Many books, first by Kent Beck:
Extreme Programming–Embrace Change,
Addison-Wesley, 2000,
ISBN 0-201-61641-6
http://www.extremeprogramming.org/
8
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 processes
http://www.agilealliance.org/
9
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 programming
Short iterations with fast delivery
10
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
11
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 work
12 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
12
Overview
Essence of Extreme Programming (XP)
–
–
–
–
Variables
Values
Principles
Practices
13
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
14
Four Variables: Cost
Increase cost and you can do a bit more
Pouring 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
15
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
16
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
17
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
18
The Values
Essence of Extreme Programming (XP)
–
–
–
–
Variables
Values
Principles
Practices
19
Four Values: Communication
Communication
– Customer centric
• Write "Stories", always available
– Pair programming
– Task estimation
– Iteration planning
– Design sessions
The Agile Manifesto
20
Four Values: Simplicity
Simplicity
– Choose the simplest thing that will work
– Choose the simplest design, technology,
algorithm, technique
21
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)
22
The Principles
Essence of Extreme Programming (XP)
–
–
–
–
Variables
Values
Principles
Practices
23
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
24
Feedback
Compiler feedback: seconds
Pair programming feedback: half minutes
Unit test feedback: few minutes
Acceptance testing: half hours
– Customer write these system level tests
• The developers need adapters (test fixtures) to make these pass
Customer feedback: daily
Iteration feedback: weekly
– Feedback: Priceless
25
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
26
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
27
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
28
Five Principles: Embracing Change
Embracing Change
– Preserve the most options while solving the most
pressing problems
29
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
30
12 Practices: On-site customer
Many software projects fail because they do not
deliver software that meets business needs
Real customer has to be part of the team
– Defines business needs
– Answers questions and resolves issues
– Prioritizes features
31
The Practices
Essence of Extreme Programming (XP)
–
–
–
–
Variables
Values
Principles
Practices
32
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 them
Developers estimate how long a story takes
33
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
34
12 Practices: Estimation
Based on similar stories from the past (“yesterday’s
weather”)
Team effort
Get good at estimation simply by doing it
Ideal 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?"
35
12 Practices: Small Releases
Releases should be as small as possible
Should make sense as a whole
Put system into production ASAP
– Fast feedback
Deliver valuable features first
Short cycle time
– Planning 1-2 months rather than 6-12 months
36
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
37
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
38
12 Practices: Testing
Software should be tested, but it is often spotty
or overlooked
Automatic testing (JUnit, for example) help us
know that a feature works and it will work after
refactoring, additional code, and other changes
Provides confidence in the program
39
Testing
Write tests at the same time as production code
– Unit tests  developer
– Feature/acceptance tests  customer
Don't need a test for every method
Testing can be used to drive development and
design of code
Allows for regression testing
– Do changes break previously working code
40
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
.
41
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 working
Other testing frameworks include
– JMeter, HttpUnit, JProbe, OptimizeIt, CPPUnit
42
12 Practices: Refactoring
Restructure code without changing the
functionality
Goal: 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
43
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, issues
Pairs 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
44
12 Practices: Collective ownership
All code can be changed by anybody on the team
Everybody is required to improve any portion of
bad code s/he sees
Everyone has responsibility for the system
Individual code ownership tends to create
experts
45
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 machine
5. Go to 1
46
Continuous Integration
Find problems early
Can see if a change breaks the system more
quickly -- while you remember the details
Small increments
47
Continuous Integration
Developing full speed only works with fresh
people
Working overtime for two weeks in a row
indicates problem
Working overtime can help the first week, and
hurt the next week
An XP day can be more exhausting, but you can
get more done in 40 hours than 60
48
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
49
Project Size
XP was designed for small teams: 2-20
Case studies show it can scale
Practical advice and modifications are presented
in Jutta Eckstein's new book
– Agile Software Development in the Large
http://jeckstein.com/agilebook/index.html
50
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/
51