Completed by Firas M.

Kadhum Iraq - Baghdad

1- The problem 2- eXtreme Programming (XP) 2.1 Definition 2.2 Goals 2.3 Activities 2.4 Values 2.5 Project Lifecycle 2.6 Rules 2.7 Practices 2.8 What is so Extreme about XP ? 2.9 One of the successes in the industry 3- Conclusions 4- References
2

The basic problem of software development is risk. Here are some examples of risk: 1- Schedule slips 2- Business misunderstood 3- Defect rate 4- Project cancelled 5- System goes sour 6- Business changes

1- Schedule slips :
The day for delivery comes, and you have to tell the customer that the software won't be ready for another six months. This means : Many projects are not delivered on time. Some deadlines can not be moved.

What if :
Most business value is delivered on time.

2- Business misunderstood :
The software is put into production, but it doesn't solve the business problem that was originally posed . Without direct communication, developers have to guess what the customer wants.

What if :
Call for the customer to be an integral part of the team. The specification of the project is continuously refined during development, so learning by the customer and the team can be reflected in the software.
5

3- Defect rate :
The software is put in production, but the defect rate is so high that it isnt used.

What if :
You have automated testing.

4- Project cancelled :
After numerous slips, the project is canceled without ever going into production.
Size of project 1 function point 10 function points 100 function points 1,000 function points 10,000 function points 100,000 function points Average Early 14.68% 11.08% 6.06% 1.24% 0.14% 0.00% 5.53% On-Time 83.16% 81.25% 74.77% 60.76% 28.00% 13.67% 56.94% Delayed 1.92% 5.67% 11.83% 17.67% 23.83% 21.33% 13.71% Cancelled 0.25% 2.00% 7.33% 20.33% 48.00% 65.00% 23.82% Sum 100.00% 100.00% 100.00% 100.00% 100.00% 100.00% 100.00%

Table 1: Percentage of projects Early, On-Time, Delayed, Cancelled (from Patterns of Software Systems Failure and Success, by Capers Jones)

What if :
Short releases deliver at least some useful working software, reflecting investment to date.
7

5- System goes sour :

The software is successfully put into production, but after a couple of years the cost of making changes or the defect rate rises so much that the system must be replaced.

What if :
The design is simple and the code quality is high.

6- Business changes:
New laws, market changes: business priorities change.

What if :
The customer can change their mind, substitute functionality, and change priorities.

2.1 Definition :
Extreme Programming (more commonly known as XP). it is part of the agile movement that focuses on the writing of the software that will implement the required system. This may involve writing Java code, C++, C#, database tables , XML files, etc. In Other Words, XP is a light-weight methodology for small to medium-sized teams developing software in the face of vague or quickly changing requirements.
10

2.2 Goals:
eXtreme Programming is described as being: A path to improvement A style of development A software development discipline The main aim of XP is to lower the cost of change. In traditional system development methods like SSADM ; Structured Systems Analysis and Design Method is a systems approach to the analysis and design of information systems , the requirements for the system are determined at the beginning of the development project and often fixed from that point on. This means that the cost of changing the requirements at a later stage will be high. XP sets out to lower the cost of change by introducing basic values, principles and practices. By applying XP, a system development project should be more flexible with respect to changes.
11

Economics of software development

cost of change

cost of change

Cost of change

Requirements

Analysis

Design

Implementation

Testing

Production

Cost of change

Time

Time

Time

Fig1. The cost of change rising exponentially over time

Fig 2. Cost of change Vs Time in an XP project

By employing the XP ideology, it is quite clear that the cost of change over time can be greatly reduced as in figure (2) above.
12

2.3 Activities:
eXtreme Programming describes Four basic activities that are performed within the software development process: 1- Coding 2- Testing 3- Listening 4- Designing

13

1- Coding:
Without code, there is no working product. Coding can be used to figure out the most suitable solution. Coding can also help to communicate thoughts about programming problems.

14

2- Testing:
eXtreme Programmings approach is that if a little testing can eliminate a few flaws, a lot of testing can eliminate many more flaws. Testing comes in Two basic flavors :
1-Unit tests: Determine whether a given feature works as intended. A programmer writes as many automated tests as they can think of that might "break" the code; if all tests run successfully, then the coding is complete. Every piece of code that is written is tested before moving on to the next feature. 2-Acceptance tests: verify that the requirements as understood by the programmers satisfy the customer's actual requirements. These occur in the exploration phase of release planning.
15

3- Listening:
Programmers must listen to what the customers need the system to do, what "business logic is needed. They must understand these needs (or requirements) well enough to give the customer feedback about the technical aspects of how the problem might be solved, or cannot be solved.

16

