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

2. 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

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

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

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

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

7. J. Nawrocki, PSP, Lecture 9 Effort estimation Actual size Actual time 1. 2. Effort = Estimated_size / P av time 1 +.. + time 2 size 1 +.. + 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

8. 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

9. 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

10. 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.

11. 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.

12. 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

13. 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

14. 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

15. 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

16. 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

17. 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

18. 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!!!

19. 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

20. 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

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

22. 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 ?