Post on 30-Dec-2015
Extreme Programming
Sylvain GirouxOctober 3rd, 2000
PlanThe Problem to SolveXP: What? Why? When?“X” ?Software Methodolgy
VariablesValuesRulesPractices
References
Risk: The Basic ProblemSoftware development
fails to deliver, and fails to deliver value.
Schedule slips Project canceled System goes sour Defect rate Business misunderstood / changes False feature rich Staff turnover
Software methodologyA software methodology is the set of rules and practices used to create computer programs.
A heavyweight methodology has many rules, practices, and documents. It requires discipline and time to follow correctly.
Rational Unified Process (1491 files in 159 folders)
A lightweight methodology has only a few rules and practices or ones which are easy to follow.
Extreme Programminga lightweight discipline of software development
for small size teams (2-10 people)
to develop software quickly in an environment of rapidly-changing requirements.
Goal of XP
to deliver the software that is needed when it is needed.
When to use XP?problem domains whose requirements change
may not have a firm idea of what the system should do
a system whose functionality is expected to change every few months.
to address the problems of project risk. If your customers need a new system by a specific date the risk is high.
If that system is a new challenge for your software group the risk is even greater.
If that system is a new challenge to the entire software industry the risk is greater even still.
When to use XP?XP requires an extended development team.
the developers the managers the customers
Why?asking questions, negotiating scope and schedules, creating functional tests
require more than just the developers be involved in producing the software.
When to use XP?Testability
Productivity XP projects unanimously report greater programmer productivity when compared to other projects within the same corporate environment.
Why Extreme ? -- IIf code reviews are good, we’ll review code all the time (pair programming).
If testing is good, everybody will test all the time (unit testing), even the customers (functional testing)
If design is good, we’ll make it part of everybody’s daily business (refactoring)
If simplicity is good, we’ll always leave the system with the simplest design that supports current functionality (the simplest thing that could possibly work).
Why Extreme ? -- IIIf architecture is important, everybody will work defining and refining the architecture all the time (metaphor)
If integration testing is important, we’ll integrate and test several times a day (continuous integration).
If short iterations are good, we’ll make the iterations really, really short –seconds and minutes and hours, not weeks and months and years (the Planning Game).
Four VariablesWe will control four variables in our projects
CostTimeQualityScope
External forces (customers and managers) get to pick the values of 3 of the variables.
The development team gets to pick the resultant value of the 4th variable.
ValuesXP is based on
Communication
Simplicity
Feedback
Courage.
Value : communicationProblems with projects can invariably be traced back to somebody not talking to somebody else about something important
A programmer doesn’t tell someone else about a critical change in the design
A programmer doesn’t ask the customer the right question, so a critical domain decision is blown
A manager doesn’t ask a programmer the right question, and project progress is misreported
Value : communication and XP Practices
XP practices that can’t be done without communication
Unit testing
Pair programming
Task estimation
Value : simplicity
What is the simplest thing that could possibly work?
Not to look toward the things you’ll need tomorrow and next week and next month
XP stance:It is better to do a simple thing today and pay a little more tomorrow to change if it needs it,
than to do a more complicated thing today that may never be used anyway
Value : simplicity and XP PracticesThe more you communicate, the clearer you can see exactly what needs to be done and the more you have confidence about what really doesn’t need to be done
The simpler your system is, the less you have to communicate about
PracticesSimple designRefactoring
Value : Feedback at scale of minutes and days
Concrete feedback about the current state of the systemDon’t ask me, ask the system
Feedback for customersWhen customers write new stories (description of features), the programmers immediately estimate them
Feedback on project progressWatching the completion of tasks to give the whole team feedback about whether they are likely to finish everything they set out to do in a span of time
Value : Feedback at scale of weeks and months
The customers and testers write functional tests for all the stories (simplified use cases) implemented by the system.
The customers review the schedule every two or three weeks to see if the team’s overall velocity matches the plan, to adjust the plan
The system is put into production as soon as it makes sense, so the business can
begin to “feel” what the system is in action and discover how it can best be exploited.
Value : Feedback and XP practicesThe more feedback you have, the easier it is to communicate
Simple systems are easier to test
XP practicesThe planning gameSmall releasesTestingPair programmingContinuous integrationOn-site customer
Value : CourageCourage to take decisions
Radical surgery on code
Throwing code away
Starting over from scratch
Prototyping multiple design alternatives, and keep only one for “real” development
Last but not least
Respect
PrinciplesFrom the 4 values,
a dozen or so of principles (rules)
are derived
to guide the development style
Central PrinciplesMain principles
Rapid feedback time between action and feedback is critical
Assume simplicity
Incremental Change Big change made all at once just don’t work
Embracing change Preserves the most options while solving the most pressing problem
Quality work Nobody likes working sloppy
Less central principlesTeach learning
No doctrine
Small initial investmentToo many resources too early in a project is a recipe for disaster
Play to winPlaying to win vs playing not to lose
For sure we need to write reports, … but getting a working system is more important…
Concrete experimentsEvery time you made a decision and you don’t test it, there is some probability that the decision is wrong.
Less central principlesOpen, honest communication
Able to tell each other where there are problems in the codeAble to express fears and get supportFree to deliver bad news to customers and management, to deliver it early, and without being punished
Work with people’s instincts, not against themXP is a process where following short-term self-interest (win, learn, be in control, good work…)also serves long-term team interest
Accepted responsibilityNot telling people what to doDoes not mean that you always do exactly what you feel like doing
Less central principlesLocal adaptation
Adapt XP principles and practices to local conditions
Travel lightYou can’t expect to carry a lot of baggage and move fastBe prepared to change directionArtifacts
Few Simple Valuable
Honest measurementThis will take 14.176 hours (???)
Back to basicsThere are 4 activities to support
Coding
Testing
Listening
Designing
XP PracticesWhat is a practice?
the usual way of doing something
Aim of practices in XP: Structure the 4 activities
Coding, testing, listening, designing
In XP, there are 12 practices
12 PracticesThe Planning GameSmall Releases. Metaphor. Simple Design. Testing. Refactoring. Pair Programming. Collective Ownership. Continuous Integration. 40-hour Week. On-site Customer. Coding Standard.
Practice: The Planning GameThe XP "customer“
define the business value of desired features
The programmerprovides cost estimates
The XP "customer“choose
what needs to be done what needs to be deferred
Practice: Small releasesXP teams
put a simple system into production early,
update it frequently on a very short cycle
Practice: MetaphorXP teams use
common "system of names" and a common system description
that guide development and communication
We don’t literally mean “the system is…”
Give everyone a coherent story within which to work
Help everyone on the project understand the basic elements and their relationships
Practice: Simple designA program built with XP should be the SIMPLEST program that meets the current requirements.
There is not much building "for the future".
Practice: Testing XP teams focus on validation of the software at all times.
Programmers develop software by writing tests first, then software that fulfills the requirements reflected in the tests.
Customers provide acceptance tests that enable them to be certain that the features they need are provided.
Practice: Refactoring XP teams improve the design of the system throughout the entire development
This is done by keeping the software cleanwithout duplicationwith high communication
simple
Yet complete
Practice: Pair Programming
XP programmers write all production code in pairs,
two programmers working together at one machine
Practice: Collective ownershipAll the code belongs to all the programmers
This lets the team go at full speed, because
when something needs changing, it can be changed without delay
Practice: Continuous integrationXP teams integrate and build the software system multiple times per day
This keeps all the programmers on the same page, and enables very rapid progress
integrating more frequently tends to eliminate integration problems that plague teams who integrate less often
Practice: 40-hour weekTired programmers make more mistakes.
XP teams do not work excessive overtime,
keeping themselves fresh, healthy, and effective
Practice: On-site customerAn XP project is steered by a dedicated individual who is empowered to
determine requirements,
set priorities,
answer questions as the programmers have them
Practice: Coding standards
to work effectively in pairs,
to share ownership of all the code, all the programmers need to write the code in the same waywith rules that make sure the code communicates clearly
Software, naming, language, {}…
XP map
A spike solution is a very simple program to explore potential solutions
ReferencesKent beck, Extreme Programming Explained: Embrace Change, Addison Wesley, 2000
Martin Fowler, Refactoring : Improving the Design of Existing Code, Addison-Wesley, 1999
http://www.xprogramming.com
http://www.xprogramming.com/xpmag/index.htm
http://www.xprogramming.com/Practices/xpractices.htm
http://www.extremeprogramming.org/