Module II

Extreme Programming

 Planning XP projects
 Playing the Planning Game
 The Goal of the Game
 The Strategy
 The Game Pieces
 The Players
 The Moves/Playing the Game
 Planning Your XP Project
 Test first coding
 How to Write Tests First?
 What to Test?
 Confidence in the Test Suite
 Making pair programming work.

DEPARTMENT OF CSE ,GIT,GITAM UNIVERSITY

 Planning XP projects
• High level and detailed plans are only created on an iteration-
by-iteration or release-by-release basis.

what is the aim of the game/planning workshop?

• It is to decide on the scope and priorities of the project and of
the releases. It is also to estimate the cost of various features
required by the software and to schedule those features into
releases. Note that using the term feature here as depending on
the type of planning being done, may be dealing with high level
user stories, lower level user stories or tasks to implement user
stories.

• XP project lifecycle diagram illustrates the various planning

stages and implementation stages within a typical XP project.
XP project lifecycle
 Playing the Planning Game
• The planning game has only two conceptual players
 Business
 Development
• The business is formed from those stakeholders who
can specify the operation of the system.
• Development is formed from members of the
development team relevant to the features being
discussed.
• The number and size of each “team” may change over
time.
 Playing the Planning Game(Contd.,)

• A key issue, and one which takes time to achieve, is that

both sides must trust each other. The Business must trust
the Developers to give honest and accurate estimates. The
Developers must trust that the Business will give them the
information they need and will work with them to create
the plan.

• The game also has rules that aim to help the two teams
work together to produce the plan. These rules can help to
gain the mutual trust and respect essential to successful
planning
 The Goal of the Game
• The goal of the planning game is to maximise the value of the
software produced by the team.

The Strategy
• The main strategy of the game is to invest as little as possible
to put the most valuable functionality into production as
quickly as possible, but without compromising the required
product quality.
• Firstly, the strategy is to “invest as little as possible”. That is,
to get the job done as quickly as possible without incurring
unnecessary overheads.
– For example: The idea of not implementing features today which may
or may not be required tomorrow.
 The Strategy(Contd.,)

• Secondly, the aim is to “put the most valuable

functionality into production”.
– Few projects have unlimited resources and unlimited time.
– If they did, then there would be no problem for
implementing anything a user might require. Instead, there
are usually financial and time constraints on a project.
– These limit what can effectively be achieved. Thus, we
want to use the time and resources available to us to
implement those features that will be of most benefit to the
end user.
 The Strategy(Contd.,)

• Thirdly, want to do all this “without

compromising the required product quality.”
– Obviously, we want the software we produce to do
its job without causing the users any difficulties.
But note the use of the phrase “required product
quality.”
 The Game Pieces
• The pieces used by the two players are the “user stories”.
• These are written down on index cards and moved around
during the game. Of course do not necessarily need to use
index cards, user stories can be written down on white boards,
scrapes of paper, entered into a software system for recording
and reference.
• However, in general, they are put onto things that can be easily
placed in piles, written on, thrown away, sorted, etc.
• Only once they are accepted, as genuine user stories are
typically entered into a computer. This is partly as they are
harder to view, manipulate, sort, etc. and partly because once
something has been entered into an electronic media they are
often harder to throw away.
 The Players
• There are only two players in the game “Business”
and “Development.” like to think them as teams,
because they are rarely a single person.
• The implication of them being teams is that they
are a gestalt personality.
– That is, each team is comprised of the set of
personalities of its constituent members. This is
important as different people operate in different ways
and will have different motivations and it is useful to
keep all this in mind when “playing” the game.
 The Players(Contd.,)
• Business is made up of a collection of those individuals
(project stakeholders) who can make decisions about
what the system should do.
• Development consists of those people who will be
involved in implementing the system.
• This includes, but is not limited to, programmers. It
may also include database administrators, system
support technologists, networking professionals, etc.
• This may surprise some, as XP may seem to be
focussed on the programming aspect of a project.
 The Players(Contd.,)
• The two “players.” The members of the two teams should be
distinct. That is, no one person should be a member of both the
Business and the Development.
• If a software house is building a bespoke system for an external
client then it is often very easy to say who should be “Business”
and who should be “Development.”
– However, for “off the shelf” shrink wrap products, the “Business” maybe
the marketing department, internal business analysts or a internal
“product owner.”
– These are all people who are internal to the company and may be internal
to the department within which the software is being constructed.
– For systems to be used internally to a company, the development team
may find that they are building systems for themselves.
• In these cases, “expert customers” need to be identified and kept in
this role for the duration of the planning game.
 The Moves/Playing the Game
There are three stages to play the game.
1. Exploration – Determine new user stories of the system.
2. Commitment – Decide which features will be addressed in
a particular release.
3. Steering – Update the plan as development progresses.

These three phases are iterative and may interact.

– For example, in the steering phase it may be noticed that some
new user stories are required. This may lead to the exploration
phase being re-run for the new user stories, followed by the
commitment phase, before a revised plan is produced by the
steering phase.
 Assignment-4
• Explain in detail about the following three
phases
– Exploration
– Commitment
– Steering

Note: refer only the Textbook

 Planning Your XP Project
The various types of planning game fit together to help
you plan your XP project. There are actually two forms
of the planning game:
1. The initial planning game
2. The release planning game
– In general, there is also another step between these, which is
called variously the “Elaboration” phase, and the
“Exploration” process. To avoid confusion with what has
already been described, we will call it the “Elaboration”
process. The elaboration process allows clarification of user
stories to take place outside the constraints of the game.
 Planning Your XP Project(Contd.,)
A typical XP project might be planned in the following manner:
1. An initial planning game (aims to get overall view of project);
2. Initial elaboration process (focusing on high level user stories);
3. Release 1 planning game;
4. Release 1 elaboration process (if required);
5. Plan iteration 1;
6. . . . . Release 1 iteration/implementation . . . ;
7. Release 2 planning game;
8. Release 2 elaboration process (if required);
9. Plan iteration 2;
10. . . . Release 2 iteration/implementation . . . ;
11. ...
12. Release n Planning game;
13. Release n Elaboration process (if required);
14. Plan iteration n;
15. . . . Release n iteration/implementation.
 The Initial Planning Game

• The initial planning game focuses on what the

system as a whole should do. It considers all
user stories that are in scope.
• It happens at the start of the project and may
reconvene at various points throughout the
lifetime of the project to review the scope of
the system, the set of user stories, their relative
priorities, etc.
 The Release Planning Game
The release planning game focuses on the contents of a
release or iteration. It has the same steps as the initial
planning game but the level of detail that needs to be
considered is much greater. During the initial planning
game, the overall plan for the project should have been
roughly planned out. At the start of a release, the details of
what will be done in that release need to be determined.
This means that:
1. User stories need to be fleshed out and may need to be
broken down into finer grained stories.
2. Detailed estimates of the stories need to be obtained.
 The Release Planning Game(Contd.,)

3. The user stories to be implemented as part of the release need

to be confirmed, revised or modified as required.
4. The project velocity may need to be revised. For example, as
the development team become more experienced in XP and the
application in which you may find development speeds up.

On completion of the release planning game it may be necessary

to explore some of the user stories further. This can happen during
the elaboration process. Once this is completed, the iteration tasks
will be planned in detail during the iteration planning process.
 The Elaboration Process
The elaboration process follows the initial planning game,
and typically on a smaller scale, a release planning game.
During this phase, research is carried out to clarify user
stories in order to estimate, clarify requirements, or
technical issues.
The aim of this is to:
• Lower the risk of bad estimates,
• Experiment/prototype different solutions,
• Improve the development teams to understand the
domain/technology,
• Ensure procedures and processes required are in place.
 The Elaboration Process(Contd.,)

• Between the initial planning game and the first

release planning game, the elaboration process
may last anywhere from a day to a month to
several months, depending on the development
teams level of expertise in the domain in
question, in the technologies being applied and
in the methods being used. Between releases,
the elaboration process is likely to be shorter,
typically in terms of days.
 Iteration Planning

There are two issues to consider when planning

an iteration.
1. Determining the size of an iteration
2. Determining what should be done within an
iteration to implement the user stories.
 Iteration Planning(Contd.,)
Size of an iteration
How do you determine how big an iteration should be? How long is a
piece of string?
– An iteration needs to be big enough to allow either a new release to be
created that adds value to the business or large enough that you are able to
make significant progress. However, it should also be small enough that the
development does not move on too far without being reviewed (by another
release planning game, etc.).
• The classic length of time for an XP iteration ranges from 1 to 3
weeks. Generally, XP projects are quiet small involving between 2
and 6 and generally at most 10 developers. This limits the amount of
work that can be done within 2–3 weeks.
• For example, if you have a team of six and your iteration is of 2
weeks duration, then at most you have 12 person weeks to play with.
 Iteration Planning(Contd.,)
Planning the iteration
– If the release planning game identifies what new
features should be added to the evolving system in
the current iteration, then the iteration plan defines
how those features will be achieved.

During the planning of an iteration, user stories

are converted into tasks which will result in the
story being implemented. One user story may be
implemented by a single task or by many tasks.
Iteration planning usually incorporates the following phases:

1. Evaluation of the last iterations lessons learned, changes to be made, etc.

2. Review of user stories to incorporate into the iteration.
3. Task exploration during which tasks are written for user stories. These
tasks may be broken down into smaller tasks to help with planning and
estimating. This generally happens when a developer volunteers to break
a user story down into one or more tasks. They may offer to do this
because they believe they know how to address that task. To break the
user story down, they should find at least one other developer to help with
the analysis. As this step progresses, they may or may not need input from
the customer or other developers. Therefore, the on-site customer can be
vital to the success of the iteration planning process.
4. Task commitment during which tasks are estimated, load factors
determined and balancing takes place.
5. Finally, the iteration plan is verified.
 Module II
