extreme programming copyright, 1999 © jerzy r. nawrocki...

Extreme ProgrammingExtreme Programming

Copyright, 1999 © Jerzy R. Nawrocki

[email protected]@put.poznan.pl

www.cs.put.poznan.pl/~nawrocki/www.cs.put.poznan.pl/~nawrocki/mse/pspmse/psp

Personal Software Process Personal Software Process

Lecture 9Lecture 9

J. Nawrocki, PSP, Lecture 9

Plan of the lecturePlan of the lecture

• IntroductionIntroduction

• From the previous lectureFrom the previous lecture• Approaches to IT system designApproaches to IT system design• XP issuesXP issues• ClosingClosing


Effort estimationEffort estimation

begin .. end

EstimatedEstimatedsizesize

ActualActualtimetime

Historical dataHistorical data



begin .. end

EstimatedEstimatedsizesize



rr22 0.5 0.5rr22 0.5 0.5



Estimated sizeEstimated sizeActual timeActual time

1. 1. 00, , 11

2. Effort = 2. Effort = 11 * Estimated_size + * Estimated_size + 00

+ ...+ ...11

nn++11 3. Range = 3. Range = tt

rr22 0.5 0.5rr22 0.5 0.5

4. Effort4. Effortminmin = Effort - Range = Effort - Range



begin .. end

ActualActualsizesize



Lack of correlation betweenLack of correlation betweensoftware sizesoftware size and and actual timeactual time



Actual sizeActual sizeActual timeActual time

1.1.

2. Effort = Estimated_size / P2. Effort = Estimated_size / Pavav

timetime11 + .. + time + .. + time22

sizesize11 + .. + size + .. + size22 PPavav==

3. P3. Pminmin= min { size= min { sizeii / time / timeii } }

PPmaxmax= max { size= max { sizeii / time / timeii } }

4. Effort4. Effortmin min = Estimated_size/P= Estimated_size/Pmaxmax

EffortEffortmaxmax= Estimated_size/P= Estimated_size/Pminmin



• IntroductionIntroduction• From the previous lectureFrom the previous lecture

• Approaches to IT system Approaches to IT system designdesign

• XP issuesXP issues• ClosingClosing


Approaches to IT system design Approaches to IT system design

• Customer is a source of money.Customer is a source of money.

• Customer is a source of requirements.Customer is a source of requirements.

• Customer is a layman in IT.Customer is a layman in IT.

• Customer is a source of trouble.Customer is a source of trouble.• Communication with a customer, due Communication with a customer, due

to his lack of understanding of IT, is to his lack of understanding of IT, is ineffective and should be kept to ineffective and should be kept to minimum.minimum.

NaiveNaive




• Customer is a source of Customer is a source of requirements.requirements.

• Customer is a layman in IT.Customer is a layman in IT.

• Customer is our Customer is our partnerpartner and we and we need his domain knowledge.need his domain knowledge.

• Communication with a customer is Communication with a customer is necessary but it needs necessary but it needs facilitationfacilitation..




• Customer is a source of Customer is a source of requirements.requirements.

• Customer is not necessarily an Customer is not necessarily an expert in IT but he is expert in IT but he is not a laymannot a layman..

• Customer is our Customer is our boss, leader,boss, leader, and and chief designerchief designer..

• Good communicationGood communication with our with our customer is necessary.customer is necessary.



• IntroductionIntroduction• From the previous lectureFrom the previous lecture• Approaches to IT system designApproaches to IT system design

• XP issuesXP issues• ClosingClosing


XP planningXP planning

• User storiesUser stories are written. are written.• The The Planning GamePlanning Game creates creates

the schedule.the schedule.• Make frequent small Make frequent small releasesreleases..• The project is divided into The project is divided into

iterationsiterations..• A planning meeting starts each A planning meeting starts each

iterationiteration..• A A stand-up meetingstand-up meeting starts each starts each

day.day.• Move people around.Move people around.

PlanPlan


XP designingXP designing

• Simplicity.Simplicity.• Choose a system Choose a system

metaphor.metaphor.• Use CRC cards for Use CRC cards for

design sessions.design sessions.• Create spike solutions to Create spike solutions to

reduce risk.reduce risk.• No functionality is added No functionality is added

early.early.

Class nameClass nameRespons-Respons-abilityability

Commu-Commu-nicationnication


XP codingXP coding

• The customer is The customer is always always availableavailable..

• Code must be written to Code must be written to agreed agreed standardsstandards..

• All code is All code is pair programmedpair programmed..• Leave Leave optimisationoptimisation till last. till last.• No No overtimeovertime..• Use collective Use collective code ownershipcode ownership..• Integrate often.Integrate often.• Only one pair Only one pair releases codereleases code at at

a time.a time.

OKOK


XP testingXP testing

• All code must have All code must have unit testsunit tests..• All code must pass All code must pass allall unit tests unit tests

before it can be before it can be releasedreleased..• When When a bug is founda bug is found tests are tests are

created.created.• Functional testsFunctional tests are run often are run often

and the score is published.and the score is published.

Let’s performa unit test..

HelpHelp


XP disadvantagesXP disadvantages

• Lack of Lack of perspectiveperspective..• Potential for a lot of Potential for a lot of reworkrework..• Not every customer can be a Not every customer can be a

leaderleader..• Not every customer will be able to Not every customer will be able to

spend so much spend so much timetime with you. with you.• Pair programming can break Pair programming can break

when a when a dominatingdominating character character meets a meets a shyshy one. It can be also one. It can be also less efficient.less efficient.

• Collective code ownership Collective code ownership requires a requires a good documentationgood documentation..

I have enough


XP advantagesXP advantages

• DynamicDynamic requirements. requirements.• InvolvementInvolvement of the customer. of the customer.• Short feedbackShort feedback from the from the

customer.customer.• The main The main responsibilityresponsibility is taken is taken

by the customer.by the customer.• Pair programming can be less Pair programming can be less

efficientefficient but more but more effectiveeffective..• If someone leavesIf someone leaves it should not it should not

be a problem to find a substitute.be a problem to find a substitute.• No No overtimeovertime..

Great!!!



• IntroductionIntroduction• From the previous lectureFrom the previous lecture• Approaches to IT system designApproaches to IT system design• XP issuesXP issues

• ClosingClosing


SummarySummary

Extreme Programming:Extreme Programming:• Strong co-operation with the Strong co-operation with the

customercustomer• Frequent small releasesFrequent small releases• First prepare unit tests, then First prepare unit tests, then

start codingstart coding• Pair programmingPair programming• Collective code ownershipCollective code ownership


Further readingsFurther readings

http://http://www.extremeprogramming.org/www.extremeprogramming.org/rules.html rules.html


Quality assessmentQuality assessment

1. What is your general 1. What is your general impression ? (1 - 6)impression ? (1 - 6)

2. Was it too slow or too fast ?2. Was it too slow or too fast ?

3. Did you learn something 3. Did you learn something important to you ?important to you ?

4. What to improve and how ?4. What to improve and how ?

extreme programming copyright, 1999 © jerzy r. nawrocki...

Documents

system design customer

previous lecture approaches

plan slide

effort range slide

actual time slide

source of requirements

source of money

naive slide