XP og dokumentation 4. Semester Forår 2009. Emner Kommunikation XP vs. UP Hvorfor dokumentere Hvordan dokumenteres adræt? Typer af relevant dokumentation.

Præsentationer af emnet: "XP og dokumentation 4. Semester Forår 2009. Emner Kommunikation XP vs. UP Hvorfor dokumentere Hvordan dokumenteres adræt? Typer af relevant dokumentation."— Præsentationens transcript:

1 XP og dokumentation 4. Semester Forår 2009

2 Emner Kommunikation XP vs. UP Hvorfor dokumentere Hvordan dokumenteres adræt? Typer af relevant dokumentation

3 Værdier for adræt modellering 1.Kommunikation 2.Enkelthed 3.Feedback “Optimism is an occupational hazard of programming, feedback is the treatment.” 4.Mod 5.Ydmyghed ”The best developers have the humility to recognize that they don't know everything, that their fellow developers, their customers, and in fact all project stakeholders also have their own areas of expertise and have value to add to a project.”

4 Effektivitet i kommunikation Fælles medium Nærhed Flerhed i modalitet Gestik Betoning Kropssprog Real time svar Imødekommenhed

5 Kommunikation i systemudvikling Stræb efter effektiv kommunikation i situationen Vær indstillet på at skifte tilgang efter behov Osmotisk kommunikation Indirekte informationsoverførsel POW Plain Old Whiteboard

6 Centrale XP-projekt principper Synlighed Adaption - Ændre adfærd Inspektion

7 Modellering vs. dokumentation Formålet med modellering er læring Understøtter kommunikation Midlertidig Behovsdrevent Formålet med dokumentation er fastholdelse Understøtter vedligeholdelse Permanent Kontraktdrevet

8 Dokumentation i UP vs. XP UP er modeldrevet: Systemet realiseres gennem modelanvendelse Systemet dokumenteres gennem modellerne XP er test og kodedrevet: Systemet verificeres gennem test Systemet realiseres gennem kode, som drives af test Systemet dokumenteres gennem kode og test, evt. med modeller som støtte

9 Dokumentation og XP ”The two most common misconceptions people have about eXtreme Programming (XP) is that you don’t model and you don’t write documentation." Fundamentalt at bruge user stories og CRC kort Håndtegninger når de foregående ikke er nok (ikke permanente) Test-first og acceptest Enkel kode + hvad man ellers har brug for!!

10 Hvorfor dokumentere? Interessenterne kræver det Altid forretningsbeslutning i XP For at understøtte kommunikation med en ekstern gruppe Må aldrig blive den primære kommunikationskilde Som støtte til at gennemtænke noget

11 Tvivlsomme grunde til dokumentation Nogen vil have kontrol ? Anmod om kørende SW i stedet? Nogen tror det giver succes i projektet Nogen vil retfærdiggøre sin eksistens ? Hvad skal dokumentationen bruges til? Man ved ikke bedre Vant til dokumentationscentrerede metoder Processen angiver udfærdigelse af dokumentation Forsikring om at alt er i orden Find en anden måde at berolige dem på Specifikationer til en anden gruppe Kan være OK, men prøve at finde alternativer

12 Effektiviteten af tidlig detaljerede krav

13 Dokumentation og XP - Eksternt ”If there is a business need for a document, the customer should request the document in the same way that she would request a feature: with a story card. The team will estimate the cost of the document, and the customer may schedule it in any iteration she wishes.” Ved afslutning til vedligeholdere: Kort dokument indeholdende: Systemets arkitektur (evt. UML diagrammer) eller metafor Vigtigste klasser simpel kode, testcases og acceptest Ved afslutning til brugerne: Brugermanualer som ved andre metoder

14 Dokumentation og XP - Internt "Outside your extreme programming project, you will probably need documentation: by all means, write it. Inside your project, there is so much verbal communication that you may need very little else. Trust yourselves to know the difference." I teamet: Krav: user story + andet supplerende + accepttest Design: UML skitser, kun hvis det føles nødvendigt (ikke permanente) Implementering: kommenter kode hvor den ikke kan gøres simpel + testcases

15 Hvornår bliver modeller permanente? 1.Når de giver en klar værdi 2.Når der er nogen der har brug for dem 3.Hvis kunden er villig til at betale for færdiggørelse og vedligeholdelse af dem Principper: Modeller med formål for øje Maksimer interessenternes investering

16 Hvornår bliver modeller blivende?

