When should Extreme Programming be used?

Extreme programming or XP as it is commonly called as has been known to be a very effective and reliable agile software development methodology having its foundation laid up on the principles of agile development. 

The first ever project that made use of extreme programming was done in the year of 1996 in the month of March. The project was quite successful and since then many companies of different sizes began using the extreme programming software development methodology for developing their software products all over the world. 

The extreme programming works out successfully every time since it stresses the satisfaction of the customers. The extreme programming does not makes promises that it will deliver the software with all the possible ways you expect it rather it delivers the software product with all the features that you require the most. 

The developers are empowered in a way to confidently respond to the ever changing needs of the customers in whichever stage of the development cycle required. 

How Extreme Programming improves the quality of software?

5 ways have been defined in which the extreme programming helps in improving the quality of the software and its productivity:

1.     Communication

2.     Simplicity

3.     Feedback

4.     Courage and

5.     Respect

When the Extreme Programming should be used?

- A software development process does not suit for all the types of the software projects.

- Extreme programming must be employed for the complex projects which require a clean and simple design void of any bombastic jargon. 

- The simple rules of the extreme programming make it easy to be implemented in most of the software projects.

- Extreme programming elements individually do not make any sense but do make sense when put together. 

- These elements and rule may seem to be very awkward at first but they are based up on sound principles and are guided by sound rules. 

- The extreme programming makes the whole development process very collaborative and works well with the projects in which the active participation of the customer is required. 

- In extreme programming once the product team work is achieved, its rules can be modified to fit the requirements of the company. 

- The activities which show less productivity are trimmed to reduce the budget of the development process. 

- The need for extreme programming grew out of the demands for short productive cycles which could satisfy the rapidly changing requirements of the industry. 

- The extreme programming has always attracted controversy whenever an environment different from its original one has been used. 

- The extreme programming demands for high discipline and hence some of the practices involved in the extreme programming are thought to be very rigid to be reduced or left unfinished. 

- But the extreme programming works according to a very relaxed schedule which can be designed by the developers. 

- This prevents frustration and creation of stubs to pass the end of day testing. 

- Thought the schedule is very lenient, a periodic integration is always required. 

- It is needed to detect the work being done in non compatible efforts before too much of the efforts are wasted in the wrong directions.

However, apart from all these positive there are a few negative aspects of the extreme programming which should always be kept in mind before you implement it for the development of your software project. 

- It lacks structure and documentation and requires senior level developers. 

- It calls for frequent meetings with a great exposure to the customers. 

- You can even land in much difficult contractual negotiations. 

What are the elements and rules of extreme programming?

Since the advent of extreme programming as a very popular iterative and incremental development process, it has been used for continually making quality software products and increasing the responsiveness to the ever changing needs and requirements of the customers and clients. 

Being an agile software development process it involves releasing of the software product in the form of “frequent releases” with all the short development cycles. It employs other techniques like the time boxing technique. 

The whole of the extreme programming has been aimed at increasing the productivity of the development cycle. Throughout the development cycles so many check points are introduced where the changes in the customer requirements or any other new requirements can be successfully and easily be included in the software development cycle. 

There are certain elements and rules of the extreme programming that we are going to discuss in this article. 

Elements of the Extreme Programming

1. Programming in pairs
2. Extensive code reviews
3. Subjecting the code to unit testing
4. Pair negotiation
5. Avoiding programming the features that are presently not required by the software system or application.
6. Stand up meetings
7. Acceptance tests
8. Flat management structure
9. Iteration plan
10. Simplicity of the code
11. Clarity of the code
12. Release planning
13. Expecting changes in the requirements of the customers and clients.
14. Frequent and effective communication among all the stake holders and the customers.

The process no doubt has got a lot of criticism because of the following problems:

1. Unstable requirements
2. Non documented compromises of the user conflicts
3. Lack of an overall documentation or specification

Rules of Extreme Programming

The rules that are followed by the extreme programming, were first stated in the year of 1999 by Don Wells at the official web site of the extreme programming. In total there are 29 rules that have been stated under different categories as mentioned below:

1. Planning
2. Managing
3. Designing
4. Coding and
5. Testing

1. Planning:

 (i) Writing the user stories

(ii)  Creation of the release schedule

(iii) Making frequent releases

(iv)  Dividing the project into iterations

 (v)   Iteration planning

2. Managing:

 (i)  Providing a open work space

(ii)  Setting a sustainable pace

(iii) Stand up meeting

(iv) Measuring the project velocity

 (v)  Moving people around

(vi)  Fixing XP

3. Designing:

 (i)  Simplicity

(ii)  System metaphor

(iii) Using CRC cards

(iv)  Creating spike solutions

 (v)   Re-factoring

4. Coding:

 (i) All time customer availability

(ii) Agreeing with the standards

(iii) Coding the unit test first

(iv)  Pair programming

 (v)  Frequent integration

(vi)  Using collective ownership

5. Testing:

 (i)  Unit tests

(ii)  Code must pass all unit tests

(iii) Acceptance tests

The first three categories are carried out explicitly since it was claimed by the critics that these are not supported by the extreme programming. 

Another set of rules was kept forward by the Ken Auer in the agile universe in the year of 2003. Ken Auer thought that the extreme programming is some what defined by its rules rather than being defined by its practices since they are subjected to ambiguity and variation. He had set out the rules under two different categories as mentioned below:

1. Rules of engagement: Rules under this category are known to dictate the environment in which the software development is carried out effectively.
2. Rules of play: Rules under this category are meant for defining all the activities whether be minor or major and rules that define the frame work for the development of the software under the rules of engagement.