280 likes | 916 Views
Contents. The problemProblems in software developmenteXtreme Programming (XP)ValuesPracticesWhy XP worksBenefits of XPConclusionsResources. Problems in software development. Risks:Schedule slipsBusiness misunderstoodDefect rateProject cancelledSystem goes sourBusiness changes. Schedul
E N D
1. Introduction to eXtreme Programming Remko Popma
Azzurri Ltd.
http://www.azzurri.co.jp
2. Contents The problem
Problems in software development
eXtreme Programming (XP)
Values
Practices
Why XP works
Benefits of XP
Conclusions
Resources
3. Problems in software development Risks:
Schedule slips
Business misunderstood
Defect rate
Project cancelled
System goes sour
Business changes eg. Netscape 6
No communication after requirements analysis, or, Business needs changes
Time pressure, quality sacrificed for short-term speed gain
Bigger projects have good chance of being cancelled: low visibility, large budgets/timeframes
System delivered, works, but complex and/or fragileeg. Netscape 6
No communication after requirements analysis, or, Business needs changes
Time pressure, quality sacrificed for short-term speed gain
Bigger projects have good chance of being cancelled: low visibility, large budgets/timeframes
System delivered, works, but complex and/or fragile
4. Schedule slips Many projects are not delivered on time
Examples: Word 1.0, Netscape 6
Some deadlines cannot be moved
Example: Y2K
What if:
most business value is delivered on time
5. Business misunderstood Without direct communication, developers have to guess what the customer wants.
Example: The Orthodontics Project
What if:
an on-site customer steers development
6. Defect rate The software is put in production, but the defect rate is so high that it isn’t used.
What if: you have automated testing
7. Project cancelled Todo: function point
http://www.yourdon.com/books/y2k2020/11.dejavu.html
Todo: function point
http://www.yourdon.com/books/y2k2020/11.dejavu.html
8. Project cancelled
What if:
short releases deliver at least some useful working software, reflecting investment to date
9. System goes sour Software is put into production successfully, but after a couple of years the cost of making changes or the defect rate rises so much that the system must be replaced.
What if:
the design is simple and the code quality is high
10. Business changes New laws, market changes: business priorities change
What if:
the customer can change their mind, substitute functionality, and change priorities
11. Economics of software development
12. What if…
13. eXtreme Programming A system of practices that a community of software developers is evolving to address the problems of quickly delivering quality software, and then evolving it to meet changing business needs.
14. eXtreme… Taking proven practices to the extreme
If testing is good, let everybody test all the time
If code reviews are good, review all the time
If design is good, refactor all the time
If integration testing is good, integrate all the time
If simplicity is good, do the simplest thing that could possibly work
If short iterations are good, make them really, really short Take practices that have been proven to be good and take them to the extreme.Take practices that have been proven to be good and take them to the extreme.
15. XP values
Communication
Simplicity
Feedback
Courage
16. XP practices The Planning Game*
Small Releases
Metaphor
Simple Design*
Testing*
Refactoring*
Pair Programming* Collective Ownership
Continuous Integration
40-Hour Week
On-Site Customer
Coding Standards
Open workspace
Daily Schema migration
17. The Planning Game Business writes a story describing desired functionality
Stories are written on index cards
Development estimates stories
Velocity determines number of stories per iteration
Business splits and prioritizes stories and determines the composition of releases
Velocity is measured and adjusted every iteration
Customer steers development Big subject: will gloss over it
Release planning & iteration planning
Big subject: will gloss over it
Release planning & iteration planning
18. Testing Unit Tests and Functional Tests
Test a little, code a little…
“Test-first programming”
Tests become the specification
Tests give confidence in the system
Tests give courage to change the system
19. Unit tests
20. Pair Programming Two people looking at one machine, with one keyboard and one mouse
Two roles: implementation and strategy
All production code is written in pairs
21. Pair Programming Benefits 15% less output than 2 solo programmers
Continuous code review: better design, fewer defects
Confidence to add to or change the system
Discipline to always test and refactor
Teach each other how the system works (reduced staffing risks)
Learn from partner’s knowledge and experience (enhances technical skills) http://members.aol.com/humansandt/papers/pairprogrammingcostbene/pairprogrammingcostbene.htm
(Alistair Cockburn & Laurie Williams)
Partner is a safety net: changing the system is not scary
http://members.aol.com/humansandt/papers/pairprogrammingcostbene/pairprogrammingcostbene.htm
(Alistair Cockburn & Laurie Williams)
Partner is a safety net: changing the system is not scary
22. Simple design
Do the simplest thing that could possibly work
Passes all the tests
No duplicate code
States every intention
Fewest possible classes and methods
23. Refactoring Design becomes everybody’s daily business
Continuously improve quality of the code
Unit Tests and Pair Programming give courage
Result:
Fast development speed
Code becomes easy to change
24. Why XP works Light-weight: discipline without bureaucracy
Under stress, people do what is easiest
All XP practices have short-term benefits as well as long-term benefits
Development as a Conversation
The code is the documentation
XP is fun
25. Who benefits from XP? get clear requirements & priorities
can do a good job
can make technical decisions
don’t work overtime
get most business value first
get accurate feedback
can make informed business decisions
can change their mind
26. Conclusions Use XP on projects
with vague or changing requirements
with small teams
XP works, and is very fast
XP is fun to execute
At Azzurri, we use XP as much as possible with clients, and exclusively for internal projects
27. XP books and papers Extreme Programming Explained – Kent Beck
Refactoring – Martin Fowler
Planning Extreme Programming – Kent Beck et al
Extreme Programming Installed – Ron Jeffries et al
Extreme Programming Examined – Giancarlo Succi et al
Extreme Programming in Practice – Robert C. Martin et al
Extreme Programming Explored – William C. Wake
Extreme Programming Applied – Ken Auer et al
The Costs and Benefits of Pair Programming – Alistair Cockburn et al http://members.aol.com/humansandt/papers/pairprogrammingcostbene/pairprogrammingcostbene.htmhttp://members.aol.com/humansandt/papers/pairprogrammingcostbene/pairprogrammingcostbene.htm
28. Web resources www.junit.org
www.xprogramming.com
www.extremeprogramming.org
www.refactoring.com
www.pairprogramming.com http://www.martinfowler.com/articles/designDead.htmlhttp://www.martinfowler.com/articles/designDead.html
29. Thank you Questions?