EXTREME PROGRAMMING

Submitted to Dr. Babasaheb Ambedkar Technological University in Lonere in Partial

Fulfillment of the
Requirements for the Degree of BACHELOR OF TECHNOLOGY in
ELECTRONICS AND TELECOMMUNICATION ENGG.

By :-
PURVESH GOPAL PATIL

Guide :-
PROF.R.K.Dhande

DEPARTMENT OF E&TC ENGINEERING

J.T. MAHAJAN COLLEGE OF ENGINEERING,
FAIZPUR 2023-24

I
 J.T. MAHAJAN COLLEGE OF ENGINEERING, FAIZPUR
Department of Electronics and telecommunication Engineering

CERTIFICATE

This is to certify that the seminar report entitled, “EXTREME PROGRAMMING”,

which is being submitted herewith for the award of B.E. is the result of the work
completed by PURVESH GOPAL PATIL under my supervision and guidance within
the four walls of the institute and the same has not been submitted elsewhere for the
award of anydegree.

Prof. R K.DHANDE Dr. A.M.PATIL

Assistant professor Head, Department of E&TC Engg.

Dr.K.G.Patil
Principal
II
III
 DECLARATION
I hereby declare that the seminar report entitled, “EXTREME PROGRAMMING” was
carriedout and written by me/ us under the guidance of Prof.R.K.DHANDE , Assistant
Professor, Department of Electronics and telecommunicatio Engineering. This work has
not been previously formed the basis for the award of any degree nor has been submitted
elsewhere for the award of anydegree

Place :- Faizpur
Date :-

IV
 ACKNOWLEDGEMENT

I would like to take this opportunity to express our gratitude our

guide for his constant guidance during the past semester. He always
appreciated whatever little progress we have achieved and
continuously gave us much required inspiration by sharing his precious
knowledge and experience.

I also thanks to Dr. A. M. PATIL HOD of second year E&TC

department & Seminar Co-Ordinator for sharing their knowledge and
experience. I sincerely thank to all teaching as well Non-Teaching
Faculty Members of Second Year ELECTRONICS AND
TELECOMMUNICATION ENGINEERING Department. I would like
to thank our respected Principal Prof. Dr. K.G. Patil sir for his support
and providing all necessary facilities to us. Last but not least I want to
thank all our friends for all their support.

V
 ABSTRACT

Extreme programming (XP) is a lightweight methodology for small-to-medium sized

teams developing software in the face of vague or rapidly changing requirements. XP is a
deliberate and disciplined approach to software development. XP stresses consumer satisfaction.
An extreme attempt to dramatically simplify the process of developing software systems is made
focusingon what delivers value: the requirements for the system or the code that implements the
system. Requirement specification in the form of User Stories, code development by pairs of
developers (Pair Programming), simplification of the code through Refactoring and careful
repeated testing are the outstanding features of extreme Programming technique. XP improves a
software project in four essential ways; communication, simplicity, feedback, and courage. XP
has rejuvenated the notion of evolutionary design with practices that allow evolutionto become a
viable design strategy.

VI
 TABLE OF CONTENTS

Chapter No. Title Page No.

1 INTRODUCTION 1

2 THE XP PRACTICES 5

3 USER STORIES 6

4 ACCEPTANCE TESTS 9

5 ACCEPTANCE TESTS 12

6 SYSTEM METAPHOR 13

7 SPIKESOLUTION 13

8 SMALL RELEASES 14

9 ITERATION 15

10 PAIR PROGRAMMING 19

11 REFACTORING 21

12 DOCUMENTATION 22

13 DISTINGUISHING FEATURES OF XP 28

14 CONCLUSION 30

15 REFERENCES 31

VII
1. INTRODUCTION

Extreme Programming (XP) is actually a deliberate and disciplined approach to

software development. About six years old, it has already been proven at many
companies of all different sizes and industries worldwide. XP is successful because it
stresses customer satisfaction. The methodology is designed to deliver the software
your customer needswhen it is needed. XP empowers software developers to
confidently respond to changing customer requirements, even late in the life cycle. This
methodology also emphasizes teamwork. Managers, customers, and developers are all
part of a team dedicated to delivering quality software. XP implements a simple, yet
effective way to enable groupware style development.

XP improves a software project in four essential ways; communication,

