Submitted in fulfilment of the requirements for the award of the degree

of Bachelor of Technology

inCOMPUTER ENGINEERING

Submitted To: Submitted by:

MS. Poonam Gera HIMANSHU MUNJAL

HOD , C.S. VIII SEM , C.S.

EXTREME PROGRAMMING(XP)

INTRODUCTION AGILE METHODOLOGIES EXTREME PROGRAMMING(XP) XP WORKFLOW XP VALUES XP PRACTICES ADVANTAGE & DISADVANTAGE XP PROGRAMMING EXAMPLE

OVERVIEW OF THE PRESENTATION

An agile development methodology

Created by Kent Beck in the mid 1990’s

A set of 12 key practices taken to their “extremes”

A mindset for developers and customers

INTRODUCTION

A methodology is a formalized process or set of practices for creating software.

An early methodology was the waterfall model.

PROBLEMS:◦ It assumes that there will be no unforeseen difficulties in the

software development.

◦ It assumes that the customers know (and can specify) what they want, in extreme detail.

CONVENTIONAL METHODOLOGIES

Agile programming methodologies assume:

◦Customers can best discover what software meets their needs via frequent iterations

◦Requirements will need to be revised, probably multiple times, during software development.

AGILE METHODOLOGIES

XP has nothing new, yet it has something new XP is a specific instantiation of an agile process XP combines best practices in a different way XP is a different approach to development which

provides-Incremental planning Flexible implementation Automatic tests

EXTREME PROGRAMMING

XP WORKFLOW

Short description of what customer wants the software to do.

Written by the customer in the customer terminology without techno-syntax.

Used to create time estimates for the release planning meeting.

Used instead of a large requirements document.

USER STORIES

XP VALUES

◦Pair Programming Teams of two people

◦Test Driven Development Writing lots of tests, and writing them early

◦Continuous Integration Putting code together as you write it, not at the last minute

◦Coding Standards Learn and follow well-established conventions

◦Collective Code Ownership You are responsible for your partner’s code

◦Simple Design

XP PRACTICES

Project Structure

◦Project: Customized an existing Labor Collection System.

◦Primary User: Human resource

◦Project Team: Programer1, Programer2, Senior Programmer, DBA, Project Manager.

XP PROGRAMMING EXAMPLE

CONVENTIONAL APPROACH

Program manager

Prog1

Pro 2 Senior Pro.

DBA

User

P1

P3

P2

P1, P2, P3 R and Data

R

Data

PROGRAMMING WITH XP

Prog1

Pro 2

User

P1, P2, P3 R and Data

Pro Lead

Built-In Quality

Overall Simplicity

Programmer Power

Customer Power

XP ADVANTAGE

Hard to do

constant involvement of the customer

Informal, little, or no documentation

Misconception on the cost of change

XP DISADVANTAGE

Light-weight: discipline without bureaucracy

Under stress, people do what is easiest◦All XP practices have short-term benefits as well as long-term

benefits

Development as a Conversation

The code is the documentation

Why XP works

Not on very large projects

Not for embedded software if the hardware is frozen

Not with data-driven apps – RAD for these

Not with “Old Economy” management

WHEN NOT TO USE XP

Work as closely as you can with your partner

Don’t just “contribute” your share of the code—also review your partner’s code, checking for problems.

You can use all the Java you know, if your partner also understands it

Don’t:◦ Depend on your partner to do it all◦ Take off and do it all yourself

What I expect of you

THANK YOU

ANY QUERIES