1
Extreme Programming
&
New Theory of Programming
2
Recap
• Time is important
• Time estimation via features
• Quality: linear burn curve
3
XP
• The most famous agile methodology
• First XP project: Chrysler’s C3 system (1997)
• Notable figures: Kent Beck, Ron Jeffries
• Toyota production system
– Low latency: Unimplemented idea pile up (stock)
– Stop the line: Detect a Defect as soon as it is introduced
4
XP’s Basic Idea
• A fixed scope is a loose-loose situation
– Customer wants to maximize scope
– Developers want to minimize scope
• Instead, decide on fixed time intervals
– Periodically, re-negotiate scope
• The software is always working
– Short cycles of break-repair
• Customer can always provide feedback
• Project cannot take a wrong path for more than a week
5
The Scope Equation
Scope = Time x Quality
• You can only fix two of the variables:
– Scope, time => Quality
– Time, Quality => Scope
– Scope, Quality => Time
6
XP: Values
• Communication
• Simplicity
• Feedback
• Courage
• Respect
7
Simplicity
•
•
•
•
Passes all tests
Reveals intentions
No duplication/Locality
Minimal number of classes and methods
8
Locality
Structure the code so changes have local
consequences
9
Stories and Tasks
• Story: a short description of customer
visible functionality
• Task: Breakdown of a task into code-level
additions/changes
• It is often that story == task
10
Iteration Cycle
• Define scope (stories)
– Planning game
• For each story: Implement smallest delta needed
to realize the story
– “minimal thing that could possibly work” (YAGNI)
– May trigger refactoring
– Incremental steps
• Reflection – what have been doing?
– Everyone can see where the project is standing
– Customer can see what is still missing
– Learning: enhance the process
11
The Planning Game
• Negotiate scope with customer
– Customer: chooses stories
– Developers: What can be completed
• Output: a set of prioritized task
• Deciding what can be completed
– Esitmate task/story using points
– Esitmate task/story using hours
– Compare to previous week
* Total capacity: “Yesterday’s weather”: Same as last weeks
• Re-plan if completed early
12
XP: Practices
• Negotiated Scope Contract
• Incremental Design
• Shared Code + Single Code Base
• Intensive testing (easiest via TDD)
– Ten-Minute Build
– Continuous Integration
– Daily Deployment
* Customer can check the system on a daily basis => Can define the
scope for the next iteration
13
Iteration-0
• At each iteration, the program evolves
– By adding new functionality to the prev. iteration
• Q: What happens at the very first iteration?
• A: Develop a skeleton
– Most of the parts
– Degenerated functionality
14
Informative Workspace
• AKA:
– “Information Radiators”
– “talking walls”
• Continues Integration Status
• Burn up
• Stories: Waiting, In progress, Completed
15
Human Factor
• Pairs
• Standup meetings
• Sense of accomplishment
– Working software
– Constant customer feedback
• TDD keeps developer focused
• Working software
– No frustration over the weekend
• Stories on real index card
– Can be sorted, shuffled, grouped, passed, posted to a wall
– Many people say they are better than s/w tools
16
XP: Larger Scale
• Decompose into several smaller projects
– Along the “natural fracture lines”
• Release Planning
– Quarterly
– Choose themes – build a bank of stories
17
Technical Debt
• A quick and dirty solution induces a technical debt
– similar to a financial debt
– Incurs interest payments: Extra effort due to the dirty design
• We can choose to continue pay the interest
• Or, we can pay down the principal
– Refactor the dirty design into a clean one
• Sometimes, quick and dirty is sensible
– Taking a loan to take advantage of a business opportunity
– Going into technical debt to meet a deadline
18
Costs
• Past
– cost = Tdevelop
• Present
– cost = Tplan + Tdevelop + Ttest + Tdeploy
• Maintenance: Tplan includes time needed for understanding
the existing system
• XP
– I have tests -> Code can adapt -> No need for sophisticated
planning (other than choosing the iteration’s scope)
– Tplan: Low
• UML process
– I carefully planned -> I have good code -> no need to adapt
– (Planning requires foresight)
– Tplan: high
19
Axioms
• Super-linearity
• Instability
• Uncertainty
• Non-traceability
20
Instability
Existing code will need to change
•
•
Code should adapt
Testing
21
Uncertainty
The more accurate the specification, the
more error prone it is
• Precise planning of the full system is a
waste of time
• XP: Roughly plan the current iteration
22
Non-traceability
It is impossible to estimate the full
effect of a change
• Instead of inventing a design, discover it
as you go along
23
Super Linearity
A large task is relatively (and absolutely)
more expensive than a small task
24
Program Breakdown
• Two ways to decompose a software project
• Feature by feature
– Many small tasks
• Subsystem by subsystem
– Few large tasks
• Essentially same amount of code
• Feature by feature is less work
– If we accept the super-linearity axiom