17 Vedr. dokumentation Systemudvikling vs. Dokumentationsudvikling Systemudviklere har viden – tekniske skrivere har færdigheder Behov under udvikling vs. efter udvikling Udfærdigelse af dokumentation undervejs eller bagefter? Kodedokumentation vs. ekstern dokumentation Kvantitet vs. kvalitet Diskussion

18 At rejse let At fremstille lige præcis nok modeller og lige præcis nok dokumentation til at klare sig Man kan rejse for let Eller for tungt Tommelfingerregel: Fremstil aldrig en model eller et dokument før du har brug for det ! Dokumentation kan være effektiv – adræt dokumentation

19 Adrætte dokumenter Maksimerer interessenternes investering ”Mager og tilstrækkelig” Indhold over form Afhængig af situationen!! Indeholder væsentlig / kritisk information Dedikeret til specifik målgruppe Brugere, drift, vedligeholdelse… JIT

20 Dokumenttyper (udvalgte) Kontraktmodeller interaktion med andre systemer (DB, legacy systemer) Design beslutninger Ledelses referat svarer til UP’s Visionsdokument + vurderingsdokument Installations- og kørselsvejledninger Projekt overblik - svarer til projektgrundlag Krav specifikation – user stories og CRC kort Support dokumentation inkl. brugermanualer Systemdokumentation Arkitektur og design, brug UML

21 XP dokumentationsstrategi Foretræk eksekverbar specifikation over statisk specifikation (dokumenter) Enkelt kilde information Dokumenter kun stabile elementer ikke spekulative elementer og derfor så sent i forløbet som muligt Dokumentation er den mindst effektive form for kommunikation

22 Dokumentationsstrategier

23 Opdatering af dokumentation ! Lad være med at opdatere med mindre det gør ondt at lade være Kontraktmodeller bør opdateres og releases før eller parallelt med de elementer de beskriver Brugermanualer, Installations- og kørsels- vejledninger bør opdateres og releases sammen med systemet Anden dokumentation kun hvis det ellers fører til mindsket produktivitet

24 Overdragelse af dokumentation Undgå det! Erstat med andre former for kommunikation Face-to-face samtaler, Videokonferencer, Telefonmøder Suppler med andre former for kommunikation Undgå misforståelser

25 Strategi for adræt dokumentation Fokuser på kundernes minimalbehov Afkræv begrundelse for behovet Hold dokumentationen simpel nok, men ikke for simpel Kunden afgør hvad der er tilstrækkeligt Hav altid et formål med dokumentationen Foretræk kommunikation fokus på forståelse frem for dokumentation Vent med at lave dokumentationen Hold dig til modeller du faktisk sørger for at holde opdaterede Gør dokumentationen offentlig tilgængelig Bed om begrundelse for dokumentationen

26 Design strategi Lad designet være levende og stadig i bevægelse (hav en model, men ændr den gerne) Undgå store designmodeller Tegnemodeller: OK – men ikke for meget Anvend kun som støtte Giver ikke konkret feedback Dyrt at holde tegnemodeller og kode synkrone Find designet i koden så snart det kan lade sig gøre

27 Dokumentation - nøgleprincipper Alt hvad kunden ønsker – kunden skal betale Behov er helt afhængig af typen af projekt Dokumentation bruges som sidste udvej ”Rejs let” betyder – udarbejd den dokumentation der er brug for – ikke den dokumentation man tror man har brug for Omkostningen ved udarbejdelsen af dokumentation skal være meget mindre end fordelen ved at have den

28 User Stories Svarer til use cases, men er ikke det samme Formål: Bruges til at estimere Bruges i stedet for kravspecifikationer User stories skrives af kunden som ting, systemet bør udføre for dem Få sætninger formuleret med kundens terminologi Udgangspunkt for kommunikation Input til accepttests

29 XP projekt

30 CRC kort (Class, Responsibilities, and Collaborators) Et kort med klasse, dens ansvar og interaktion til andre klasser Bruges til konceptuel modellering eller design Udførsel af scenarier – ”Hvad hvis….” Når kort løftes op i luften er de objekter der kan udføre det de har ansvaret for og bede andre objekter om at udføre det de ønsker. På denne måde får man checket om alle de klasser man har beskrevet kan udføre det ønskede scenarie

31 CRC kort På bagsiden af kortet (impl.oplysninger): Beskrivelse af klassen Dens attributter Arbejd i grupper med tutorial på: http://www.csc.calpoly.edu/~dbutler/tutorials/winter96/crc_b/