SCHOOL OF COMPUTING

DEPARTMENT OF INFORMATION SYSTEM (IS)

SUBMITTED BY_

1.HALEFOM GEBREHANS EITM/UR177342/12

2.YORDANOS MEBRAHTU UGR/178226/12

SUBMITTED TO

INS- BERIHULEY
INTRODUCTION

One of the well-known methods of Agile is extreme programming (XP in short) and is driven by a set of
values including simplicity, communication, feedback and courage . The XP process is characterized by a
short development life cycle, incremental planning, continuous feedback and reliance on
communication and evolutionary design.

The core part of XP consists of a simple set of practices including a planning game, small releases,
metaphor, simple design, test driven development (TDD), refactoring, Pair Programming (PP), collective
ownership, continuous integration, 40-hour week, onsite customer and coding standards. This
interesting composition of XP is one of the main reasons that make it successful.

It was first Beck and Jeffries who developed the XP as system. Extreme Programming (XP) is a software
development methodology developed to improve the quality of software as well to respond to the
changing needs of customers. The variation in composition and interaction between the values and
practices and their feedback in the XP system have made the software system more complex and needs
more knowledge to understand each and every common practice of XP. XP is known to be a
lightweight agile software development methodology with some extreme practices which are
lightweight in nature but very difficult and sometimes unrealistic to implement the practices and there
are only a few analytical studies of XP. Most of the literature and books have been drafted by the
inventors of the Agile Manifesto and are concerned with the promotion and commercialization of the
agile methods and the services they provide. Figure 1 shows the general overviews of XP. Release
planning is done with the help of system metaphor obtained architectural spikes and the requirement
specifications obtained from user story. Release plan helps to carry out the iteration which in turn
produces a piece of software. Small releases are released after the acceptance test approved by
customer.

Extreme Programming is used as research framework to examine the causes why cent percent
implementation of XP is not possible. Therefore, an interpretive approach is followed to conduct the
literature review and this approach is concerned with the hermeneutic cycle derived from document
and literary analysis. The hermeneutic cycle is used for the modeling of extreme programming regarding
the most criticized practices of XP. Lightweight requirement, onsite customer and Pair Programming are
the three most criticized and extreme practices of XP. Interpretive approach was used for agile modeling
to address all the pitfalls of the three extreme practices of XP to make it realistic and practical.

Extreme Programming: Development teams started using Extreme Registration (XP) in the mid-1990s.
Like other agile approaches, XP is iterative and provides small issues at the end of each iteration. It
defines XP "as a discipline for software development based on the values of simplicity, communication,
feedback and courage. It works by bringing the whole team together in a simple practice, with lots of
feedback so that the team can see where they are and adapt the practices to their particular situation.
The extreme programming philosophy says that makes software development fun, simple, flexible,
predictable, less risky, efficient and more scientific.

3.1. Values, principles and practices of Extreme Programming

Extreme Programming (XP) is based on the five values .

 Communication

 Simplicity

 Feedback

 Courage

 Respect3

The fundamental principles of Extreme Programming are

 Rapid feedback

 Assume simplicity

 Incremental change

 Embracing change

 Quality work

Extreme Programming (XP) is based on the 12 practices −

 The Planning Game

 Small Releases

 System Metaphor

 Simple Design

 Continuous Testing

 Refactoring

 Pair Programming
 Collective Code Ownership

 Continuous Integration

 40-Hour Work Week

 On-site Customer

 Coding Standards4.

3.2. User Stories

XP uses the concept of user stories as the central mechanism for defining needs. They are created by
system users to define attributes and functionalities that will be included in the solution and do not have
a high level of detail. Each user story is usually accompanied by a list of acceptance criteria that
identifies specific details about the story. [8]

Stories are used to:

•prioritize work into iterations,

•identify risk associated with a request,

•estimate the effort required to deliver the request, and

•establish a conversation between the team and the product owner around the subject of the real
business need, in order to confirm a common understanding of what has to be done.

3.3. Release Planning and Execution

XP relies on three levels of planning:

•release planning,

•iteration planning, and

•daily planning.

Release planning identifies the next set of usable characteristics that a release can compose. There are
often some job changes before the product is ready for release.

In XP, release plans are used to track and describe the features or functionality that will be delivered in
each product release.

The launch plan is similar to the portfolio concept in the Scrum framework. The adjourned planning
meetings are then used as a way of team collaboration in planning the next edition. As the team works
to schedule the issue, user stories are sorted based on the most important features for the customer,
ensuring that the most important features are always delivered first. The stories are broken down into
granular functional requirements in a technique called story decomposition, on a just-in-time basis.
Then, by putting the story together, the team identifies the detailed design and acceptance criteria for
the story.

While iterations are underway, XP is similar to Scrum in that it uses daily meetings as the primary vehicle
for team communication. This daily position meeting is used to facilitate daily planning activities and to
review the progress of the previous day's position. In practice, teams using the XP approach often
combine elements such as endings, roles, and ceremonies (such as sprint planning and sprint reviews)
from the Scrum framework.

3.4. Roles and Responsibilities

In Extreme Programming there are four key roles:

•Customer: The customer creates and prioritizes the user stories and performs risk analysis.

•Developer: The developer communicates directly with the customer and builds only what is necessary
to deliver on each iteration.

•Tracker: The tracker keeps track of the schedule and the metrics.

•Coach: The coach guides and mentors the team in applying XP practices effectively.

3.5. Business Analysis in XP