4- Designing:
From the point of view of simplicity, one could say that system development doesn't need more than coding, testing and listening. If those activities are performed well, the result should always be a system that works. In practice, this will not work. One can come a long way without designing but at a given time one will get stuck. The system becomes too complex and the dependencies within the system cease to be clear. Developers can avoid this by creating a design structure that organizes the logic in the system. Good design will avoid lots of dependencies within a system; this means that changing one part of the system will not affect other parts of the system.

17

2.4 Values:
Underlying eXtreme Programming are Five basic values , these are: 1- Communication 2- Simplicity 3- Feedback 4- Courage 5- Respect

18

1- Communication:
It is good to talk ( particularly, between users and developers). So that means communication within a software team. The goal is to give all developers a shared view of the system which matches the view held by the users of the system. XP employs a coach whose job is noticing when people (developers , users) arent communicating and reintroduce them.

19

2- Simplicity :
Do the simplest thing that could possibly work. XP encourages starting with the simplest solution. And extra functionality can then be added later. The difference between this approach and more conventional system development methods is the focus on designing and coding for the needs of today instead of those of tomorrow, next week, or next month. If a simple solution is adopted, then it is easier for all to understand.
20

3- Feedback :
It is good to get feedback. Projects should get feedback early, and often, from the customer, from the team, from real end users, etc. Feedback helps to identify problems early on, deal with unknowns and clarify issues. That is, it generally helps avoid nasty shocks later on. Feedback can be at different time scales, for example : 1-Unit test tells programmers status of the system. 2-When customers write new user stories, programmers estimate time required to deliver changes. 3-Programmers produce new releases every 2-3 weeks for customers to review.
21

4- Courage :
You will need courage to adopt XP, Why? To communicate and accept feedback. To throw code away. To enable developers to feel comfortable with refactoring their code when necessary. This means reviewing the existing system and modifying it so that future changes can be implemented more easily. To remove source code that is obsolete, no matter how much effort was used to create that source code.

22

5- Respect :
The respect value includes respect for others as well as self-respect. Programmers should never commit changes that break compilation, that make existing unit-tests fail , or that otherwise delay the work of their peers. Nobody on the team should feel unappreciated or ignored. This ensures a high level of motivation and encourages loyalty toward the team and toward the goal of the project. Adopting the Four earlier values leads to respect gained from others in the team. Finally, this value is very dependent upon the other values, and is very much oriented toward people in a team.

23

2.5 XP Project Lifecycle:

24

1- User Stories:
A user story is a short description of what the business or customer wants the software to do, written by the customer. User Stories should be short (e.g., about Three sentences long).
The

Purpose:

1) User Stories are used to create time estimates for the release planning meeting. 2) User Stories are also used instead of a large requirements document. 3)They also drive the creation of the acceptance tests.

25

2- Architectural Spike:
A spike solution is a very simple program to explore potential solutions. Create spike solutions to figure out answers to tough technical or design problems. The goal is reducing the risk associated with an unknown area of the system, technology or application domain or increase the reliability of a user story's estimate.

26

3- Release Planning:
A release-planning meeting is used to create the release plan, which lays out the overall project. That is, the release plan indicates which user stories will be implemented and in which release this will happen. It also indicates how many iterations are planned and when each iteration will be delivered.

27

4- Iterations:
Iterative Development adds agility to the development process. Divide your Development schedule into about a dozen iterations of 1 to 3 weeks in length. One week is the best choice even though it seems very short. Keep the iteration length constant through out the project. This is the heart beat of your project. It is this constant that makes measuring progress and planning simple and reliable in XP. At the beginning of each iteration, an Iteration Planning meeting is held to determine exactly what will happen within that iteration (such as what programming tasks there will be and when they will be done).

28

5- Acceptance Testing:
Acceptance tests are created from user stories. Each iteration implements one or more user stories; these stories will be translated into a series of acceptance tests during the iteration. To do this, the customer must specify scenarios to test whether a user story has been correctly implemented. A story is not limited to one acceptance test and may be related to many acceptance tests (depending on the complexity of the scenario). The customers who evaluate the results of the acceptance tests and reviewing test scores to decide which failed tests are of highest priority. Acceptance tests are also used as regression tests prior to a production release.
29

6- Small releases Or Release:

The development team needs to release iterative versions of the system to the customers often. The release planning meeting should identify meaning chucks of system functionality that makes business sense in relation to the users and to the state of the system at various intervals. These meaningful releases should be made available to users when available. This will allow early frequent feedback from the users. At the end of every iteration you will have tested, working, production ready software to demonstrate to your customers.

30

