e

Xtreme Programming
Team members : Gaurav Agarwal (101243) Kushagra Kasbi (101253) Sahil Lamba (101285) Shiva Arora (101316)

Why Is It Called eXtreme?

XP takes commonsense principles and practices to extreme levels. If code reviews are good, well review code all the time (pair programming). If testing is good, everybody will test all the time (unit testing). If design is good, well make it part of everybodys daily business (refactoring). If integration testing is important, then well 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.

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.

Key Assumption of XP
The cost of change curve can be flattened
How?
Better program organization (object-oriented) Simple designs kept simple with refactoring Automated testing to maintain integrity Better tools and faster machines

Because of this we can:

Make decisions later, defer costs, keep options open Reduce the time-to-ROI with partial solutions Learn from feedback, adapt to change

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

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.

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)

XP Values
Communication
Simplicity Feedback Courage

Communication
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 arent communicating and reintroduce them Is this a role for yours truly in our class?
11

Simplicity
''Do the simplest thing that could possibly work'' (DTSTTCPW) principle Elsewhere known as KISS A coach may say DTSTTCPW when he sees an XP developer doing something needlessly complicated

YAGNI principle (''You aint gonna need it'')

How do simplicity and communication support each other?
12

Feedback
Feedback 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
13

How does valuing feedback turn the waterfall model upside down?

Courage

The courage to communicate and accept feedback

The courage (prototypes) to throw code away

The courage to refactor the architecture of a system Do you have what it takes?

14

XP Principles
Rapid Feedback
Assume Simplicity Incremental Change

Concrete Experiments
Open Honest Communication Work With Instincts Accepted Responsibility Local Adaptation Travel Light Honest Measurement

Embracing Change
Quality Work Teach Learning

Small Initial Investment

Play to Win

XP Practices

XP Practices: Whole Team

All contributors to an XP project are one team Must include a business representative--the Customer
Provides requirements Sets priorities Steers project

Team members are programmers, testers, analysts, coach, manager Best XP teams have no specialists

XP Practices: Planning Game

Customer comes up with a list of desired features for the system
How is this different from the usual requirements gathering?

Each feature is written out as a user story

Describes in broad strokes what the feature requires Typically written in 2-3 sentences on 4x6 story cards

Developers estimate how much effort each story will take, and how much effort the team can produce in a given time interval (iteration)
Project velocity = how many days can be committed to a project per week
Why is this important to know? Given developer estimates and project velocity, the customer prioritizes which stories to implement Why let the customer (rather than developer) set the priorities?

XP Practices: Customer Tests

The Customer defines one or more automated acceptance tests for a feature
Team builds these tests to verify that a feature is implemented correctly Once the test runs, the team ensures that it keeps running correctly thereafter

System always improves, never backslides

XP Practices: Small Releases

Team releases running, tested software every iteration Releases are small and functional The Customer can evaluate or in turn, release to end users, and provide feedback Important thing is that the software is visible and given to the Customer at the end of every iteration

XP Practices: Simple Design

Build software to a simple design Through programmer testing and design improvement, keep the software simple and the design suited to current functionality Not a one-time thing nor an up-front thing Design steps in release planning and iteration planning Teams design and revise design through refactoring, through the course of the project

XP Practices: Pair Programming

All production software is built by two programmers, sitting side by side, at the same machine All production code is therefore reviewed by at least one other programmer Research into pair programming shows that pairing produces better code in the same time as programmers working singly Pairing also communicates knowledge throughout the team

XP Practices: Test-Driven Development

Teams practice TDD by working in short cycles of adding a test, and then making it work Easy to produce code with 100 percent test coverage These programmer tests or unit tests are all collected together Each time a pair releases code to the repository, every test must run correctly

XP Practices: Design Improvement

Continuous design improvement process called refactoring:
Removal of duplication Increase cohesion Reduce coupling

Refactoring is supported by comprehensive testing-customer tests and programmer tests

XP Practices: Continuous Integration

Teams keep the system fully integrated at all times
Daily, or multiple times a day builds Avoid integration hell Avoid code freezes

XP Practices: Collective Code Ownership

Any pair of programmers can improve any code at any time No secure workspaces All code gets the benefit of many peoples attention Avoid duplication Programmer tests catch mistakes Pair with expert when working on unfamiliar code

XP Practices: Coding Standard

Use common coding standard
All code in the system must look as though written by an individual Code must look familiar, collective code ownership to support

XP Practices: Metaphor
XP Teams develop a common vision of the system
With or without imagery, define common system of names

Ensure everyone understands how the system works, where to look for functionality, or where to add functionality

XP Practices: Sustainable Pace

Team will produce high quality product when not overly exerted Avoid overtime, maintain 40 hour weeks Death march projects are unproductive and do not produce quality software Work at a pace that can be sustained indefinitely

The Overall XP Lifecycle

Fall 2004

30

XP Path

Fall 2004

31

XP Development

Fall 2004

32

XP Collective Code Ownership

Fall 2004

33

Advantages/Disadvantages
ADVANTAGES Customer focus increase the chance that the software produced will actually meet the needs of the users The focus on small, incremental release decreases the risk on your project:
by showing that your approach works and by putting functionality in the hands of your users, enabling them to provide timely feedback regarding your work.

Continuous testing and integration helps to increase the quality of your work XP is attractive to programmers who normally are unwilling to adopt a software process, enabling your organization to manage its software efforts better.

Advantages/Disadvantages
DISADVANTAGES

XP is geared toward a single project, developed and maintained by a single team. XP is particularly vulnerable to "bad apple" developers who: don't work well with others who think they know it all, and/or who are not willing to share their "superior code XP will not work in an environment where a customer or manager insists on a complete specification or design before they begin programming. XP will not work in an environment where programmers are separated geographically. XP has not been proven to work with systems that have scalability issues (new applications must integrate into existing systems).

Conclusion
XP focuses on people Values team work over power XP works well when there are uncertain or volatile requirements XP is a process not a miracle cure for all software development

problems

Thank You !!