Seminar Report

Acknowledgement

Before I get into think of the things, I would like to add a few heartfelt words to the

people who were a part of this seminar right from the very beginning, the idea of

making this seminar was conceived. People without the help of whom the

preparation of this seminar would be really a difficult task.

First & foremost I thank Mr. R. L. Mathur, Principal, Lachoo Memorial College of

Science & Technology, Jodhpur and whole management for always co-operating us.

I express our sincere thanks with innate humanity to our faculty members, Mr.

Vaibhav Gupta and all others for providing help whenever needed and for providing

stimulating academic environment for work.

Last but not least I am thankful to my parents, friends and colleagues for their

contribution to the seminar.

Bharat Vaishnav

Generated by Foxit PDF Creator © Foxit Softwarehttp://www.foxitsoftware.com For evaluation only.

CONTENTS

1. Introduction 1

2. History 2

3. Goal of XP 3

4. XP Values 4

4.1 Communication 1

4.2 Simplicity 2

4.3 Feedback 3

4.4 Courage 4

4.5 Respect 5

5. Principles of XP 5

6. Activities of XP 6

6.1 Coding 1

6.2 Testing 2

6.3 Listening (Planning) 3

6.4 Designing 4

7. XP Practices 7

7.1 Whole Team 1

7.2 Planning Game 2

7.3 Customer Tests 3

7.4 Small Releases 4

7.5 Simple Design 5

7.6 Pair Programming 6


7.7 Test-Driven Development 7

7.8 Refactoring (Design Improvement) 8

7.9 Continuous Integration 9

7.10 Collective Code Ownership 10

7.11 Coding Standard 11

7.12 Metaphor 12

7.13 Sustainable Pace 13

8. XP Project Work Flow 8

9. Controversial Aspects 9

10. Applications of XP 10

11. Conclusion 11

12. Bibliography 12


Introduction:

Extreme Programming (XP) is a lightweight discipline of software development based

on principles of simplicity, communication, feedback, courage, and respect. XP is

designed for use with small teams who need to develop software quickly in an

environment of rapidly-changing requirements. It works by bringing the whole team

together in the presence of simple practices, with enough feedback to enable the team

to see where they are and to tune the practices to their unique situation.

Proponents of Extreme Programming and agile methodologies in general regard

ongoing changes to requirements as a natural, inescapable and desirable aspect of

software development projects; they believe that adaptability to changing

requirements at any point during the project life is a more realistic and better approach

than attempting to define all requirements at the beginning of a project and then

expending effort to control changes to the requirements.

However, XP has been noted for several potential drawbacks, as compared to more

document-based methodologies, including problems with unstable requirements, no

documented compromises of user conflicts, and lack of an overall design spec or

document.


History:

XP was created by Kent Beck during his work on the Chrysler Comprehensive

Compensation System (C3) payroll project. Beck became the C3 project leader in

March 1996 and began to refine the development method used in the project and

wrote a book on the method named “Extreme Programming Explained”.

Most software development in the 1990s was shaped by two major influences;

internally, object-oriented programming replaced procedural programming as the

programming paradigm favored by some in the industry; externally, the rise of the

Internet and the dot-com boom emphasized speed-to-market and company-growth as

competitive business factors. Rapidly-changing requirements demanded shorter

product life-cycles, and were often incompatible with traditional methods of software

development.

XP created quite a buzz in the late 1990s and early 2000s, seeing adoption in a

number of environments radically different from its origins. The high discipline

required by the original practices often went by the wayside, causing certain practices

to be deprecated or left undone on individual sites. Agile development practices have

not stood still, and XP is still evolving.

Although Extreme Programming itself is relatively new, many of its practices have

been around for some time; the methodology, after all, takes “Best Practices” to

extreme levels.


Goal of XP:

The main aim of XP is to reduce the cost of change. In traditional system

development methods the requirements for the system are determined at the beginning

of the development project and often fixed from that point on. This means that the

cost of changing the requirements at a later stage will be high. XP sets out to reduce

the cost of change by introducing basic values, principles and practices. By applying

XP, a system development project should be more flexible with respect to changes.


XP Values:

Extreme Programming recognized five values as:

Communication

Simplicity

Feedback

Courage

Respect

Communication:

Building software systems requires communicating system requirements to the

developers of the system. In formal software development methodologies, this task is

accomplished through documentation. Extreme Programming techniques can be

viewed as methods for rapidly building and disseminating institutional knowledge

among members of a development team. The goal is to give all developers a shared

view of the system which matches the view held by the users of the system. To this

