eXtreme Programming - PowerPoint PPT Presentation

1 / 32
About This Presentation
Title:

eXtreme Programming

Description:

More information about XP can be found at http://c2.com/cgi/wiki?ExtremeProgrammingRoadmap ... Robert Martin. Martin Fowler. XP-eXtreme Programming ... – PowerPoint PPT presentation

Number of Views:104
Avg rating:3.0/5.0
Slides: 33
Provided by: MarkGu
Category:

less

Transcript and Presenter's Notes

Title: eXtreme Programming


1
eXtreme Programming
  • CS2340
  • Spring 2003

2
XP References
  • Diagrams in this presentation are from
    http//www.extremeprogramming.org
  • More information about XP can be found at
    http//c2.com/cgi/wiki?ExtremeProgrammingRoadmap
  • Extreme Programming Explained, Kent Beck,
    Addison-Wesley
  • comp.software.extreme-programming

3
The Three Extremos
  • Ward Cunningham
  • Kent Beck
  • Ron Jefferies
  • Other notables
  • Robert Martin
  • Martin Fowler

4
XP-eXtreme Programming
  • Focus on the simplest thing that could possibly
    work.
  • An approach to programming particularly
    appropriate for
  • Small team (2-10 programmers)
  • High risk
  • Rapid changing or unstable requirements
  • Requires testability
  • Main focii
  • Communication, simplicity, feedback, courage

5
Kent Communication, simplicity, feedback,
courage
  • Its all about communication
  • With users via User Stories and CRC Cards
  • With other programmers via Pair Programming
  • Simplicity
  • We code no feature before its time
  • Feedback
  • From the users
  • From the code via Unit Tests
  • Courage It all does work, but it goes against
    much of common wisdom

6
(No Transcript)
7
The Overall XP Lifecycle
8
User Stories
  • The Customer contacts an XP development group to
    start a project. An XP team insists that the
    Customer sit with their team the whole time
    they're developing. An XP project typically has
    three phases
  • an exploration phase, where the Customer writes
    stories, the Programmers estimate them, and the
    Customer chooses which stories will be developed
  • an iteration phase, where the Customer writes
    tests and answers questions, while the
    Programmers program and
  • a release phase, where the Programmers install
    the software, and the Customer (hopefully)
    accepts the result.
  • The Customer in XP has frequent opportunities to
    change the team's direction if circumstances
    change. Because testing is so prominent, the
    Customer is aware of the project's true status
    much earlier in the cycle.

9
User Stories
  • Basis for
  • Requirements
  • Test Cases
  • Project Plan
  • Estimate by User Story
  • Velocity for overall tracking
  • Workload distribution through sign-up

10
Daily Standup Meeting
  • Communication among the entire team is the
    purpose of the stand up meeting.
  • A stand up meeting every morning is used to
    communicate problems, solutions, and promote team
    focus.
  • Everyone stands up in a circle to avoid long
    discussions.
  • It is more efficient to have one short meeting
    that every one is required to attend than many
    meetings with a few developers each.
  • With limited attendance most meetings can take
    place spontaneously in front of a computer, where
    code can be browsed and ideas actually tried out.

