Module II

Extreme Programming
 Introduction
 Core XP values
 The twelve XP practices
 About extreme programming
 Planning XP projects
 Test first coding
 Making pair programming work.

18-11-2024 1
 XP INTRODUCTION
Extreme Programming (more commonly known as XP). XP is part of the agile
movement that focuses on the writing of the software that will implement the required
system.

• XP has been widely misunderstood and is often associated with hacking, a lack of
planning, avoiding the creation of documentation and of programmers wildly
attacking code while working in pairs.

• XP places a great deal of emphasis on planning, and on the production of software

that is as simple as is achievable, but that still gets the job done.

• This simplicity should help other developers understand the code; however,
understanding the code often relies on good commenting, clarity of the actual
implementation and consistency.

18-11-2024 2
 CORE XP VALUES

1. Communication

2. Simplicity

3. Feedback

4. Courage

18-11-2024 3
Communication:

 Whatever the reason for poor communications, many problems or defects

within software systems can be traced back to poor communications during the
development of the system. This may be poor communication between
programmers, between end users and the development team, between
developers and manager, etc.

 projects undertaken in a University Computer Science degree actively

encourage group working or communication of any sort. Indeed, many require
the student to confirm that the project is all their own work and that they did
not collaborate with anyone else!

18-11-2024 4
Simplicity:
 A rule I have adopted and forced those working with me to adopt for many years now is to keep
things simple. If a simple solution is adopted, then it is easier for all to understand.

 I have had to argue this case many times. I remember trying to convince a very talented and
skilled developer that using a set of binary flags within an int to hold information about the state
of the system was not a good idea.

 The simplicity value underlying XP says that you should aim for the simplest solution that does
the job (echoes of Agile Modelling here).Why is this, the theory (and general experience is) that
the simpler the implementation, the easier it is to implement, test, understand, maintain, etc. Thus,
the easier it is to find and correct bugs in the software.

 This does not mean that the solution is necessarily simple or trivial; rather that it is the simplest
solution to the problem in hand. 18-11-2024 5
Feedback:
 It is good to get feedback. Projects should get feedback early, and often, from the
customer, from the team, from real end users, from other project stakeholders, etc.

 It helps to identify problems early on, deal with unknowns and clarify issues. That is, it
generally helps avoid nasty shocks later on. Feedback can be at many different levels, for
example, by running unit tests every time any new code is integrated into the system, any
problem introduced by the new code can be identified immediately.

 At another level, giving frequent small releases to friendly end users, containing just
enough new functionality to make it worth their while, means that they can provide
feedback quickly and frequently about the evolving system

18-11-2024 6
Courage:

 You will need courage to adopt XP. Why? Because you need courage to refactor
code (that is change existing code so that it is better than it was before but such
that it does not provide any new functionality), you need courage to throw away
code, you need courage to code for now and leave tomorrow to tomorrow and
you need courage to move management to adopt XP’s way of working.

 There are twelve core practises which effectively define XP. If you have not
adopted all twelve, then you are not truly doing XP (although you may be very
near to XP within some agile continuum). 18-11-2024 7
 TWELVE CORE PRACTISES
1. The planning game: This focuses on planning the next release.
2. Small releases: A software system is developed iteratively with small
releases adding system features and allowing rapid feedback.
3. Simple design: Keep things as simple as possible but not simpler.
4. Testing: Unit tests and acceptance tests must be continually developed and
the code must pass unit tests for development to continue.
5. Refactoring: This involves improving the system (e.g., to aid simplicity)
without changing the functionality.
6. Pair programming: All code is developed by developers working in pairs
(at a single machine).

18-11-2024 8
 TWELVE CORE PRACTISES(Contd.,)
7. Collective ownership: Everyone owns all the code so anyone has the
right to change any of the code at any time in order to improve it.
8. Continuous integration: New code is integrated and the system rebuilt
every time a task is completed (which may be many times a day).
9. On-site customer: Have a real customer as part of the team, so that they
are always available to answer questions.
10. Coding standards: Have them and use them.
11. 40-hour week: Work no more than 40 hours a week so that the
developers are always fresh and ready for the challenges facing them.
12. System metaphor: Use the system metaphor to guide the whole
development. It is a metaphor for how the system operates (it is similar
to the architecture of the system but typically simpler).
18-11-2024 9
 1. THE PLANNING GAME
 What’s in a Name.
 First let us deal with the name of this practise “The Planning Game”. I have found
