extreme Programming Kunders og udvikleres menneskerettigheder

Transkript

1 extreme Programming Software Engineering 13 1 Kunders og udvikleres menneskerettigheder Kunder: At sætte mål og få projektet til at følge dem At kende varighed og pris At bestemme softwarefunktionalitet At kende projektets status At kunne ændre krav og kende prisen for ændringerne At kunne vurdere risici med hensyn til tid, pris og kvalitet At have adgang til leverancer undervejs Udviklere: At kende mål og prioriteter At vide i detalje hvad der skal bygges At have adgang til kunde, ledelse, marketing eller andre med ansvar for funktionalitet At kunne arbejde teknisk forsvarligt altid At godkende arbejdsindsats og tidsplan for eget vedkommende At kunde og topledelse kender projektets faktiske status At arbejde i en arbejdsom omgivelse fri for hyppige forstyrrelser 2 SOE13 1

2 XP and traditional process models Figure 1. The evolution of the Waterfall Model (a) and its long development cycles (analysis, design, implementation, test) to the shorter, iterative development cycles within, for example, the Spiral Model (b) to Extreme Programming s (c) blending of all these activities, a little at a time, throughout the entire software development process. 3 XP Practices SOE13 2

3 XP and timescales Figure 2. XP according to various timescales. At the scale of months and years, you have the stories in this release and then the stories in future releases. At the scale of weeks and months, you have stories in this iteration and then the stories remaining in this release. At the scale of days and weeks, you have the task you are working on now and then the rest of the tasks in the iteration. And at the scale of minutes and days, you have the test case you are working on now and then the rest of the test cases that you can imagine. Extreme Programming Analyse Test Kodning Design + projektledelse 6 SOE13 3

4 Extreme Analysis Systemet beskrives som et sæt user stories Brugere skriver stories, der beskriver een anvendelse af systemet Samme ide som use cases, men uformel 7 Extreme Testing Tests skrives før kodning unit tests før hver klasse end-to-end tests før nogen klasse Omsæt hver user story til et sæt af tests Alle unit tests skal på ethvert tidspunkt passeres fuldstændigt 8 SOE13 4

5 Extreme Coding Skriv koden svarende til een test case af gangen Løs opgaven så simpelt som muligt Mål: At gennemføre testene hurtigst muligt skriv nye klasser brug/modificer gamle klasser kopier kode supplér med betingelser Følg kodnings-standarder Skriv koden så klart som muligt 9 Pair Programming Al kode skrives af par Par taler konstant sammen Par skiftes hyppigt til at kode Folk skifter par flere gange dagligt Kode reviewes fortløbende 10 SOE13 5

6 Refactoring: Extreme Design Det skal sikres, at hver ting udføres ét sted - eliminer al gentaget kode Det skal sikres at hver klasse/funktion gør netop een ting Al kode skal kunne læses Alle tests kører 11 Extreme Design cont. Et projekt starter med et par dages design på white-boards/crc-kort Større problemer håndteres på designmøder på gruppeniveau Dokumentation skrives efter kodning - og kun højst nødvendigt Start simpelt, brug refactoring for at bevare det simpelt 12 SOE13 6

7 Extreme Scheduling Kunder skriver stories Udviklere estimerer omkostninger Kunder bestemmer næste skridt Een iteration svarer til en gruppering af stories svarende til få ugers arbejde Udviklere realiserer stories een ad gangen indtil iterationen er afsluttet 13 What is extreme? Ekstremt - men ikke usædvanligt user stories, forhandling af tidsplan, leverancer i trin, aftestning, enkelhed Ekstremt og usædvanligt programmering for par refactoring 14 SOE13 7

8 Rules and Practices of XP I Planning User stories are written. Release planning creates the schedule. Make frequent small releases. The Project Velocity is measured. The project is divided into iterations. Iteration planning starts each iteration. Move people around. A stand-up meeting starts each day. Fix XP when it breaks. Coding The customer is always available. Code must be written to agreed standards. Code the unit test first. All code is pair programmed. Only one pair integrates code at a time. Integrate often. Use collective code ownership. Leave optimization till last. No overtime Rules and Practices of XP II Designing Simplicity. Choose a system metaphor. Use CRC cards for design sessions. Create spike solutions to reduce risk. No functionality is added early. Refactor whenever and wherever possible. 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. Acceptance tests are run often and the score is published SOE13 8