Extreme Programming

Publish in

Documents

11 views

Please download to get full document.

View again

of 44
All materials on our website are shared by users. If you have any questions about copyright issues, please report us to resolve them. We are always happy to assist you.
Share
Description
Extreme Programming. Sylvain Giroux October 3 rd , 2000. Plan. The Problem to Solve XP: What? Why? When? “X” ? Software Methodolgy Variables Values Rules Practices References. Risk: The Basic Problem. Software development fails to deliver, and fails to deliver value.
Transcript
Extreme ProgrammingSylvain GirouxOctober 3rd, 2000Plan
  • The Problem to Solve
  • XP: What? Why? When?
  • “X” ?
  • Software Methodolgy
  • Variables
  • Values
  • Rules
  • Practices
  • References
  • Risk: The Basic Problem
  • Software development
  • fails to deliver,
  • and fails to deliver value.
  • Schedule slips
  • Project canceled
  • System goes sour
  • Defect rate
  • Business misunderstood / changes
  • False feature rich
  • Staff turnover
  • Software methodology
  • A software methodology is the set of rules and practices used to create computer programs.
  • A heavyweight methodology has many rules, practices, and documents. It requires discipline and time to follow correctly.
  • Rational Unified Process (1491 files in 159 folders)
  • A lightweight methodology has only a few rules and practices or ones which are easy to follow.
  • Extreme Programming
  • a lightweight discipline of software development
  • for small size teams (2-10 people)
  • to develop software
  • quickly
  • in an environment of rapidly-changing requirements.
  • Goal of XP
  • to deliver the software
  • that is needed
  • when it is needed.
  • When to use XP?
  • problem domains whose requirements change
  • may not have a firm idea of what the system should do
  • a system whose functionality is expected to change every few months.
  • to address the problems of project risk.
  • If your customers need a new system by a specific date
  • the risk is high.
  • If that system is a new challenge for your software group
  • the risk is even greater.
  • If that system is a new challenge to the entire software industry
  • the risk is greater even still.When to use XP?
  • XP requires an extended development team.
  • the developers
  • the managers
  • the customers
  • Why?
  • asking questions,
  • negotiating scope and schedules,
  • creating functional tests
  • require more than just the developers be involved in producing the software.
  • When to use XP?
  • Testability
  • Productivity
  • XP projects unanimously report greater programmer productivity when compared to other projects within the same corporate environment.
  • Why Extreme ? -- I
  • If code reviews are good,
  • we’ll review code all the time (pair programming).
  • If testing is good,
  • everybody will test all the time (unit testing), even the customers (functional testing)
  • If design is good,
  • we’ll make it part of everybody’s daily business (refactoring)
  • If simplicity is good,
  • we’ll always leave the system with the simplest design that supports current functionality (the simplest thing that could possibly work).Why Extreme ? -- II
  • If architecture is important,
  • everybody will work defining and refining the architecture all the time (metaphor)
  • If integration testing is important,
  • we’ll integrate and test several times a day (continuous integration).
  • If short iterations are good,
  • we’ll make the iterations really, really short –seconds and minutes and hours, not weeks and months and years (the Planning Game).Four Variables
  • We will control four variables in our projects
  • Cost
  • Time
  • Quality
  • Scope
  • External forces (customers and managers) get to pick the values of 3 of the variables.
  • The development team gets to pick the resultant value of the 4th variable.
  • Values
  • XP is based on
  • Communication
  • Simplicity
  • Feedback
  • Courage.
  • Value : communication
  • Problems with projects can invariably be traced back to somebody not talking to somebody else about something important
  • A programmer doesn’t tell someone else about a critical change in the design
  • A programmer doesn’t ask the customer the right question, so a critical domain decision is blown
  • A manager doesn’t ask a programmer the right question, and project progress is misreported
  • Value : communication and XP Practices
  • XP practices that can’t be done without communication
  • Unit testing
  • Pair programming
  • Task estimation
  • Value : simplicity
  • What is the simplest thing that could possibly work?
  • Not to look toward the things you’ll need
  • tomorrow and next week and next month
  • XP stance:
  • It is better
  • to do a simple thing today and pay a little more tomorrow to change if it needs it,
  • than
  • to do a more complicated thing today that may never be used anywayValue : simplicity and XP Practices
  • The more you communicate,
  • the clearer you can see exactly what needs to be done and the more you have confidence about what really doesn’t need to be done
  • The simpler your system is,
  • the less you have to communicate about
  • Practices
  • Simple design
  • Refactoring
  • Value : Feedback at scale of minutes and days
  • Concrete feedback about the current state of the system
  • Don’t ask me, ask the system
  • Feedback for customers
  • When customers write new stories (description of features),
  • the programmers immediately estimate them
  • Feedback on project progress
  • Watching the completion of tasks to give the whole team
  • feedback about whether they are likely to finish everything they set out to do in a span of timeValue : Feedback at scale of weeks and months
  • The customers and testers write functional tests for all the stories (simplified use cases) implemented by the system.
  • The customers review the schedule every two or three weeks
  • to see if the team’s overall velocity matches the plan,
  • to adjust the plan
  • The system is put into production as soon as it makes sense,
  • so the business can
  • begin to “feel” what the system is in action and
  • discover how it can best be exploited.
  • Value : Feedback and XP practices
  • The more feedback you have,
  • the easier it is to communicate
  • Simple systems are easier to test
  • XP practices
  • The planning game
  • Small releases
  • Testing
  • Pair programming
  • Continuous integration
  • On-site customer
  • Value : Courage
  • Courage to take decisions
  • Radical surgery on code
  • Throwing code away
  • Starting over from scratch
  • Prototyping multiple design alternatives,
  • and keep only one for “real” developmentLast but not leastRespectPrinciplesFrom the 4 values, a dozen or so of principles (rules)are derived to guide the development styleCentral Principles
  • Main principles
  • Rapid feedback
  • time between action and feedback is critical
  • Assume simplicity
  • Incremental Change
  • Big change made all at once just don’t work
  • Embracing change
  • Preserves the most options while solving the most pressing problem
  • Quality work
  • Nobody likes working sloppy
  • Less central principles
  • Teach learning
  • No doctrine
  • Small initial investment
  • Too many resources too early in a project is a recipe for disaster
  • Play to win
  • Playing to win vs playing not to lose
  • For sure we need to write reports,
  • … but getting a working system is more important…
  • Concrete experiments
  • Every time you made a decision and you don’t test it,
  • there is some probability that the decision is wrong.Less central principles
  • Open, honest communication
  • Able to tell each other where there are problems in the code
  • Able to express fears and get support
  • Free to deliver bad news to customers and management,
  • to deliver it early, and without being punished
  • Work with people’s instincts, not against them
  • XP is a process
  • where following short-term self-interest (win, learn, be in control, good work…) also serves long-term team interest
  • Accepted responsibility
  • Not telling people what to do
  • Does not mean that you always do exactly what you feel like doing
  • Less central principles
  • Local adaptation
  • Adapt XP principles and practices to local conditions
  • Travel light
  • You can’t expect to carry a lot of baggage and move fast
  • Be prepared to change direction
  • Artifacts
  • Few
  • Simple
  • Valuable
  • Honest measurement
  • This will take 14.176 hours (???)
  • Back to basics
  • There are 4 activities to support
  • Coding
  • Testing
  • Listening
  • Designing
  • XP Practices
  • What is a practice?
  • the usual way of doing something
  • Aim of practices in XP:
  • Structure the 4 activities
  • Coding, testing, listening, designing
  • In XP, there are 12 practices
  • 12 Practices
  • The Planning Game
  • Small Releases.
  • Metaphor.
  • Simple Design.
  • Testing.
  • Refactoring.
  • Pair Programming.
  • Collective Ownership.
  • Continuous Integration.
  • 40-hour Week.
  • On-site Customer.
  • Coding Standard.
  • Practice: The Planning Game
  • The XP "customer“
  • define the business value of desired features
  • The programmer
  • provides cost estimates
  • The XP "customer“
  • choose
  • what needs to be done
  • what needs to be deferred
  • Practice: Small releasesXP teams
  • put a simple system into production early,
  • update it frequently on a very short cycle
  • Practice: MetaphorXP teams use
  • common "system of names" and a
  • common system description
  • that guide development and communication
  • We don’t literally mean “the system is…”
  • Give everyone a coherent story within which to work
  • Help everyone on the project understand the basic elements and their relationships
  • Practice: Simple design
  • A program built with XP should be
  • the SIMPLEST program that meets the current requirements.
  • There is not much building "for the future".
  • Practice: Testing
  • XP teams focus on validation of the software at all times.
  • Programmers develop software by writing tests first,
  • then software that fulfills the requirements reflected in the tests.
  • Customers provide acceptance tests
  • that enable them to be certain that the features they need are provided.Practice: Refactoring
  • XP teams improve the design of the system
  • throughout the entire development
  • This is done by keeping the software clean
  • without duplication
  • with high communication
  • simple
  • Yet complete
  • Practice: Pair Programming
  • XP programmers write all production code in pairs,
  • two programmers working together at one machine
  • Practice: Collective ownership
  • All the code belongs to all the programmers
  • This lets the team go at full speed,
  • because when something needs changing, it can be changed without delayPractice: Continuous integration
  • XP teams integrate and build the software system multiple times per day
  • This keeps all the programmers on the same page,
  • and enables very rapid progress
  • integrating more frequently tends to eliminate integration problems that plague teams who integrate less often
  • Practice: 40-hour week
  • Tired programmers make more mistakes.
  • XP teams do not work excessive overtime,
  • keeping themselves fresh, healthy, and effective
  • Practice: On-site customer
  • An XP project is steered by a dedicated individual who is empowered to
  • determine requirements,
  • set priorities,
  • answer questions as the programmers have them
  • Practice: Coding standards
  • to work effectively in pairs,
  • to share ownership of all the code,
  • all the programmers need to write the code in the same way
  • with rules that make sure the code communicates clearly
  • Software, naming, language, {}…XP mapA spike solution is a very simple program to explore potential solutions References
  • Kent beck, Extreme Programming Explained: Embrace Change, Addison Wesley, 2000
  • Martin Fowler, Refactoring : Improving the Design of Existing Code, Addison-Wesley, 1999
  • http://www.xprogramming.com
  • http://www.xprogramming.com/xpmag/index.htm
  • http://www.xprogramming.com/Practices/xpractices.htm
  • http://www.extremeprogramming.org/
  • Related Search
    We Need Your Support
    Thank you for visiting our website and your interest in our free products and services. We are nonprofit website to share and download documents. To the running of this website, we need your help to support us.

    Thanks to everyone for your continued support.

    No, Thanks