Extreme Programming (XP) is a software creation methodology, one of several agile software development methodologies. The main purpose of the flexible methodology is to find better and more flexible solutions when creating software.
The basic rules of the Agile Manifesto (agilemanifesto.org) manifesto that Extreme Programming – XP also follows are:
- Individual qualities and communication are preferred to rigorous processes and tools
- Running software at the expense of comprehensive documentation
- Client assistance displaces a contractual agreement
- Easily responsive to change software instead of strictly following a plan
The main purpose of the Extreme Programming methodology is to reduce the cost of a project if a change is needed. From this, we conclude that Extreme Programming is a methodology suitable for use with projects that have frequently changing requirements, and then more standard methodologies (such as the Waterfall model, for example) are not optimal for high productivity; is appropriate for projects involving new technologies or unforeseen implementation problems; also used for smaller and easier to implement projects with informal methods; good technology for research projects.
Principles of Extreme Programming (XP)
XP follows its own simple rules and practices, which at first glance may not seem reliable, but in fact, experience shows that they produce good results:
Communication – Extreme Programming stimulates verbal communication, unlike other concepts where communication is done through documentation.
Simplicity – Extreme Programming begins with the simplest possible design and solution to a given problem, which is improved by refactoring, with programming being written today, not tomorrow.
Feedback from the system – by means of unit tests or periodic integration tests, programmers have direct feedback from the state of the system after the changes have been introduced; this feedback makes it easier to detect code errors and rewrite a given snippet.
by the client – the functional tests are written by the client and by the testers. They will get a clear idea of the current state of the system. These tests are scheduled to be performed once every 2-3 weeks to allow the client to closely monitor the development.
from the team – after the client immediately says his new requirements the team can immediately give a concrete answer as to how long it will take for the new requirements to be implemented.
Courage – the courage to design and write code for today, not tomorrow; the courage to rewrite a code that does not meet the new requirements, despite the fact that you have taken a lot of time and effort, courage makes developers feel good when their code needs refactoring.
Respect – In XP, team members need to respect each other because it is thought that this improves teamwork, resulting in better results.
Activities in Extreme Programming (XP)
Activities that Extreme Programming describes and that are used in the software development process itself:
Coding – Extreme Programming advocates believe that the only really important thing in software development is writing code. Many Agile proponents of the methodology, such as Scrum and Kanban, think so. Avoiding classic project management practices and focusing on real work on product development is considered as a primary goal. See Lean and Agile software development.
Testing – Without testing, we cannot be sure that our product truly meets the specifications; we can’t be sure if what we wrote is what we wanted to write – we use Unit Test for this purpose; we can’t be sure if what we meant was what we had in mind – to test this we do acceptance tests of the client’s requirements (given in exploration phase of release planning).
Listening – Developers generally don’t need to be aware of the business side of the system itself. On the other hand, they need to “listen” to know what the customer needs.
Designing – When creating a product using XP, one of the most important things is creating a good design in the beginning.
Extreme Programming has 12 practices grouped into 4 areas that are inherited from software engineering best practices:
Fine scale feedback:
Pairs Programming – two programmers working together on one computer, driver and navigator. As the driver writes to the computer, the navigator monitors its operation. And it is a good idea to change roles in half an hour, and to change partners every day.
The advantages of pair programming are that it writes more valid code, makes fewer logical mistakes; knowledge is exchanged because as much as one knows, one can never know everything and can always learn more; that’s how team members come together, something very important to the XP Agile methodology.
If people change more often, more of them will be introduced to the various features and thus everyone will be much more familiar with the overall product and communication will be easier. This is thought to result in fewer work interruptions leading to greater productivity.
Another advantage is that fewer computers are needed to get the job done, and the free ones can be used for other purposes.
Planning Game – the basic planning process; the planning game itself is a team meeting that takes place once every iteration (usually once a week). The planning process itself consists of 2 parts: release planning and iteration planning
Release Planning – focuses on what the requirements are for the next release. It consists of 3 phases:
Exploration Phase – The client says what his requirements are
Commitment Phase – have an agreement on what kind of functionality will be sought at the next release and when it is expected to be released
Steering Phase – requirements can be improved in this phase, new ones can be added, some of the old ones can be removed
Iteration Planning – The activities and tasks of developers are already discussed here, the client does not interfere. It consists of 3 phases:
Exploration Phase – The requirements are divided into different tasks.
Commitment Phase – Tasks are distributed among developers and the time required to complete them will be evaluated
Steering Phase – Complete the tasks and compare them with the prerequisites.
Test-Driven Development – Unit tests, which are written before the code is written, are used to anticipate in advance situations where the code may fail. With XP, it is considered that the product is complete when no new states can occur in which the code fails.
Whole Team – With Agile, the Extreme Programming methodology is the customer for whom the product is intended; XP does not generally create products for many people; they are created for a specific client who will then use the product and the developers themselves keep in touch with it.
- Continuous Integration – A practice where developers often integrate their work.
- Design Improvement – code refactoring
- Small Releases
- Shared Understanding:
- Coding Standards
- Collective Code Ownership
- Simple Design
- System Metaphor
- Welfare Programmer:
- Sustainable Pace