Extreme Programming Supporting Practices - Extreme Programming

What are the supporting practices of extreme programming?

The practices of Extreme Programming are considered as a whole in such a way that they support each other. The strength of one covers the weakness of others.

This chapter focus on the possible weakness of each of the practice and the support practice for overcoming the weakness.

supporting_practices

The Planning Game – Support from other XP Practices

The Planning Game – Disadvantages

It is not possible to start development with a rough plan, and the plan cannot be constantly updated and the time taken is too long and leads to customer dissatisfaction.

The Planning Game with other XP practices

The planning game is supported by other XP practices in the following manner:

  • On the basis of the developer estimates, the plan is updated with the concent of the customer.
  • The mistakes of the plan can be set in four weeks or maximum a month in case of short releases.
  • The potential changes and improvement opportunities can be spotted quickly as the customer sits along with the team.
  • Continuous testing helps the developers and the customer to decide what is required immediately.

The development can be started with a simple plan and as it goes along is refined.

Short Releases – Support from other XP Practices

Short Releases – Disadvantages

After a time period, it is not possible to go to production. It is not possible to make new releases on the system either from daily to couple of months as it requires time for absorbing new requirements, changes.

Short Releases with other XP practices

Short Releases is supported by other XP practices in the following manner:

  • Even a small system is enhanced with a business value as the planning game facilitates to work on the most valuable stories.
  • The cost of packaging a release is made minimal by continuous integration.
  • The defect rate is reduced by testing in a way that the release does not require a lengthy test cycle.
  • The design that is sufficient for the release can be made.

As soon as the development begins, short releases can be made.

Metaphor – Support from other XP Practices

Metaphor with other XP practices

Metaphor is supported by other XP practices in the following manner:

  • he working of metaphor can be identified by having a quick concrete feedback from the code implemented by using pair programming.
  • In terms of metaphor, the on-site customer is comfortable talking about the system.
  • The understanding of metaphor implementation is refined by the continuous refactoring.
  • Mapping with metaphor can be done by simple design.

With a Metaphor, the development can be started.

Simple Design – Support from other XP Practices

Simple Design − Disadvantages

The simple design serves the purpose for today’s code and the design does not serve the purpose of evolving the system.

Simple Design with other XP practices

Simple Design is supported by other XP practices in the following manner:

  • Changes can be made by refactoring
  • It is ensured from metaphor that the design changes that happen in future follow a convergent path.
  • A working simple design can be confidentially made by using pair programming.
  • Focusing on right design is facilitated by 40-hour week
  • It is ensured that the simple design is on the track by customer testing and continuous unit testing.

Hence, without speculation, the best possible design for today can be developed.

Testing – Support from other XP Practices

Testing - Disadvantages

It is assumed that −

  • It is not possible to write all the tests
  • Too much of time cannot be made for writing the tests
  • The tests are not written by developers.

Testing with other XP practices

Testing is supported by other XP practices in the following manner:

  • Tests can be easily written by simple design
  • The decision regarding the required tests can be done by refactoring
  • Pair programming facilities in developing the ideas that even if one cannot get, the partner may get.
  • The developer with required skills is enabled to work on the complex part of coding and testing by collective ownership.
  • Immediate running of test and continuous integration made by the pair ensures -
  1. That the new code works if 100% tests pass, or
  • That if any test fails, it is that pair’s code that is failing the system so that the changes can be immediately reversed and the pair can start afresh.
  • In order to run the tests and give feedback, customers are facilitated with a working system by Short releases.
  • All the tests can be run and feedback can be provided immediately on the working system by on-line customers.
  • After testing the plan for the next release, feedback is taken from the customers using Planning game.

The tests are written by the customers and developers. The working of the rest of the extreme programming is ensured by the automated tests.

Refactoring – Support from other XP Practices

Refactoring - Disadvantages

The design of the system cannot be refactored all the time as it would -

  • Take too long.
  • Be too hard to control, and
  • Most likely break the system.

Refactoring with other XP practices