11
Unit Tests
  • A unit test is written BEFORE THE CODE IS WRITTEN
    for each piece of the system.
  • When you create your tests first, before the
    code, you will find it much easier and faster to
    create your code.
  • The combined time it takes to create a unit test
    and create some code to make it pass is about the
    same as just coding it up straight away.
  • But, if you already have the unit tests you don't
    need to create them after the code, saving you
    some time now and lots later.
  • Eases regression testing
  • JUnit (for Java), SUnit (for Smalltalk), CppUnit
    (for C allow for running all unit tests.
  • When a bug is found, a new unit test is written
    to catch that bug in the future

12
SUnit
13
Pair Programming
  • Pair programming increases software quality
    without impacting time to deliver.
  • All code to be included in a production release
    is created by two people working together at a
    single computer.
  • Any code written by an individual must be thrown
    out
  • It is counter intuitive, but 2 people working at
    a single computer will add as much functionality
    as two working separately except that it will be
    much higher in quality. With increased quality
    comes big savings later in the project.
  • The best way to pair program is to just sit side
    by side in front of the monitor. Slide the key
    board and mouse back and forth.
  • One person types and thinks tactically about the
    method being created, while other thinks
    strategically about how that method fits into the
    class.

14
Does Pair Programming work?
  • Laurie Williams Utah dissertation
  • Two classes, one pairedone traditional
  • Paired students had lower performance at first
  • By end of class, paired students had
  • More function points completed
  • Fewer bugs
  • In less time!

15
Part of the goal is Learning
  • From WikiWikiWeb
  • Pair up your people.
  • When applicable, each pair should have a
    relatively experienced and a relatively
    inexperienced person.
  • For work being done at a computer, put the
    relatively inexperienced person at the keyboard,
    so everything the experienced person says has to
    flow through the novice to the computer.
  • The point is not for the guru to dictate to the
    greenhorn on the contrary, putting the novice at
    the keyboard is meant to keep him or her more in
    the loop.

16
Integrate Constantly
  • Developers should be integrating and releasing
    code into the code repository every few hours,
    whenever possible.
  • In any case never hold onto changes for more than
    a day.
  • Continuous integration often avoids diverging or
    fragmented development efforts, where developers
    are not communicating with each other about what
    can be re-used, or what could be shared.
  • Everyone needs to work with the latest version.
  • Changes should not be made to obsolete code
    causing integration head aches.
  • Use Unit Tests to facilitate Integration

17
40 Hour Work Weeks
  • You cant make a pregnancy take only three
    months by putting three mothers on it. Fred
    Brooks
  • Overtime is not the solution to bad development
    efforts
  • XP Rule No more than two overtime weeks in a
    row
  • Exhausted developers are not efficient
  • Defect reduction strategy

18
Refactor Mercilessly
  • We computer programmers hold onto our software
    designs long after they have become unwieldy.
  • We continue to use and reuse code that is no
    longer maintainable because it still works in
    some way and we are afraid to modify it.
  • But is it really cost effective to do so?
  • Extreme Programming (XP) takes the stance that it
    is not.
  • When we remove redundancy, eliminate unused
    functionality, and rejuvenate obsolete designs we
    are refactoring.
  • Refactoring throughout the entire project life
    cycle saves time and increases quality.
  • Refactor mercilessly to keep the design simple as
    you go and to avoid needless clutter and
    complexity. Keep your code clean and concise so
    it is easier to understand, modify, and extend.
    Make sure everything is expressed once and only
    once. In the end it takes less time to produce a
    system that is well groomed.

19
Avoid new functionality
  • Keep the system uncluttered with extra stuff you
    guess will be used later.
  • Only 10 of that extra stuff will ever get used,
    so you are wasting 90 of your time.
  • We are all tempted to add functionality now
    rather than later because we see exactly how to
    add it or because it would make the system so
    much better.
  • It seems like it would be faster to add it now.
  • But we need to constantly remind ourselves that
    we are not going to actually need it.
  • Extra functionality will always slow us down and
    squander our resources.
  • Turn a blind eye towards future requirements and
    extra flexibility.
  • Concentrate on what is scheduled for today only

20
One of Four Hats
  • Kent Beck
  • When you are coding you should only be wearing
    one of four different hats.
  • Refactoring code, but only changing the interface
  • Refactoring code, but only changing the
    implementation
  • Adding new functionality, but only changing the
    interface
  • Adding new functionality, but only changing the
    implementation.

21
Example of Refactoring
  • (Kent Beck on the Refactoring Browser in
    Smalltalk)
  • If I notice
  • ...
  • area aRectangle right - aRectangle left
    (aRectangle bottom - aRectangle top).
  • ....
  • I select the statement to the right of the
    assignment and "extract method", naming the new
    method areaOf. Now I have
  • ...
  • area self areaOf aRectangle.
  • ...
  • areaOf aRectangle
  • aRectangle right - aRectangle left
    (aRectangle bottom - aRectangle top)

22
Example (contd)
  • Now I notice that aRectangle cares a lot more
    about this message than I do
  • area self areaOf aRectangle.
  • ...
  • areaOf aRectangle
  • aRectangle area
  • Rectanglegtgtarea
  • self right - self left (self bottom - self
    top)
  • Now, areaOf isn't doing me much good
  • ...
  • area aRectangle area.
  • ...
  • Rectanglegtgtarea
  • self right - self left (self bottom - self
    top)

23
Key Idea
  • We only do one refactoring a time
  • We follow standard refactorings
  • Therefore
  • Design is improved
  • We verify each change with our unit tests

24
XP is against BigDesignUpFront
  • The Code is the Design
  • When the original phases of software development
    were laid down, they were just plain wrong.
    Requirements, Design, Implementation, and Test
    are not what we think they are. Design is not
    something that you do only before you code.
    Implementation is not the act of coding. We can
    see this if we look realistically at what they
    are in other engineering disciplines.
  • "The final goal of any engineering activity is to
    create some kind of documentation.
  • After reviewing the software development
    lifecycle today, it appears that the only
    software documentation that actually seems to
    satisfy the criteria of an engineering design are
    the source code listings.
  • XP is often accused of not believing in comments.
    Thats not exactly true.
  • They do believe heavily in Self-documenting
    code
  • But they also believe The position of the
    article was not that source code makes all other
    documentation obsolete, it is simply that the act
    of programming is designing.

25
Ward Cunningham On Comments
  • We comment methods only after doing everything
    possible to make the method not need a comment.
  • We prefer to clarify the code directly over
    putting in an explanation of what the code could
    say it if were better done.
  • We have written "literate programs", cf DonKnuth,
    and no one has used them. Too bad, really, they
    were cool.

26
Can this really work?
  • There are several Fortune 500 companies that are
    now using XP, including Ford, Daimler-Chrysler,
    and First Union.
  • But it only works ALL TOGETHER. AlmostXP is
    like being AlmostAlive or AlmostSolvent.
  • The emphasis on readable code (even without
    comments) works because Pair Programming ensures
    readable code
  • The integrating constantly is made possible by
    the Unit Tests
  • The lack of up-front design effort works because
    the User is on-site, the user stories drive the
    effort, and theres a high degree of
    communication among the team members, and
    refactoring continually improves the existing
    code base

27
The Overall XP Lifecycle
28
XP Path
29
XP Development
30
XP Collective Code Ownership
31
Lessons Learned
32
XP in Perspective
  • People tend to love XP or ridicule it
  • If you dont have a specification, your program
    cant be wrong!
  • In reality, its not a binary choice. XP is at
    one extreme end of the process spectrum.
  • There is much interest these days in so-called
    agile methodologies which generally are much
    closer to XP than to traditions heavyweight
    approaches.
Write a Comment
User Comments (0)
About PowerShow.com