end, Extreme Programming favors simple designs, common metaphors, collaboration

of users and programmers, frequent verbal communication, and feedback.

Simplicity:

Extreme Programming encourages starting with the simplest solution. Extra

functionality can then be added later. The difference between this approach and more

conventional system development methods is the focus on designing and coding for

the needs of today instead of those of tomorrow, next week, or next month.

Proponents of XP acknowledge the disadvantage that this can sometimes entail more

effort tomorrow to change the system; their claim is that this is more than

compensated for by the advantage of not investing in possible future requirements that

might change before they become relevant. Coding and designing for uncertain future

requirements implies the risk of spending resources on something that might not be

needed. Related to the "communication" value, simplicity in design and coding should

improve the quality of communication. A simple design with very simple code could

be easily understood by most programmers in the team.


Feedback:

Within Extreme Programming, feedback relates to different dimensions of the system

development:

Feedback from the system: by writing unit tests, or running periodic

integration tests, the programmers have direct feedback from the state of the

system after implementing changes.

Feedback from the customer: The functional tests are written by the customer

and the testers. They will get concrete feedback about the current state of their

system. This review is planned once in every two or three weeks so the

customer can easily steer the development.

Feedback from the team: When customers come up with new requirements in

the planning game the team directly gives an estimation of the time that it will

take to implement.

Feedback is closely related to communication and simplicity. Flaws in the system are

easily communicated by writing a unit test that proves a certain piece of code will

break. The direct feedback from the system tells programmers to recode this part. A

customer is able to test the system periodically according to the functional

requirements, known as user stories.

Courage:

Several practices embody courage. One is the commandment to always design and

code for today and not for tomorrow. This is an effort to avoid getting bogged down

in design and requiring a lot of effort to implement anything else. Courage enables

developers to feel comfortable with refactoring their code when necessary. This

means reviewing the existing system and modifying it so that future changes can be

implemented more easily. Another example of courage knows when to throw code

away: courage to remove source code that is obsolete, no matter how much effort was

used to create that source code. Also, courage means persistence: A programmer

might be stuck on a complex problem for an entire day, then solve the problem

quickly the next day, if only they are persistent.


Respect:

The respect value manifests in several ways. In Extreme Programming, team

members respect each other because programmers should never commit changes that

break compilation, that make existing unit-tests fail, or that otherwise delay the work

of their peers. Members respect their work by always striving for high quality and

seeking for the best design for the solution at hand through refactoring.

Adopting four earlier values led to respect gained from others in team. Nobody on the

team should feel unappreciated or ignored. This ensures high level of motivation and

encourages loyalty toward the team, and the goal of the project. This value is very

dependent upon the other values, and is very much oriented toward people in a team.


Principles of XP:

The principles that form the basis of XP are based on the values just described and are

intended to foster decisions in a system development project. The principles are

intended to be more concrete than the values and more easily translated to guidance in

a practical situation.

Extreme Programming sees feedback as most useful if it is done rapidly and

expresses that the time between an action and its feedback is critical to learning and

making changes. Unlike traditional system development methods, contact with the

customer occurs in more frequent iterations. The customer has clear insight into the

system that is being developed. He or she can give feedback and steer the

development as needed.

Unit tests also contribute to the rapid feedback principle. When writing code, the unit

test provides direct feedback as to how the system reacts to the changes one has made.

Assuming simplicity is about treating every problem as if its solution were

"extremely simple". Traditional system development methods say to plan for the

future and to code for reusability. Extreme programming rejects these ideas.

The advocates of Extreme Programming say that making big changes all at once does

not work. Extreme Programming applies incremental changes: for example, a system

might have small releases every three weeks. By making many little steps the

customer has more control over the development process and the system that is being

developed.

The principle of embracing change is about not working against changes but

embracing them. For instance, if at one of the iterative meetings it appears that the

customer's requirements have changed dramatically, programmers are to embrace this

and plan the new requirements for the next iteration.


Activities of XP:

XP describes four basic activities that are performed within the software development

process.

Coding

Testing

Listening (Planning)

Designing

Coding:

The advocates of XP argue that the only truly important product of the system

development process is code. Without code you have nothing.

Coding can be drawing diagrams that will generate code, scripting a web-based

system or coding a program that needs to be compiled.

Coding can also be used to figure out the most suitable solution. For instance, XP

would advocate that faced with several alternatives for a programming problem, one

should simply code all solutions and determine with automated tests which solution is

most suitable.

Coding can also help to communicate thoughts about programming problems. A