that the very name of this practise causes problems (at least here in the UK).
 The questions I have encountered range from “what’s a game got to do with serious
software development?” to “why make us play a game, we want to plan the
project?”.
 The idea of this practise is far more serious than the name obviously implies. If you
have a problem with calling this practise the planning game then call it something
like the “Project Planning Workshop.” For me, this name is a far more accurate
description of what it does.
 XP has framed this practise in terms of a game to help elucidate what should happen
when planning an XP project; we will therefore stick with the term “Project Planning
Game” in this book.

18-11-2024 10
 PLANNING AN XP PROJECT
 XP projects involve a great deal of planning .This may have come as a shock to
some as they may have thought of XP as legalised hacking and thus considered
planning to have no part in XP.

 In planning is core to XP, although it is a very different form of planning than that
which might be found within a more traditional single delivery style of project.

 Many times, in a more traditional development project, a large amount of time is

spent crafting an elegant, complex and detailed plan using some tool such as
Microsoft Project. The end result is printed proudly by the project manager on the
largest printer available.

 They may even hang it on a wall for all to see. What happens next obviously
varies, but here is a scenario that is actually an amalgam of various projects I have
been in some way associated with in the past.
18-11-2024 11
 PAST ASSOCIATION

1. Developers begin to examine the plan and start making comments about how anyone could
expect them to produce component X is 3 days, or question where the database migration task is.

2. As development progresses, developers tell their project leaders of their progress and estimated
completion times, projects leaders tell their manager. At each stage, people unconsciously (or
otherwise) err on the side of optimism in their estimates. Resulting in a better-estimated position
than is the actuality.

3. The manager may or may not enter into the plan, the current state of the project, as he sees it.

4. At some point, some critical milestone is missed, at this point, the plan is re-assessed and it is
realised that the plan and reality are out of alignment. The manager then tries to find a way of
squaring the circle of the project. At this point, they may start forcing people to work excessive
overtime or may negotiate a later delivery or modify the list of features to be implemented. All of
which usually involve extensive discussions with the client.

5. The resulting plan may lead the whole project back to step 1 again and a new cycle of
catastrophe planning.
18-11-2024 12
AGILE INFLUENCES ON PLANNING AN XP PROJECT

There are a number of implications for how you will carry out any
planning for an agile project that come from trying to be agile. These
are:

 Plan for now

 Responsibility

 Dependencies

 Simplicity

18-11-2024 13
PLAN FOR NOW:
This is akin to only implementing what you need for today and
leaving the rest for tomorrow. Thus, you should only do the planning
that you need for the next release/next iteration in detail and no
more. You can still do long-term planning, but not in such great
detail.

 Part of this comes from the realisation that at the start of that
release, when you consider the user stories to be implemented,
you may find that a different set are required due to user feedback,
or changing requirements, etc.

18-11-2024 14
Responsibility:

The typical project is planned top down. That is, the top-level
management try and plan the project (hopefully with input from the
actual developers). The end result is a plan for which the developers
feel no responsibility and towards which they feel no trust. Agile
planning involves the developers the whole way. They should feel that
the plan is as much theirs as it is the managers.

 Thus, for example, the person expected to implement a particular

feature is the one who must estimate it. Also, remember that in XP,
an iteration should be very short and have a duration of weeks
rather than months.
18-11-2024 15
Dependencies:

 When planning an XP project, you should ignore the dependencies

between parts. That is, you should not worry about whether task x
is required before task y. Instead, you should focus on the highest
business priorities first and allow other issues to come out in the
wash.

18-11-2024 16
Simplicity (in planning):

You should keep in mind the type of planning that is being done at that point in time in order to
keep things as simple as possible (but not too simple). For example, if you are planning to help
determine the priorities and ordering of user stories, then much less detail is required. However,
if you are planning the implementation of a set of tasks for a particular iteration, then far greater
detail is required.