simplicity feedback, and courage. XP programmers communicate with their customers
and fellow programmers. They keep their design simple and clean. They get feedback
by testing their software starting on day one. They deliver the system to the customers
as early as possible and implement changes as suggested. With this foundation XP
programmers are able to courageously respond to changing requirements and
technology. XP is different. It is a lot like a jig saw puzzle. There are many small
pieces. Individually the pieces make no sense, but when combined together a complete
picture can be seen. This is a significant departure from traditional software
development methods and ushers in a change in the way we program.

If one or two developers have become bottlenecks because they own the core
classes in the system and must make all the changes, then try collective code
ownership. You will also need unit tests. Let everyone make changes to the core
classes whenever they need to. You could continue this way until no problems are left.
Then just add the remaining practices as you can. The first practice you add will seem
easy. You are solving a large problem with a little extra effort.

1
The second might seem easy too. But at some point between having a few XP rules and
all of the XP rules it will take some persistence to make it work. Your problems
willhave been solved and your project is under control. It might seem good to abandon
the new methodology and go back to what is familiar and comfortable, but continuing
does pay off in the end. Your development team will become much more efficient than
you thought possible. At somepoint you will find that the XP rules no longer seem like
rules at all. There is a synergy between the rules that is hard to understand until you
have been fully immersed. This up hill climb is especially true with pair programming,
but the pay off of this technique is very large. Also, unit tests will take time to collect,
but unit tests are the foundation for many of the other XP practices so the pay off is
very great.

2
 XP projects are not quiet; there always seems to be someone talkingabout
problems and solutions. People move about, asking each other questions and trading
partners for programming. People spontaneously meet to solve tough problems, and
then disperse again. Encourage this interaction, provide a meeting area and set up
workspaces such that two people can easily work together. The entire work area should
be open space to encourage team communication. The most obvious way to start
extreme programming (XP) is with a new project. Start out collecting user stories and
conducting spike solutions for things that seem risky. Spend only a few weeks doing
this. Then schedule a release planning meeting. Invite customers, developers, and
managers to create a schedule that everyone agrees on. Begin your iterative
development with an iteration planning meeting. Now you're started.

Usually projects come looking for a new methodology like XP only after the
project is in trouble. In this case the best way to start XP is to take a good long look at
your current software methodology and figure out what is slowing you down. Add XP
to this problem first. For example, if you find that 25% of the way through your
development process your requirements specification becomes completely useless,
then get together with your customers and write user stories instead.

3
 If you are having a chronic problem with changing requirements causing you to
frequently recreate your schedule, then try a simpler and easier release planning
meeting every few iterations. (You will need user stories first though.) Try an iterative
style of development and the just in time style of planning of programming tasks. If
your biggest problem is thenumber of bugs in production, then try automated
acceptance tests. Use this test suite for regression and validation testing. If your biggest
problem is integration bugs then try automated unit tests. Require all unit tests to pass
(100%) before any new code is released into the code repository.

4
2. THE XP PRACTICES

Extreme programming implements several software development practices. But

not all of them are exclusive to XP. These practices work well and contribute
significantly to the project‟s overall success. There are12 practices in XP.

1. Planning Game
2. Small releases
3. Metaphor
4. Simple design
5. Test Driven Development
6. Refactoring
7. Pair programming
8. Collective ownership
9. Continuous development
10. Sustainable pace
11. On-site customer
12. Coding standards

5
3. USER STORIES

User stories serve the same purpose as use cases but are not the same. They are
used to create time estimates for the release planning meeting. They are also used
instead of a large requirements document. User Stories are written by the customers as
things that the system needs todo for them. They are similar to usage scenarios, except
that they are not limited to describing a user interface. They are in the format of about
threesentences of text written by the customer in the customers‟ terminology without
techno-syntax.

User stories also drive the creation of the acceptance tests. One or more
automated acceptance tests must be created to verify the user story has been correctly
implemented.

One of the biggest misunderstandings with user stories is how they differ from
traditional requirements specifications. The biggest difference is in the level of detail.
User stories should only provide enough detail to make a reasonably low risk estimate
of how long the story will take to implement. When the time comes to implement the
story developers will go to the customer and receive a detailed description of the
Developers estimate how long the stories might take to implement. Each story will get
a 1, 2 or 3-week estimate in "ideal development time". This ideal development time is
how long it would take to implement the story in codeif there were no distractions, no
other assignments, and you knew exactly what to do. Longer than 3 weeks means you
need to break the story down

