Personal Software Process Lecture 9 Extreme Programming Jerzy
- Slides: 22
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 IT system design • XP issues • Closing J. Nawrocki, PSP, Lecture 9
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. . end J. Nawrocki, PSP, Lecture 9
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 time Historical data begin. . end J. Nawrocki, PSP, Lecture 9
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 IT system design • XP issues • Closing J. Nawrocki, PSP, Lecture 9
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 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 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 IT system design • XP issues • Closing J. Nawrocki, PSP, Lecture 9
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. • 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. • 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 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 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 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 system design XP issues • Closing 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 http: //www. extremeprogramming. org /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 ? J. Nawrocki, PSP, Lecture 9
- Extreme programming in software engineering
- Extreme close up camera shot
- Extreme programming
- Software crisis of 1960s
- Extreme programming in agile
- Extreme programming xp ventajas y desventajas
- Slidetodoc.com
- Extreme programming diagram
- Extreme programming workflow
- Extreme point theorem linear programming
- Extreme programming advantages
- Extreme programming
- Dilbert negotiation
- Extreme programming refactoring
- Ventajas y desventajas de la metodologia xp
- Extreme programming
- User requirements are expressed as in extreme programming
- 01:640:244 lecture notes - lecture 15: plat, idah, farad
- C data types with examples
- Psp emphasize personal measurement of
- Introduction to the personal software process
- Personal software process
- Personal software process