The game has three phases through which play proceeds. These phases are the exploration
phase, the commitment phase and the steering phase. Although we will describe each phase
sequentially, play does not necessarily flow sequentially from one phase to another, nor from
one move to another within each phase.

18-11-2024 17
Although the primary output of the Business Game is the plan, it:

 Allows customers to make business decisions,

 Allows developers to make technical decisions.

 To combine the results into the iteration oriented plan.

Within this framework the customer determines:

 Scope – what is in and out of the system.

 Priority – what is more important, less important, must haves and nice to haves, etc.

 Composition of releases – what will be in each release.

 Release dates
18-11-2024 18
In turn, the development team decides

 Estimates of how long various features will take.

 Consequences of for example, using a particular technology, for example,

 Linux versus Microsoft Windows XP, Java versus C#, J2EE (Java 2 Enterprise Edition)
versus .Net.

 Team and Project Organisation (e.g. the organisation of the tasks)

 Risks associated with different features (e.g. Will MySQL provide the required level of
performance or should an Oracle database be used).

 Detailed scheduling – which features are to be done when and in what order.

 This involves balancing the technical risks (which will benefit from being addressed
early on) with the business priorities that may be more important to the end user.

18-11-2024 19
Rather the whole process is cyclical, and play moves between
steps as and when required.

The steps performed during each phase are:

 Elaboration phase

 Commitment Phase

 Steering Phase

18-11-2024 20
Elaboration phase
This phases help to identify what the system needs to do. It is
compressed of the following steps:

 Write a story – The business writes a user story describing some

behaviour required of the system.

 Estimate a story – Development estimates how long the story will

take to implement. If they cannot estimate the story or the story
seems too big then they can ask for clarification or break the story
up into smaller chunks.

 Break a story up – The business must break a story down into

small chunks if required.
18-11-2024 21
 COMMITMENT PHASE
This phase allows business to determine the scope of the release and when that release will occur (based on
information provided by development and business).

The steps within the commitment phase are:

 Sort by value – business must sort the stories (written on index cards) into three supplies (1) must have, (2)
should have and (3) nice to have. This is effectively applying a relative priority to each story.

 Sort by risk – Development now sorts the stories into three further piles (1) stories that can be estimated
precisely, (2) stories that can be estimated roughly and (3) stories that can’t be estimated.

 Set velocity – development indicates how quickly they will be able to achieve the estimates (which have
been made in an idealised type of time).

 Choose scope – Business selects which user stories will be in the next release.

18-11-2024 22
 STEERING PHASE
The purpose of the steering phase is to allow the plan to be updated as things change over time. This phase is a little
different from the last two in that the last two are likely to have happened at the same time. This phase happens later on
within an iteration or between iterations as required. The players return to the game to consider what has been
happening during the lifetime of the project (or at least the lifetime of the current iteration, etc.).

The steps in the steering phase are:

 Iteration – from each iteration the business picks the stories that will form that iteration.

 Recovery – if it is realised that not all the stories can be implemented for a particular iteration, then Development
must ask Business to help determine which stories should remain in the iteration and which might be moved to later
iterations.

 New Story – if Business realises that an important story has been omitted, then it can introduce that story to
Development. This story can be estimated and the iteration re-planned. This will probably mean that one or more
existing stories will be removed from the current iteration, etc.

 Re-estimate – if it is clear that the current plan was over or under optimistic, then Development can re-estimate the
remaining user stories and adjust the project velocity and consider the18-11-2024
resulting implications.
23
 TYPES OF PLANNING GAMES

Actually two types of planning games, they are:

1. The initial planning game

2. The release/iteration planning game.

 The only real difference between the two versions of the planning game is in the level of detail.
 The initial planning game paints with a broad brush and plans the general set of iterations and roughly plans
out the user stories for each iteration. It is only really interesting in ballpark estimates, etc.
 The release or iteration planning game, plans out in more detail a single iteration and explores the high level
user stories by breaking them down into lower level stories