programmer dealing with a complex programming problem and finding it hard to

explain the solution to fellow programmers might code it and use the code to

demonstrate what he or she means. Code, say the exponents of this position, is always

clear and concise and cannot be interpreted in more than one way. Other programmers

can give feedback on this code by also coding their thoughts.

Testing:

One cannot be certain of anything unless one has tested it. Testing is not a perceived,

primary need for the customer. A lot of software is shipped without proper testing and

still works. In software development, XP says this means that one cannot be certain


that a function works unless one tests it. This raises the question of defining what one

can be uncertain about.

You can be uncertain whether what you coded is what you meant. To test this

uncertainty, XP uses Unit Tests. These are automated tests that test the code.

The programmer will try to write as many tests he or she can think of that

might break the code he or she is writing; if all tests run successfully then the

coding is complete.

You can be uncertain whether what you meant is what you should have meant.

To test this uncertainty, XP uses acceptance tests based on the requirements

given by the customer in the exploration phase of release planning.

Listening (Planning):

Programmers do not necessarily know anything about the business side of the system

under deve2lopment. The function of the system is determined by the business side.

For the programmers to find what the functionality of the system should be, they have

to listen to business.

Programmers have to listen "in the large": they have to listen to what the customer

needs. Also, they have to try to understand the business problem, and to give the

customer feedback about his or her problem, to improve the customer's own

understanding of his or her problem.

Designing:

From the point of view of simplicity, one could say that system development doesn't

need more than coding, testing and listening. If those activities are performed well,

the result should always be a system that works. In practice, this will not work. One

can come a long way without designing but at a given time one will get stuck. The

system becomes too complex and the dependencies within the system cease to be

clear.


One can avoid this by creating a design structure that organizes the logic in the

system. Good design will avoid lots of dependencies within a system; this means that

changing one part of the system will not affect other parts of the system.


XP Practices:

The core practices of XP are:

Whole Team

Planning Game

Customer Tests

Small Releases

Simple Design

Pair Programming

Test-Driven Development

Refactoring (Design Improvement)

Continuous Integration

Collective Code Ownership

Coding Standard

Metaphor

Sustainable Pace (40-hour Week)


Whole Team:

All the contributors to an XP project sit together, members of one team. This team

must include a business representative -- the "Customer" -- who provides the

requirements, sets the priorities, and steers the project. Its best if the Customer or one

of her aides is a real end user who knows the domain and what is needed. The team

will of course have programmers. The team may include testers, who help the

Customer define the customer acceptance tests. Analysts may serve as helpers to the

Customer, helping to define the requirements. There is commonly a coach, who helps

the team keep on track, and facilitates the process. There may be a manager,

providing resources, handling external communication, coordinating activities. None

of these roles is necessarily the exclusive property of just one individual: Everyone on

an XP team contributes in any way that they can. The best teams have no specialists,

only general contributors with special skills.

Planning Game:

XP planning addresses two key questions in software development: predicting what

will be accomplished by the due date, and determining what to do next. The emphasis

is on steering the project -- which is quite straightforward -- rather than on exact

prediction of what will be needed and how long it will take -- which is quite difficult.

There are two key planning steps in XP, addressing these two questions:

Release Planning is a practice where the Customer presents the desired features to

the programmers, and the programmers estimate their difficulty. With the cost

estimates in hand, and with knowledge of the importance of the features, the

Customer lays out a plan for the project. Initial release plans are necessarily

imprecise: neither the priorities nor the estimates are truly solid, and until the team

begins to work, we won't know just how fast they will go. Even the first release plan

is accurate enough for decision making, however, and XP teams revise the release

plan regularly.


Iteration Planning is the practice whereby the team is given direction every couple of

weeks. XP teams build software in two-week "iterations", delivering running useful

software at the end of each iteration. During Iteration Planning, the Customer presents

the features desired for the next two weeks. The programmers break them down into

tasks, and estimate their cost (at a finer level of detail than in Release Planning).

Based on the amount of work accomplished in the previous iteration, the team signs

up for what will be undertaken in the current iteration.

These planning steps are very simple, yet they provide very good information and

excellent steering control in the hands of the Customer. Every couple of weeks, the

amount of progress is entirely visible. There is no "ninety percent done" in XP: a

feature story was completed, or it was not. This focus on visibility results in a nice

little paradox: on the one hand, with so much visibility, the Customer is in a position

to cancel the project if progress is not sufficient. On the other hand, progress is so

visible, and the ability to decide what will be done next is so complete, that XP