6
further. Less than 1 week and you are at too detailed a level, combine some stories.
About 80 user stories plus or minus 20 is a perfect number tocreate a release plan
during release planning.

Another difference between stories and a requirements document isa focus on

user needs. You should try to avoid details of specific technology, data base layout,
and algorithms. You should try to keep stories focused on user needs and benefits as
opposed to specifying GUI layouts.

7
4. ACCEPTANCE TESTS

Acceptance tests are created from user stories. During an iteration the user
stories selected during the iteration planning meeting will be translated into acceptance
tests. The customer specifies scenarios to test when a user story has been correctly
implemented. A story can have one ormany acceptance tests, what ever it takes to
ensure the functionality works.

Acceptance tests are black box system tests. Each acceptance test represents
some expected result from the system. Customers are responsible for verifying the
correctness of the acceptance tests and reviewing test scores to decide which failed
tests are of highest priority. Acceptance tests are also used as regression tests prior to a
production release.

A user story is not considered complete until it has passed its acceptance tests.
This means that new acceptance tests must be created each iteration or the
development team will report zero progress. Quality assurance (QA) is an essential
part of the XP process. On some projects QA is done by a separate group, while on
others QA will be integrated intothe development team itself. In either case XP
requires development to have much closer relationship with QA.

Acceptance tests should be automated so they can be run often. The acceptance
test score is published to the team. It is the team'sresponsibility to schedule time to
each iteration to fix any failed tests. The name acceptance test was changed from
functional tests. This better reflects the intent, which is to guarantee that customer‟s
requirements havebeen met and the system is acceptable.

8
4.1. UNIT TESTING

Unit testing is a development practice and part of the extreme programming

(XP) methodology. But this does not depend on other XP practices; it may be used with
other software development process. Unit testing is not done by specialized testers; it is
a part of the daily development routine of a programmer. Unit testing means testing a
unit of code. A unit of a code is generally a class in an object oriented system. It could
also be a component or any other piece of related code. A unit test isan automated test,
where one or more methods of one or more classes are invoked to create an observable
result.

Automated means that the results are verified automatically. The tests are
usually written in the same computer language as the production code. The test
verification is therefore code, which compares actual resultsto the expected results. If a
result is unexpected, the test fails. This kind of testing is in contrast to the usual print
lines mixed into the production code, where the programmer looks at the output on the
command line and tries to figure out whether the code behaves as expected.

Unit tests are written in java using JUnit. JUnit is a testing framework written
in Java. JUnit defines how to structure test cases and provides tools to run them. The
tests are usually executed in VisualAge.

9
 Principle methods of a class should be tested. Tests should write for the cases
that are critical. Writing a test guarantees that if a developer changes the code inn an
unanticipated way, the error will be detected immediately when the tests are run.
Confidence in the code is enhanced if all tests are still running after a day of coding.
Each test should be independent of other tests. This reduces the complexity of the tests
and it avoids false alarms because of unexpected side effects. One test method tests one
or more methods of production code the developer should write the unit tests while (or
before or after) developing the production code. Tests should be run before and after
refactoring a piece of code, before starting to implement a new functionality in the
system and during integration.

10
5. RELEASE PLANNING

A release planning meeting is used to create a release plan, which lays out the
overall project. The release plan is then used to create iterationplans for each individual
iteration. It is important for technical people to make the technical decisions and
business people to make the business decisions. Release planning has a set of rules that
allows everyone involved with the project to make their own decisions. The rules
define a method to negotiate a schedule everyone can commit to.

The essence of the release planning meeting is for the development team to
estimate each user story in terms of ideal programming weeks. An ideal week is how
long you imagine it would take to implement that story if you had absolutely nothing
else to do. No dependencies, no extra work, but do include tests. The customer then
decides what story is the most important or has the highest priority to be completed.

User stories are printed or written on cards. Together developers andcustomers

move the cards around on a large table to create a set of stories to be implemented as
the first (or next) release. A useable, testable system that makes good business sense
delivered early is desired. You may plan by time or by scope. The project velocity is
used to determine either how many stories can be implemented before a given date
(time) or how long a set of stories will take to finish (scope). When planning by time
multiply the number of iterations by the project velocity to determine how many user
stories can be completed. When planning by scope divide the total

weeks of estimated user stories by the project velocity to determine howmany iterations
till the release is ready.

