We were doing incremental development
as early as 1957, ... the technique used
was, as far as I can tell, indistinguishable
from XP.
Jerry Weinberg
Craig Larman: Iterative and Incremental Development: A Brief History
6
Slide 7
Slide 7 text
"Perlis: I’d like to read three sentences to close this issue.
1. A software system can best be designed if the testing is
interlaced with the designing instead of being used after
the design.
2. A simulation which matches the requirements contains
the control which organizes the design of the system.
3. Through successive repetitions of this process of
interlaced testing and design the model ultimately
becomes the software system itself.
1968 NATO Conference on Software Engineering
7
Slide 8
Slide 8 text
Barry
Boehm
Kent Beck
Kent Beck, Extreme Programming Explained
8
Slide 9
Slide 9 text
Involve the customer through small, incremental
releases of a working program
http://mgintravels.wordpress.com/2013/03/04/camping-in-the-olive-gardens-of-patara/
9
XP
The Planning Game
Small releases
Metaphor
Simple Design
Testing
Refactoring
Pair Programming
Collective Ownership
Continuous Integration
40-Hour Week
On-Site Customer
Coding Standards
Practices
Values
Simplicity
Courage
Communication
Feedback
11
Slide 12
Slide 12 text
1. Planning Game
(Scrum)
Planning game
Business people
Scope
Priority
Dates
Technical people
Estimates
Consequences
Process
12
Slide 13
Slide 13 text
2. Small Releases
(Continuous Delivery)
Subversion
Sviluppatori
Jenkins Server di collaudo
1. Commit
2. Pull changes
3. Build
4. Unit test
5. Deploy
6. Acceptance tests
7. Success! or Failure!
13
Slide 14
Slide 14 text
3. Metaphor
(Domain-Driven Design)
Ubiquitous Language
Simple models
14
Slide 15
Slide 15 text
4. Simple Design
1. Runs all the tests
2. Has no duplicated logic
3. States every intention important to the
programmers
4. Has the fewest possible classes and
methods
15
Slide 16
Slide 16 text
5. Testing
(TDD, BDD, ATDD)
The result is a program that becomes more and
more confident over time---it becomes
more capable of accepting change, not less.
The customer writes Acceptance Tests
16
Slide 17
Slide 17 text
6. Refactoring
When implementing a program feature, the
programmers always ask if there is a way of
changing the existing program to make
adding the feature simpler.
After they have added a feature,
they ask if they can now see how to
make the program simpler
17
Slide 18
Slide 18 text
7. Pair Programming
All production code is written with
two people looking at one machine
18
Slide 19
Slide 19 text
8. Collective Ownership
Code belongs to the team, not the individual
19
Slide 20
Slide 20 text
9. Continuous Integration
Make integration painless by doing it often
20
Slide 21
Slide 21 text
10. 40-Hours Week
Teams working overtime are failing
21
Slide 22
Slide 22 text
11. Customer On Site
A real customer must sit with the team
22
Slide 23
Slide 23 text
12. Coding Standards
The team controls the work environment
23
Slide 24
Slide 24 text
Se XP funziona così
bene, perché non lo
fanno tutti?
24
Slide 25
Slide 25 text
XP is hard
Involve the customer.
Take responsibility.
Learn. Study. Learn.
Give feedback.
25
Slide 26
Slide 26 text
It’s not the answer they
want to hear
26
Slide 27
Slide 27 text
It’s just
“good programming
practice”
http://blog.8thlight.com/uncle-bob/2013/12/10/Thankyou-Kent.html
27
Slide 28
Slide 28 text
Community!
Milano XPUG User Group
Italian Agile Day
Agile Coach Camp, 5-7 giugno
milano-xpug.pbworks.com
agileday.it
accitaly.wordpress.com
https://it.groups.yahoo.com/neo/groups/extremeprogramming-it/info
28
Slide 29
Slide 29 text
Grazie per l’attenzione!
Sono
freelance!
Contattami!
Corso TDD:
17-18 aprile, Bologna
12-13 giugno, Milano
www.avanscoperta.it
29