Personal Software Process Lecture 9 Extreme Programming Jerzy

  • Slides: 22
Download presentation
Personal Software Process Lecture 9 Extreme Programming Jerzy. Nawrocki@put. poznan. pl www. cs. put.

Personal Software Process Lecture 9 Extreme Programming Jerzy. Nawrocki@put. poznan. pl www. cs. put. poznan. pl/~nawrocki/mse/psp J. Nawrocki, PSP, Lecture 9 Copyright, 1999 © Jerzy R. Nawrocki

Plan of the lecture • Introduction • From the previous lecture • Approaches to

Plan of the lecture • Introduction • From the previous lecture • Approaches to IT system design • XP issues • Closing J. Nawrocki, PSP, Lecture 9

Effort estimation Estimated size Actual time Historical data begin. . end J. Nawrocki, PSP,

Effort estimation Estimated size Actual time Historical data begin. . end J. Nawrocki, PSP, Lecture 9

Effort estimation Estimated size Actual time r 2 0. 5 Historical data begin. .

Effort estimation Estimated size Actual time r 2 0. 5 Historical data begin. . end J. Nawrocki, PSP, Lecture 9

Effort estimation 1. r 2 0. 5 Estimated size Actual time 0, 1 2.

Effort estimation 1. r 2 0. 5 Estimated size Actual time 0, 1 2. Effort = 1 * Estimated_size + 0 3. Range = t 1 1+ +. . . n 4. Effortmin = Effort - Range J. Nawrocki, PSP, Lecture 9

Effort estimation Lack of correlation between software size and actual time Actual size Actual

Effort estimation Lack of correlation between software size and actual time Actual size Actual time Historical data begin. . end J. Nawrocki, PSP, Lecture 9

Effort estimation 1. Actual size Actual time Pav= size 1 +. . + size

Effort estimation 1. Actual size Actual time Pav= size 1 +. . + size 2 time 1 +. . + time 2 2. Effort = Estimated_size / Pav 3. Pmin= min { sizei / timei } Pmax= max { sizei / timei } 4. Effortmin = Estimated_size/Pmax Effortmax= Estimated_size/Pmin J. Nawrocki, PSP, Lecture 9

Plan of the lecture • Introduction • From the previous lecture • Approaches to

Plan of the lecture • Introduction • From the previous lecture • Approaches to IT system design • XP issues • Closing J. Nawrocki, PSP, Lecture 9

Approaches to IT system design Naive • Customer is a source of money. •

Approaches to IT system design Naive • Customer is a source of money. • Customer is a source of requirements. • Customer is a layman in IT. • Customer is a source of trouble. • Communication with a customer, due to his lack of understanding of IT, is ineffective and should be kept to minimum. J. Nawrocki, PSP, Lecture 9

Approaches to IT system design • Customer is a source of money. • Customer

Approaches to IT system design • Customer is a source of money. • Customer is a source of requirements. • Customer is a layman in IT. • Customer is our partner and we need his domain knowledge. • Communication with a customer is necessary but it needs facilitation. J. Nawrocki, PSP, Lecture 9

Approaches to IT system design • Customer is a source of money. • Customer

Approaches to IT system design • Customer is a source of money. • Customer is a source of requirements. • Customer is not necessarily an expert in IT but he is not a layman. • Customer is our boss, leader, and chief designer. • Good communication with our customer is necessary. J. Nawrocki, PSP, Lecture 9

Plan of the lecture • Introduction • From the previous lecture • Approaches to

Plan of the lecture • Introduction • From the previous lecture • Approaches to IT system design • XP issues • Closing J. Nawrocki, PSP, Lecture 9

XP planning Plan J. Nawrocki, PSP, Lecture 9 • User stories are written. •

XP planning Plan J. Nawrocki, PSP, Lecture 9 • User stories are written. • The Planning Game creates the schedule. • Make frequent small releases. • The project is divided into iterations. • A planning meeting starts each iteration. • A stand-up meeting starts each day. • Move people around.

XP designing Class name Respons- Communication ability J. Nawrocki, PSP, Lecture 9 • Simplicity.

XP designing Class name Respons- Communication ability J. Nawrocki, PSP, Lecture 9 • Simplicity. • Choose a system metaphor. • Use CRC cards for design sessions. • Create spike solutions to reduce risk. • No functionality is added early.

XP coding OK J. Nawrocki, PSP, Lecture 9 • The customer is always available.

XP coding OK J. Nawrocki, PSP, Lecture 9 • The customer is always available. • Code must be written to agreed standards. • All code is pair programmed. • Leave optimisation till last. • No overtime. • Use collective code ownership. • Integrate often. • Only one pair releases code at a time.

XP testing Let’s perform a unit test. . • All code must have unit

XP testing Let’s perform a unit test. . • All code must have unit tests. • All code must pass all unit tests before it can be released. • When a bug is found tests are Help created. • Functional tests are run often and the score is published. J. Nawrocki, PSP, Lecture 9

XP disadvantages • Lack of perspective. I have enough • Potential for a lot

XP disadvantages • Lack of perspective. I have enough • Potential for a lot of rework. • Not every customer can be a leader. • Not every customer will be able to spend so much time with you. • Pair programming can break when a dominating character meets a shy one. It can be also less efficient. • Collective code ownership requires a good documentation. J. Nawrocki, PSP, Lecture 9

XP advantages Great!!! J. Nawrocki, PSP, Lecture 9 • Dynamic requirements. • Involvement of

XP advantages Great!!! J. Nawrocki, PSP, Lecture 9 • Dynamic requirements. • Involvement of the customer. • Short feedback from the customer. • The main responsibility is taken by the customer. • Pair programming can be less efficient but more effective. • If someone leaves it should not be a problem to find a substitute. • No overtime.

Plan of the lecture • • Introduction From the previous lecture Approaches to IT

Plan of the lecture • • Introduction From the previous lecture Approaches to IT system design XP issues • Closing J. Nawrocki, PSP, Lecture 9

Summary Extreme Programming: • Strong co-operation with the customer • Frequent small releases •

Summary Extreme Programming: • Strong co-operation with the customer • Frequent small releases • First prepare unit tests, then start coding • Pair programming • Collective code ownership J. Nawrocki, PSP, Lecture 9

Further readings http: //www. extremeprogramming. org /rules. html J. Nawrocki, PSP, Lecture 9

Further readings http: //www. extremeprogramming. org /rules. html J. Nawrocki, PSP, Lecture 9

Quality assessment 1. What is your general impression ? (1 - 6) 2. Was

Quality assessment 1. What is your general impression ? (1 - 6) 2. Was it too slow or too fast ? 3. Did you learn something important to you ? 4. What to improve and how ? J. Nawrocki, PSP, Lecture 9