Arbejdsgange

Jira manual – Sprintudvikling og testprocedurer

Business og Tech boards

Når et projekt starter, bliver problemerne i Jira opdelt i 2 boards: Business og Tech. Tech-boardet indeholder alle problemer for tech-teamet i forbindelse med udviklingen af appen. Business boardet indeholder alt det andet – problemerne for salg, marketing, administration osv. Efterhånden som virksomheden vokser, kan business boardet blive delt op i flere boards.

 

Forretningstavlen

Business boardet er et Kanban board (Trello er det mest kendte eksempel), hvor medarbejderne kan tilføje emner og sætte deadlines. Problemer er normalt tildelt en bestemt person, og etiketter på problemer bruges til at gruppere problemer. Du tilføjer et problem til forretningstavlen ved at indstille komponenten til Forretning.

I Business-boardet bruger vi feltet “Due date” til at angive deadline. Når et problem nærmer sig sin deadline, vil Jira flytte problemet fra sin gruppe til en “høj prioritet”-gruppe øverst.

En issue scheduler bruges til at oprette tilbagevendende problemer.

 

Den tekniske tavle

Udviklingen følger scrum-modellen, der sigter mod at udgive tidligt og udgive ofte, og The Tech Board er derfor opdelt i sprints, som er korte perioder med en bestemt funktion eller et bestemt område af appen som fokusområde inden for sprintet.

The Tech Board bruger normalt ikke forfaldsdatoer, og vi tildeler sjældent personer til problemer, da arbejdet er planlagt i sprints.

 

Sprints

Vi arbejder i sprints fra mandag kl. 9.00 til mandag kl. 9.00 dansk tid. Hver sprintlængde kan være 1-4 uger eller månedlig, normalt starter et projekt med korte sprintlængder og øger sprintlængden, når kunderne begynder onboarding. Den mest almindelige længde er 2 uger. Teamlederen og udvikleren diskuterer problemer på de daglige morgenmøder, og teamlederen gennemgår dem med CTO‘en hver uge.

Når udvikleren begynder at arbejde på et problem, flytter han status til ‘I gang’, og når han er færdig, flytter han problemet til status ‘Test’. Hver morgen efter stand-up-mødet gennemgår teamlederen problemerne i testen og ændrer status til “godkendt” eller tilbage til “i gang”.

Hvis teamlederen af en eller anden grund ikke er i stand til at afslutte testen af alle problemer i ‘Test’ efter morgenmøderne, kan teamlederen tilføje problemlinks i virksomhedens “tech-team”-kanal, som CEO/CPO/CMO kan teste og flytte til ‘Godkendt’.

 

Typer af problemstatus

  • Todo: Klar til arbejde. Udvikleren starter problemer efter rang (ikke prioritet).

  • I gang: Udviklere er begyndt at arbejde på et problem. Hvis der er brug for input, skubber han til DEV.

  • Test: Udvikleren er færdig og har skubbet problemet til TEST.

  • Godkendt: Teamlederen eller projektmedarbejderne har testet opgaven/ændringen, og den er klar til produktion.

  • Udført: Opgaven er blevet skubbet til PROD.

Vigtige godkendte issues bliver skubbet til PROD i løbet af sprintet. Mandag omkring kl. 9.00 dansk tid skubbes alle godkendte ændringer til PROD. Issues sættes til ‘Done’, når de skubbes, og når alle godkendte issues er blevet skubbet, afslutter teamlederen sprinten og sender et link til sprintrapporten i virksomhedens Slack #tech-team-kanal.

Projektmedarbejderne kontrollerer de udførte emner i sprintrapporten og informerer kunder/partnere baseret på de indstillede etiketter og bruger de udførte emner/funktioner i marketing- og salgsmateriale (nyhedsbreve, hjemmeside osv.).

 

Problemer

Nye problemer oprettes i backloggen med en problemtype.

 

Typer af problemer

  • Bug: En fejl eller en forkert oversættelse.

  • Idé: En idé til en ny funktion.

  • Historie: En beskrivelse af en ny funktion skrevet i almindelige brugertermer. Beskriver, hvad det er.

  • Opgave: Noget, der skal gøres, beskrevet i tekniske termer. Beskriv, hvordan man gør det.

  • Delopgave: Større opgaver skal brydes ned i underopgaver.

  • Epic: En del af systemet, der grupperer relaterede historier og opgaver (f.eks. Frontend eller UI/UX, Profile).

  • Test: En del af systemet eller funktionen, der skal testes, eller noget, der ikke er forståeligt.

I slutningen af et sprint bliver produktejeren (som regel CEO’en) og CTO’en enige om problemerne i det næste sprint, og CTO’en rangerer problemerne. Rangeringen kan ske før hvert sprint eller mange sprints i forvejen. Som en meget grov tommelfingerregel kan der være 1 story, 15 tasks, 10 bugs og 5 tests i et 2-ugers sprint pr. udvikler.

Oprettelse af et problem

  • For at oprette en fejl eller noget, der kræver et skærmbillede, skal du bruge Capture til at oprette problemet. Brug en skabelon for at sikre, at problemet har de korrekte oplysninger.

  • For historier, opgaver osv. skal du bruge Jira venstre sidebjælke “Opret fra skabelon” og vælge “En ny opgave – felteksempler”. Dette vil forudfylde resumé og beskrivelse med forklaringen/eksemplerne nedenfor, som du kan udveksle.

  • Til andre problemer, eller når du har styr på at oprette gode problemer, skal du bruge Jira og klikke på + i venstre sidepanel. Inputfelterne understøtter Markdown, så du kan bruge “1.” til en nummereret liste, “*” til bullets osv.

Når du opretter fejl og opgaver, skal du huske at holde dem så korte som muligt, samtidig med at de er lette at forstå, og fokusere på opgavens ToDo. Jo kortere og enklere du holder problemerne for udvikleren, jo hurtigere og bedre vil han udvikle dem.

Arbejdsgange

FREE DOWNLOAD

Send download link to: