RMS PROCESMODEL CAP DETTE DOKUMENT BESKRIVER VORES SKRÆDDERSYEDE PROCESMODEL. MODELLEN Udgivelsesdato. Oprettelsesdato. Sprog.

Transkript

1 PROCESMODEL RMS DETTE DOKUMENT BESKRIVER VORES SKRÆDDERSYEDE PROCESMODEL. MODELLEN BYGGER PÅ XP OG SCRUM, KRYDDERET MED LIDT GODT FRA UP. CAP Oprettelsesdato Udgivelsesdato Baseret på Workshop Revision Henvendt til Alle med interesse for RMS 2.0.0

2 1 Indholdsfortegnelse 1 Indholdsfortegnelse Indledning Læsevejledning Forudsætninger Forkortelser Vores procesmodel Praksis Roller Arbejdsprodukter Værdier Litteratur Revision Indledning Dette dokument har til formål at beskrive vores skræddersyede procesmodel, som vi har kaldt Customized Agile Process. Vi har lavet modellen på baggrund af Extreme Programming, Scrum og Unified Process, hvor nogle af navngivningerne også kommer fra. Andre emner har vi selv navngivet, da de er unikke for denne proces. len skal bruges i sammenhæng med udvikling af et ressourcestyringssystem til ABB Engineering Odense og det dertil tilkoblede diplomingeniør-afgangsprojektet af Mikael Dahl og Nima Marashi. 2.1 Læsevejledning Dokumentet er opdelt efter fire grupperinger, som tilsammen udgør processen: Praksis Roller Arbejdsprodukter Værdier 2.2 Forudsætninger Det anbefales at man har forhåndskendskab til agile systemudviklingsmetoder, men det burde også være tilstrækkeligt blot at kende noget til systemudvikling. Ønskes en dybdegående forståelse af procesmodellens tilblivelse, kan man læse i dokumentet Workshop, som dette dokument er et produkt af. Side 2 ad 17

3 Man kan også studere i det henviste litteratur under afsnit 5. 3 Forkortelser Ord Forklaring Accepttest En test, der, over for kunden, verificerer at en implementeret feature fungerer. Architecture Softwarearkitekturen i et CAP-projekt CAP Forkortelse for Customized Agile Process. CAP-team Et projekthold i vores skræddersyede procesmodel, Customized Agile Process eller CAP. Common room Det rum, som CAP-teamet opererer i. Cue cards Små håndskrevne sedler, hvorpå der står en feature eller anden opgave, som skal behandles. Customer En kunde i et CAP-projekt Daily team chat Et dagligt stående møde for CAP-teamet. Design document Et dokument, som samler skitseringer og forklarer designet med bl.a. reverse engineering. Feature En egenskab ved systemet, som opfylder et eller flere krav. Function Description Et dokument, som indeholder product backlog, vision og acceptests. Kick off En indledende praksis i CAP. Mentor CAP-teamets vejleder. Navigator En rolle i CAP, som er ansvarlig for at opretholde processens ånd og være ekspert i dens udførelse. Parprogrammering Programmeringsaktivitet fra XP, hvor man altid koder med en makker. Playmaker En rolle i CAP, som er ansvarlig for at følge fremgang og sørge for at opgaver bliver uddelegeret og løst. Product backlog Prioriteret bruttoliste over features til produktet. Project backlog En liste som inkluderer product backlog og projektgruppens interne opgaver. Project Foundation Et dokument, som danner rammerne og grundlaget for hele projektet. QA Forkortelse for Quality Assurance, altså kvalitetssikring. Refactoring En praksis, hvor man omskriver noget kode, uden at ændre på funktionaliteten. Release backlog Den del af product backlog som bliver implementeret til næste release. Sprint En iteration i CAP. Sprint backlog En plan for et sprint, som indeholder features, opgaver og deres tasks, som skal behandles. Sprint burndown En graf, som viser sprint backloggens fremskreden. Sprint Planning En praksis, som definerer de opgaver, som skal løses i et sprint Sprint review En praksis i slutningen af hvert sprint, hvor bl.a. de foreløbige resultater demonstreres. Systemmetaforer Sigende og ofte simplificerede navne om forskellige dele af systemet. Task De mindste delopgaver, som en feature eller opgave, kan bestå af. Test-first-development En underpraksis af test, hvor man skriver tests før man koder. Side 3 ad 17

4 The big picture Unittests Workshop Et stort lærred, som bliver udfyldt i løbet af et sprint, med ting, som besriver den overordnede arkitektur. Små automatiserede binære tests, som tester enkelte stumper af kode. En aktivitet, som typisk varer en halv eller hel dag, som beskæftiger sig med et afgrænset problem. Workshoppen munder typisk ud i et produkt. 4 Vores procesmodel 4.1 Praksis De fundne grupperinger fra Fejl! Henvisningskilde ikke fundet., vil nu blive gennemgået en efter en: Beskrivelse Denne indledende praksis handler om identificering og styring af krav. CAP-teamet afholder en workshop, som har til formål at identificere så mange krav og features som muligt. Det hele sker i samarbejde med kunden, som på en eller anden måde har tilkendegivet sine krav til systemet. Det kunne enten være vha. et kravspecifikationsdokument eller ved direkte tilstedeværelse. Når der er blevet identificeret nok krav, udarbejdes et product backlog, som indeholder alle kravene, i form af features, samt (forslag til) hvordan de kan testes for accept af kunden. Dokumentet bliver sendt til kunden, som overvejer og kommenterer de skrevne features og deres accepttests. Når udviklerne og kunden har nærmet sig hinanden tilstrækkeligt, måske efter flere runder af dokumentudveksling, bliver de skrevne features prioriteret af kunden. Således opnås en prioriteret række af features som i hvert fald udgør nok stof til første iteration. Udviklerne kan vælge at overføre de features, som de regner med at kunne nå indtil næste release dato, til et release backlog. Denne indledende proces kaldes for kick off. Navn Kick Off Sprint Planning Efter at de fundne features er blevet forfinet og forhandlet, tilføjer CAP-teamet yderligere de emner, som skal laves til selve afrapporteringen og prioriterer dem i forhold til featurene. Den liste, som nu indeholder produktets og projektets emner, kaldes for en project backlog. Derefter bliver alle opgaver hver i sær nedskrevet på et stykke seddel og hængt op på en opslagstavle i det fælles rum, hvor deres prioritering også fremgår af hvordan de er sat op i forhold til hinanden. Disse sedler bliver kaldt for cue cards, som udover at betyde stikordskort, også lyder som Queue card, altså et kort, som indgår i en kø. Det er nu udviklernes opgave at behandle køen af cue cards, en efter en, og bryde dem ned i mindre tasks, som derefter bliver estimeret i halve dage. Hvis en task varer andet end en halv til to dage, bliver den omdefineret. De identificerede tasks bliver fyldt ind i det kommende sprint (betydende en iteration, som vi adopterer fra Scrum vores sprints varer mellem 3- Sprints Side 4 ad 17

5 4 uger), indtil summen af taskenes estimeringer passer med længden af sprintet. Resultatet er en sprint backlog, som godkendes i samarbejde med kunden. Sprint afslutning Alle sprints bliver rundet af med et afsluttende sprint review, hvor projektdeltagere og interessenter deltager. Her er det selve de foreløbige produkter, der bliver demonstreret og der anvendes ikke power point præsentationer. I stedet for foregår demonstrationen hands-on og via dialog. Systemets styrker, svagheder, fremtid og udfordringer bliver fremlagt og der bliver modtaget feedback fra interessenterne og de kan komme med forbedringsforslag og ønsker, men udviklerne forpligter sig ikke til andet end at tage de nævnte ting med i overvejelserne til næste sprint planning. Bemærkninger om sprints: Hvis det ikke er det første sprint i projektet, der er tale om, bliver project backloggen forfinet og genforhandlet af interessenterne, hvor der er mulighed for at omprioritere eller komme på helt nye og uopdagede krav. Hvis det derimod er første sprint, er der ikke behov for det ovennævnte, da der netop er afholdt et kick off. Når et sprint er i gang, kan deadlinen ikke ændres og ligeledes er det forbudt at tilføje cue cards eller tasks til sprint backloggen. For at angribe trusler inden de angriber projektet og for at definere, støbe og afprøve arkitekturen så tidligt i forløbet som muligt, er det features med den største arkitekturiske indvirkning der implementeres, frem for andre features, som ikke går i dybden. Desuden anvendes metaforer om arkitekturens dele, så systemet får en lettere og mere overskuelig identitet. Det er f.eks. mere sigende at kalde et subsystem der gemmer data i en fil for en writer end en Hex2ASCII_CONV. Architecture Alle gruppedeltagere arbejder i det samme fælles rum og alt hvad der skal bruges til projektarbejdet er indenfor rækkevidde. Det gælder opslagstavler til ophængning af cue cards og project- og sprint backlogs, tavler eller whiteboards til skitsering, digitalkamera til at tage billeder af skitserne, printerserver, kaffemaskine osv. Dermed er holddeltagerne altid til rådighed for hinanden og der bliver skabt et specielt team spirit og der er en kampgejst for at nå guldet. Alternativet havde været, at deltagerne arbejdede hjemmefra eller ikke havde et dedikeret fælles rum og ville ikke føle sig hjemme og tilpas på samme måde. De ville måske føle sig frustreret over ikke at kunne få adgang til nødvendige redskaber når de havde brug for dem og alt i alt ville hele projektet blive berørt af deres dårlige trivsel. Common Room Hver dag, på samme tidspunkt og samme sted, afholdes et stående møde, kaldet daily team chat, ved tavlen eller whiteboardet, hvor en række faste punkter gennemgås: 1. Hvad har du lavet siden sidste team chat? Daily Team Chat Side 5 ad 17

6 2. Hvad vil du lave fra nu og til det næste team chat? 3. Hvad står i vejen for at opnå sprintets mål? 4. Er der opgaver, der skal føjes til sprint backlog? (oversete opgaver, ikke nye) 5. Har du lært noget nyt eller truffet nogen beslutninger, som er vigtige for resten af holdet? Hvis en af deltagerne har problemer med en opgave eller har brug for at få taget en vigtig beslutning, bliver det skrevet op på tavlen og diskuteret umiddelbart efter team chatten. Hvis det er en beslutning, som kan tages inden for gruppen, bliver den taget inden for én time. Er det en forhindring, som kan løses internt, løses det inden dagen er omme. Men hvis det derimod er en beslutning eller en forhindring, som omhandler en ekstern interessent, f.eks. customer eller mentor, sørger gruppen for at kontakte den pågældende repræsentant personligt, telefonisk eller over e.l. Inden udviklerne sætter sig til at programmere, kan de bruge lidt tid på at overveje designet og diskutere forskellige strategier. Men i stedet for at sidde ved en lille computerskærm og lave smarte diagrammer med et kompliceret værktøj, bør de i stedet stå ved en tavle og lave simple skitser af designforslag og tiltag. Når de er blevet enige om det grove design og skal til at programmere, kan de hurtigt tage et billede af skitsen vha. et digitalkamera og anvende det til dokumentation. Det er anbefalet at anvende UML2 standard, men man skal passe på at det ikke tager pusten fra den kreativitet, som softwaredesign er. Når man efterfølgende sidder med systemets kildekode, kan man anvende et smart CASE-værktøj til at lave smarte og UML2- overensstemmende diagrammer. Visualization Der anvendes en række teknikker til tests, som sikrer en løbende QA af koden, systemet og brugbarheden af systemet. Unittests o Der lavet automatiske binære tests til små kodeenheder, altså funktioner og klasser, der (i et isoleret miljø og adskilt fra resten af systemet) tester enhederne med forskellige definerede inputs. Test-first-development o Unittests bliver skrevet inden programmeringen af en enhed går i gang. Udvikleren overvejer nøje hvordan enheden kan fejle og skriver sine testcases derefter. Det er med til at der gøres vigtige indledende overvejelser. Kundeaccepttests o Udviklere og kunden bliver ved kick-off enige om hvorledes de valgte features skal testes, således at udviklerne kan arbejde mod et acceptabelt resultat og kunden kan verificere at de implementerede features er acceptable. Test Side 6 ad 17

7 Når man designer og programmerer, skal man bestræbe sig på at finde den mest simple løsning der findes, for at problemet lige netop bliver løst. Huskesætningen, der siger kod for i dag design for i morgen gælder ikke her. Man tænker på det aktuelle problem og laver f.eks. ikke klassehierakier, blot fordi at der måske bliver behov for det i fremtiden. Antallet af klasser og metoder holdes på et minimum, så længe det ikke går ud over den nødvendige funktionalitet, kodestandarder og god kodeskik. Simple Design Programmeringsaktiviteten er, af åbenlyse årsager, en uundgåelig aktivitet i enhver systemudviklingsproces og i de agile processer er den helt central og elementær. Vores programmeringsaktivitet er hentet fra XP. Parprogrammering Normal programmeringspraksis foregår parvis, hvor den ene har tastaturet og f.eks. koder en funktion eller en algoritme og den anden kommenterer, gør opmærksom på fejl og har et overblik over det overordnede task, som er ved at blive implementeret. Makkerparret bestemmer selv hvornår de vil skifte roller, så længe det i hvert fald sker et par gange i løbet af en dag og det er ligeligt fordelt i mellem dem. Hyppigt refactoring Udviklerne bør finde det naturligt at lave refactoring ofte og uopfordret, hvor de optimerer koden, gør den mere overskuelig, gør designet mere intuitivt og simpelt uden at ændre på funktionaliteten og uden at testene begynder at fejle. Kodestandader Det skal ikke være muligt at kunne se forskel på forskellige dele af koden, selvom de er kodet af flere udviklere og kvaliteten og standarden skal være høj og ensartet. Der skal vedtages et sæt af kodenormer, som bliver fulgt af hele holdet. Programming Fælles kodeejerskab Alle udviklere ejer al kode og ingen er eneansvarlige for et stykke kode. Løbende integration Hver gang udviklerparret tjekker en klasse eller flere klasser tilbage i versionsstyringssystemet, sørger de for at kompilere al kode og køre alle unittests på en anden maskine end den de sidder ved. Side 7 ad 17

8 4.2 Roller Beskrivelse På samme måde som en diamant bare er en sten uden dens bedste ven, er et udviklerhold blot en gruppe computernørder, hvis de ikke har en customer. Man kunne også skubbe analogien et skridt længere, mod hvad er forsvarligt, og sige at kunden, på samme måde som diamantens bedste ven, ikke ved hvad den vil have, og vil gå igennem helvede for at få det 1. Kunden er ansvarlig for, i samarbejde med udviklingsholdet, at udforme en række krav til hvad systemet skal kunne og hvordan de opstillede krav skal testes efterfølgende. Et utopisk systemudviklerideal er, at have en alvidende kunde i nærheden, helst lige ved siden af skærmen, så man kan spørge om alverdens små detaljer og bede vedkommende om at kommentere på hver eneste kodelinje man skriver. Velvidende om at ovenstående ideal er uopnåelig for de fleste projekthold, anbefaler CAP en så høj kundedeltagelse som overhovedet muligt. Hvis det ikke er muligt at få en eller flere kunderepræsentanter i samme lokale som udviklerholdet, må man prøve at få en aftale om at kunne træffe dem når som helst. Man skal stræbe efter at få kunden til at deltage ved alle de relevante praksis, som kræver kundens mening og feedback, og forpligte kunden til at gennemse og kommentere dokumenter og artefakter, som udviklerholdet fremsender. Navn Customer En padawan har sin jedi 2, en lærling har sin mester og en CAP team-deltager har sin mentor. Holdet kan til enhver tid regne med at få råd og vejledning fra sin mentor, ligesom de kan bruge hans erfaringer og visdom, til at træffe de rigtige beslutninger for deres projekt. Det er her vigtigt at bemærke, at mentoren ikke er ansvarlig for at lede holdet eller uddelegere opgaver til holdet. Hvis der opstår situationer, som CAP-teamet simpelthen ikke magter at kunne løse på egen hånd, og det er inden for hans ekspertiseområde, kan han aktivt hjælpe CAP-teamet med at fjerne en forhindring eller tage en vigtig beslutning. Det er dog ikke almen praksis for mentoren at han er en aktiv faktor i CAPteamet. Mentor 1 Ours is a world where people don't know what they want and are willing to go through hell to get it., Don Marquis 2 I hollywood sagaen, Star Wars, findes der en række uselviske, erfarne og meget evnefulde personer, kaldet jedis (jedi er), som kæmper på den gode side af kraften. En padawan er et talentfuldt ungt barn, som har potentiale til at blive jedi en dag, og han bliver, fra en tidlig alder, ledsaget af en master-jedi, som videregiver sine erfaringer til ham. Side 8 ad 17

9 I mange forskellige holdsport, har man en playmaker på holdet. I basketball er playmakerens rolle at bygge angrebsspillet op, og det gør han fra det mest hensigtsmæssige sted, i midten af modstanderens banehalvdel og direkte overfor kurven. Han har overblikket og er knivskarp til at spille den rigtige medspiller på det rigtige tidspunkt. De andre spillere er fremragende til deres sport hver for sig, men uden playmakeren kan de ikke udføre en vindende taktik på den mest optimale måde og har svært ved at opretholde et konstruktivt og dynamisk spil fra start til slut. På den anden side er playmakeren intet værd, hvis de andre spillere enten ikke kan deres sport eller ikke er enige med den taktik playmakeren udfører. På samme måde som med basketball, er playmakeren i et CAP-team den der har det kolde overblik ved hvad der skal til for at opnå et sprints og projektets mål. Han ved lige præcis hvornår de forskellige delopgaver i et sprint skal laves og han sørger for at opgaverne bliver besat af holddeltagerne, men han tvinger aldrig nogen til at lave noget de ikke vil og han lytter til holdets forslag til alternative strategier. Hvis det kniber med at nå alle opgaver på tidsplanen, er det playmakeren der har ansvaret for at få det til at hænge sammen igen. Playmaker I de fleste sportsgrene, og for den sags skyld også i basketball, er der en person som er ekspert i spillets regler og er ansvarlig for at alle deltagere gennemfører spillet i den rigtige ånd. Det er nemlig en dommers opgave at styre spillet inden for de rammer, som oprindeligt var tiltænkt den. Der er en del forskelle på en dommer og en navigator, men hensigten er den samme: at spillets regler bliver fulgt. Hvis nogen af holddeltagerne er i tvivl om hvad der videre skal ske i processen eller hvis de er i tvivl om hvordan bestemte praksis bedst bliver udført, er det en navigators ansvar at guide dem i processens ånd. Det opnår han dels ved at kende processen bedre end alle andre og ved at undersøge alternative udveje og tilpasse dem til projektets aktuelle behov. Navigatorens rolle er intet værd, hvis de, som skal navigeres, ikke stoler nok på ham til at følge hans vej. Derfor skal han være overbevisende og kunne argumentere for sine holdninger og vejvisninger og han skal stole på de andres instinkter, selvom de strider imod hans forslag. Navigator Side 9 ad 17

10 Et CAP Team består af en række udviklere, hvoriblandt der også er en navigator og en playmaker. Det betyder altså at alle på holdet først og fremmest er udviklere og de varetager følgende opgaver: Skriver tests Tegner designskitser på tavlen (helst i selskab med andre udviklere) Programmerer i par Refaktorerer Identificerer tasks og estimerer dem Da en mentor normalt ikke træffer beslutninger for CAP teamet, er han ikke direkte en del af holdet. Selvom han vil have at holde opnår et godt resultat, bliver han ikke berørt af det, hvis det ikke lykkedes for dem. CAP Team Side 10 ad 17

11 4.3 Arbejdsprodukter Beskrivelse Navn Det er en god ide at have ét dokument, som forholdsvis kort og præcist, beskriver hvordan det færdige system kommer til at se ud og supplerer beskrivelserne med figurer og konceptbilleder. Hvis det ikke var fordi at dette dokument også husede product backlog en, ville den godt kunne kaldes for et visionsdokument, men det er et godt sted at putte kravene samt de udarbejdede accepttests. Meningen med funktionsbeskrivelsen er, at den flere gange under projektet skal udveksles mellem kunde og CAP teamet, så begge parter kan administrere krav og features iterativt. Function Description I starten af hvert sprint, bliver der hængt et stort hvidt lærred eller lignende op. I løbet af sprintets fremskreden, og dermed arkitekturens opbygning, bliver dette lærred gradvist fyldt ud med små påklistrede figurer, tegninger, diagrammer og lignende, så man til sidst i sprintet står med et stort rigt billede, som beskriver den overordnede arkitektur, sammenhænge internt og eksternt i systemet, og hvad man nu ellers kan bruge til at vise den store sammenhæng og deraf navnet: The Big Picture. Der er enkelte ting, som man skal være opmærksom på. Man skal f.eks. ikke decideret begynde at designe flotte illustrationer og figurer. Det ville nemlig stride imod mange af de principper, som definerer et agilt proces: det ville være spild af tid, hvis det skulle ændres eller udskiftes, den der havde lavet designarbejdet ville være påvirket af den arbejdstid vedkommende havde puttet i det og ville være utilbøjelig til at tænke i andre baner og endelig ville det simpelthen ikke være det mest simple, som kunne løse opgaven. Derfor anbefales det blot at man tager et stykke papir, tegner det man nu vil på det, klipper det ud og klistrer det med englehudstape, så det let kan pilles ned igen. The Big Picture I løbet af implementeringen af systemet, vil der blive tegnet adskillige skitser på en tavle eller whiteboard. Selvom disse skitser kun højst sandsynligt vil ændre sig igennem programmeringen, og sikkert ikke vil passe til koden efterfølgende, er det alligevel en god idé at bruge et digitalkamera til at fotografere og gemme alle skitserne. Så kan man nemlig, efter hvert sprint, lave reverse engineering på koden vha. et CASE-værktøj og anvende de figurer og diagrammer, som kommer ud af det, samt de oprindelige skitser, til at dokumentere designet. Således kan man både dokumentere de oprindelige tanker og hvordan de blev anvendt til at resultere i det endelige design. Design Document Side 11 ad 17

12 CAP adopterer direkte Scrums product backlog og release backlog, som er en prioriteret liste af de krav og features, som systemet skal bestå af, hvor det første er en bruttoliste, og det sidste er en nettoliste for næste release. Udover listen af krav og features, er der også tilhørende estimater af deres implementeringstid, med højere nøjagtighed jo højere man kommer på den prioriterede liste. Udover de to nævnte backlogs, har CAP-teamet også et project backlog, som de kan putte interne opgaver i. Kunden har ingen magt eller indsigt i disse opgaver. Disse backlogs bør udvikles og ændre sig i takt med ændringer i forretningsværdier og teknologier. Product & Release Backlog Side 12 ad 17

13 Inden projektet bliver søsat med et kick off, er der en stribe detaljer og aftaler, som skal sættes på plads. Det drejer sig specielt om CAP-teamets deltagere, ressourcer, interne og eksterne aftaler, projektets mål osv. Man kunne f.eks. inddrage følgende punkter 3 : 1. Udgangspunkt 1. Baggrund 2. Projektets mål 3. Ydre rammer 4. Kritiske faktorer 2. Organisering 1. Projektgruppens ressourcer 2. Interessenter 3. Virtuel organisering 4. Gruppekontrakt 3. Metode 1. Overordnet fremgangsmåde 2. Overordnet tidsplan 3. Teknikker og beskrivelsesværktøjer 4. Arbejdsform 5. Skriftligt materiale 6. Virtuelle diskussioner 4. Underskrifter Project Foundation Et vigtigt punkt, set med CAP-briller, er 3.1, Overordnet fremgangsmåde. Det omhandler nemlig en yderligere skræddersyning af det allerede skræddersyede CAP, hvor CAP-teamet tager processens forskrifter og tilpasser den det aktuelle projekt. Det gælder bl.a. at tildele rollerne til konkrete personer, at definere hvordan backlogs skal se ud og administreres o.l. 7 Der bliver udarbejdet et backlog for hvert sprint, hvor krav og features fra project backloggen er blevet dekomponeret til små tasks. Sprint backloggen skal opdateres hver gang der er en ændring og den skal overvåges af playmakeren. Sprint Backlog 3 Kilde og supplerende information: Værktøjer - Organisatorisk implementation af groupware i distribuerede projektgrupper på masteruddannelser af Pernille Bjørn, Roskilde Universitetscenter, Juni 2002 Side 13 ad 17

