Muaaz Hasan Zubairi

University of Management and Technology

Lahore

XP(Extreme Programming)

The first Extreme Programming project was started March 6, 1996. Extreme Programming is one of several popular Agile Processes. It has already been proven to be very successful at many companies of all different sizes and industries world wide.

Extreme Programming is successful because it stresses customer satisfaction. Instead of delivering everything you could possibly want on some date far in the future this process delivers the software you need as you need it

Extreme Programming empowers your developers to confidently respond to changing customer requirements, even late in the life cycle.

Extreme Programming emphasizes teamwork. Managers, customers, and developers are all equal partners in a collaborative team. Extreme Programming implements a simple, yet effective environment enabling teams to become highly productive. The team self-organizes around the problem to solve it as efficiently as possible. 

Major principles of the model

Extreme Programming improves a software project in five essential ways; communication, simplicity, feedback, respect, and courage.

Extreme Programmers constantly communicate with their customers and fellow programmers. They keep their design simple and clean. They get feedback by testing their software starting on day one. They deliver the system to the customers as early as possible and implement changes as suggested. Every small success deepens their respect for the unique contributions of each and every team member. With this foundation Extreme Programmers are able to courageously respond to changing requirements and technology

The most surprising aspect of Extreme Programming is its simple rules. Extreme Programming is a lot like a jig saw puzzle. There are many small pieces. Individually the pieces make no sense, but when combined together a complete picture can be seen. The rules may seem awkward and perhaps even naive at first, but are based on sound values and principles.

Major factor of agility which is handled by this model

Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.

Business people and developers must work together daily throughout the project.

Simplicity--the art of maximizing the amount of work not done--is essential.

Human Factors

Software Engineering Methodsthe value of communication is expressed

by the practices pair programming.It is also explained how the “40-hour

week” (or, sustainable pace, or no extended overtime) is based on the assumption that tired programmers make

more mistakes.

Working in Teams:

It is explained that a team using agile processes probably functions better as a democratic team, since there are no layers in between the manager and the engineers, and communication, valued by many of the agile processes, is enhanced.

practice of collective ownershipensures the democratic approach.

Particularly, with respect to XP teams, the human related

topic of small ego that is necessary for any democratic is emphasized. In addition, it is

discussed how the XP practices may increase trust among team members.

Software as a Product

examines the human aspect of softwareengineering from the perspective of the

customers - the people that use software products. It

focuses on how users and developers deal with defining software requirements in a way that

fulfill customers’ needs. Indeed, the process of defining customer’s requirements is viewed

in this lesson as a process in which both the customer and the developers participate.

If a software team wishes to produce the software that the customer needs, the customer should be able to give the developers on going feedback. For this purpose the customer should be on-site.

Learning Processes in Software Engineering:

There is a lot of learning like how to communicate with different people.

How to work together.

Pros and cons

Done well, XP gets a team to gel more than anything.

It builds true competency in all team members.It makes for an enjoyable and honest work day.It gets people out of their cubes and talking to one

another.It teaches developers about how to write quality

code and how to improve their notions of design; it helps them to improve estimates. It improves the resumes of developers.

It gives management many tools, including predictability, flexibility of resources, consistency, and visibility into what's really going on.

It gives customers the ability to see whether or not a company can deliver on its promises.

A personal favorite: you don't spend a lot of time in stupid, wasteful meetings, and you don't produce a lot of useless documents that no one reads and that aren't trustworthy anyway.

When should Extreme Programming be Used?

Extreme Programming (XP) was created in response to problem domains whose requirements change. Your customers may not have a firm idea of what the system should do. You may have a system whose functionality is expected to change every few months. In many software environments dynamically changing requirements is the only constant. This is when XP will succeed while other methodologies do not.

XP was also set up to address the problems of project risk. If your customers need a new system by a specific date the risk is high. If that system is a new challenge for your software group the risk is even greater. If that system is a new challenge to the entire software industry the risk is greater even still. The XP practices are set up to mitigate the risk and increase the likelihood of success.

XP is set up for small groups of programmers. Between 2 and 12, though larger projects of 30 have reported success. Your programmers can be ordinary, you don't need programmers with a Ph.D. to use XP. But you can not use XP on a project with a huge staff. We should note that on projects with dynamic requirements or high risk you may find that a small team of XP programmers will be more effective than a large team anyway.

Phases of extreme programming

1) PlanningThe first phase of Extreme Programming life cycle is

planning, where customers or users meet with the development team to create ‘user stories’ or requirements. The development team converts user stories into iterations that cover a small part of the functionality or features required. A combination of iterations provides the customer with the final fully functional product.

The programming team prepares the plan, time, and costs of carrying out the iterations, and individual developers sign up for iterations.

Designing An iteration of XP programming starts with designing. The guiding principles of this stage are: Thrust on simplicity by expressing a thing only once and not adding

functionality in anticipation. Using systems metaphor or standards on names, class names and

methods, and agreeing on uniform styles and formats to ensure compatibility among the work of different team members

Using Software Class Responsibilities and Collaboration (CRC) Cards that allow for a departure from the traditional procedural mindset and make possible object oriented technology. Such cards allow all members of the project team to contribute ideas, and collate the best ideas into the design

Creating spike solutions or simple programs that explore potential solutions for a specific problem, ignoring all other concerns, to mitigate risk

Coding Coding constitutes the most important phase in the Extreme Programming life

cycle. XP programming gives priority to the actual coding over all other tasks such as documentation to ensure that the customer receives something substantial in value at the end of the day.

Standards related to coding include: Developing the code based on the agreed metaphors and standards, and

adopting a policy of collective code ownership. Pair programming or developing code by two programmers working together

on a single machine, aimed at producing higher quality code at the same or less cost.

Strict adherence to 40-hour workweeks with no overtime. This ensures the developers work in the peak of their mental and physical faculties.

Frequent integration of the code to the dedicated repository, with only one pair integrating at a time to prevent conflicts, and optimization at the end.

TestingExtreme program integrates testing with the

development phase rather than at the end of the development phase. All codes have unit tests to eliminate bugs, and the code passes all such unit tests before release.

Another key test is customer acceptance tests, based on the customer specifications. Acceptance test run at the completion of the coding, and the developers provide the customer with the results of the acceptance tests along with demonstrations.

Listening The basis of extreme programming is a continuous

mechanism of customer involvement through feedback during the development phase. Apart from the customer, the developer also receives feedback from the project manager.

The basis of feedback is the customer acceptance tests. Each feedback of the customer that specifies revised requirement becomes the basis of a new design, and the process of design-coding-tests-listening repeats itself. If the customer remains satisfied with the test results the iteration ends there, and the design for the new iteration starts, which again follows the design-coding-testing-listening cycle.

Extreme programming Vs Spiral Model

Agile Programming is quite similar to the Spiral software development methodology except that Agile has shorter iteration times. Agile Programming is particularly effective on smaller projects (say, 10 or fewer team members), non-critical projects (in other words, not projects such as medical or weapons systems), and non-distributed systems (in other words, when all team members are in one physical location).

Scrum vs xp

Scrum teams do not allow changes into their sprints. Once the sprint planning meeting is completed and a commitment made to delivering a set of product backlog items, that set of items remains unchanged through the end of the sprint. XP teams are much more amenable to change within their iterations. As long as the team hasn’t started work on a particular feature, a new feature of equivalent size can be swapped into the XP team’s iteration in exchange for the unstarted feature.

Scrum doesn’t prescribe any engineering practices; XP does. I love the XP engineering practices, particularly things like test-driven development, the focus on automated testing, pair programming, simple design, refactoring, and so on.