Extreme programming is one of the most specific agile development frameworks, with clearly defined engineering practices. It focuses on producing high-quality software that meets customer expectations whilst improving the quality of life for the development team.
In the eXtreme Programming agile framework, There are 5 key sets of rules at the heart of an XP project.
User stories are essential, written from the perspective of the customer. They are three sentences long and avoid technical language
Releases should be planned, which lays out the overall project. This is then used to create a release schedule.
Releases should be small and frequent, to get real user feedback as quickly as possible
The project must be divided into iterations, which are planned just before starting
Teams should have a dedicated and open workspace
Each day starts with a standup
The pace of delivery should be sustainable
Velocity should always be measured
Staff should be trained cross disciplines and rotated to avoid having exclusive specialists for parts of the project. This is called 'Collective Code Ownership'
When XP doesn't work, it should be discussed in a retrospective
Designs should be simple
Use CRC cards when designing the system
Do 'spike solutions' to learn and explore technical problems
Don't add unneeded functionality
Refactor and change the design of the software as and when required
Developers should have access to the customer for feedback
Code must be written to agreed standards
Use test-driven methodology
Pair program all production code
Use source control
All code must have unit tests
All code must pass these tests before being released
When a bug is identified, create a test around it, then resolve the issue