18-11-2024 24
 2. SMALL RELEASES

 The system being developed should be released often to the end users so that they
can provide frequent and rapid feedback to the development team. Thus, the smallest
possible releases that can add business value should be identified and scheduled.

 As soon as a set of tasks can add value to the customer, it should be released to that
customer. This not only allows customers frequent opportunities for providing
feedback, but also makes short-term planning easier.

 In each instance of the planning game needs to consider only the next few weeks and
thus the level of unknowns and the amount that the team can have diverged from the
plan is limited

18-11-2024 25
 3. SIMPLE DESIGN
Pure XP, this design process also happens just as the code is to be implemented. XP itself
does not mandate how the code is designed, it could be done merely by the pair
programmers discussing how they would approach the coding, it could be done in an Agile
Modelling manner, it could be done using flow charts, etc. XP does present the following
as being features of a simple (and thus from XP’s point of view) effective design. A simple
design is one that:

 Passes all the tests available for it.

 Has no duplicated logic.

 Ensures that any assumptions, or intentions, made by the developers are explicit to
anyone reading the code (for example by using Javadoc or other comments in the code).

 Has the fewest possible classes and methods.

18-11-2024 26
 4.TESTING
Test are produced before any code is written, acceptance tests are generated as soon as
requirements (in the form of user stories) are written, unit tests are produced before the
code is implemented, all code must pass all tests from development to progress, etc.

 A complete set of tests for all code produced (as you created the tests first).

 Simplest code that passes all tests.

 A clear view of what code should and should not do.

 A simple way of checking that refactored code has not altered functionality.

 A great deal of “documentation” explaining what a particular module should or should

not do.

18-11-2024 27
 5. REFACTORING
Refactoring is that art of refining a system’s implementation without changing its
functionality. This may seem unproductive, after all you have expended effort on modifying
an existing system

 Before implementing a new feature. The refactoring performed at this point may make it
easier to add the new feature.

 After implementing a new feature. Refactoring at this point may help to make the
resulting solution simpler.

 Refactoring may mean that you end up spending longer implementing a feature due to
refactoring, but the result should be that you aim to produce the simplest solution
containing clean effective code, with fewer potential problem areas/black holes.

 Refactoring certainly takes belief, trust and courage in what you are doing, but to
compensate the Test practise helps prove that any refactoring has not broken anything in
the system.

18-11-2024 28
 6. PAIR PROGRAMMING
Pair programming is what they think of when they think of XP two developers working together at one machine, with one
keyboard and one mouse, write all software in the system. This is possible because the two developers play different roles:

 One focuses on the method, class or interface, etc. being implemented (this is the one with the keyboard and the
mouse).

 The second focuses on the more strategic issues such as how well does this solution fit with the rest of the system,
what are its implications, is there a simpler solution, do the tests cover all possibilities, etc.

Two brains are better than one.

 Knowledge of the system is spread amongst the team.

 Test coverage may be better as two people will bring two different perspectives with them.

 Experience is spread amongst the team. If the team is comprised of a mixture of new graduates and developers with
ten years experience within the application domain, then by pair programmer, the experienced developers quickly
share their understanding of the domain, the technologies and the programming language with the new graduates.

 All code is dynamically reviewed by at least one other person who also understands the scenario within which it was
developed. This greatly helps to avoid the type of review that ends up 18-11-2024
focusing on the way
29 the code is laid out rather

than the quality of what has been produced.

 7. COLLECTIVE OWNERSHIP
 Everyone owns all the system code! That is, all code is the shared responsibility of all
the developers on the project. Everybody thus has the right, and indeed the duty, to
make changes to any part of the system whenever they identify an opportunity to
improve it.

 This is something quite different from saying that the code is owned by the project (and
thus no individual owns the code) as in this case, typically nobody has responsibility for
the code or has a “duty” to improve it.

 It is also very different from saying that developers must take ownership of their own
code. In this case, each developer “owns” part of the system but not anything outside
their own remit.

18-11-2024 30
 8. CONTINUOUS INTEGRATION

 Every time a task is completed, the resulting code should be integrated into the current
