Fra Scrum til UnityHub
Er I vant til at arbejde med Scrum – f.eks. i Jira, Azure DevOps eller Axosoft – kender I de fleste idéer i forvejen. UnityHub bygger på de samme principper, men med færre ting at vedligeholde. Til gengæld hænger udviklingen sammen med tidsregistrering, Cases og fakturering.
Siden her oversætter Scrum-begreberne og viser, hvordan I arbejder i hverdagen.
Begreberne
| Scrum | UnityHub | Bemærk |
|---|---|---|
| Produkt | Produkt og produktversion | Planerne hører til en produktversion |
| Epic | Udviklingsplan | Formål, resultatmål, budget i timer og en produktejer |
| User story | Opgave af typen Ny funktion | Formål er historien (hvorfor), Resultatmål er acceptkriterierne |
| Task / sub-task | Tjekliste på opgaven | Er der flere ansvarlige, så lav flere opgaver på planen |
| Bug | Opgave af typen Fejl | Se Fejl og tilbageløb |
| Improvement | Opgave af typen Forbedring | En mindre ændring af noget, der findes |
| Product owner | Produktejer | Står på udviklingsplanen |
| Definition of Ready | Klar | Produktejeren godkender formål og resultatmål |
| Definition of Done / accept | Resultat godkendt | Produktejeren godkender – eller afviser med en kommentar |
| Sprint | Periode | Typisk 14 dage |
| Sprint planning | Perioder → Tilføj opgaver | Med belastning pr. person, mens I planlægger |
| Velocity / kapacitet | Kapacitet og fast andel | Måles fra tidsregistreringen |
| Daily scrum | Stand-up | På fælles skærm, person for person |
| Burndown | Burndown | På perioden |
| Story points | Estimat og Rest i timer | Se nedenfor |
| Product backlog | Planens opgaver | Se Backlog |
| Sprint review | Resultat godkendt | Løbende – ikke kun i slutningen af perioden |
| Retrospective | Tilbageløb og intern omkørsel | Tal til jeres retrospective – se Fejl og tilbageløb |
Hvad er anderledes?
- Timer i stedet for story points. I registrerer alligevel tid, så prognose, kapacitet og burndown bygger på rigtige timer. Hold Rest opdateret på dine opgaver – det er den, alt regner på.
- Fire statusser. Ikke startet, I gang, Udskudt og Færdig. Board under Opgaver viser dem som kolonner, men der er ingen ekstra kolonner til review eller test – godkendelserne erstatter dem.
- To godkendelser i stedet for Scrum events. En opgave er Klar, før den startes, og resultatet godkendes, når den er færdig. Det er her, produktejeren styrer kvaliteten.
- Ingen sub-tasks. Brug tjeklisten. Er en opgave for stor til én periode, så del den i flere opgaver på planen.
- Du ser kun det, der er klar. Under Opgaver vises planopgaver først, når de er klar og lagt i perioden. Så arbejder ingen på noget, der ikke er afklaret.
- Én registrering. Tiden du registrerer på en opgave, bruges både til planens budget, periodens burndown, din arbejdstid og – på en Case – faktureringen.
Hverdagen
Som udvikler
- Inden stand-up: skriv din note under Min stand-up (på perioden eller i mobilvisningen under Mere). I går udfyldes selv fra din tidsregistrering.
- Find dit arbejde under Mit arbejde → Opgaver. Her står det, der er klar og planlagt til dig.
- Sæt opgaven I gang, og registrér tid på den under Min tid. Opdatér Rest, når du registrerer.
- Brug tjeklisten til de små trin, og noter til det, andre skal vide.
- Sæt opgaven Færdig, når resultatmålet er nået. Produktejeren godkender resultatet – eller afviser det, og så er opgaven tilbage hos dig som I gang med en kommentar.
Som produktejer
- Skriv – eller få skrevet – formål og resultatmål, og tryk Godkend som klar, når de er gode nok.
- Godkend eller afvis resultatet, når en opgave er færdig. Det kan gøres fra planen, fra opgaven og på telefonen. Se Klar, resultat og tilbageløb.
- Hold øje med Prognose og Tilbageløb på planen.
Som planlægger
- Opret perioden, og tilføj de opgaver, der er klar – hold belastningen under 100 %.
- Start perioden, og luk den igen. Ufærdige opgaver flyttes med til næste periode.
Opgavetyper
| Type | Ikon | Bruges til |
|---|---|---|
| Opgave | – | Alt det almindelige: support, drift, interne opgaver. Standard for alle opgaver |
| Ny funktion | ★ | Ny funktionalitet – svarer til en user story. Standard for nye opgaver på en plan |
| Fejl | 🐞 | Noget, der ikke virker, som det skal |
| Forbedring | ↗ | En mindre ændring af noget, der findes |
Typen vælges på opgaven ved siden af Status og Prioritet, og kan altid rettes. Under Opgaver kan du filtrere på typen.
Typen vises kun, når Udviklingsplaner er slået til. Opgaver på Cases og tilbud har ikke flere felter end før – fejlfelterne nedenfor findes kun på opgaver på en udviklingsplan.
Fejl og tilbageløb
Hvor hører en fejl hjemme?
- En kunde melder en fejl: support opretter en opgave på kundens Case. Her registreres supporttiden og faktureres som altid.
- Udviklingen skal rette den: opret en opgave af typen Fejl på en udviklingsplan – f.eks. en fast plan Fejlrettelser pr. produktversion – og sæt Kilde til kundens Case.
- Fejl fundet under test: opret den som Fejl på den plan, I arbejder på.
- Oprettet under Opgaver? En site manager kan flytte opgaven til den rigtige plan under Relateret til – se Flyt en opgave til en udviklingsplan.
Felterne på en fejl
| Felt | Betydning |
|---|---|
| Alvorlighed | Kritisk, Høj, Normal eller Lav |
| Fundet | I test (før release) eller Efter release |
| Stammer fra | Nummeret på den opgave, fejlen kommer fra, f.eks. 1233. Skal udfyldes, når fejlen er fundet efter release |
| Kilde | Den Case, hvor fejlen blev meldt (valgfri) |
| Fejlbeskrivelse | Hvad sker der, og hvordan genskabes det? |
| Forventet resultat | Hvad er rigtigt, når fejlen er rettet? |
En fejl skal også være Klar, før den startes – men en Kritisk fejl kan sættes i gang med det samme. Den vises så som Startet uden godkendelse.
Tilbageløb
Tilbageløb er fejl, der kommer tilbage efter release. De tæller på den plan, de stammer fra – også når de rettes på en anden plan eller på en Case. Timerne bliver stående der, hvor de er brugt.
På planen ser du kortet Tilbageløb:
- Tilbageløb – antal fejl efter release og timerne på dem, og hvor stor en del det er af de timer, der er brugt på planen (tilbageløbsgraden). Farven er grøn, gul eller rød.
- Intern omkørsel – afviste resultater og fejl fundet i test. Det er tegn på, at kvalitetssikringen virker, og tæller ikke med i tilbageløbsgraden.
- En liste over fejlene med alvorlighed, hvad de stammer fra, og hvor de rettes.
Under Udviklingsplaner kan du skifte til Tilbageløb og se tallene pr. produktversion og plan.
Se Klar, resultat og tilbageløb for et gennemregnet eksempel.
Grænserne for gul og rød sættes af en administrator under Integrationsindstillinger – standard er gul fra 7 % og rød fra 12 %. Kun site managers og planens produktejer ser tilbageløb, og kun i timer.
Backlog
Der er ikke én stor backlog – den ligger på planerne:
- Planens opgaver er backlog'en for planen. Opgaver, der ikke er klar, er markeret, så I kan se, hvad der mangler afklaring.
- Perioder → Tilføj opgaver viser alt, der ikke er planlagt endnu. Filtrér på produkt og udviklingsplan, og sæt flueben ved det, der skal med.
- Vil du se alle planopgaver under Opgaver – også dem, der ikke er klar – så slå Vis alle planopgaver til.
Brug Prioritet og Forfaldsdato på opgaverne til at vise, hvad der er vigtigst.
Spørgsmål og svar
Hvor er story points? Der er ingen. Estimér i timer, og hold Rest opdateret. Prognosen bliver mere præcis, fordi den bygger på den tid, I faktisk bruger.
Kan jeg lave sub-tasks? Brug tjeklisten. Skal flere personer arbejde på hver sin del, så lav flere opgaver på planen.
Jeg kan ikke se min opgave under Opgaver. Den er ikke Klar endnu, planen er ikke Aktiv, eller opgaven er ikke lagt i den aktive periode. Slå Vis alle planopgaver til for at se den.
Jeg kan ikke gemme en fejl. En fejl fundet efter release skal have Stammer fra udfyldt med et opgavenummer, der findes.
Skal vi stadig holde retrospective? Ja – brug Tilbageløb og Intern omkørsel som udgangspunkt. Peger tallene på en bestemt plan eller type opgave, er det et godt sted at starte.