Uppgift och ticket — vad är det, spårningssystem och arbete med uppgifter

Vad är en uppgift och ticket?

Uppgift (från eng. task) — en arbetsenhet registrerad i ett spårningssystem. Innehåller beskrivning, prioritet (Critical, High, Medium, Low), utförare, deadline och status. Inom mobil utveckling kan en uppgift vara “Lägg till profilsida med avatar”, “Implementera paginering av flöde” eller “Uppdatera targetSdk-version till 35”. Varje uppgift är kopplad till ett projekt, sprint och en specifik utvecklare eller team.

Ticket (från eng. ticket) — en bredare entitet. En ticket kan vara en buggrapport (“Appen kraschar vid skärmrotation på Android 14”), en funktionsbegäran (“Lägg till stöd för mörkt tema”), ett ärende till teknisk support (“Push-notis kommer inte fram”) eller en uppgift från en chef (“Förbered en crash rate-rapport för månaden”). Skillnaden mellan en uppgift och en ticket är otydlig: i Jira är båda begreppen förenade i Issue. Huvudskillnad: en uppgift är alltid arbete med en utförare, en ticket kan vara en begäran utan specifik utförare fram till triage.

I Scrum och Kanban är uppgifter huvudinslaget i backloggen. Varje uppgift bör uppfylla INVEST-kriteriet (Independent, Negotiable, Valuable, Estimable, Small, Testable). Oberoende uppgifter kan implementeras i valfri ordning. Uppskattningsbara — teamet kan uppskatta arbetsinsatsen. Små — ryms i en sprint. Testbara — har tydliga acceptanskriterier. Stora uppgifter (epics) delas upp i mindre delar tills alla kriterier är uppfyllda.

Typer av uppgifter inom mobil utveckling

Feature — ny funktionalitet i appen. Exempel: “Inloggningsskärm via biometri (Face ID / Touch ID)”. Feature-uppgifter är alltid kopplade till en user story och har Acceptanskriterier. Uppskattning — i story points (1, 2, 3, 5, 8, 13). Bug — en defekt som hittats under utveckling eller testning. Prioritet för en bugg-ticket bestäms av severity (crash → Critical, UI-bugg → Medium, skrivfel → Low). Inom mobil utveckling är en crash rate över 0,1% en kritisk bugg som kräver omedelbar åtgärd.

Tech Debt / Chore — tekniska uppgifter utan synlig effekt för användaren: uppdatering av bibliotek (Dependency Bump), omfaktorisering (Migrering från ViewPager till ViewPager2), konfigurering av CI/CD, skriva tester. Tech Debt-uppgifter underskattas ofta, även om enligt data från Stripe 2025 går upp till 30% av tiden för ett mobilt team till underhåll och avbetalning av teknisk skuld. Att ignorera Tech Debt leder till en ökning av antalet buggar och en avmattning i utvecklingen av nya funktioner.

Ytterligare typer: Spike (forskningsuppgift — studera ny teknik, skriva POC), Task (allt arbete som inte rör kod — dokumentation, designgranskning), Improvement (förbättring av befintlig funktionalitet — optimering av skärmens laddningstid). I Jira kan issue-typer konfigureras per projekt. Standarduppsättning för ett mobilt team: Story, Bug, Task, Improvement, Epic. Epic — ett stort ämne som förenar flera berättelser. Exempel: “E-handel: varukorg och beställning”.

Livscykel för en uppgift: från skapande till stängning

