Hvordan lage gode saker i Jira

INT sin beste praksis for gode beskrivelser av utviklingssaker i Jira.

Teams

Vi fordeler oss på ulike teams. Detaljene om dette finnes her.

Typer utviklingssaker

Saker i Jira skal utformes på hovedsaklig en av tre måter, story, FDD, eller bug. User story er anbefalt format. FDD format må gjerne brukes når brukerperspektivet er mindre relevant. Formatene gir ein kontekst, som gjer det enklare å utvikle beste løysinga. Prøv å gjere ei sak til ein user story i eit halvt minutt, før du evt. bruker FDD eller enklere beskrivelse (kun Bug).

  • Story - Arbeid som må gjerast. Skal være på job story format eller user story format (om sluttbrukar er involvert).
    • User story: Som X, vil eg Y, slik at Z (kven, kva og kvifor)
      • Døme: Som sluttbrukar som bytter passord vil eg ha info om kor lang tid det vil ta før det kan brukast i alle system, slik at ikkje vert frustrert eller forvirra av å ikkje få tilgang.
    • Job story: Når (situasjon), vil eg (motivasjon), slik at (resultat).
      • Døme: Når ei gruppe er 14 dagar unna sluttdato, vil eg at alle moderatorar av gruppa får ein e-post som varsler om dette, slik at dei har mulighet for å forlenge levetida til gruppa.
      • Døme: Når Cerebrum slår saman to personar, vil eg at Cerebrum sender ein eNotifikasjon for samanslåinga, slik at andre system kan handtere ei samanslåing i sitt system.
      • Stories styrast av Product Owner (PO). Endring av stories i pågåande sprint gjerast i dialog med PO.
      • Stories gåast gjennom på Sprint Review.
    • FDD feature - Arbeid som må gjerast av meir teknisk karakter, eller der brukarane ikkje er involverte.
      • Skal være på FDD format: <verb> <resultatet> for/på/frå/til <objektet>
        • Døme: «legg til person-id i output frå cerebrum/rest/*/persons/*»
        • Døme: «Legg til samtykkeknapp på framsida»
    • Bug - Feil som må fiksast. Ikkje krav til format.

    I tillegg har bruker vi to andre sakstyper for spesifikke situasjoner:

    • Epic - Vi bruker epic som ein "super-brukerhistorie" - alle brukerhistorier i ein epic må fullførast for å oppfylle epic-en si brukarhistorie. Definisjonen på epic er egentlig «en brukerhistorie som er for stor for en enkelt sprint», men Jira mangler anna kategorisering, så då bruker vi epic av praktiske årsaker.
      • Skal vere på user-story format (sjå over) - kven, kva og kvifor.
      • Sub-Task - Alle tasks, uavhengig av om det er teknisk eller ikkje. Valgfritt format.
        • Sub-Tasks styrast fritt av utviklingsteamet, etter eige behov. Det er berre den overordna storyen som vert gått gjennom på Sprint Review, ikkje kvar enkelt story.

      Prioriteringar

      Våre prioriteringar:

      1. Critical
      2. Major
      3. Minor

      Det finnast fleire nivå i Jira, og dei kan berre settast globalt, for alle prosjekt, men vi ignorerer andre enn denne lista.

      Status-typar

      Nokre status-typar vi bruker i Jira treng litt meir utdjuping:

      • For Evaluation: Saka må evaluerast av PO før den kan takast med i ein sprint. Alle nye saker får denne statusen, og det er i houvdsak PO som tek seg av slike saker. Kritiske saker og bøggs kan utviklarane dytte vidare til Open.
      • On Hold: Markerer at saka må handterast av PO før den kan gå vidare. Til dømes fordi den treng avklaringar på forretningssida. Brukast typisk i sprint-møter for å markere at saka må behandlast av PO før den kan jobbast med.
      • Backlog: Saker som ikkje er klare for utvikling, og har ingen konkret plan endå. PO sine saker, med andre ord.

      Definition of Done

      Generelt er en sak ferdig, eller "ferdig ferdig" (done-done), når vårt arbeid med saka er ferdig. Gjenstår det til dømes prodsetting, eller sjekk av korleis prodsettinga har gått, er ikkje saka ferdig. Arbeid kan splittast ut i eigne saker, etter behov.

      Det finnes flere unntak fra denne regelen. Generelt skal utviklere vurdere i hvert enkelt tilfelle om det er hensiktsmessig avvike. Diskuter gjerne med PO. 

      Meir konkrete punkt før ei sak er ferdig:

      • All relatert kode skal ha gått gjennom QA og blitt merga. Vanlegvis til master, evt ein pseudo-master ved større endringar.
      • Alle relaterte endringer skal vere prodsatt.
      • Ved saker som gjer endringar eller ny funksjonalitet: Jira-saka skal ha ein kommentar som oppsummerer kva som er gjort teknisk. Dette hjelper både PO og andre i teamet seinare, når ein lurer på kva som har skjedd, spesielt for saker utan lenke til kode.
      Publisert 6. sep. 2017 15:02 - Sist endret 13. jan. 2023 15:26