11
6. SYSTEM METAPHOR

Choose a system metaphor to keep the team on the same page by naming
classes and methods consistently. What you name your objects is very important for
understanding the overall design of the system and codereuse as well. Being able to
guess at what something might be named if it already existed and being right is a real
time saver. Choose a system of names for your objects that everyone can relate to
without specific, hard toearn knowledge about the system. For example the Chrysler
payroll system was built as a production line. At another auto manufacturer car sales
were structured as a bill of materials. There is also a metaphor knownas the naive
metaphor which is based on your domain itself. But don't choose the naive metaphor
unless it is simple enough.

7. SPIKE SOLUTION

Create spike solutions to figure out answers to tough technical or design

problems. A spike solution is a very simple program to explore potential solutions.
Build a system that only addresses the problem under examination and ignore all other
concerns. Most spikes are not goodenough to keep, so expect to throw it away. The
goal is reducing the risk of a technical problem or increase the reliability of a user
story's estimate.

When a technical difficulty threatens to hold up the system's development put a

pair of developers on the problem for a week or twoand reduces the potential risk.

12
8. SMALL RELEASES

The development team needs to release iterative versions of the system to the
customers often. The release planning meeting is used to discover small units of
functionality that make good business sense and can be released into the customer's
environment early in the project. Thisis critical to getting valuable feedback in time to
have an impact on the system's development. The longer you wait to introduce an
important feature to the system's users the less time you will have to fix it.

13
9. ITERATION

Iterative Development adds agility to the development process. Divide

development schedule into about a dozen iterations of 1 to 3 weeksin length. Keep the
iteration length constant through out the project. Thisis the heartbeat of your project. It
is this constant that makes measuring progress and planning simple and reliable in XP

Do not schedule programming tasks in advance. Instead have an iteration

planning meeting at the beginning of each iteration to plan out what will be done.
Just- in-time planning is an easy way to stay on top of changing user requirements. It
is also against the rules to look ahead and try to implement anything that it is not
scheduled for this iteration. There will be plenty of time to implement that
functionality when it becomes the most important story in the release plan.

14
 It is important to take iteration deadlines seriously. Track progress during an
iteration. If it looks like you will not finish all of your tasks then call another iteration
planning meeting, re-estimate, and remove some of the tasks. Concentrate your effort
on completing the most important tasks as chosen by your customer, instead of
having several unfinished tasks chosen by the developers.

It may seem silly if your iterations are only one week long to makea new plan,
but it pays off in the end. By planning out each iteration as if it was your last you will
be setting yourself up for an on-time delivery of your product.

9.1. BUGS

When a bug is found tests are created to guard against it coming back. A bug in
production requires an acceptance test be written to guard against it. Creating an
acceptance test first before debugging helps customers concisely define the problem
and communicate that problem to the programmers. Programmers have a failed test to
focus their efforts and know when the problem is fixed.

Given a failed acceptance test, developers can create unit tests to show the
defect from a more source code specific point of view. Failing unit tests give
immediate feedback to the development effort when the bughas been repaired. When
the unit tests run at 100% then the failing acceptance test can be run again to validate
the bug is fixed.

15
9.2. PROJECT VELOCITY

The project velocity (or just velocity) is a measure of how much work is getting
done on your project. To measure the project velocity you simply add up the estimates
of the user stories that were finished during the iteration. It's just that simple. You also
total up the estimates for the tasks finished during the iteration. Both of these
measurements are used for iteration planning.

During the iteration planning meeting customers are allowed to choose the
same number of user stories equal to the project velocitymeasured in the previous
iteration. Those stories are broken down into technical tasks and the team is allowed to
sign up for the same number of tasks equal to the previous iteration's project velocity.

This simple mechanism allows developers to recover and clean up after a

difficult iteration and averages out estimates. Your project velocity goes up by
allowing developers to ask the customers for another story when their work is
completed early and no clean up tasks remain.

A few ups and downs in project velocity are expected. You should use a release
planning meeting to re-estimate and re-negotiate the release plan if your project
velocity changes dramatically for more than one iteration. Expect the project velocity
to change again when the system is put into production due to maintenance tasks.
Project velocity is about as detailed a measure as you can make that will be
accurate. Don't bother