projects tend to deliver more of what is needed, with less pressure and stress.

Customer Tests:

As part of presenting each desired feature, the XP Customer defines one or more

automated acceptance tests to show that the feature is working. The team builds these

tests and uses them to prove to themselves, and to the customer, that the feature is

implemented correctly. Automation is important because in the press of time, manual

tests are skipped.

The best XP teams treat their customer tests the same way they do programmer tests:

once the test runs, the team keeps it running correctly thereafter. This means that the

system only improves, always notching forward, never backsliding.

Small Releases:

XP teams practice small releases in two important ways:

First, the team releases running, tested software, delivering business value chosen by

the Customer, every iteration. The Customer can use this software for any purpose,


whether evaluation or even release to end users (highly recommended). The most

important aspect is that the software is visible, and given to the customer, at the end of

every iteration. This keeps everything open and tangible.

Second, XP teams release to their end users frequently as well. XP Web projects

release as often as daily, in house projects monthly or more frequently. Even shrink-

wrapped products are shipped as often as quarterly.

It may seem impossible to create good versions this often, but XP teams all over are

doing it all the time.

Simple Design:

XP teams build software to a simple design. They start simple, and through

programmer testing and design improvement, they keep it that way. An XP team

keeps the design exactly suited for the current functionality of the system. There is no

wasted motion, and the software is always ready for what's next.

Design in XP is not a one-time thing, or an up-front thing, it is an all-the-time thing.

There are design steps in release planning and iteration planning, plus teams engage in

quick design sessions and design revisions through refactoring, through the course of

the entire project. In an incremental, iterative process like Extreme Programming,

good design is essential. That's why there is so much focus on design throughout the

course of the entire development.

Pair Programming:

All production software in XP is built by two programmers, sitting side by side, at the

same machine. This practice ensures that all production code is reviewed by at least

one other programmer, and results in better design, better testing, and better code.

It may seem inefficient to have two programmers doing "one programmer's job", but

the reverse is true. Research into pair programming shows that pairing produces better

code in about the same time as programmers working singly. That's right: two heads

really are better than one!


Pairing, in addition to providing better code and tests, also serves to communicate

knowledge throughout the team. As pairs switch, everyone gets the benefits of

everyone's specialized knowledge. Programmers learn, their skills improve, they

become more valuable to the team and to the company. Pairing, even on its own

outside of XP, is a big win for everyone.

Test-Driven Development:

Extreme Programming is obsessed with feedback, and in software development, good

feedback requires good testing. Top XP teams practice "test-driven development",

working in very short cycles of adding a test, then making it work. Almost

effortlessly, teams produce code with nearly 100 percent test coverage, which is a

great step forward in most shops.

It isn't enough to write tests: you have to run them. Here, too, Extreme Programming

is extreme. These "programmer tests", or "unit tests" are all collected together, and

every time any programmer releases any code to the repository (and pairs typically

release twice a day or more), every single one of the programmer tests must run

correctly. One hundred percent, all the time! This means that programmers get

immediate feedback on how they're doing. Additionally, these tests provide invaluable

support as the software design is improved.

Refactoring (Design Improvement):

Extreme Programming focuses on delivering business value in every iteration. To

accomplish this over the course of the whole project, the software must be well-

designed. The alternative would be to slow down and ultimately get stuck. So XP uses

a process of continuous design improvement called “Refactoring”.

The refactoring process focuses on removal of duplication, and on increasing the

"Cohesion" of the code, while lowering the "Coupling". High cohesion and low

coupling have been recognized as the hallmarks of well-designed code for at least

thirty years. The result is that XP teams start with a good, simple design, and always

have a good, simple design for the software. This lets them sustain their development

speed, and in fact generally increase speed as the project goes forward.


Refactoring is, of course, strongly supported by comprehensive testing to be sure that

as the design evolves, nothing is broken. Thus the customer tests and programmer

tests are a critical enabling factor.

Continuous Integration:

Extreme Programming teams keep the system fully integrated at all times. We say that

daily builds are for wimps: XP teams build multiple times per day.

The benefit of this practice can be seen by thinking back on projects you may have

heard about where the build process was weekly or less frequently, and usually led to

"integration hell", where everything broke and no one knew why.

Infrequent integration leads to serious problems on a software project. First of all,

although integration is critical to shipping good working code, the team is not

practiced at it, and often it is delegated to people who are not familiar with the whole

system. Second, infrequently integrated code is often -- I would say usually -- buggy

code. Problems creep in at integration times that are not detected by any of the testing