build. To do this, the new code must of course, pass all unit tests (including the new ones
introduced with the new feature).

 Any problem encountered should be immediately resolved.

 In general, any problem will relate to changes made to support the new feature and will
thus be easily identifiable.

 Once all tests are passed, the new code can be released to version control and a complete
new build

18-11-2024 31
 9. ON-SITE CUSTOMER

 How many times have you looked at a requirements document, relating to the task you
are about to work on and thought “what does this mean?” or “yes, but what should
happen if they cancel at this point?” etc. These are questions that an expert customer
(for example, an end user or someone doing the job at the moment) can answer.

 In XP, such a customer should be part of the team so that such queries can be answered
quickly and effectively allowing for rapid responses and rapid feedback.

 On-site customers can also help to resolve disputes (over business issues relating to the
system), help set small-scale priorities (is this feature or that feature more important)
and review the evolving system.

18-11-2024 32
10. BENEFITS OF CODE STANDARDS
 It avoids wasted arguments over small things such as where brackets
should go (on the same line or the next line) within a Java statement.

 It means that everyone gets familiar with the style of coding to be

adopted which makes code easier to read.

 Simple guidelines such as “All constants in capitals” mean that as soon as

such a convention is seen its meaning is known immediately.

 Helps to create an environment where code becomes de-personalised.

 Helps make activities such as refactoring and pair programming easier.

18-11-2024 33
 11. 40-HOUR WEEK
To put it another way, developers can only focus on developing code successfully for a
certain number of hours a week, beyond this your at best wasting their and your time and at
worst helping to introduce problems into the system.

The 40-hour rule isn’t exactly a 40-hour rule more a guideline as 35 or 45 hours might be
appropriate, but 60 to 80 hours every week .

12.SYSTEM METAPHOR
 In XP terms, the system metaphor is a story or view that expresses the overall way in
which the system will operate. It is typically less detailed than the architectural design
that you may have encountered

18-11-2024 34
 Assignment -3

Explain About extreme programming?

18-11-2024 35
 EXTREME ABOUT EXTREME PROGRAMMING
Many of the practises are, or have been incorporated into, described by ,or presented as,
parts of various existing software engineering methodologies.
what is so different, so extreme, about Extreme Programming?

The answer lies in a number of following places:

 .Extreme Programming is very lightweight :

It really only focuses on the programming of a software system.

 Extreme Programming takes the best practises to their ultimate conclusions:

Kent Beck says that he pictured each of the practises as a knob on a control board and turned each knob up to
maximum and looked at what happened.

18-11-2024 36
 Considerations in Extreme Programming
1. If code reviews are good, then review code all the time (pair programming).

2. If testing is good, everybody will test all the time (unit testing), even customers (acceptance testing).

3. If designing is good, then make it part of what everyone does every day (refactoring).

4. If simplicity is good, then always strive for the simplest effective solution (i.e., the simplest solution that works).

5. If architecture is important, then ensure that everyone is involved in creating and refining the architecture all the time
(system metaphor).

6. If integration testing is good, then integration and testing should be an on going (daily or even hourly) thing
(continuous integration).

7. If short iterations are good, then make them as short as possible, i.e., hours, or days not weeks and months (the
Planning Game).

18-11-2024 37
 REVIEW

Practises supporting the ability to fix a problem when it is found

18-11-2024 38
Practises to fix a problem
If a problem is noted in one area of the system by John, then:

1. Collective Ownership means that it is John’s responsibility to fix it.

2. Pair Programming allows John to work with Steve who is an expert in the problem area.

3. Simple Design means that the solution was already the simplest possible and thus should be clear and easy to
understand (relatively).

4. Refactoring allows the change to be made and verified. That is, the revised code can be guaranteed to have been
kept as simple as possible and to have not altered the functionality (as it should have passed all the tests).

5. Testing guarantees that the system still functions as before and that we have not broken anything else during the
refactoring.

6. Continuous integration ensures that the new code is only integrated once it has passed all the tests, but that it is
then immediately part of the evolving solution.
18-11-2024 39
Thank you

18-11-2024 40