$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
Tweet

More Decks by Matteo Vaccari

Other Decks in Technology

Transcript

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  5. 5

    View Slide

  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

    View Slide

  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

    View Slide

  8. Barry
    Boehm
    Kent Beck
    Kent Beck, Extreme Programming Explained
    8

    View Slide

  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

    View Slide

  10. Presupposti
    •Team.
    •Personalità risolte.
    •Cliente coinvolto.
    10

    View Slide

  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

    View Slide

  12. 1. Planning Game
    (Scrum)
    Planning game
    Business people
    Scope
    Priority
    Dates
    Technical people
    Estimates
    Consequences
    Process
    12

    View Slide

  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

    View Slide

  14. 3. Metaphor
    (Domain-Driven Design)
    Ubiquitous Language
    Simple models
    14

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  18. 7. Pair Programming
    All production code is written with
    two people looking at one machine
    18

    View Slide

  19. 8. Collective Ownership
    Code belongs to the team, not the individual
    19

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  26. It’s not the answer they
    want to hear
    26

    View Slide

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

    View Slide

  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

    View Slide

  29. Grazie per l’attenzione!
    Sono
    freelance!
    Contattami!
    Corso TDD:
    17-18 aprile, Bologna
    12-13 giugno, Milano
    www.avanscoperta.it
    29

    View Slide