Open (To Do) — uppgiften skapad men inte påbörjad. Innehåller beskrivning, Acceptanskriterier, prioritet. I denna status bör uppgiften genomgå grooming (förtydligande och uppskattning) innan den går in i sprinten. In Progress — utvecklaren har börjat arbeta. Inom mobil utveckling är det viktigt att länka commits och pull requests till uppgiften: i Jira via Smart Commits (APP-123 #comment fixa bugg), i GitHub/GitLab via nyckelord i PR-beskrivningen (Closes APP-123).

In Review — kod skickad för granskning. Automatiska kontroller: CI (Gradle build, lint, enhetstester), SonarQube (kodkvalitet), Danger (changelog, tester). Utvecklaren kan inte påbörja nästa uppgift medan den aktuella är i Review — detta förhindrar multitasking. QA / Testing — testaren kontrollerar på verkliga enheter (Android — olika OS-versioner och skärmstorlekar, iOS — olika iPhone-modeller). Om buggar hittas återgår uppgiften till In Progress med en kommentar.

Done (Closed) — uppgiften slutförd: kod sammanfogad i main/master, godkänd i testning, redo för release. Vissa team lägger till statusen Deployed — uppgiften når användaren först efter att builden publicerats i butikerna. Det är viktigt att stänga uppgifter med en kommentar om resultatet: vilken version, vilken PR, vilka mätvärden som ändrats. Enligt data från Linear (2025) återkommer team som stänger uppgifter med resultatbeskrivning 40% mindre ofta till samma uppgifter.

Livscykeln kan inkludera statusen Blocked — uppgiften kan inte utföras på grund av ett externt beroende (väntar på design, svar från backend, godkännande från chef). Blockerade uppgifter bör ha en kommentar med orsak och datum för nästa kontroll. Veckovis granskning av blockerade uppgifter hjälper till att identifiera systematiska förseningar i utvecklingsprocessen. Blockeringar längre än 2 veckor kräver eskalering till produktchefsnivå.

Spårningssystem för uppgifter

Jira — industristandard för team från 10 personer. Stöder Scrum- och Kanban-tavlor, avancerad workflow-konfiguration, anpassade fält, automatiseringar, integration med Bitbucket/GitHub. Nackdelar: överflödig för små team, långsamt gränssnitt, komplicerad konfiguration. För mobila projekt konfigureras Jira med: plugin för Mobile-specific fields (Platform, OS version, Device model), integration med TestFlight och Firebase Test Lab, automatisering av release-byggen. Jira — valet för företagsprojekt med byråkratiska processer.

Linear — modern tracker för produktteam. Snabbt gränssnitt, förstklassigt stöd för kortkommandon, inbyggd Cycle (motsvarighet till sprint), integration med GitHub och Slack. Fördelar: snabbhet i att skapa uppgifter via CMD+K, automatisk fördelning i faser (Triaged → Backlog → Upcoming → Current → Completed), inbyggd dokumentation och roadmaps. Linear väljs av startups och produktteam som värdesätter arbetshastighet. År 2025 använder 40% av nya mobila projekt Linear.

Trello — enkel kanban-tavla för små team (2-5 personer). Kort med checklistor, etiketter, deadlines. Nackdel: inga sprints, begränsad analys, svårt att skala. YouGile — rysk motsvarighet till Trello med kanban-tavlor, chatt och videosamtal. Asana — tracker med fokus på projekt och tidslinjer. Valet av tracker beror på teamstorlek, budget och preferenser: Jira för enterprise, Linear för produktteam, Trello/YouGile för startups. Viktigt: verktyget bör vara enhetligt för hela teamet — designers, utvecklare, testare, chefer arbetar i ett system.

Bästa praxis för hantering av uppgifter

Skriv Acceptanskriterier — acceptanskriterierna bör vara konkreta och verifierbara. Dåligt: “Inloggningsskärmen fungerar”. Bra: “Användaren anger e-post och lösenord, klickar på Logga in. Om uppgifterna är korrekta — övergång till huvudskärmen. Om felaktiga — visas felmeddelandet “Felaktig e-post eller lösenord””. Acceptanskriterier (AC) är ett kontrakt mellan utvecklare, testare och produktchef. Utan AC uppfyller uppgiften inte Definition of Ready (DoR) och bör inte komma in i sprinten.

Länka allt. Commits, PR:ar, testfall, designmockuper (Figma), diskussioner i Slack — allt bör vara kopplat till uppgiften. I Jira görs detta via länkar i kommentarer, i Linear — via automatiskt länkande av PR. Enklick-regeln: från uppgift till design/kod/tester — inte mer än ett klick. Utvecklaren öppnar uppgiften och ser omedelbart mockupen i Figma, PR-länken och testfallen. Detta snabbar på onboarding av nya teammedlemmar med 30% enligt data från Linear (2025).

Skapa inte spökuppgifter. En uppgift utan beskrivning, utan AC och utan prioritet är skräp. Om ingen på det dagliga standup-mötet kommer ihåg varför uppgiften skapades — bör den tas bort eller förtydligas. 48-timmarsregeln: om en uppgift har varit i status In Progress utan aktivitet i 48 timmar — bör utvecklaren lämna en kommentar om orsakerna till förseningen. Enligt data från Jira (2025) stängs 60% av uppgifter som varit inaktiva i mer än 3 dagar utan att ha utförts.

Nedbrytning av uppgifter: epic, user stories och deluppgifter

Epic — ett stort funktionsområde som förenar flera berättelser. Exempel: “Användarregistrering” omfattar “Välkomstskärm”, “Val av intressen”, “Ladda upp avatar”, “Konfigurera notiser”. User Story — en uppgift ur användarens perspektiv. Format: “Som [roll], vill jag [handling] för att [värde]”. Exempel: “Som användare vill jag logga in via biometri för att inte behöva ange lösenord varje gång”. User Story skrivs av produktchefen eller produktägaren.

Deluppgift (Sub-task) — nedbrytning av tekniskt arbete inom Story / Task. Exempel för Story “Profilsida”: Sub-task 1: Skapa UI för skärmen (XML / SwiftUI), Sub-task 2: Koppla till ViewModel, Sub-task 3: Skriva enhetstester, Sub-task 4: Snapshot-tester, Sub-task 5: UI-tester (Espresso / XCUITest). Regel för nedbrytning: varje deluppgift slutförs på 1-2 dagar. Om utvecklaren uppskattar deluppgiften längre — delar vi ytterligare. Deluppgifter är en intern teknik inom teamet, de syns inte i produktbackloggen. Summan av uppskattningarna för deluppgifter är inte nödvändigtvis lika med uppskattningen för den överordnade Story (en del av arbetet — kommunikation, kodgranskning, testning).

Nedbrytningspyramid: Epic (Kvartal / Halvår) → Feature / Story (Sprint) → Task (1-3 dagar) → Sub-task (Några timmar). INVEST-tekniken hjälper till att kontrollera kvaliteten på nedbrytningen. Om uppgiften inte är Independent (beroende av andra) — är det en signal om att nedbrytningen är felaktig. Om uppgiften inte är Small (mer än 8 story points) — måste den delas ytterligare. Vanligt mönster: Epic → 5-15 Stories → varje Story → 3-8 Sub-tasks. Slutlig uppskattning av epic = summan av uppskattningar för Stories, men den första sprinten har vanligtvis en avvikelse på 20-30% i uppskattningarna.

Vanliga misstag vid arbete med uppgifter

Misstag 1: för stora uppgifter. En uppgift på 2 veckors arbete är en epic som måste brytas ner. Stora uppgifter lämpar sig inte för daglig spårning, de hänger i In Progress i veckor. Regel: maximal storlek på en uppgift — 2-3 dagars arbete. Allt större — bryt ner. Bieffekt: utvecklaren känner framsteg genom att stänga 2-3 uppgifter i veckan istället för en gigantisk. Detta ökar motivationen och förutsägbarheten av deadlines.

Misstag 2: avsaknad av Acceptanskriterier. Utvecklaren gjorde funktionen, testaren kontrollerade — allt ok. Chefen: “Var är redigeringsknappen?” — “Det står inte i uppgiften”. Utan AC förstår varje part uppgiften på sitt eget sätt. Resultat: omarbetning, konflikter, missade deadlines. AC — kontrakt: om det inte finns några kriterier i uppgiften — är den inte redo för sprinten. Vid grooming kontrolleras först förekomsten av AC. Om AC saknas — skickas uppgiften till produktchefen för bearbetning.

Misstag 3: glömmer Tech Debt. Teamet gör bara Feature-uppgifter sprint efter sprint. Efter ett halvår: kompilering tar 15 minuter, Gradle är föråldrad med 3 huvudversioner, tester fallerar på CI på grund av deprecation. Lösning: avsätt 20% av teamets tid till Tech Debt (Google SRE-praxis “SLO-baserad felbudget”). Skapa minst en Tech Debt-uppgift för varje Feature-sprint. Proportion: för varje 3 Feature-uppgifter — 1 Tech Debt eller Bug. Detta förhindrar ackumulering av teknisk skuld och bibehåller utvecklingshastigheten.