Kent Beck developed Extreme Programming, in which every person in the project is an integral part of the ‘Whole Team’. The team revolves around a business representative called ‘the customer’, who is also part of the team and works with them daily.
Extreme Programming (XP) is a trivial discipline of software development based on the principles of communication, simplicity, feedback, and courage. XP is designed for use with small teams that need to develop software quickly in rapidly-changing requirements.
Teams use a simple form of planning to decide what should be done next in order to predict when the project would be completed. The team produces the software in a series of small fully-integrated releases that pass all the tests the customer has defined by focusing on business value.
Programmers in such teams work together in pairs as a group with simple design and tested code improving the design continually to keep it always just right for the current requirements. The group keeps the system fully integrated and running at all the time.
Programmers always write code in pairs and work together all the time. They code in a consistent way, so that everyone can understand and improve the code as per the requirement.
There are 12 Basic Practices of XP
In software development, XP planning addresses two key questions, which are predicting what will be accomplished by the due date, and determining what to do next. The emphasis is on direction finding the project, which is quite straightforward rather than on exact prediction of what will be required and how much time it will take.
a] Release Planning: In this planning, the customer presents the desired features to the programmers, and the programmers calculate their difficulty.
The customer lays out a plan for the project with the estimates, and with knowledge of the importance of the features. Initial release plans are necessarily imprecise, because until the team begins to work neither the priorities nor the estimates are truly solid.
b] Iteration Planning: This is the practice in which the team is given direction every week. XP teams develop software in two-week iterations, delivering software at end of each iteration. The customer then presents the features desired for the next two weeks.
The programmers divide these into different tasks and estimate their cost. Based on the amount of work accomplished in the previous iteration, the team decides for what will be done in the current iteration.
XP teams practice small releases in two different ways. Firstly, the team releases tested, running software, delivering business value chosen by the customer. The customer uses this software for evaluation or even for releases to end-users.
The most important aspect is that the software is visible to the customer at the end of every iteration. This keeps everything visible, open, and tangible to the customer.
Secondly, XP teams release software to end users very frequently. In fact, some XP web projects release upgrades and increments almost daily.
Extreme Programming teams develop a common view of how the program works, which is termed as a ‘metaphor’. This is nothing but a simple suggestive description of the working of the program. XP teams use a common name system to ensure that everyone understands how everything works and can find the functionality they are looking for.
These teams use simple design to build software. There are certain design steps in release planning and iteration planning, plus teams engage in quick design sessions and design revisions through the course of the entire project.
In an incremental, iterative process like Extreme Programming, good design is very important. That’s why there is so much concentration on design throughout the entire development of software.
The customer defines one or more automated tests designed to show that the feature is working as envisioned. The team runs these tests and uses them to prove to the customer that the feature is implemented correctly. Automation is used to skip manual tests.
In the best teams, the customer tests are the same as programmer tests; once the test runs correctly the team keeps it running correctly thereafter.
XP teams improve the development of the software throughout its design cycle. This is done by maintaining the software with high communication, keeping it simple and complete, and without duplication.
All development of software in XP is built by using two programmers, sitting side by side at the same machine. This practice guarantees that at least one programmer reviews all development code, which results in better design, better testing, and better code.
Though it seems like two programmers doing ‘one programmer’s job’, the reverse is true because pairing produces better code in the same time as programmers working singly. Pair programming offers better code and tests, and serves to communicate knowledge. Pair also switch from time to time so everyone gets the benefits of the teams knowledge.
Collective Code Ownership
In collective code ownership any pair of programmers can improve any code at any time. This means that the code gets the attention of many people, which improves code quality and reduces defects. The other important advantage is that when code is owned by particular individuals, then required features may be put in the wrong place.
XP teams build and integrate the software design system multiple times everyday. This ensures that all the programmers are on the same page and enables rapid growth. Team integrating more regularly tends to reduce integration problems that plague teams who integrate less often.
Exhausted programmers make more mistakes. XP teams do not work overtime, maintaining team members fresh, healthy, and effective.
An XP project is observed by a dedicated individual who determines requirements, sets priorities, and answers questions. The effect of an on-site customer is that communication improves with less hard-copy documentation.
For a team to work in pairs and to share ownership of all the code, all the programmers should write the code with some rules that make sure the code communicates clearly.
Thus, teams use a common coding standard so that all the code in the system looks as though a single individual wrote it. The specifications of the standards are not important, but it is important that all the code looks familiar in support of collective ownership.