Extreme Programming (XP) is a software engineering process, which uses Agile Software Development Methodology and was first introduced by Kent Beck in 1996. With traditional software development methodologies which most of them are linear, one of the problems most software development methodologies had was not being cost-effective for companies because the requirements always were changing and modifying those new requirements could cost a lot and that was the period when Extreme Programming was introduced. Extreme Programming is beneficial when requirements change frequently, which introduces barriers where new requirements can be altered. This process also has its own benefits and drawbacks. Some of the points of using Extreme Programming are as follows and they may be considered an advantage or disadvantage depending on individual software engineers and individual clients:
- Organized programming
- Fewer mistakes
- Programmer and client satisfaction
- Customer has control
- Test Iterations
- New technologies
- Methodology rules
- Engineer designs the software product
- Client initials requirements
- The administrator has development rules
Refactoring and Test Driven Development (TDD) are used with extreme programing. The refactoring is the different way and methods of doing objects in programming. One of the principals of using Extreme Programming is not to be intimidated about refactoring because there is always a time when there is another task and that may change everything in the past and use unit testing after it. After the process of refactoring it is necessary to run all tests against the code to see everything is working, as they should be. Programming in pairs and code reviews are two aspects involved with XP and user stories and communications are the cores of planning in XP. Plans have to be pre-written and scheduled before they invalidate. The feedback from the client, pair programming and other collaborators will help software developers to develop the software better.
XP’s Life Cycle Stages
Planning
This is the first phase of the Extreme Programming life cycle, which involves user stories along with iterations. The development team will create Iterations later. The user stories are collected from the client requirements by the development team. The iterations provide some structures and operations requires. The developers will work on iterations once after the development team concocts the scheme, time, and money of functioning the iterations.
Designing
After the plan is ready with its iterations, the designing process will come into effect. Now when it comes to design, it does not mean that complex design rather than simplicity. The core goal is continuing to search for system implementation that is as simple as possible and simple does not mean that the system does not meet its requirements but should be trusted.
Coding
Coding is the most vital phase of all life cycle stages because with XP it has priority over all other tasks. Format and style of coding must be unchanged so as to enable compatibility among the team. This format and style results in faster and wider teamwork. This phase includes pair programming, metaphor, regular integration and firm observances such as 40-hour workweeks with no overtimes, code review, and refactoring.
Testing
In Extreme Programming, testing always comes with coding and development stage rather than after the completion. Occasionally, there are developers and teams where they write the tests first and write the codes later because that will give them some idea of what their codes need to do. They are also called Unit Tests and the purpose of doing them is to remove bugs before the delivery. Alternatively, there is an approval test run at the end of the coding to deliver the client with approval results.
Listening
In every phrase in this cycle listening to the client is very important to see what they expect the system to do because with listening to the clients, developers ensure they understand these requirements. Also, developers can provide clients with feedback about the technical aspects if they understand the requirements well enough. All feedbacks captured will be revised the requirements by the development team and that will become a foundation of new design. After this phase, the cycle will be repeated over again.
Importance of capturing the ‘story’
Assume there is a software engineer with a client asking to make software for his or her requirements. Depending on how long or short the process of creating that software is, the engineer does not want client dissatisfaction soon after the project is finished, especially when the project was reasonably big and software engineers put so much effort for it.
Before the discovery of user stories, the most common way to capture client requirements was through the specifications, which took a snapshot at one point in time. Software inconspicuousness prevents most clients from realistically intellectualizing the system in their minds. Similar if they could, communication mistakes would undoubtedly keep software engineers from being able to create it from their directions and that is when the importance of user stories comes into effect.
The user stories are the itinerary for every software engineer journey. They are the guileless explanation of a single aspect of almost every system. The purpose of the user stories is the minimum amount of information, which is called a step necessary to allow the client to describe a path within the system. To productively produce applications that will satisfy the client needs, software engineers must have a connoisseur understanding of their customers’ requirements in every user stories and it is vital to capture the whole story thoroughly from clients for every and each step.
Introduction to four basic XP activities, other XP practices, and phases
As it was mentioned before XP has some core values such as communication, simplicity, feedback, and courage. There are practices for XP such as below. However, practices are divided into four sections. In some of its planning stages has phase related to them:
Activities in XP are part of XP’s life cycle. In the planning game practice, there are planning involves for every iteration and user stories are provided by clients and that cause time reduction and client satisfaction. On the other hand, sometimes planning is not necessary and the client is not always available. In small releases phase because there is less functionality involves, consequently, releases happen regularly. The metaphor is the verbal design of the system and the usual set of terminology, which is the fast and easy way of describing the scheme. With the simple design, time is never wasted and it is simpler to grasp everything, which refactoring and cooperative possession are made possible. Refactoring is assuring the high quality of the system in some cases, changing the way in which something is done in the system. Test Driven Development (TDD) is simply Unit Testing, which designs the system with test first. The reason for testing first is to give the programmer some idea and goals. The benefit of pair programming is focus and concentration as two people can answer any questions better than only one people. As it was mentioned earlier about refactoring, there is a practice called collective ownership, which allows refactoring and is the idea of code ownership for developers. XP introduces another practice called continuous integration and with that, new qualities and alterations are worked into the system. Continuous integration enables small releases and lowers to extensive process. There is 40-hour workweek that some developer use in related to XP, which simply indicates the working hours in a week. They use practice to restrict the working hours to 40 because most developers will not be effective after 40 hours a week. It is worth to mention that with on-site customers, which helps to give feedback to the development team, can give firm and decent responses to the development inquiries. Finally, with coding standards also known as code review, all code should look similar and this will cut the total time, which developers employ remake and reformatting it.
There are also release-planning phases in XP. The stage which the client provides developers with high-level requirements for the system called Exploration Phase whereas, in Commitment Phase, the date of the next release will be committed. Adjusting the plan and adding the new requirements or removing the existing requirements are discussed in Steering Phase.
Conclusion
There is not any best methodology when it comes to software development methodology. Extreme Programming is self-control software development based on principles of courage, feedback, communication and the most important one, simplicity. Software progress is a continuously evolving discipline. XP is popular because of its discipline between all other agile software development methodologies. Lightness can be felt with XP and constantly using the feedbacks. As programmers write and rewrite the code in XP projects, the client sees growth in the system and because the details of the requirements matter a lot and also because with XP developers can capture details more often, consequently the only object will remain is the coding.
