Sammen med Sune Monrad fra Cobraid, og Johannes kom vi frem til tre gode råd, som du også lige skal have:
- Man skal køre med Full Stack Teams
- Opgaverne skal brydes ned, så man ikke kun har User Stories
- Brug deadlines og milepæle i Scrum
Projekt Giraf
Projekt Giraf har været i gang i 7 år. Det er et software-projekt, som de studerende kaster sig over i deres sidste semester. Det primære læringsmål er, at de studerende lærer, hvordan man arbejder på store projekter. Kommer der så også noget brugbart software ud, er det en ekstra gevinst.
De studerende ønskede at bruge Scrum i projektet. De havde haft en smule undervisning i det og kunne forstå, at det var det nye sort inden for IT-projekter. De læste op på det og organiserede sig som de mente det var foreskrevet i lærebøgerne om Scrum. Men det gik ikke helt som det skulle. Derfor tog Anton kontakt til os for at høre, hvad vi havde af gode råd.
Hvis du gerne vil høre mere om, hvordan projektet forløb, så kan du høre Antons beskrivelse af hele forløbet i vores podcast. Den finder du lige her
Full Stack Teams
Når man har et Scrum team er det vigtigt, at teamet har de nødvendige kompetencer til at løse en opgave fra A-Z. Teamet må ikke være afhængig af, at nogen udenfor teamet lige skal gøre noget, for at kunne komme videre med opgaven. Det stiller store – og måske endda urealistiske – krav til teamets medlemmer. Det er jo ikke sikkert, at der en database-ekspert eller en UX-ekspert i hvert team.
Selvom det er optimalt, så kan teamet godt fungere alligevel, så længe der er en i teamet, der har det område som sit ansvar. Hvis teamets udnævnte database-ekspert kommer på glatis, kan vedkommende trække på hjælp fra database-eksperter i andre teams. For at gøre det nemmere, kan man med fordel etablere “Guilds”, som er vidensnetværk på tværs af teams, hvor man kan dele erfaringer med netop det kompetenceområde, man har i sit eget team.
Opgaverne skal brydes ned
En opgave må aldrig være for stor. Store opgaver skal altid brydes ned i tasks og det er altid hele teamet, der gør det sammen. Når teamet sammen bryder en user story ned i mindre tasks sker der nemlig en masse vidensdeling. Der bliver delt konkrete idéer og forslag til, hvordan opgaven skal løses, og ikke blot overordnede antagelser, som senere viser sig at være umulige eller alt for komplekse. Når det bliver konkret, kan alle bedre forholde sig til det og tænke med.
Det er en fin balancegang dog, for tasken skal ikke løses – den skal blot skitseres. For mange kokke fordærver maden og på samme måde fordærver for mange udviklere koden. Derfor skal koden ikke skrives i fællesskab. Det skal holdes på skitse-niveau, hvor idéer, forslag og udfordringer vendes og drøftes.
Deadlines og milepæle
Det er en misforståelse, at der ikke er deadlines og milepæle i agile projekter – for det er der. Mange endda! Det handler om, hvem der sætter dem og på hvilket niveau, de sættes. En Product Owner sætter sammen med kunden milepæle for, hvornår bestemte dele af produktet forventes af være færdigt.
Sker der noget undervejs i projektet, som gør, at kunden ønsker at skifte retning, tilpasses milepælene sammen med kunden. Når en Product Owner har prioriteret opgaverne og teamet har vurderet, hvor meget der kan komme med i næste sprint, er der sat en deadline for, hvornår de opgaver er løst, nemlig når sprintet er færdigt.
Det, der ikke er, er store regneark med en detaljeret oversigt over, hvornår alle funktioner forventes at være færdige mange måneder ud i fremtiden. Reglen er, at det vil ændre sig undervejs og at milepæle og deadlines derfor løbende må ændres og rettes til.
Det har vi faktisk skrevet et indlæg om, hvornår man skal gøre hvad og på hvilket niveau. Det kan du læse her
