Extreme

Programming
Definition

Extreme Programming (XP) is an agile software

development framework that aims to produce
higher quality software, and higher quality of life
for the development team. XP is the most
specific of the agile frameworks regarding
appropriate engineering practices for software
development.
 When Applicable

• Dynamically changing software requirements

• Risks caused by fixed time projects using new
technology
• Small, co-located extended development team
• The technology you are using allows for automated
unit and functional tests
 XP's Five Values
• Communication. Software development is inherently a team sport that relies
on communication to transfer knowledge from one team member to everyone
else on the team. XP stresses the importance of the appropriate kind of
communication – face to face discussion with the aid of a white board or other
drawing mechanism. Most projects fail because of poor communication. So
implement practices that force communication in a positive way.

• Simplicity. Simplicity means ―what is the simplest thing that will work?‖ The
purpose of this is to avoid waste and do only absolutely necessary things such
as keep the design of the system as simple as possible so that it is easier to
maintain, support, and revise. Simplicity also means address only the
requirements that you know about; don’t try to predict the future.
• Develop the simplest product that meets the customer’s needs

• Courage. Be prepared to make hard decisions that support the other

principles and practices. You need courage to raise organizational issues that
reduce your team’s effectiveness. You need courage to stop doing something
that doesn’t work and try something else. You need courage to accept and act
on feedback, even when it’s difficult to accept.
Respect
The members of your team need to respect each other in order to communicate
with each other, provide and accept feedback that honors your relationship,
and to work together to identify simple designs and solutions.

Feedback
You need courage to raise organizational issues that reduce your team’s
effectiveness. You need courage to stop doing something that doesn’t work and
try something else. You need courage to accept and act on feedback, even
when it’s difficult to accept. Developers must obtain and value feedback from
the customer, from the system, and from each other.
• XP is based on these
– four values and
– twelve practices
– have been extended various ways since XP’s introduction
• Extreme Programming (XP) takes an ‘extreme’ approach
to iterative development.
– New versions may be built several times per day;
– Increments are delivered to customers approx. every 2 weeks;
– All tests must be run for every build and the build is only
accepted if tests run successfully.
 Roles

• Although Extreme Programming specifies particular practices

for your team to follow, it does not really establish specific
roles for the people on your team.
• Depending on which source you read, there is either no
guidance, or there is a description of how roles typically found
in more traditional projects behave on Extreme Programming
projects. Here are four most common roles associated with
Extreme Programming:
 1. The Customer
The Customer role is responsible for making all of the business
decisions regarding the project including:

What should the system do (What features are included and what
do they accomplish)?
How do we know when the system is done (what are our
acceptance criteria)?
How much do we have to spend (what is the available funding,
what is the business case)?
What should we do next (in what order do we deliver these
features)?
The XP Customer is expected to be actively engaged on the
project and ideally becomes part of the team.

The XP Customer is assumed to be a single person, however

experience has shown that one person cannot adequately provide
all of the business related information about a project. Your team
needs to make sure that you get a complete picture of the
business perspective, but have some means of dealing with
conflicts in that information so that you can get clear direction.
 2. The Developer

Because XP does not have much need for role definition,

everyone on the team (with the exception of the customer and a
couple of secondary roles listed below) is labeled a developer.

Developers are responsible for realizing the stories identified by

the Customer. Because different projects require a different mix
of skills, and because the XP method relies on a cross functional
team providing the appropriate mix of skills, the creators of XP
felt no need for further role definition.
 3. The Tracker
• Some teams may have a tracker as part of their team. This
is often one of the developers who spends part of their
time each week filling this extra role. The main purpose
of this role is to keep track of relevant metrics that the
team feels necessary to track their progress and to identify
areas for improvement. Key metrics that your team may
track include velocity, reasons for changes to velocity,
amount of overtime worked, and passing and failing tests.

• This is not a required role for your team, and is generally

only established if your team determines a true need for
keeping track of several metrics.
 4. The Coach

• If your team is just getting started applying XP, you

