Exercise 2:

Reference course name: Development & Testing with Agile: Extreme Programming
Get a working knowledge of using extreme automation through XP programming
practices of test first development, refactoring and automating test case writing.
Solve the questions in the “Take test” module given in the reference course name to
gauge your understanding of the topic

Extreme programming is related to the agile development methodology, so let’s turn to

the Agile Alliance for the definitive explanation. According to the Alliance, “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. Furthermore, XP is the
most specific of the agile frameworks regarding appropriate engineering practices for
software development.”

Extreme programming is built upon a set of principles, practices, and values that emphasize
the technical aspect of software development to enable small to midsize teams to create
superior quality software while adapting to changing, evolving requirements.

So instead of jumping off a mountain or water-skiing without the skis, extreme programming
just means taking good programming practices to the extreme. Or, as Rolling Stones'
frontman Mick Jagger once said, "Anything worth doing is worth overdoing."

How Does Extreme Programming Work

Extreme programming operates on a precise set of engineering practices built on principles

and values. Here is a flowchart showing XP methodology, courtesy of Digite.

Let’s look at each part of the methodology in greater detail.

What Are the Values, Principles, and Practices of Extreme Programming

The following elements work together to create extreme programming, fostering better
cooperation between team members and ultimately developing a higher quality product.

XP Values
Values offer teams purpose, guiding them in making high-level decisions. However, values
are abstract and difficult to apply in concrete terms in the real world. The five values are:

 Communication: You can’t work together effectively without sharing knowledge, and you
can’t share knowledge without communication.
 Simplicity: Developers can save time and effort by writing simple, effective code that
works properly. Ultimately, the less complex code enhances product value.
 Feedback: Early, constant feedback is ideal for team members who release frequent
software deliveries, helping them to adjust as the project evolves and changes. The sooner
programmers know that the product requires changes, the easier it is to create those
changes (and less painful).
 Respect: Every team member cares about their work, and everyone contributes.
 Courage: It takes guts to admit you're mistaken and that your idea didn't work and must be
changed. Being honest takes courage, and you need honesty in providing realistic
estimates, even if stakeholders don't like the truth.

XP Principles

Unlike values, principles are more grounded, down-to-earth, concrete ideas. Principles define
what teams must do specifically and provide a means for team members to hold each other
accountable to XP’s values. The five principles are:

 Fast feedback: This principle means getting feedback quickly and responding to it fast,
and not putting it off.
 Assumed simplicity: Team members must direct their energy on whatever task has the
highest priority and avoid unnecessary or redundant jobs. Keep it simple.
 Incremental changes: It's better to make small changes step-by-step than to let them
accumulate and handle them all simultaneously.
 Embrace change: Speaking of changes, if the client wants to modify the product,
programmers should support the idea and map out how they will incorporate the new
changes.
 Produce quality work: A team that works well together will inevitably create a superior
product and take pride in the result.

XP Practices
The interconnected set of practices listed below are the heart and soul of extreme
programming. There were originally a dozen practices, but over time they have been refined
and whittled down. This list of practices is the most current.

 Sit together: This principle harkens back to the value of communication. A face-to-face
conversation is typically the best means of communication, so the team should sit together
in the same area without walls or dividers.
 Whole team: The whole team comprises a cross-functional group of people, each having a
needed role in contributing to product development. Everyone plays their part and works
together daily.
 Informative workspace: Since the team should sit together, the workspace should be
conducive to this. However, there need to be some privacy provisions.
 Energized work: Team members should take whatever steps are needed to be physically
and mentally focused. These steps include being free from distractions, not overworking,
staying healthy, and respecting your teammates.
 Pair programming: All production software is created by a pair of people sitting at the
same machine, a riff on the idea of needing two sets of eyes to spot mistakes.
 Stories: Stories describe the product’s uses in terms that the customers and users can relate
to. In addition, these stories help developers and programmers plan their work.
 Weekly cycle: Weekly cycles are analogous to iterations. The team meets at the start of
the week to discuss the progress to date. The customer chooses the stories to be worked on
that week. The team decides how to tackle them.
 Quarterly cycle: Quarterly cycles are comparable to releases and keep each weekly cycle’s
detailed work in line with the overall project. The customer shares the overall plan for the
team in context with the features to be done within a quarter.
 Slack: Throw in some low priority assignments or stories into the weekly and quarterly
cycles that can be dropped if the team falls behind on the higher priority stories or tasks.
 Ten-minute build: The ten-minute build’s ultimate goal is to automatically build the entire
system and run every test within ten minutes. This practice motivates the team to increase
their reliance on build process automation.
 Continuous integration: Immediately test code changes when they are added into the larger
codebase, helping team members spot errors and integration issues as they happen.
 Incremental design: This practice recommends that programmers do a small bit of work
up-front to grasp the correct perspective of the system design, then go deep into the details
of a given aspect of the design when delivering specific features. This method is a cost-
effective way of making changes and gives programmers the most up-to-date information
they require to make design decisions.
 Test-first programming: Instead of developing code, writing tests, then running tests, this
practice has programmers following this sequence:

 Write a failing automated test

 Run a failing automated test
 Develop code to make the test pass
 Run test
 Repeat

XP Key Roles and Responsibilities

Although an experienced extreme programming team shouldn’t depend on rigid roles,

beginning teams can benefit from the boundaries, helping people stay in their lane until the
process is no longer needed. These are the four most common XP roles:

 The Customer: There should be an actual customer on-site to prioritize user stories,
answer questions, and collaborate with acceptance testing. If there is no one available, the
customer should appoint a representative.
 The Programmers: Programmers estimate how much work it takes to finish tasks and
stories, write the automated tests, and implement customer stories.
 The Coach: Not every team needs a leader, but sometimes this role is required to make
sure everyone follows the practices consistently enough to turn into habits and ensure that
team members don't lapse into old patterns.
 The Tracker: As the name implies, the tracker keeps track of the team’s progress metrics,
including identifying obstacles and devising workarounds.