Extreme Programming

By: Amuno Mazino Student No.:20101126

Agenda
Whats eXtreme Programing

The Overall XP Lifecycle

What is Extreme Programming?

Created by Kent Beck in mid 1996

Agile 4 Principles
1.

Communication
XP encourages extreme communication between

the customer and programmer Put the customer on the development team and release working versions every 2 to 4 weeks
Programmers work in pairs:

Two people to

every one machine.

owned by the team, not by individuals Pair programming also is excellent in matching up programmers of differing abilities e.g mentor inexperienced programmers Pair Programming provides constant code

Agile 4 Principles
2.

Feedback The faster change is identified, the faster it can be dealt with. When customers write new user stories, programmers estimate time required to deliver changes Unit Tests are written for most every piece of production code. Unit tests must run at 100% before any code is checked in Acceptance Tests are written with the customer to verify the application is doing what the customer needs it to do.

Agile 4 Principles
3.

Simplicity The customer is the ultimate driving force in XP Do what the customer needs, as simply as possible, and nothing else. All code should be refactored as often as possible Refactoring is a process of improving a code's structure without changing its functionality Refactoring produces highly decoupled objects which makes them easy to test, easy to use, more flexible, and therefore, more changeable.

Agile 4 Principles
4.

Courage

No more fragile code! The courage to communicate and accept feedback The courage to throw code away (prototypes) The courage to refactor the architecture of a system

The Overall XP Lifecycle

XP Development

XP 12 Practices
The XP practices we will emphasize are: Planning Game Testing Refactoring Simple Design Collective Ownership Metaphor Continuous Integration On-Site Customer Pair Programming Small Releases Coding Standards 40-Hour week 11

Planning Game
Each iteration begins with the Planning Game, an

12

informal process that sets the agenda for the iteration. The game starts with the customer defining requirements, or 'user stories'. Technical members work with the customer to normalize these stories into manageable chunks and break them down into specific tasks. Based on the time estimates given combined with the team's velocity (average number of stories/tasks the team has completed in past iterations), the user stories are prioritized by the

Testing
Testing is a crucial practice on an XP project XP succeeds by making a project resilient.

Resilience means accurate and frequent feedback In XP, there are two categories of tests: unit tests and acceptance tests.
A unit test is a piece of code that exercises one

aspect of a piece of production code. Unit tests should be small and fast
Acceptance tests are distinguished from unit tests

in a couple of ways.
First, they should test the system end-to-end
13

Second, the customer is involved in creating the

Refactoring
Refactoring is the process of improving the

design of code without changing the functionality. The code should be clean and readable. Any duplication should be consolidated. Refactorings should be done on an ongoing basis throughout development of the code. As soon as structure improvements make themselves known, they should be done. Unit tests provide the quick feedback required to steer a programmer back on track during a refactoring.

14

Simple Design
The main reason for this is to eliminate

15

unnecessary development time It's easy for the technical members of a team to overdo aspects of the project because we might need it. Here we come to a couple of XP's acronyms: YAGNI and DTSTTCPW. YAGNI stands for "You Aren't Going To Need It." Too often, the team attempts to build in functionality they might need in the future DTSTTCPW stands for "Do The Simplest Thing That Could Possibly Work."

Collective Ownership
Collective ownership refers to the code

Collective ownership allows anyone on the team

16

at any time to work with any piece of code. In an XP project, however, every piece of code is developed test- first, ensuring each piece of functionality is unit tested XP aims to avoid hang- ups caused by individual ownership by focusing ownership of the team on the whole One concern about collective ownership is ensuring each programmer is a positive contributor to the team and not riding on others'

Metaphor-(Imagine it!)
The project metaphor is, more or less, an informal

architecture of the system. The concepts can be literal or figurative, depending on the clarity of the actual system. A good metaphor can sometimes inspire improvements to the application itself. Since an XP project has little to no formal architecture documentation, the metaphor can be a useful tool to aid in communication among team members, especially between programmers and customer
17

Continuous Integration
To stay resilient, after writing new code that

passes all tests locally, programmers must then integrate their changes with the latest code base and ensure all the tests still pass It's recommended this task be done many times a day, usually on a dedicated integration machine

18

On-Site Customer
Every XP project has one or more individuals to

19

fulfill the customer role on the team. The customer's job is to write and prioritize stories (tasks from a user's perspective that the software must perform), assist with acceptance testing Be on hand to answer questions from the development team as they arise The project starts and ends with the customer! Having the customer be an active member of the team provides for frequent and cheap communication

Pair Programming
All programming on an XP team is done in pairs,

20

two people at one machine. One takes a turn 'driving' while the other actively participates verbally As ideas flow between the two, the keyboard can be swapped off as often as necessary to get the best code on the screen. Pair assignments are fluid and change throughout the course of a day. Loads of benefits in pair programming!

Small Releases
Small releases are a key part of generating

feedback and making a project resilient An XP project is a series of iterations, each lasting 2 to 4 weeks Each release may or may not be a production release, especially in the early days of a project. Small releases also help the technical members of the team give accurate estimates. Any time estimate beyond 2 to 4 weeks tend to be very imprecise
21

Coding standards
Coding standards make it simpler for your teammates (or yourself, weeks later) to read your code Java has some very well defined conventions you should learn Some conventions are strictly mechanical, such as formatting (spacing and indentation)
Eclipse can, upon request, correct your formatting for you

Some conventions require human intelligence Use meaningful names, with the correct part of speech Use adequate comments, written for the correct audience Prefer clearly written code to clever code

22

40-Hour week
XP promotes a well rested team

Its founders do not believe in the extended

overtimes, which creates fatigue and defeats concentration Tired workers make mistakes and their desire to work decreases. Getting the best from your worker does not need overtime!

23

Successful XP Projects
Very rapid development

Exceptional responsiveness to user and customer

change requests High customer satisfaction Amazingly low error rates System begins returning value to customers very early in the process

XP Ground rules!
Extreme Programming (XP) is a lightweight process
Small team (2 to 12) Continuous access to customers OO design and code (Smalltalk, Java) Change management system (code and tests) The system is always working (growing functionality over time) Overall development cycle between 4 and 12 months New release to customer every 2-3 months Internal iterations every two weeks Not for life-critical systems (heart monitor, nuclear power plant,

avionics systems, etc.)

XP Advantages
Built-In Quality

Overall Simplicity
Programmer Power Customer Power Synergy Between Practices

26

XP Disadvantages
Informal, little, or no documentation

Scalability
Contract Issues Misconception on the cost of change Tailoring

27

Conclusion
People tend to love XP or ridicule it
If you dont have a specification, your program

cant be wrong!

In reality, its not a binary choice. XP is at one

extreme end of the process spectrum. There is much interest these days in so-called agile methodologies which generally are much closer to XP than to traditional heavyweight approaches.

28

Q&A