While XP focuses on value-based development, it does not explicitly address business analysis activities.
XP is built on the basic assumption that the role of the customer is played by a small number of people
who know what the most valuable roles are. When XP is implemented on a larger scale, or with
customers who do not have a clear view of the incremental value of features, business analysts add
significant value through facilitation and negotiation with stakeholders to reach a
common5understanding of what the most valuable deliverables will be. Business analysts can also
contribute by facilitating story

mapping.

In traditional XP, clients create and manage user stories directly. This can lead to non-detection
requirements that run the risk of restricting resolution without considering root cause or applicability to
other customer groups. Business analysis skills can be used to ensure that underlying issues are
addressed in a way that works for the majority of project stakeholders, if not, as well as to ensure that
full acceptance criteria have been collected for all user scenarios. They often carry out writing and
storytelling activities on projects that involve dedicated business analysts.

3.6. Techniques
•User Story: User stories identify which roles in the story provide value and therefore identify the
stakeholders who can elaborate on that value.[

•Story Mapping: Story maps show relationships between user stories and larger activities that the user
must be able to accomplish.

•Story Decomposition: Epics, features, or minimally marketable features (MMF) tie groups of user
stories together intolarger packages that can be discussed with stakeholders.

•Story Elaboration: Defines the detailed design and acceptance criteria for a user story on a just ‐in ‐
time / just‐enough basis.

3.7. Extreme programming Life Cycle

Five stages of XP software development life cycle:

Planning

This is the first step in the Extreme Programming development life cycle. Its main task is to establish the
objectives of the entire project and certain iterative cycles. At this point, the team meets with the
customer and asks about all future aspects of the software. The customer formulates vision of the
product in the form of user stories. The developers evaluate them and prioritize them in the release
plan. After that, work begins to turn them into tasks.

Designing

At this stage of the project, the team must define the main characteristics of the future code. The main
thing is to create a simple design, because simplicity is one of the fundamental principles of the XP
methodology. Extreme Programming developers often share responsibilities at the design stage. Each
developer is responsible for the design of a certain part of the code.

Coding

The developers of Extreme Programming believe that good code should be simple. That's why they
constantly refactor it. The refactoring procedure allows them to simplify the code or its parts without
affecting the functionality of the final product.

Testing

In Extreme Programming, the test procedure is generally performed not after the final or intermediate
product is made, but in conjunctionconjunction with the code writing procedure.

Listening
In the final stage of the life cycle, the XP team must obtain customer feedback. He is the only person
who estimates the final and intermediate products.7

Comparisons of Extreme programming and Traditional approach

Extreme Programming is different from traditional approaches in many ways:

1. XP involves short, tight iterations of building and releasing software.

2. The customer is on site and is a component of the event team. Once the iteration has started,
developers add pairs. No development is finished by one individual. All development is jointly owned.
This can be a surprisingly element of XP.

3. A 'test-first' philosophy prevails. In XP you write the test to point out that the code will work before
you write the code. Testing and coding are performed together. Before any new software is released,
the entire test suite is run to make sure that it doesn't break the other component of the system.

4. Some principles underlying the people aspects of XP are: work no over 40 hours every week, be
courageous, take responsibility and share ownership.

5. Some principles underlying code production are: keep it simple, have one shared metaphor to guide
system development, regularly restructure the system to boost it (refactoring), continuously integrate
and test, and follow coding standard.

EXTREME PROGRAMMING STRENGTHS AND WEAKNESSES

Extreme is an adaptive process and is also highly flexible, allowing software development to keep up
with rapidly changing business needs for global competition, this practice enables organizations to meet
the needs of a changing product with frequency. Scheduling reduces administrative and overhead costs,
improves staff productivity, and meets customer needs, compared to the traditional plan-based
development process.

On the other hand, extreme programming has weaknesses; it is a process for a small development team
of 10 to 12, it is also not scalable, which makes it difficult to take real large-scale projects. It also lacks
artifacts and poor documentation, making it difficult to maintain the system developed with a great
methodology, unlike the plan-driven process that practices great advanced design with artifacts and
extensive documentation in each development life cycle. . Due to the lack of initial planning, according
to the schedule compared to the traditional plan-based process, this safety application system is not
recommended for a critical system. Experienced developers are required to implement them
successfully.

Strengths

Quick prototype delivery

Iterative approach to development

Create room for experimental designs.

Enhanced system reliability.

Refactoring enhances software quality.

Quality code.

Access to dedicated users.

Lower overhead.

Suitable for medium size team.

Weaknesses

Not scalable

Too much emphasis on early results delivery.

Too much emphasis on early results delivery.

Test-drive approach extends development time.

Undefined requirements.

Unstructured approach to development.

Lacked planning.

It lacked documentation.

Higher overhead.

Not suitable for a large size team.

CONCLUSIONS

Extreme Programming is a software development approach based on values of simplicity,

Companies that build their workflow on XP principles and values create a competitive yet motivational
atmosphere within and between teams. Programmers appreciate each other’s project input; deliver
software quickly because they can distinguish relevant tasks from unnecessary ones. They react quickly
to feedback realizing it’s a reasonable criticism aimed at making a product better.

XP teams don’t consider each technical challenge as a problem but think of it as a way to develop skills.
REFERENCES

[1] W. S. Humphrey, A discipline for software engineering. Reading, Mass.: Addison Wesley,1995.

[2] L. Williams and A. Cockburn, "Agile software development: It's about feedback and change," IEEE
Software, vol. 20, pp. 39-43, 2003.

[3] K. Beck, Extreme programming explained: Embrace change. Reading, MA.: Addison Wesley Longman,
Inc., 2000.

[4] G. Succi and M. Marchesi, "Extreme Programming Examined: Selected Papers from the XP 2000
Conference,"