Refactoring is supported by other XP practices in the following manner:

  • Wherever required changes can be made by collective ownership.
  • Reformatting is not required before refactoring by using coding standards
  • A tough refactoring can be handled confidently by pair programming
  • With a simple design, the refactoring is easier.
  • With metaphor, communicate is made easy.
  • It is not possible to break anything without knowledge by using testing.
  • Few possibilities of making a mistake if 40-hour week is used.

Refactoring can be done whenever there is a chance to –

  • Simplifying the system
  • Reducing the duplication
  • Clearly communication.

Pair Programming – Support from other XP Practices

Pair Programming - Weakness

All the code cannot b written in pairs. If two people do not get along well, it is very difficult.

Pair Programming with other XP practices.

Pair Programming is supported by other XP practices in the following manner:

  • The conflicts can be reduced by the coding standards
  • The chance of unnecessary discussions is reduced by 40-hour work, as everyone will be fresh and focused.
  • Before the implementation part is tackled, a chance to align the understanding is provided by unit tests written by pairs.
  • The decisions regarding naming and design is taken by using Metaphor.
  • A common understanding between the pair is developed by simple design.
  • In order to make the system simple, combined decisions can be made by refactoring.
  • The mistakes can be corrected by using refactoring and the experiments done by one of the partners is not objected by the other partner.
  • A cordial relationship is maintained by the team by collective ownership.

Hence the code can be written in pair.

Collective Ownership – Support from other XP Practices

Collective Ownership with other XP practices

Collective Ownership is supported by other XP practices in the following manner:

  • The chances of conflicts are reduced by continuous integration
  • The chances of breaking things accidentally are reduced by testing.
  • The developers can learn faster by using pair programming.
  • The conflicts on the code are reduced by coding standards.
  • The system can be maintained simple and easily understandable by refactoring.

Thus for improvement, anyone can change the code anywhere in the system and the rate of evolution of the system reduces without collective ownership.

Continuous Integration - Support from other XP Practices

Continuous Integration – Disadvantages

The process of integration is too long and there are chances of accidental breakings.

Continuous Integration with other XP practices

Continuous Integration is supported by other XP practices in the following manner:

  • By testing it is quickly known that nothing is broken.
  • The streams of changes to integrate becomes half by pair programming
  • The chance of conflicts are reduced by refactoring
  • There will be a consistent code by using coding standards
  • Immediate feedback on the system is ensured by short release
  • The whole view of the system is made available who ever changes the code and integrates by using collective ownership.

Hence, after a few hours integration can be made possible. Delay in integration may lead to chances of rise in conflicts and integration cost.

40-Hour Week – Support from other XP Practices

40-Hour Week – Disadvantages

Sufficient business value cannot be created in 40 hours.

40-Hour Week with other XP practices

40-Hour Week is supported by other XP practices in the following manner:

  • The more work that is valuable to do is provided by planning game.
  • Working on what exactly is required is facilitated by the combination of planning game and testing.
  • On time completion by staying in focus is enabled by refactoring and simple design.
  • Pair programming helps you to work on what you can do, sharing the other work with your partner.
  • The complete practices facilitates in developing at high speed.

Hence enough business value can be produced in 40-hour weeks. The rest of the practices cannot be executed by team if they do not stay fresh and energetic.

On-Site Customer – Support from other XP Practices

On-Site Customer – Disadvantages

Having a full-time real customer on the team is not possible. They on the other hand can produce more business value elsewhere.

On-Site Customer with other XP practices

On-Site Customer is supported by other XP practices in the following manner:

They can produce value for the project −

  • Scope decisions for the developers are made in planning game
  • The clarity on domain is provided to the developers in metaphor.
  • In testing, by writing acceptance tests and by performing acceptance testing after every short release.

By their contribution to the project, organization value can be produced.

Coding Standards – Support from other XP Practices

Coding Standards – Disadvantages

As the developers are individualistic, the team cannot code to a common standard.

Coding Standards with other XP practices

Coding Standards is supported by other XP practices in the following manner:

  • The desired and necessary coding standards can be easily adapted by pair programming
  • For the code to be consistent standard is followed by continuous integration.
  • The changes are made whenever and wherever required by aligning to the standards by collective ownership.

Extreme Programming Related Tutorials

Extreme Programming Related Practice Tests

All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd DMCA.com Protection Status

Extreme Programming Topics