Extreme Programming (XP)

[seminar surveyer]

---

By:
Anu Gude
Syed Rahila

[attachment=7740]

Presentation Outline
Overview of Extreme Programming
Key Practices of Extreme Programming
Advantages of XP
Disadvantages of XP
Summary/Conclusions
References/Links
Overview
Extreme Programming (XP) was conceived and developed by Kent Beck to address the specific needs of software development conducted by small teams in the face of vague and changing requirements.
Extreme Programming nominates coding as the key activity.
The programmer is the heart of XP.
Overview
Why Extreme?
XP takes commonsense principles and practices to extreme levels.
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).
If design is good, we’ll make it part of everybody’s daily business (refactoring).
If integration testing is important, then we’ll integrate and test several times a day.
If short iterations are good, we will make the iterations really, really short – seconds, minutes and hours, not weeks, months and years.
Overview
This new lightweight methodology challenges many conventional tenets, including the long-held assumption that the cost of changing a piece of software rises dramatically over the course of time.
The cost of change curve for XP is a flat curve, which is achieved by simple design, tests, and an attitude of constant refinement of the design.
Overview
Historical Cost of Change Curve - The cost of change rising exponentially over time
Overview
XP Cost of Change Curve - The cost of change may NOT rise over time
Overview
Fundamentals of XP include:
Writing unit tests before programming and keeping all of the tests running at all times.
Integrating and testing the whole system--several times a day.
Producing all software in pairs, two programmers at one screen.
Starting projects with a simple design that constantly evolves to add needed flexibility and remove unneeded complexity.
Putting a minimal system into production quickly and growing it in whatever directions prove most valuable.
Overview
Why is XP so different?
XP doesn't force team members to specialize and become analysts, architects, programmers, testers, and integrators--every XP programmer participates in all of these critical activities every day.
XP doesn't conduct complete up-front analysis and design--an XP project starts with a quick analysis of the entire system, and XP programmers continue to make analysis and design decisions throughout development.
Develop infrastructure and frameworks as you develop your application, not up-front--delivering business value is the heartbeat that drives XP projects.
Don't write and maintain implementation documentation--communication in XP projects occurs face-to-face, or through efficient tests and carefully written code.
Overview
XP - What is involved: The four basic activities of Extreme Programming are coding, testing, listening, and designing.

Coding: You code because if you don't code, at the end of the day you haven't done anything.
Testing: You test because if you don't test, you don't know when you are done coding
Listening: You listen because if you don't listen you don't know what to code or what to test
Designing: And you design so you can keep coding and testing and listening indefinitely (good design allows extension of the system with changes in only one place)

---