Detaljar i vår metodikk

Ymse detaljar som teamet er enige om, i vår metodikk. Oppdaterast fortløpande ved behov.

Teams

Vi fordeler oss på ulike teams:

Kven IAM UiO-int BOTT-int Anna
Fredrik 100%      
Jo     100%  
Jonas   100%    
Tobias 50%   10% (SM) 40% TSG-prosjektleiar
Andreas Ellewsen     100%  
Simeon 100%     NyFlyt, eValg2
Marius   100%    
Sivert 100%     NyFlyt
Raymond       SAP: 100%
Buen (40%) 100%      
Jon 100%      
Axel 100%     NyFlyt
Stein 100%      
Andreas Tolfsen 100%      

Tabellen oppdaterast fortløpande, og er meint å reflektere dagens situasjon.

Typer utviklingssaker

Vi skiller mellom følgande typar saker i Jira:

  • Initiative - Overordna gruppering av epics i Jira. Brukast for kategorisering, av prosjektleiarar.
  • 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å under) - kven, kva og kvifor.
  • 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.
  • Story - Arbeid som må gjerast. Skal være på job story format eller user story format (om sluttbrukar er involvert).
    • 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.
    • 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.
    • 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.
  • 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.

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).

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.
Publisert 6. sep. 2017 15:02 - Sist endret 20. okt. 2020 09:45