Extreme Programming Copyright, 1999 © Jerzy R. Nawrocki Personal Software Process Lecture 9

J. Nawrocki, PSP, Lecture 9 Plan of the lecture IntroductionIntroduction From the previous lectureFrom the previous lecture Approaches to IT system designApproaches to IT system design XP issuesXP issues ClosingClosing

J. Nawrocki, PSP, Lecture 9 Effort estimation begin.. end Estimatedsize Actualtime Historical data

J. Nawrocki, PSP, Lecture 9 Effort estimation begin.. end Estimatedsize Actualtime Historical data r 2 0.5

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

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

J. Nawrocki, PSP, Lecture 9 Effort estimation Actual size Actual time Effort = Estimated_size / P av time time 2 size size 2 P av = 3. P min = min { size i / time i } P max = max { size i / time i } P max = max { size i / time i } 4. Effort min = Estimated_size/P max Effort max = Estimated_size/P min Effort max = Estimated_size/P min

J. Nawrocki, PSP, Lecture 9 Plan of the lecture IntroductionIntroduction From the previous lectureFrom the previous lecture Approaches to IT system designApproaches to IT system design XP issuesXP issues ClosingClosing

J. Nawrocki, PSP, Lecture 9 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 to his lack of understanding of IT, is ineffective and should be kept to minimum.Communication with a customer, due to his lack of understanding of IT, is ineffective and should be kept to minimum. Naive

J. Nawrocki, PSP, Lecture 9 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 our partner and we need his domain knowledge.Customer is our partner and we need his domain knowledge. Communication with a customer is necessary but it needs facilitation.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 is a source of money. Customer is a source of requirements.Customer is a source of requirements. Customer is not necessarily an expert in IT but he is not a layman.Customer is not necessarily an expert in IT but he is not a layman. Customer is our boss, leader, and chief designer.Customer is our boss, leader, and chief designer. Good communication with our customer is necessary.Good communication with our customer is necessary.

J. Nawrocki, PSP, Lecture 9 Plan of the lecture IntroductionIntroduction From the previous lectureFrom the previous lecture Approaches to IT system designApproaches to IT system design XP issuesXP issues ClosingClosing

J. Nawrocki, PSP, Lecture 9 XP planning 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.Plan

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

J. Nawrocki, PSP, Lecture 9 XP coding 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. OK

J. Nawrocki, PSP, Lecture 9 XP testing 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 created. Functional tests are run often and the score is published. Lets perform a unit test.. Help

J. Nawrocki, PSP, Lecture 9 XP disadvantages Lack of perspective. 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. I have enough

J. Nawrocki, PSP, Lecture 9 XP advantages 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. Great!!!

J. Nawrocki, PSP, Lecture 9 Plan of the lecture IntroductionIntroduction From the previous lectureFrom the previous lecture Approaches to IT system designApproaches to IT system design XP issuesXP issues ClosingClosing

J. Nawrocki, PSP, Lecture 9 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 /rules.html

J. Nawrocki, PSP, Lecture 9 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 ?