Extreme programming (XP) is a type of software development which is designed to improve the quality responsiveness of a software while having the ability of fitting into the changing needs of a customer’s requirement. This software development was developed by Kent Beck during his work on the Chrysler Comprehensive Compensation System (C3). XP works by providing periodic “releases” throughout a project in short development cycles which increases the productivity of a customer’s requirement while allowing enough feedback for teams to be able to view and review the project’s progress.
With XP, teamwork cannot be under emphasized. Everybody on the team (managers, customers, developers etc.) are all on an equal level. Team work is necessary because a team gets to self-organize around a project’s problem and solving them as fast as possible hereby providing a unique show of value.
Very many successful companies worldwide use XP most especially IT companies.
VALUES OF EXTREME PROGRAMMING
There are five fundamental values that guides extreme programming. These values is what XP is primarily based on. This allows individuals or teams to work in harmony while enabling you feel confident on the directions of the project.
For a team to function effectively, communication is necessary. Problems tend to arise when there’s a gap or bridge in communication. Some of these problems include:
- A designer might need to tell the customer about a critical change but when there’s no communication, a problem arises
- A designer may need to ask questions to seek confirmation or more understanding but when communication is absent, problem arises.
- A designer may ignore or misinterpret an important message that was conveyed by the customer.
Extreme programming requires consecutive and consistent communication among teams, customers and managers in an open discussion without fear of retribution. Problems rarely occur or solved when communication is present.
Extreme programming encourages users to always start with the simplest of solutions. That means, always learn to start little while you pay a little more for changes as time goes on. Simplicity occurs when you create projects starting with small steps and maintaining them for a long period of time for reasonable costs. It is always better you do simple rather than doing a complicated thing that may never be used.
Simplicity principle tells us the following:
Users need to focus more on designing and coding to satisfy the needs of today than that of tomorrow. Never implement features you know you don’t need. Any extra feature can be added later. This is sometimes see as “you aren’t going to need it” (YAGNI).
Always try to write simple codes that will bring more value to your product as this saves time, energy and money.
Simplicity and communication go hand in hand. Simplicity in any design improves any form of communication. The simpler your system or project is, the less you have to communicate with programmers. This often always leads to better communication.
A simple design accompanied with a simple code would easily be understood by programmers on the team.
Feedback works closely with communication and simplicity. When there is a flaw in the system, it is easily communicated so that we can look through it and make every necessary adjustment. When a working software has been delivered to the customer, feedback is important in order for any change to be made.
Giving feedbacks about the current nature of a system is nothing short of priceless. This is because the value of feedback is a *continuously running system that delivers information about itself in a reliable way.
Generally, team members would have to deliver a software constantly, get feedback about it from the customer and find ways to improve on the product based on the new change/requirements given.
Feedback must be gotten or ensured on multiple levels;
Feedback from the customer: frequent tests are performed by the customer to give feedbacks which developers will use to work.
Feedback from the System: Unit tests are being run periodically to ensure that developers have a direct feedback from the system regarding the state of development especially after making changes.
Feedback from the team: when a customer gives new requirements or features, the team is given the chance to give an estimation of the time that it would take to implement those features or requirements.
One thing to note here is; always learn to code and design not for tomorrow but for today. Courage means that every programmer needs to learn or have persistence. For example, a programmer might rack his head over a particular problem but might get the problem solved immediately the next day, only if they are persistent. Another example of courage a programmer needs to know is, knowing when to throw a code away; it takes courage to throw away a coding that was time consuming.
The following points outline how Extreme programming provides courage to programmers;
Courage helps developers in evaluating their own results without doubts or excuses and also making sure they respond to changes swiftly.
- laying focus on what is required.
- Communicating properly and open to receive feedbacks.
- Being adaptive to changes.
- Refactoring a code and knowing when to throw a code away (when needed).
Respect is reciprocal they say. It is actually true. Everyone on the team should always and never fail to give respect to each other as team members. Nobody on the team should feel under-appreciated or ignored and no one should ever make a team member feel that way.
Developers should never delay the work of their peers or even make changes that will cause shattering changes. Developers should respect the needs of their customers and customer should be able to do same. Team members should also respect their own works by always striving to be the best not only in character but also in any project they may be handling.
All other values leads up to respect. This is because respect is very deep value. In XP:
- Developers respect the expertise of the customers and vice versa.
- Management respects the right of the developers to accept the responsibility and receive authority over their own work.
- Everyone contributes value such as enthusiasm.