Extreme Programming

 Planning XP projects
 Playing the Planning Game
 The Goal of the Game
 The Strategy
 The Game Pieces
 The Players
 The Moves/Playing the Game
 Planning Your XP Project
 Test first coding
 How to Write Tests First?
 What to Test?
 Confidence in the Test Suite
 Making pair programming work.

DEPARTMENT OF CSE ,GIT,GITAM UNIVERSITY

 Test First Coding
• At least one project I know used the “if I compile then you
can release it into the current build” rule as sufficient
evidence of testing – with obvious and predictably
disastrous results. So, unit testing all code before releasing
it, is not a universal truth!

• When you have written some code that is to be used by the

rest of the project, you should be sure that it works. Making
these unit tests part of what you release into the central
source code repository of your project also means that if
anything changes anyone can re-run your unit tests and
check that your code still works.
 Test First Coding(Contd.,)
• When you write code you should also write the
unit tests that go with it to verify that code.
• The next step towards test first coding is therefore
not a huge one. That is, you should write the tests
before you write the code. This may seem strange
at first, but over time it does become second
nature.
• Test first coding also ensures, of course, that all
code produced does have a relevant set of unit
tests available for it.
 Assignment-5
How to Write Tests First?

Note: refer only the Textbook

 What to Test?
Testing is good and writing tests first is better.
what should I test? Should every single method in
every class in my application have a test written for it?
Probably not!
Should I only write tests for major subsystems
Again probably not!
So, what should I test?
As with many things in software, there are no hard and
fast rules for what you should test.
XP-oriented guidelines:
1. Write tests for any tasks being implemented.
2. Write tests for any classes or combinations of classes that are non-trivial and could
easily be broken. For example, if one particular class implements a complex
algorithm to find sneak circuits within electronic relays, then write tests for that
class even though it may only be one element of a larger module.
3. Avoid writing tests for methods that just call another method, e.g. delegate methods,
if the called method already has a test written for it.
4. Assume that more tests are better then less and that no one will complain about
having too many tests, but that people will complain if an important test is missing.
5. Write tests that instil confidence in the system. For example, if one area of the
system is invoked by many others (such as a data access management subsystem),
then having a set of tests for that area adds to the confidence of those using it.
6. Add tests that will help cover areas of the system being modified. If you are
refactoring some code, and feel that one or more tests are missing then add them.
7. If you happen to notice that a suite of tests for a particular module, subsystem or
class appears to be missing in one or more tests, then add them.
 Confidence in the Test Suite

The developers must have confidence in the test

suite created. Not only is this important for their
belief in the system but it is also particularly
important for two other importance practises:
1. Your ability to refactor and prove that you have
not changed the functionality of the system
2. The guarantee that if you code in a test first
manner, that you have produced the simplest code
that covers the requirements.
 Confidence in the Test Suite(Contd.,)
• You should not get hung up on the quality of the tests, just do
the best you can.
• It is very unlikely that you will never miss out some test
condition – that’s life but that is what refactoring is for and
why everyone is responsible for all the code.
• If you have missed something out, then at some point someone
should notice this and come back and add a new test.
• If the code now fails that test, then it should be “improved”
such that it passes the test.
• This is a normal XP practise and should not elicit any response
such as “I found a bug in your code AGAIN!!” If it does then
it indicates that there is a problem within the XP team far more
than that there was a problem with your work
 Making pair programming work
• Pair programming all code is always reviewed by at least one
other person who is focussed on what the code needs to do.
• Pair programming isn’t easy, actually its quite hard. This is not
what you often hear, but it is a fact! Most programmers have
been trained to work alone, to change the habit of a lifetime is
never easy.
• In addition, few people can just pair program straight off, most
need to learn how to pair program.
• Knowing how to work in pairs is hard because it is not only a
different way of working, it involves inter-personal skills, pair
dynamics, communication, tolerance and trust.
 Making pair programming work(Contd.,)
• For example, when people think of pair programming, they
think of two people working on the same code. Fine, but it is
not possible for two people to actually program at the same
time.
• In pair programming, one developer takes hands on control of
the keyboard and mouse, while the other monitors what the
“driver” is doing (often referred to as the “navigator”).
• This requires active participation from both sides. But this is
not how most programmers have been trained to work.
• Most programmers expect to be the “driver,” they are not
attuned to being the “navigator.”
• Being the driver is what programmers traditionally have been.
• In pair programming situations, many programmers will
initially fall straight into this role.
 Making pair programming work(Contd.,)
There are no hard and fast rules to how to do this, there are things
that can help:
1. Engage in a dialogue.
2. Listen to each other
3. Take frequent breaks
4. Don’t be a back seat driver
5. Make pair programming practical
6. Use a common environment
7. Shared language and vocabulary
8. Allowing non-pair time
9. Change partners often
Pair-programming workflow