may find it helpful to include a Coach on your team.
This is usually an outside consultant or someone from
elsewhere in your organization who has used XP
before and is included in your team to help mentor
the other team members on the XP Practices and to
help your team maintain your self discipline.

• The main value of the coach is that they have gone

through it before and can help your team avoid
mistakes that most new teams make.
12 Core Practices of Extreme
Programming
 Planning Game

In XP the main planning process is called Planning Game. There are 2

levels of plans in XP; level one is release planning and level 2 is iteration
planning.

In both levels, there are 3 steps: exploration, commitment, and steering.

The first phase is release planning. The team and stakeholders/customers

collaboratively decide what are the requirements and features that can be
delivered into production and when. This is done based on priorities,
capacity, estimations and risks factor of the team to deliver.

In Iteration planning the team will pick up the most valuable items from
the list and break them down into tasks then estimates and a committment
to delivering at the end of the iteration.
 Simple Design
In the XP, the team will not do complex or big architecture and designs
upfront; instead the team will start with a simple design and let it emerge
and evolve over a period of iterations. The code is frequently refactored so
that it will be maintainable and free of technical debt. Simple designs
make the 'definition of done' easier.

XP teams conduct a small test or proof-of-concept workout called spike.

The outcome of the spike helps the team to apprehend the validity of the
hypothesis, gauge the complexity of the solution and feel assured to
estimate and build something primarily based on the test.
 Test-Driven Development (TDD)

In XP Developers write the unit test cases before starting the coding.
The team automates the unit tests and it helps during the build and
integration stage. The main benefit of TDD is that programmers
have to only write the code that passes the tests.

Basics steps of TDD,

Write the unit test case first

Write a minimal amount of code to pass the test.
Refactor it by adding the needed feature and functionality, While
continuously making sure the tests pass.
 Code Standard
Organizations want their programmers to hold to some well-
described and standard style of coding called coding standards. It is
a guideline for the development team as in XP. Since there are
multiple programming pairs at play coding standards are very useful
to make consistency in code, style, naming conversion, exception
handling and use of parameters.

These standards must define and agreed before the team starts the
coding.

It will make the code simple to understand and helps detect the
problem or issues quickly and also increases the efficiency of the
software.
 Refactoring
Refactoring as the word suggests, is restructuring or reconstructing
existing things. In XP over a period of time the team produces lots
of working code and it increases the complexity and that contributes
technical debt. To avoid this, we should consider the below points,

Ensure code or functions are not duplicated.

Ensure all variables in scope, defined and used.
No long functions or methods
Removing unnecessary stuff and variables
Proper use of access modifiers etc.

By refactoring, the programmers look to improve the overall code

quality and make it more readable without altering its behavior.
 Pair Programming
This is my favorite and most used practice. Pair programming
consists of two programmers operating on the same code and unit
cases, on the same system (one display and one keyboard). One
programmer plays the pilot role and focuses on clean code, and
compiles and runs. The second one plays the role of navigator and
focuses on the big picture and reviews code for improvement or
refactoring.

Every hour or given a period of time this pair is allowed to switch

roles so that the pilot will play the role of navigator and vice versa.

The pairs of pilots and navigators are also not fixed and they are
frequently swapped, the main benefits of that over a period of time
is that everyone gets to know about the code and functionality of the
whole system.
 Collective Code Ownership
By following pair programming practices the XP team always takes collective
ownership of code. Success or failure is a collective effort and there is no
blame game. There is no one key player here, so if there is a bug or issue then
any developer can be called to fix it.

Continuous Integration

CI is Continuous Integration. In XP, Developers do pairs programming on

local versions of the code. There is a need to integrate changes made every few
hours or on a daily basis so after every code compilation and build we have to
integrate it where all the tests are executed automatically for the entire project.

If the tests fail, they are fixed then and there, so that any chance of defect
propagation and further problems are avoided with minimum downtime.

The team can use CI tools like Jenkins, shippable, Integrity, Azure DevOps
Pipelines, etc
 Small Release