2.6 Rules:
The first version of rules for XP was published in 1999 by Don Wells at the XP website. 29 rules are given in the categories of planning, managing, designing, coding, and testing, see Fig. 4. Another version of XP rules was proposed by Ken Auer in XP/Agile Universe 2003. He felt XP was defined by its rules, not its practices (which are subject to more variation and ambiguity, we will discuss later).

31

The Rules of Extreme Programming

Fig. 4

http://www.extremeprogramming.org/rules.html
32

2.7 Practices:
There are Twelve core practices which effectively define XP. If you have not adopted all twelve, then you are not truly doing XP. The Planning Game Small Releases Metaphor Simple Design Testing Refactoring

Pair Programming Collective Ownership Continuous Integration 40-Hours a Week On-Site Customer Coding Standards

33

1- The Planning Game:

Quickly determine the scope of the next release by combining business priorities and technical estimates. Customer comes up with a list of desired features for the system. Each feature is written out as a user story. 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. Given developer estimates and project velocity, the customer prioritizes which stories to implement.
34

2- Small Releases:
A software system is developed iteratively with small releases adding system features and allowing rapid feedback. Start with the smallest useful feature set. Release early and often, adding a few features each time . The small releases help the customer to gain confidence in the progress of the project.

35

3 - Metaphor:
Use Metaphor to guide the whole development. It is a metaphor for how the system operates ( it is similar to the architecture of the system but typically simpler).

4 - Simple Design:
The system should be designed as simply as possible at any given moment. Extra complexity is removed as soon as it is discovered.

36

5 - Testing :
Programmers continually write unit tests, which must run flawlessly for development to continue. Customers write tests demonstrating that features are finished. Test first; before adding a feature, write a test for it! Testing gives confidence in the system and courage to change the system.

6 - Refactoring:
Programmers restructure the system without changing its behavior to remove duplication, improve communication, simplify, or add flexibility. You can do this practice with confidence that you didn't break anything because you have the tests.
37

7 - Pair Programming:
All production code is written with Two programmers at One machine. Continuous code review: better design, fewer defects . Teach each other how the system works (reduced staffing risks) Learn from partners knowledge and experience (enhances technical skills) .

8 - Collective Ownership:
Anyone can change any code anywhere in the system at any time.

9 - Continuous integration:
New code is integrated and the system rebuilt every time a task is completed (which may be many times a day). Tests have to run 100% both before and after integration. Implements continuous processes of applying quality control.
38

10 - 40-Hours a Week:
Work no more than 40 hours a week so that the developers are always fresh and ready for the challenges facing them.

11 - On-Site Customer:
Include a real, live customer on the team, available full-time to answer questions. Means that development team has continuous access to a real live customer.

12 - Coding Standards:
Programmers write all code in accordance with rules emphasizing communication through the code. Coding standard is an agreed upon set of rules that the entire development team agree to adhere to throughout the project. The standard specifies a consistent style and format for source code, within the chosen programming language, as well as various programming constructs and patterns that should be avoided in order to reduce the probability of defects.
39

Taking proven practices to the extreme ;

If testing is good, let everybody test all the time, If code reviews are good, review all the time, If design is good, re-factor all the time, If integration testing is good, integrate all the time, If simplicity is good, do the simplest thing that could possibly work, If short iterations are good, make them really, really short.

40

Ford Motor Company VCAPS (Vehicle Cost and Profit System ) system :
Spent four unsuccessful years trying to build the Vehicle Cost and Profit System using traditional waterfall methodology. But , XP developers successfully implemented that system in less than a year using eXtreme Programming (XP).

41

 Using XP , especially for small teams. XP delivers clean designs and high quality software on a realistic schedule. XP teams have a laser-like focus on testing. Each line of code is tested thoroughly, and all code is reviewed thus ensuring a High Level of Quality. XP encourages a high degree of teamwork, getting the entire team (including the customer) to work together in a room. Programmers work in pairs, with each pair sharing a monitor and keyboard. The whole team collectively owns the code. Design is simple. In XP, you do not design for something in the future, you design for today. The idea is to get the simplest code possible, and not to plan for some future needs that may or may not happen. Being able to add/modify features. Given that XP works on an iterative approach, it is much easier to be able to add features or modify these features based on reviews. The whole development process is visible and accountable. It is very easy to measure as to whether what has been achieved is as per the schedule.
42

[1] J. Hunt, Agile Software Construction, Springer, 2006. [2] William C. Wake, Extreme Programming Explored, 2000. [3]Jeffries, R., (Ed.), XProgramming.com, last confirmed 010903, http://www.xprogramming.com [4] Kent Beck, Extreme Programming Explained : Embrace Change, AddisonWesley,2000. [5] Extreme Programming http://extremeprogramming.org [6] http://www.selectbs.com/process-maturity/what-is-extreme-programming [7] XP Universe Web site http://www.xpuniverse.com

43