16
dividing the project velocity by the length of the iteration or the number ofpeople. This
number isn't any good to compare two project's productivity. Each project team will
have a different bias to estimating stories and tasks,some estimate high, some estimate
low. It doesn't matter in the long run. Tracking the total amount of work done during
each iteration is the key to keeping the project moving at a steady predictable pace.

The problem with any project is the initial estimate. Collecting lots of details
does not make your initial estimate anything other than a guess. Worry about
estimating the overall scope of the project and get that right instead of creating large
documents. Consider spending the time you would have invested into creating a
detailed specification on actuallydoing a couple iterations of development. Measure the
project velocity during these initial explorations and make a much better guess at the
project's total size.

17
10. PAIR PROGRAMMING

Pair or collaborative programming is where two programmers develop

software side by side at one computer .for a 15%increase in program development
hours, pair programming improves design quality, reduces staffing risk, enhances
technical skills, improves team communications, and is considered as more enjoyable
at statistically significant levels. Here programmers work on same algorithm, design,
or programming task.

Different aspects of organizational and software engineering support pair

programming as following:
 economics
 Satisfaction: people working in pairs have found the experience
more enjoyable than working alone.
 Design quality: programs produced by pairs were notably shorter
than those delivered by solo developers.
 Continuous reviews: pair programming‟s shoulder-to-shoulder
technique serves as a continual design and code review, leading to
more efficient defect removal rates .review ha s a unique
educational capability. The process of analyzing and critiquing
artifacts produced by others is a potent method for learning about
languages, design techniques, application domains and so forth.
Mistakes are found as they are entered, saving the cost of
compilation and providing the economic benefit of early defect
identification and removal.

18
 Problem solving: team acquires the ability to solve the „impossible
problems faster.
 Learning: pair programmers get a chance to learn from each other.
 Team building and communication: people learn to discuss and
work together. This improves team communication and
effectiveness.
Pair programming contributes in three ways:

1. People learn to work together.

2. Learning to work together means that people on the team
will share both problems and solutions more quickly.
Teamwork is enhanced.
3. Raises the communication bandwidth and frequency within
the project, increasing overall information flow within the
team. Rotating partners‟ increases the overall information
flow farther.
 Staff and project management: because multiple people have
familiarity with each piece of code, pair programming reduces
staff- loss risk.

19
11. REFACTORING

Refactoring allows us to revise the structure or the design of an existing piece

of software so that it becomes easier to add or modify functionality. It is important to
be able to revise the software‟s design in this manner because otherwise only
additions or modifications that are in some sense consistent with the original design
can be made. Individual refactoring steps should be small and each should be checked
to avoid bugs. A key feature of refactoring method is that after each refactoring step
we test the modified software to ensure that the software continues to work as it did
before the refactoring.

Refactorings can be classified into two groups, syntactic and semantic.

A syntactic refactoring step is a change in some essentially syntactic aspect

of the piece of the software. An important point to note about such Refactorings is
that essentially all of the needed work can be carried out by Refactoring Browsers
and if this is done there is no need tocarry out a test following the refactoring because
the browser would havemade sure that all the necessary changes have been properly
carried out.

Semantic Refactorings modify the logic of the software and how it

functions. Hence the browsers will not be able to make the needed changes. The
designer has to do it. Following such a refactoring, the designer will have to
test to ensure that the refactoring has been donecorrectl

20
12. DOCUMENTATION

XP practices are natural. At least the practices are trying to go withthe natural
instincts of people (and of programmers). They try to set up behaviors which are self-
sustaining, not through discipline or through pressure, but because they have results
which are good and which are proximate enough to the behaviors so as to reinforce
them. XP ensures that you have the communication you need, without increasing the
documentation you have to write.
Documentation or Communication: It true that programmer doesn‟t liketo write
documents. It's also true that on many projects the documents getout of date. It's
conventional to blame the latter on the former, but the truth is that when the schedule
gets tight, managers and project leaders are just as inclined to skip the updates as are
programmers. Programmers don't like documentation because managers make it clear
that what they really want is the program. What do programmers like? They like to
program. They like to write code; they like to make it work; they like to make it
beautiful. How can we go with that natural instinct and meet our needs for
documentation? Documents are used to communicate: to communicate requirements,
internal design, status and information needed externally to the project. Let's look at
those in turn. For each, we'll focus on what needs to be communicated and how XP
helps make sure that the communication happens.

21
Communicating Requirements: Some projects work from large requirements
documents specifying what needs to be in the product. There are some issues with the
use of such documents, and sometimes they are quite important:
 Documents don't really communicate very well.
 Documents aren't easy to write for customers.
 Documents take time.