A cross-functional team in XP, releases Minimum Viable Product (MVP)
frequently. Small releases also help to breakdown complex modules in a small
chunk of code. This helps the developer team as well as the on-site customer to
demonstrate the product and focus only on the least amount of work that has the
highest priority.

System Metaphor
• This is majorly connected with the user story, the story must be simple enough
to be easily understood by user and developers and to relate it with code.
• It could be a naming conversion practice used in design and code to have a
shared understanding between teams. For example Order_Food() is easily
explained -- this will be used to order food.
•
• It easy for the team to relate to the functionality of the particular component by
just looking at its name.
•
 Onsite Customer
• This is a similar role as Product Owner in Scrum. Onsite
customer plays a major role here and is responsible for crafting
the vision, defining user stories and acceptance criteria, the
definition of done and release planning.

• They are the experts who know the domain or product and know
how to generate a return of investment (ROI) by delivering the
minimum viable product (MVP).

• If the onsite customer role is not full time, the role can be filled
with product managers, product owners, UI-UX designers and
business analysts who are called proxies.

• The word ―on-site‖ implies that the customers or their proxies sit
together with the rest of the team to ensure that communication
flows freely.
 Sustainable Pace
• This is a people-centric practice. In XP practices like
TDD, continuous integration and refactoring of code
help to proactively improve the quality and stability of
the working software.

• XP maintains a sustainable pace by introducing down

time during the iteration. The team is not doing actual
development at this time but acts as a buffer to deal
with uncertainties and issues. Teams can use the slack
time to pay down technical debt by refactoring code or
do research to keep up the pace.
 Pair Programming
Pair programming consists of two programmers sharing
a single workstation (one screen, keyboard and mouse
among the pair).

The programmer at the keyboard is usually called the

―driver‖, the other, also actively involved in the
programming task but focusing more on overall
direction is the ―navigator‖; it is expected that the
programmers swap roles every few minutes or so.
• both programmers must be actively engaging with the
task throughout a paired session, otherwise no benefit
can be expected
• a simplistic but often raised objection is that pairing
―doubles costs‖; that is a misconception based on
equating programming with typing – however, one
should be aware that this is the worst-case outcome of
poorly applied pairing
• at least the driver, and possibly both programmers, are
expected to keep up a running commentary; pair
programming is also ―programming out loud‖ – if the
driver is silent, the navigator should intervene
• pair programming cannot be fruitfully forced upon
people, especially if relationship issues, including the
most mundane (such as personal hygiene), are getting
in the way; solve these first!
 Pair Programming Advantages

• There are several compelling reasons you should consider this

strategy:
• Two heads are better than one. If the driver encounters a
hitch with the code, there will be two of them who’ll solve the
problem.
• More efficient. Common thinking is that it slows down the
project completion time because you are effectively putting
two programmers to develop a single program, instead of
having them work independently on two different programs.
But studies have shown that two programmers working on the
same program are only 15% slower than when these
programmers work independently, rather than the presupposed
50% slow down.
• Fewer coding mistakes. Because there is another programmer
looking over your work, it results in better code. In fact, an earlier
study shows that it results in 15% fewer bugs than code written by
solo programmers. Plus, it allows the driver to remain focus on the
code being written while the other attends to external matters or
interruption.

• An effective way to share knowledge. Code Fellows talks about

how it could help programmers learn from their peers in this blog
post. It would allow programmers to get instant face-to-face
instruction, which is much better than online tutorials and faster than
looking for resources on the Internet. Plus, you can learn things
better from your partner, especially in areas that may be unfamiliar
to you. Developers can also pick up best practices and better
techniques from more advanced programmers. It can also facilitate
mentoring relationships between two programmers.

• Develops your staff’s interpersonal skills. Collaborating on a

single project helps your team to appreciate the value of
communication and teamwork.
In sum, it helps your programmers learn from each other while coming
up with programs and applications with better code quality and fewer
bugs.
Why is Programming in Pairs Better than Code Reviews?
Code reviews are a process wherein another programmer takes a look at
your code to find something that needs improvement or find defects in
it. It combines testing with quality control to ensure that everything in
your code is good. This helps you ensure that your code is improved.

