Extreme Programming is a light-weight methodology for small to medium-sized teams developing software in the face of vague or rapidly changing requirements. Developed by Kent Beck (earlier helped create Class-responsibility-collaboration card, a viable alternative to UML sequence diagram to design the dynamics of object interaction and collaboration.) which is an Alternative to “heavy-weight” software development models (which tend to avoid change and customers). Here is how IEEE view Extreme Programming.
"Extreme Programming turns the conventional software process sideways. Rather than planning, analyzing, and designing for the
far-flung future, XP programmers do all of these activities a little
at a time throughout development.”
-- IEEE Computer , October 1999
Success in industry
Chrysler Comprehensive Compensation system
–After finding significant, initial development problems, Beck and Jeffries restarted this development using XP principles
–The payroll system pays some 10,000 monthly-paid employees and has 2,000 classes and 30,000 methods, went into production almost on schedule, and is still operational today
Ford Motor Company VCAPS system
–Spent four unsuccessful years trying to build the Vehicle Cost and Profit System using traditional waterfall methodology
–XP developers successfully implemented that system in less than a year using Extreme Programming.
Scrum vs XP – What is the difference?
In traditional software life cycle models, the cost of changing a program rises exponentially over time. Why would it cost more to make large changes during testing than during requirements specification? A key assumption of XP is that the cost of changing a program can be hold mostly constant over time. Hence XP is a lightweight (agile) process.
Above pictures are self descriptive, anyway please check my other posting "Extreme Programming practices explained" for more detailed explanation.
Think about it, What does lack of communication do to projects?
XP emphasizes value of communication in many of its practices:
–On-site customer, user stories, pair programming, collective ownership (popular with open source developers), daily standup meetings, etc. XP employs a coach whose job is noticing when people aren’t communicating and reintroduce them
''Do the simplest thing that could possibly work'' (DTSTTCPW) principle. Elsewhere known as KISS (“Keep It Simple, Stupid!”). A coach may say DTSTTCPW when he sees an XP developer doing something needlessly complicated. Follow YAGNI principle (''You ain’t gonna need it''), keep it to the point of interest. simplicity and communication support each other,
Feedback is an essential tool for successful project deliveries. Feedback should be invited at different time scales. Unit tests tell programmers status of the system. When customers write new user stories, programmers estimate time required to deliver changes. Programmers produce new releases every 2-3 weeks for customers to review. Valuing feedback turn the waterfall model upside down.
XP teams (expected to) have the courage to communicate and accept feedback. They have the courage to throw code away (prototypes), and re-factor the architecture of a system. Design, architecture or prototype changes are no longer a worry for Software development process, do you see the change?
Without which you can never be successful, is our last value, Respect. Everyone gives and feels the respect they deserve as a valued team member. Everyone contributes value even if it's simply enthusiasm. Developers respect the expertise of the customers and vice versa. Management respects the team’s right to accept responsibility and receive authority over their work.