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
- Programming in pairs
- Extensive code reviews
- Subjecting the code to unit testing
- Pair negotiation
- Avoiding programming the features that are presently not required
by the software system or application.
- Stand up meetings
- Acceptance tests
- Flat management structure
- Iteration plan
- Simplicity of the code
- Clarity of the code
- Release planning
- Expecting changes in the requirements of the customers and clients.
- 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:
- Unstable requirements
- Non documented compromises of the user conflicts
- 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:
- Planning
- Managing
- Designing
- Coding and
- 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:
- Rules of engagement: Rules under this category are known to dictate
the environment in which the software development is carried out
effectively.
- 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.
No comments:
Post a Comment