2.6 XP: Extreme Programming: Agile Software Construction

Agile Software Construction
2.6 XP: eXtreme Programming

Extreme Programming, or as it is more commonly known XP, was originally designed as a way of supporting small development teams working within uncertain and changing requirements. That is, it was a response to many of the more traditional heavyweight approaches that are often overkill for small software developments. However, it was not an attempt to throw everything away and just program (which is a common misinterpretation of XP). Rather, XP was designed as an approach based on software engineering principles, but focussed on the timely delivery of software that meets users requirements (rather than on the sometimes over bearing processes that surround the development of software). An important aspect of XP is the empowerment of the actual developers they should be able to react immediately to changing customer requirements, even late in the development life cycle. XP also places great emphasis on the software development team and teamwork. The team, in turn, incorporates management, technical personnel and end users all cooperating towards the common good. It takes as one of its aims that teams communicate and constantly pay attention to all the details necessary to make sure that the software being developed matches the user requirements, to help to produce quality software. Underlying XP are four basic principles, these are: Communication it is good to talk (particularly, between users and developers). Simplicity keep it simple and grow the system as and when required. Feedback let users provide feedback early and often. Courage to go with such an approach. These four basic principles have led to the following key ideas presented within XP: Code in pairs. This is probably the thing that people rst hear with relation to XP. The idea is that all software is developed in pairs (i.e., with two programmers at one screen). The concept is that if code reviews are good, because they force at least one other person to consider your code, then constantly working in pairs results in constant reviewing of code and feedback between the two developers. Stay in contact with the customer. For example, place a customer representative in the team, so that you have access to them all of the time. Meet regularly with the customer to give information and receive feedback. Create tests before coding then test heavily. Developers should write the unit tests before the code to be tested. Part of the argument is that if you cant write the test
Agile Methods and the Agile Manifesto
(i.e., dont know what the inputs and outputs should be), then you shouldnt be writing the code. You should then automate testing so that you can regularly re-run the tests to make sure that nothing that has been done breaks earlier results. Short iterations. Each iteration should be relatively short allowing for rapid and frequent feedback. Thus, a minimal system may be produced and possibly even put into production quickly and the system will grow in whatever directions prove most valuable. Keep it simple. Start projects with a simple design that can evolve later as required by future iterations. This removes unnecessary complexity from early iterations. It also removes the need to code in additional functionalities believed to be required by future iterations, but which may actually never be needed. Dont anticipate: code for current needs. That is, dont over-engineer solutions based on what they may one day need to do, rather focus on what they need to do now and leave tomorrows functionality to tomorrow. Collective ownership. Everyone within the team owns the software and has responsibility for it. When something goes wrong, no one should ever consider it not to be his or her problem because Bill wrote that piece of code. In turn, XP does not support a culture of blame and recrimination everyone is responsible for all the code. As a result of this, everyone is responsible for xing a problem when they nd it rather than ignoring it.
2.6.1 The XP Project Lifecycle

We have now briey considered the primary goals and principles of XP, but what is XP? Is it just programming in pairs? No, XP does provide a software development lifecycle model as well as guidelines on the organisation of a software development team. The XP lifecycle is presented in Figure 2.1.
2.6.2 User Stories

User stories are similar in some respects to Use Cases from the Rational Unied Process in that they aim to capture how the user will use the system. However, they are written by the users themselves and not by the development team. Note
Test Scenarios
User Stories
Requirements Bugs Release Plan Customer Acceptance
Architectural Spike
System Metaphor
Release Planning
Iteration
Release
Acceptance Tests
Small Releases
Unresolved Problem
Resolved Problem
Next Iteration
Spike
Fig. 2.1 XP lifecycle.
Agile Software Construction
that the users should not be limited to describing just the user interface. Rather the user stories should describe how the user would use the system to accomplish something. It is worth noting that User Stories are not detailed requirements. These will be obtained during the iterations, when and if the aspect of the system covered by a particular user story is to be implemented. Instead, User Stories should only be detailed enough to allow a reasonable estimate to be made of the time taken to implement them under ideal conditions for the planning meeting. They should be short (e.g., about three sentences long) and should use the terminology of the user and not the terminology of the software development team. These user stories should feed into the release-planning meeting and to the creation of the user acceptance tests.
2.6.3 Architectural Spike

A Spike in XP terms is an attempt to reduce the risk associated with an unknown area of the system, technology or application domain. A Spike may involve some investigation, research and possibly some software to evaluate or elucidate the problem. The result of most explorations is usually not good enough to keep and so should be thrown away. Early on the overall architecture of the system to be developed is an important issue that needs to be resolved. Thus, at this stage research and analysis of the architecture to use should be carried out and fed into the release planning meeting. Other spikes are used during the project-planning phase to determine unresolved issues.
2.6.4 Release Planning

A release-planning meeting is used to create the release plan, which lays out the overall project. That is, the release plan indicates which user stories will be implemented and in which release this will happen. It also indicates how many iterations are planned and when each iteration will be delivered. This is done by negotiation between the interested parties using estimates derived from the user stories. The estimates are produced by the technical members of the team potentially with input from the users. The users prioritise the user stories possibly with input from the technical team members. From this, the timescales for the project, the delivery dates of various iterations, and the nal system delivery are all negotiated. If it is found that management or users are unhappy about the proposed delivery dates, then one or more of the features of the system, the resources available or the time taken must be modied until all participants are happy. Note that individual iterations are planned just before the iteration commences, not in advance.

2.6 XP: Extreme Programming: Agile Software Construction

Uploaded by

Copyright:

Available Formats

2.6 XP: Extreme Programming: Agile Software Construction

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

2.6 XP: Extreme Programming: Agile Software Construction

Uploaded by

Copyright:

Available Formats

Agile Software Construction

2.6 XP: eXtreme Programming

Agile Methods and the Agile Manifesto

2.6.1 The XP Project Lifecycle

2.6.2 User Stories

Fig. 2.1 XP lifecycle.

Agile Software Construction

2.6.3 Architectural Spike

2.6.4 Release Planning

You might also like