that takes place on an unintegrated system. Third, weak integration process leads to

long code freezes. Code freezes mean that you have long time periods when the

programmers could be working on important shippable features, but that those

features must be held back. This weakens your position in the market, or with your

end users.

Collective Code Ownership:

On an Extreme Programming project, any pair of programmers can improve any code

at any time. This means that all code gets the benefit of many people's attention,

which increases code quality and reduces defects. There is another important benefit

as well: when code is owned by individuals, required features are often put in the

wrong place, as one programmer discovers that he needs a feature somewhere in code

that he does not own. The owner is too busy to do it, so the programmer puts the

feature in his own code, where it does not belong. This leads to ugly, hard-to-maintain

code, full of duplication and with low (bad) cohesion.


Collective ownership could be a problem if people worked blindly on code they did

not understand. XP avoids these problems through two key techniques: the

programmer tests catch mistakes, and pair programming means that the best way to

work on unfamiliar code is to pair with the expert. In addition to ensuring good

modifications when needed, this practice spreads knowledge throughout the team.

Coding Standard:

XP teams follow a common coding standard, so that all the code in the system looks

as if it was written by a single -- very competent -- individual. The specifics of the

standard are not important: what is important is that all the code looks familiar, in

support of collective ownership.

Metaphor:

Extreme Programming teams develop a common vision of how the program works,

which we call the "Metaphor". At its best, the metaphor is a simple evocative

description of how the program works.

XP teams use a common system of names to be sure that everyone understands how

the system works and where to look to find the functionality you're looking for, or to

find the right place to put the functionality you're about to add.

Sustainable Pace:

Extreme Programming teams are in it for the long term. They work hard, and at a pace

that can be sustained indefinitely. This means that they work overtime when it is

effective, and that they normally work in such a way as to maximize productivity

week in and week out. It's pretty well understood these days that death-march projects

are neither productive nor produce quality software. XP teams are in it to win, not to

die.


XP Project Work Flow:



Controversial Aspects:

The practices in XP have been heavily debated with strong opinions for or against

using XP. Some of the controversial aspects of XP are:

Unstable Requirements

User Conflicts

No Big Design Up Front

Customer Representative

Other Aspects

Unstable Requirements:

Proponents of XP claim that by having the on-site customer request changes

informally, the process becomes flexible, and saves the cost of formal overhead.

Critics of XP claim this can lead to costly rework and project scope creep beyond

what was previously agreed.

User Conflicts:

Change control boards are a sign that there are potential conflicts in project objectives

and constraints between multiple users. XP’s expedited methodology is somewhat

dependent on programmers being able to assume a unified client viewpoint so the

programmer can concentrate on coding rather than documentation of compromise

objectives and constraints.

No Big Design Up Front:

There is no Big Design Up Front. Most of the design activity takes place on the fly

and incrementally, starting with “the simplest thing that could possibly work” and

adding complexity only when it’s required by failing tests. Critics fear this would

result in more re-design effort than only re-designing when requirements change.


Customer Representative:

A customer representative is attached to the project. This role can become a single-

point-of-failure for the project, and some people have found it to be a source of stress.

Also, there is the danger of micro-management by a non-technical representative

trying to dictate the use of technical software features and architecture. However,

terms of the development contract and ensuring the customer representative feels

engaged all serve to mitigate this risk.

Other Aspects:

Requirements are expressed as automated acceptance tests rather than

specification documents.

Requirements are defined incrementally, rather than trying to get all in

advance.

Software developers are usually required to work in pairs.


Applications of XP:

Controversial aspects notwithstanding, XP remain a viable choice for some projects.

Projects suited to XP are those that:

Involve new or prototype technology, where the requirements change rapidly,

or some development is required to discover unforeseen implementation

problems.

Are research projects, where the resulting work is not the software product

itself, but domain knowledge.

Are small and more easily managed through agile methods.

Adapting to rapidly changing business needs.

Involve stable technology and have fixed requirements, where it is known that

few changes will occur.


Conclusion:

Extreme Programming is a discipline of software development based on values of

simplicity, communication, feedback, courage and respect. It works by bringing the

whole team together in the presence of simple practices, with enough feedback to

enable the team to see where they are and to tune the practices to their unique

situation.


Bibliography:

Websites:

www.Google.com

www.XProgramming.com

www.ExtremeProgramming.org

www.Wikipedia.com


Seminar Report

Documents

xp practices

extreme programming

principles of xp

xp values

goal of xp

activities of xp

applications of xp

system development project