Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 3 Current »

Extreme programming (XP) is an agile development method that uses on-site customer collaboration, paired programming, and automated testing processes. XP is a widely used agile method focusing on simplicity, internal communications, and customer feedback. XP, presented by Beck in 1999, is one of the oldest agile methods. The advantages of XP are short iteration cycles, direct communication with an on-site customer, and continuous integration and testing. The disadvantages are that the practice requires minimal documentation and the method is unsuitable for reengineering projects. As a note, the XP method is challenging to use on large projects and projects of a critical nature. Although practiced before the concept of agile was defined, XP is an agile development process. 

Much like scrum, XP uses iterative phases in the software development process. The first phase of XP is the initialization phase, in which project team members gather requirements from customers directly involved with the team to determine project scope and cost. In the requirements-gathering phase, the team uses story cards to document and describe the request and elicit dialogue with the customer. In the second phase (analysis phase), the software team develops the architecture and iteration plan. Repeated code development and testing cycles follow the requirements and analysis phase, and the code is integrated into a deliverable release once it achieves the functional request. Additionally, one of the critical distinctions in the XP development process is the concept of paired programming. 

Paired programming is a development approach in which two programmers sit together, one assuming the role of the driver and the other the navigator. Paired programming is a standard practice in XP where two people collaborate in coding. The driver sits at the keyboard to type the code while the navigator oversees the code input, watching for syntax errors and ensuring the program meets the required deliverable. The programmer actively writes the code (driver) and focuses on completing the current task. The navigator, who is overlooking the code writing, can judge the strategic direction of the work performed, offering ideas for improvement or potential future problems. The approach uses two programmers to collaborate on a single code set, working together to complete a development request. 

Paired programming can have an advantage over developers working independently. In paired programming, the driver and the navigator often change roles throughout the project. The benefits of paired programming are constant code review and the brainstorming of approaches during the code’s development. Programmers can quickly catch and resolve errors, thus producing better code using a collaborative approach. Additionally, pairing an expert programmer with an average or novice programmer provides mentorship to the novice. However, teaming individuals who have the same expertise can cause counterproductive work. Therefore, the benefits of paired programming can be more significant when developers have different skill levels or experience.

  • No labels