14 Sprint backloggens, og dermed hele sprintets, fremgang, bliver visualiseret vha. et sprint burndown, som er en graf der viser summen af opgaver, samt hvordan det går med at behandle dem eller brænde dem ned. Sprint Burndown Som tidligere skrevet, bliver krav og features fra project backloggen, nedskrevet på stykke papir, kaldet cue cards, og hængt op på en opslagstavle i det fælles rum. De bliver hængt op på en måde, så man kan se hvordan de er blevet prioriteret i forhold til hinanden. Cue cards bliver også brugt til at tilføje åbenhed og overskuelighed til sprintets og projektets mål, ved at CAP-teamet kan følge med i hvordan kravene bliver behandlet en efter en. Kent Beck, som har opfundet Extreme Programming, forslår følgende design af story cards: Cue Cards Figur 1 - Eksempel på story cards. Kilde: Kent Beck "Extreme Programming Explained", Nov Customized Agile Process er enig med Kent Beck, og anbefaler at man opbygger en cue card på samme måde. En af grundene til at en cue card ikke får navnet story card, er at den gerne må, men ikke skal være skrevet af en kunde. En anden grund er, at cue cards er mere sigende og giver flere associationer end story cards gør. Side 14 ad 17

15 4.4 Værdier Beskrivelse Navn CAP-teamet har en forpligtelse over for de forskellige interessenter, men bestemt også over for sig selv med hensyn til at nå sprintets satte mål. Playmakeren er forpligtet til at holde et vågent øje med om opgaverne bliver løst som de skal og navigatoren har en forpligtelse til at praktisere processens ånd. Mentoren er forpligtet til at være til rådighed for CAP-teamet og Customer er forpligtet til at prioritere product backloggen, deltage i udformningen af acceptests og være med til sprint-reviews. Commitment Der foregår intensiv kommunikation under parprogrammering, med kunden, med mentoren og ikke mindst til daily team chats. Comnunication Man skal have mod til at tage hurtige beslutninger, mod til at lave drastiske ændringer uden at få systemet til at fejle. Man skal have mod til at stole på kollegernes instinkter og mod til at være selvstændig og gå efter guldet. Courage Forandringsparathed hænger ofte sammen med feedback. Man får bl.a. feedback fra unittests, løbende integration, accepttests, sprint reviews, mentor og customer. Den øjeblikkelige feedback, som f.eks. kommer af unittests, giver udvikleren selvtillid og gør systemudviklingen til en leg. Andre langsigtede former for feedback, sikrer at udviklingen arbejder i den rigtige retning og korrigerer om nødvendigt. Feedback Side 15 ad 17

16 CAP-teamet skal have 100 % fokus på sprintets mål uden udefrakommende distraheringer såsom tilføjelse af krav eller kundens indblanding om hvordan systemet skal udvikles. Navigatorens skal have fokus på den overordnede proces og playmakeren skal holde sit fokus på sprint backloggen. Focus Projektets og sprintets mål, beslutninger, opgaver og fremgang skal til enhver tid være tilgængelig for CAP-holdet. Deltagerne skal dele viden med hinanden og kunne betro sig til med problemer og kunne få hjælp, uden at blive dømt. Navigatoren og playmakeren skal altid være åbne for forslag og, i hvert fald, tage dem til efterretningen. Openness CAP-teamets deltagere skal have respekt for hinanden og blive respekteret af customer og andre interessenter. De skal blive respekteret for deres individualitet og indbyrdes styrker og svagheder. Man skal ikke hænge folk ud for fejltagelser, men tage ansvaret som et team. En udvikler skal have den respekt og suverænitet til at træffe beslutninger for sin delopgave på egen hånd. Respect Et CAP-projekt angriber risici, inden de angriber CAP-teamet. Det betyder at holdet tager fat om diverse risici, såsom usikkerhed og kompleksitet, på et tidligt stadie, og får dem nedbrudt, så de ikke vælter projektet på de sene, kritiske tidspunkter. Risk aware Side 16 ad 17

17 Det magiske ord i alle henseender er simpelhed. Det er en værdi som præger mange hjørner af CAP såsom, cue cards, the big picture og skitser. Når der bliver programmeret, er det også en tommelfingerregel, at den mest simple løsning, som overhovedet kan gå, er den foretrukne løsning. Simplicity 5 Litteratur Craig Larman, Agile and Iterative Development 2003, ISBN: Craig Larman, Applying UML and Patterns 2004, ISBN: Kent Beck, Extreme Programming Explained ISBN: Revision Side/Kapitel Beskrivelse Dato/Initialer Alle Dokument oprettet /NM Alle Småændringer og rettelser i forbindelse /MD med review Alle Dokument reviewet og godkendt /OD Side 17 ad 17