Requirements documents may sometimes be necessary, but they are not

without cost. XP tries a more natural way to communicate requirements:
conversation.
In XP, there is the notion of the "On-Site Customer". Someone who knows
what is needed -- ideally the actual customer or user -- is nearthe team at all times.
They communicate the requirements directly, through several of the XP practices.
Release Planning Communicates Requirements: During the release planning
process, the Customer explains all the requirements stories. There is discussion with
the programmers until they understand the stories well enough to estimate them. This
is communicating requirements.
Iteration Planning Communicates Requirements: During the iteration planning
process, the Customer explains all the stories in more detail: enough detail for the
programmers to figure out the detailed tasks to implement them. This is
communicating requirements
Acceptance Tests Communicate Requirements: The XP customer
defines, and the team writes, acceptance tests for all the stories. These
tests serve as executable requirements definitions. They can also be used

22
quite readily as part of a tracking and documentation process showing that
requirements have been implemented.
Informal Conversations Communicate Requirements: Because the Customer is On
Site, she is also available for questions to clarify details of the requirements. She
quickly learns to control how many interruptions she gets by improving the
information she communicates during release and iteration planning. Too little, and
she gets too many interruptions. Too much and she spends too much time in
preparation. She can balance things between writing, conversation, and question
answering to suit her own needs.
Natural Communication of Requirements: the On-Site Customer practice converts
an inefficient paperwork exercise into a dynamic conversation discussing
requirements as the project goes along. Everything is communicated -- must be
communicated if the tests are to run -- and the balance between paper, presentation,
conversation, and question answering can be adjusted to suit the participants.
Communicating Internal Design: All the members of the team need to understand
the system. They need to be able to advance the code, to make it do whatever is
needed. They need to do those changes in a way that are consistent with the overall
shape of the code, and the direction it is moving: we might say with its design.
One way to be sure that everyone on the team understands and follows the design is
to create a design and document it with UML diagrams or words or both. Everyone
would agree that you shouldn't do too much of this up front, but it's hard to say how
much is too much. To communicatea design in this way, you need good-looking
documents and more comprehensive.

23
Release Planning Communicates Design: The XP release planning process includes
a step where the programmers take the stories anddiscuss them among themselves, in
order to estimate them. To estimate them, they figure out roughly how to implement
each story. Guess what: the programmers are communicating about design. And
watch them carefully: sometimes when they think they might forget, they write a
noteabout how to implement a story, right on the card. They're recording enough
about the design to remember it later. This is design, and communication of design.
Iteration Planning Communicates Design: The XP Iteration planning process
includes a step where the programmers brainstorm the tasks to doeach story, putting
the tasks on the whiteboard for later signup. This is a design step. The whole team is
participating in the design, and seeing it take shape. The key design components are
left on the whiteboard until implemented. This is design, and communication of
design. Day to Day Development Communicates Design: In Quick Design Session: a
few programmers get together and do a little CRC session or draw some UML or
discuss how to do something. When they come up with something interesting, they
tell the folks who weren't in the session about it. They do this naturally: it's interesting
and they want to talk about it. If they come up with an important notion, they'll draw
and write it on the whiteboard and leave it up while it's useful. This is design, and
communication of design.
Pair Programming and Collective Ownership Communicates Design:
XP teams practice pair programming. Pairs switch around daily, with
everyone working with everyone. XP teams practice collective code

24
ownership, so that everyone can (and does) work on all parts of the system from time
to time. This is communication of design.
Refactoring Communicates Design: An essential aspect of XP is refactoring. Martin
Fowler's book Refactoring is subtitled Improving the design of existing code.
Refactoring is a process whereby the programmers (in pairs, of course) examine and
consider whether the codeis reflecting the design in their heads, and consider what the
code is saying about what the design should be. Then they improve the code to
improve the design. This is design, and communication of design.
Natural Communication of Design: Within the XP team, the practices bring about a
high level of common understanding of the design. Using the natural willingness of
programmers to talk about what they are doing and how cool it is, and using pair
programming, XP teams spread what needs to be known without the need for much
formality.
Communicating Status: Some aspects of your status certainly need to be
communicated externally to the project team. These communications willoften -- but
not always -- lead to documents.
Standup Meeting: XP recommends a daily "standup" meeting, where theteam stands
in a circle and quickly raises issues that people need to understand. This will include
design issues and the like, but the main thing is a quick review of status, requests for
help, problems encountered,and discoveries made. The standup meeting makes sure
that all the attendees know about everything that's going on. Naturally, customers and
managers are invited, and should attend.
Big Visible Chart: The important status information that needs to be fresh in people's
minds all the time should be represented in Big Visible Chart. Here are some
examples of useful charts:

