<?>
<?>
Extreme Programming is an agile model which beliefs in continuous communication between project team members and stakeholders, continuous feedback, simplicity, and respect. The most important is the communication principle which encourages the team members to share their knowledge and communicate with the client in the best form. Simplicity helps software programmers to look for simple solutions to the problems faced in the project life. In order to think about future problems solution developers also build up a design feature to help them in the future. Continuous communication between customers and the project team enables the developers to carry on the project in the right direction to fulfill the client requirements and support reducing paperwork.
Agility nature is based on changes that encourage developers to accept changes collaboratively. In the Agile model team members have a positive behavior to encourage and give respect to each other’s work. The members of the team respect the work of the others and try not to depress the others which leads to a good and polite working environment. Extreme Programming is the bundle of small pieces in which individual piece makes no sense individually but after being assembled and given the full paradigm of the project. This is the main difference between traditional/ corporate software management methods and the Extreme Programming management method. Extreme Programming has a focus on the code written regardless of the time factor. In the initial phase of a project, the main focus is on the core product and features are coming in the later phases but coding is an important area where to focus on all the time. The software design depends on the evaluation of software changes.
The simplicity principle of Extreme Programming prefers that the design should be simple, as much as possible, for the present state, not for future needs. Design and analysis practices are applied to later phases of the project, in the beginning, these not being considered more important. In Extreme Programming, one builds a story card where the user’s story is written. Each piece or part of a story card is explained before programming a story card. User Story (US) is the assets of the customer which is contained in software system requirement (SSR) in small paragraphs in such a language that is known by the customer. US is a short way to define the requirements of the stakeholder regardless of managing a big case of documents. Like the corporate project management models, Extreme Programming also describes the following four variables for a project: cost, time, quality, and scope. However, in Extreme Programming, one of these is always ignored by project managers – this variable is the quality because if the project manager wants that his team to collect some user’s requirements with limited resources and to meet the requirements in a specified time frame, then he has to compromise on quality. In Extreme Programming projects work under stress is always involved and pressure always sacrifices the quality factor. Therefore, project managers establish only three parameters in Extreme Programming.
Extreme Programming believes in small groups in the development team, ten to twelve people each. The cost variability depends on resources when advanced technology or season experts are required in some areas; under these circumstances, the cost of the project will increase. Extreme Programming aims to maintain a higher quality of the project within less possible development time. For this reason, the development assigns the task of testing because they have ideas about the problems and their solutions coming during testing. The development team should be flexible to accept changes in code and design according to the user’s requirements in such a manner as to maintain quality. Extreme Programming is based on the iterative and incremental development model which is designed to deliver high-quality software according to the customer’s needs in the deterministic time frame. The main Extreme Programming objective is to make high-quality software within the less possible time. Extreme Programming believes in the pair programming approach because the coding is written and reviewed at the same movement and the client should be involved in the development process because he is the one who knows the real requirements. The code should be simple and understandable and it will be rewritten to improve the quality as well as performance. The most significant factor which is involved here is the coding which should be common to all within the development team, which every team member can understand, modify, or can test. The project team performs the testing before they are moving forward for adding new features or functionalities and each iteration having the phase of code is tested. In other words, they are revising the code at the same movement when you are writing it. The development team shares all their work and reuses the same piece of code in other areas or modules of the project. Extreme Programming has less documentation concept, not the same as the user story, but at the end of the project, it will rule out. For this reason, the user story can be considered documentation. This is the reason why Extreme Programming is suitable for small projects with fewer members in the working team, in which fewer implementation risks are involved. Extreme Programming is best for small projects but poor performance in medium and large development projects is the limitation of Extreme Programming.
<?>
<?>