CHAPTER Installing Windows XP Professional and Windows Server 2003
Xp presentation 2003
-
Upload
eaiti -
Category
Technology
-
view
90 -
download
1
Transcript of Xp presentation 2003
eXtreme Programming
A lightweight development process for small to medium-sized
projects (an Agile Process)
by Shahid N. Shah
Slide 2 of 18
Sampling of Available Methodolgies
Waterfall*
Extreme Programming
Crystal Family (Alistair Cockburn)
Open Source
Adaptive Software Development (Jim Highsmith)
SCRUM
Feature Driven Development (FDD, Jeff De Luca and Peter Coad)
Dynamic System Development Method (DSDM, $$)
Rational Unified Process ($$)*
* Non-agile
Slide 3 of 18
XP Philosophy
Always ask yourself: “what is the simplest thing that could possibly work?” -- Kent Beck, XP Creator
Never do any more coding, more testing, more process, or more documentation than is absolutely necessary to delight the customer.
Main values: Communication, Feedback, Simplicity, and Courage
Formalize and do what has been known by “smart guys” for years
Not a “license to hack”!
Slide 4 of 18
XP Key Practices
Adaptive, not predictiveThe Planning Game -- Quick, up-date as needed, 80/20 rule, push out what doesn’t need to be immediately decidedSmall releases -- Get simple system into production quickly, add features in small releasesSimple design -- Design as simple as possibleRefactoring -- Continuously restructure to simplify, remove duplication40 hour weekOn-site customer -- collective ownershipTravel light -- No more documentation than needed to support deployment of application
Slide 5 of 18
Customer’s bill of rights
To set objectives for the project and have them followed.
To know how long the software project will take and how much it will cost.
To decide which features are in and which are out of the software.
To know the project’s status.
To make reasonable changes to requirements throughout the course of the project and to know the costs of making these changes.
To be apprised regularly of risks that could affect cost, schedule or quality.
To have ready access to project deliverables throughout the project.
Slide 6 of 18
Developer’s Bill of Rights
To know the project objectives and to be able to clarify priorities.
To know in detail what product I’m supposed to build.
To have ready access to the customer, manager, marketer, or other person responsible for the functionality.
To work each phase of the project in a technically responsible way.
To approve effort and schedule estimates for any work that I will be asked to perform.
To have my project’s status reported accurately to customers and upper management.
To work in a productive environment free from frequent interruptions.
Slide 7 of 18
Benefits of XP
Software stays soft
Handles changing requirements with relative ease
Quickly produces something useful, keeps making useful enhancements -- delivery is provided when customer is ready
Average developers can produce great software
Slide 8 of 18
Prerequisites
Flexible Project Management
Goal is to delight customers and not to maintain process (though they are not mutually exclusive)
Groups that can talk to each other
Close contact with users
Slide 9 of 18
Obvious things to do
Staged Deliverycontinuous stream of value feedbackadapt to change
Business people make business decisions and technical people make technical decisions
Regression testing, unit tests
Review designs and code
Slide 10 of 18
Extreme Programming
Analysis
Test
Code
Design
Project Management
Slide 11 of 18
Extreme Analysis
Describe system as a set of user stories (storyboards)
Users write stories explaining one use of the system (explain by example)
Like use cases, but informal (no special tools are needed)
Realize that all artifacts created during design will rarely be updated after implementation
Slide 12 of 18
Extreme Testing
Write tests before code unit tests before each class end-to-end tests before any classes
Convert each user story into a set of tests All unit tests must run 100% all the time
Don’t worry if you can’t test everything GUI real-time I/O complete coverage
Don’t worry if testing is expensive
Slide 13 of 18
Extreme Coding
Eliminate code in favor of configurationWrite code for test cases one at a timeWrite the simplest thing that could possibly work Goal: make the tests work ASAP
write new classes use/change old classes copy code add if statements
Enforce coding standards
Slide 14 of 18
Pair Programming
All code is written in pairs
Pairs talk continually
Pair switches driver frequently
People switch pairs several times a day
Continuous code review
Slide 15 of 18
Refactoring:Extreme Design
Make sure each thing is done in one place - eliminate all duplicate code
Make sure each class/function does one thing
All code must be readable
All tests run
Slide 16 of 18
Extreme Design
Project starts with a few days of design on white-boards/CRC cards
Major problems lead to group design sessions (servers, objects, etc)
Documentation is after the fact, and no more than necessary
Start simple, refactor to keep simple
Slide 17 of 18
Extreme Scheduling
Customer write stories
Developers estimate cost
Customer decides which to do next
Group a few weeks worth of stories into an iteration
Developers implement stories one at a time until iteration is finished
Slide 18 of 18
What is Extreme?
Extreme, but not unusual user stories, schedule negotiation, staged
delivery, testing, simplicity
Extreme and unusual pair programming continuous refactoring
Slide 19 of 18
Conclusion
Produce consistently better applications with fewer people (or less qualified people), in less time, with higher quality and significantly lower overall cost.