However, it is challenging to find somebody to review your code

because people may not want to look at another’s code and understand
their reasoning just for the sake of checking its quality. Most of the
time, code reviews happen when somebody else tries to add some
functionality to your code, or fixes bugs. But by then, you, as the
original programmer, might not even be around to appreciate the code
review.
With pairing, it is like having somebody review your code instantly and
regularly. It is a higher form of code reviews. Two people have to be
there and understand the program being written.

And if one sees problems with the other’s code, then it can be instantly
corrected. You also have fewer chances of having bugs written into
your code. Code reviews are not as proactive as you have to wait until
the code is completed — bugs and all — before somebody could take a
look at and correct it.
 Challenges of Pairing
The common problems observed when it comes to pair programming
include the following:
• The pair should be equally engaged and be participative for the
duration of the task. Otherwise, there would be no benefits.
• People who have not tried it may think that it will double the cost
because you are putting two programmers on one project. However,
this is a misconception that needs to be clarified. On top of the fact
that pairing, done right, will only result in 15% slowdowns in terms
of the individual output, it actually speeds up the coding process and
ensures better quality code, which lessens the chances that the
program would have to be redone.
• Pair programming should also be a programming out loud process,
where the pair is verbally detailing what it is doing.
• It’s not something that you can force your team to do. It’s highly
social and interactive, so you should be able to detect pairs that may
have problems with each other, such as clashing personalities or
even problems with personal hygiene.
 Extreme Programming team
Despite the fact that even one person can create an XP team; specialists usually
define seven Extreme Programming team roles.

Programmer
His responsibility is to estimate user stories and separate them from technical
tasks. He is also responsible for estimating the time required to finish the
project.
Tester
This employee is responsible for conducting functional tests and informing
the team on their results.
Tracker
This person’s main task is to interview the developers every week and find
out if something in their work goes wrong.
Customer
The customer is the main person in XP. He is the one who writes user stories
and estimates the final and intermediate product.
Coach
His main responsibility is to keep the project extreme. He teaches
other team members how to achieve this goal.
Manager
A very important role in every Extreme Programming team. This
person is responsible for conducting team meetings and making them
effective.
Doomsayer
This role is also extremely important, because this person’s main task
is to follow the progress of the project and avoid problems in its
realization, like not meeting the terms, or other failures.
 Extreme Programming - Tools
ExtremePlanner
• ExtremePlanner is a browser-based Agile Project
management solution that is designed specifically
to support Agile methods including Scrum and
Extreme Programming.
• ExtremePlanner concentrates on planning and
tracking the progress of features (or user stories)
that have actual business value to customers.
• www.extremeplanner.com
 Project Planning and Tracking System

• PPTS is a Web-based environment supporting

teams who have chosen to develop Software
according to the Agile Methodologies Scrum
and/or Extreme Programming.
• http://ses-ppts.sourceforge.net/
 Targetprocess

• Targetprocess is a Visual project management

software that enables you to visually manage
complex work and focus on the things that
matter.
• Targetprocess gives the visibility and
transparency you need across your organization.
From Kanban and Scrum to almost any
operational process, Targetprocess flexibly adapts
to your management approach and
organizational structure.
• For more information − www.targetprocess.com
 Plone Extreme Management Tool

Plone Extreme Management tool provides project administration which

supports the Extreme Pr
• Plone Extreme Management tool provides −
• Content types −
– Project − Project Managers can add multiple projects. For each project,
iterations and stories can be added by both the customers and
employees.
– Iteration − The project will be planned with iterations. An iteration is a
period of 1 to 3 weeks in which a number of stories will be implemented.
– Offer − Contains the stories that a customer wants in this project. It is
used as a way to bundle the wishes of the client and give a first indication
of the size of a project.
– Story − The customer can define new features by describing these feature
in a story.
– Task − The employees can estimate the story by defining tasks.
– Booking − While working on tasks the employees can track time and
easily book those at the end of the day.