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.