$30 off During Our Annual Pro Sale. View Details »

Extreme Programming

Extreme Programming

My presentation at Agile For Innovation http://www.agileforinnovation.com/ 14 march 2014

Matteo Vaccari

March 14, 2014

More Decks by Matteo Vaccari

Other Decks in Technology


  1. Matteo Vaccari @xpmatteo http://matteo.vaccari.name/ eXtreme Programming 1

  2. Cheap, fast, good. You can have it all. 2

  3. c2.com/cgi/wiki?ExtremeProgramming 3

  4. martinfowler.com/articles/xp2000.html 4

  5. 5

  6. 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
  7. "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
  8. Barry Boehm Kent Beck Kent Beck, Extreme Programming Explained 8

  9. 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
  10. Presupposti •Team. •Personalità risolte. •Cliente coinvolto. 10

  11. 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
  12. 1. Planning Game (Scrum) Planning game Business people Scope Priority

    Dates Technical people Estimates Consequences Process 12
  13. 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
  14. 3. Metaphor (Domain-Driven Design) Ubiquitous Language Simple models 14

  15. 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
  16. 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
  17. 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
  18. 7. Pair Programming All production code is written with two

    people looking at one machine 18
  19. 8. Collective Ownership Code belongs to the team, not the

    individual 19
  20. 9. Continuous Integration Make integration painless by doing it often

  21. 10. 40-Hours Week Teams working overtime are failing 21

  22. 11. Customer On Site A real customer must sit with

    the team 22
  23. 12. Coding Standards The team controls the work environment 23

  24. Se XP funziona così bene, perché non lo fanno tutti?

  25. XP is hard Involve the customer. Take responsibility. Learn. Study.

    Learn. Give feedback. 25
  26. It’s not the answer they want to hear 26

  27. It’s just “good programming practice” http://blog.8thlight.com/uncle-bob/2013/12/10/Thankyou-Kent.html 27

  28. 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
  29. Grazie per l’attenzione! Sono freelance! Contattami! Corso TDD: 17-18 aprile,

    Bologna 12-13 giugno, Milano www.avanscoperta.it 29