25
 Story Chart. You need to know how you're doing on getting stories
done. Consider a simple bar chart, the height showing the total
number of stories, with the number currently completed filled in.
Thischart shows any growth in the requirements, and shows
progresstoward completion, at a glance.
 Story Wall. Some teams keep all the story cards up on a wall,
arranged in iteration order: the planned order of implementation.
When the customer changes her mind about the order, or about a
story, the wall is rearranged. Stories that are done are marked,
perhapswith a bright green diagonal line through the card.
 Iteration Wall. The plan and status for the current iteration should be
visible to all, all the time. Some teams write the iteration plan on the
whiteboard. Typically when a task or story is done, the team will mark
it completed. A glance at the wall tells everyone what's up. Other
teams fill the wall with the story and task cards, marking them
complete as they get finished.
Communicating Externally: You may need external documentation to support the
product, either at the design level or for user documentation. The natural flow of the
process supports getting the work done.
 Status Reports: Send management copies of your Big Visible
Charts, tied together with a few paragraphs.
 Requirements Tracking: If you need requirements tracking, try
associating stories with acceptances tests, and maybe include a
little version information extracted from your code management
software.

26
 The details of what to document and how to produce the information are
always unique to the project and its people. But the focusthat XP would recommend
is always this:
1. Communicate using the hottest medium you possibly can: from face-
to-face conversation at a whiteboard down through phone
conversation, through email, video or audiotape, down to paper or its
online equivalent.
2. Find ways to have people's everyday activities embody
communication. Find ways to have their everyday activities
automatically generate the information that needs to be published.
Find ways to extract information from development artifacts like
source code.
3. Treat periodic or specialized documents as stories: use your existing
planning mechanisms to get them done.

13. DISTINGUISHING
FEATURES OF XP

XP is distinguished from other methodologies by:

 Its early and concrete and continuing feedback from short cycles.
 Its incremental planning approach which quickly comes up with
an overall plan that is expected to evolve through the life of the
project.
 Its ability to flexibly schedule the implementation of
functionality, responding to changing business needs.

27
 Its reliance on automated tests written by programmers and
customers to monitor the progress of development, to allow the
system to evolve and to catch defects easily.
 Its reliance on oral communication, tests and source code to
communicate system structure and intent.
 Its reliance on an evolutionary design process that lasts as long as
the system lasts.
 Its reliance on the close collaboration of programmers with
ordinary skills
 Its reliance on practices that work with both short-term instincts of
programmers and the long-term instincts of the project.
 Risk management: the basic problems faced by all projects are
schedule slips, project canceled, defect rate, business
misunderstood, business changes and so on. XP address risks at all
levels of development process.
 Placing highest value on code that is easily read.

28
14. CONCLUSION

Extreme Programming is a software engineering process and philosophy

based on well-known practices. Extreme Programming triesto make things happen in
ways that people find natural and pleasant. In the case of documentation, this is
accomplished by recognizing that the point is communication, not simply
documentation, then using the most effective forms of communication, and the most
automatic forms, wherever possible. XP is different from established software
processes. Italso provides new challenges and skills as designers need to learn how
todo a simple design, how to use refactoring to keep design clean and how to use
patterns in an evolutionary style.

29
15. REFERENCES

 Laurie Williams, North Carolina state University, “The XP

Programmer”, May/June 2003 IEEE SOFTWARE
 Jonathan Rasmusson, ThoughtWorks, “Introducing XP into
Greenfield Projects: Lessons learned”, May/June 2003 IEEE
SOFTWARE
 William.A.Wood and William.L.Kleb, NASA Langley Research
Center, “Exploring XP for Scientific Research”, May/June 2003
IEEE SOFTWARE
 www.xprogramming.com
 www.extremeprogramming.org
 Giancarlo Succi and Michele Marchese, Addison
Wesley- “Extreme Programming Examined‟‟
 Kent Beck-“Extreme Programming Explained”

30
31