Aufgabe und Ticket — was sie sind, Trackingsysteme und die Arbeit mit Aufgaben

Was ist eine Aufgabe und ein Ticket?

Aufgabe — eine in einem Trackingsystem erfasste Arbeitseinheit. Enthält Beschreibung, Priorität (Critical, High, Medium, Low), Bearbeiter, Termin und Status. In der mobilen Entwicklung kann eine Aufgabe „Bildschirm "Profil" mit Avatar hinzufügen“, „Seitennummerierung des Feeds implementieren“ oder „targetSdk auf 35 aktualisieren“ sein. Jede Aufgabe ist einem Projekt, Sprint und einem bestimmten Entwickler oder Team zugeordnet.

Ticket — eine breitere Entität. Ein Ticket kann ein Bugbericht („App stürzt bei Bildschirmdrehung unter Android 14 ab“), eine Funktionsanfrage („Unterstützung für dunkles Thema hinzufügen“), eine technische Support-Anfrage („Push-Benachrichtigung kommt nicht an“) oder eine Aufgabe des Managers („Crash-Rate-Bericht für den Monat erstellen“) sein. Die Grenze zwischen Aufgabe und Ticket ist verschwommen: In Jira sind beide Konzepte in Issue vereint. Der Hauptunterschied: Eine Aufgabe hat immer einen Bearbeiter, während ein Ticket bis zur Triage eine Anfrage ohne bestimmten Bearbeiter sein kann.

In Scrum und Kanban sind Aufgaben das Hauptelement des Backlogs. Jede Aufgabe sollte die INVEST-Kriterien (Independent, Negotiable, Valuable, Estimable, Small, Testable) erfüllen. Unabhängige Aufgaben können in beliebiger Reihenfolge umgesetzt werden. Schätzbare — das Team kann den Aufwand schätzen. Kleine — passen in einen Sprint. Testbare — haben klare Abnahmekriterien. Große Aufgaben (Epics) werden in kleinere Aufgaben zerlegt, bis alle Kriterien erfüllt sind.

Aufgabentypen in der mobilen Entwicklung

Feature — neue Anwendungsfunktionalität. Beispiel: „Biometrischer Anmeldebildschirm (Face ID / Touch ID)“. Feature-Aufgaben sind immer mit einer User Story verknüpft und haben Abnahmekriterien. Die Schätzung erfolgt in Story Points (1, 2, 3, 5, 8, 13). Bug — ein während der Entwicklung oder des Testens gefundener Fehler. Die Priorität eines Bug-Tickets wird durch die Schwere bestimmt (Crash → Critical, UI-Fehler → Medium, Tippfehler → Low). In der mobilen Entwicklung ist eine Crash-Rate über 0,1% ein kritischer Fehler, der sofort behoben werden muss.

Tech Debt / Chore — technische Aufgaben ohne sichtbare Auswirkung auf den Benutzer: Bibliotheksaktualisierungen (Dependency Bump), Refactoring (Migration von ViewPager zu ViewPager2), CI/CD-Einrichtung, Schreiben von Tests. Tech-Dept-Aufgaben werden oft unterschätzt, obwohl laut Stripe 2025 bis zu 30% der Zeit eines mobilen Teams für Wartung und Rückzahlung technischer Schulden aufgewendet wird. Das Ignorieren technischer Schulden führt zu mehr Fehlern und verlangsamt die Entwicklung neuer Funktionen.

Zusätzliche Typen: Spike (Forschungsaufgabe — neue Technologie erkunden, POC schreiben), Task (jede nicht Code-bezogene Arbeit — Dokumentation, Design-Review), Improvement (Verbesserung bestehender Funktionalität — Optimierung der Bildschirm-ladezeit). In Jira werden Issue-Typen pro Projekt angepasst. Das Standardset für ein mobiles Team: Story, Bug, Task, Improvement, Epic. Epic — ein großes Thema, das mehrere Stories vereint. Beispiel: „E-Commerce: Warenkorb und Checkout“.

Aufgabenlebenszyklus: von der Erstellung bis zum Abschluss

Open (To Do) — Aufgabe erstellt, aber nicht begonnen. Enthält Beschreibung, Abnahmekriterien, Priorität. In diesem Status muss die Aufgabe vor dem Eintritt in einen Sprint das Grooming (Verfeinerung und Schätzung) durchlaufen. In Progress — Entwickler hat mit der Arbeit begonnen. In der mobilen Entwicklung ist es wichtig, Commits und Pull Requests mit der Aufgabe zu verknüpfen: in Jira über Smart Commits (APP-123 #comment fix bug), in GitHub/GitLab über Schlüsselwörter in der PR-Beschreibung (Closes APP-123).

In Review — Code zur Überprüfung gesendet. Automatische Prüfungen: CI (Gradle Build, Lint, Unit Tests), SonarQube (Codequalität), Danger (Changelog, Tests). Der Entwickler kann die nächste Aufgabe nicht übernehmen, während die aktuelle in Review ist — dies verhindert Multitasking. QA / Testing — der Tester prüft auf realen Geräten (Android — verschiedene OS-Versionen und Bildschirmgrößen, iOS — verschiedene iPhone-Modelle). Werden Fehler gefunden, kehrt die Aufgabe mit einem Kommentar zu In Progress zurück.

Done (Closed) — Aufgabe abgeschlossen: Code in main/master gemergt, getestet, bereit für die Veröffentlichung. Einige Teams fügen einen Deployed-Status hinzu — die Aufgabe erreicht den Benutzer erst, nachdem der Build in den Stores veröffentlicht wurde. Es ist wichtig, Aufgaben mit einem Ergebnis-kommentar zu schließen: welche Version, welcher PR, welche Metriken sich geändert haben. Laut Linear (2025) kehren Teams, die Aufgaben mit einer Ergebnisbeschreibung schließen, zu 40% seltener zu denselben Aufgaben zurück.

Der Lebenszyklus kann einen Blocked-Status umfassen — die Aufgabe kann aufgrund einer externen Abhängigkeit nicht abgeschlossen werden (Warten auf Design, Backend-Antwort, Manager-Genehmigung). Blockierte Aufgaben müssen einen Kommentar mit dem Grund und dem Datum der nächsten Überprüfung enthalten. Eine wöchentliche Überprüfung blockierter Aufgaben hilft, systemische Verzögerungen im Entwicklungsprozess zu erkennen. Blocker, die länger als 2 Wochen dauern, erfordern eine Eskalation auf die Ebene des Produktmanagers.

Aufgabenverfolgungssysteme

Jira — der Industriestandard für Teams ab 10 Personen. Unterstützt Scrum- und Kanban-Boards, erweiterte Workflow-Anpassung, benutzerdefinierte Felder, Automatisierungen und Integration mit Bitbucket/GitHub. Nachteile: überdimensioniert für kleine Teams, langsame UI, komplexe Konfiguration. Für mobile Projekte wird Jira angepasst mit: dem Plugin Mobile-specific fields (Platform, OS version, Device model), Integration mit TestFlight und Firebase Test Lab sowie Automatisierung von Release-Builds. Jira ist die Wahl für Unternehmensprojekte mit bürokratischen Prozessen.

Linear — ein moderner Tracker für Produktteams. Schnelle UI, erstklassige Tastaturkürzel-Unterstützung, integrierter Cycle (Sprint-Analogon), Integration mit GitHub und Slack. Vorteile: schnelle Aufgabenerstellung über CMD+K, automatische Phasenverteilung (Triaged → Backlog → Upcoming → Current → Completed), integrierte Dokumentation und Roadmaps. Linear wird von Startups und Produktteams gewählt, die Geschwindigkeit schätzen. Im Jahr 2025 verwenden 40% der neuen mobilen Projekte Linear.

Trello — ein einfaches Kanban-Board für kleine Teams (2–5 Personen). Karten mit Checklisten, Etiketten, Fälligkeitsdaten. Nachteil: keine Sprints, eingeschränkte Analytik, schwer skalierbar. YouGile — ein russisches Analogon zu Trello mit Kanban-Boards, Chat und Videoanrufen. Asana — ein Tracker mit Fokus auf Projekte und Zeitpläne. Die Wahl des Trackers hängt von Teamgröße, Budget und Präferenzen ab: Jira für Unternehmen, Linear für Produktteams, Trello/YouGile für Startups. Wichtig: Das Tool sollte für das gesamte Team einheitlich sein — Designer, Entwickler, QA, Manager arbeiten alle im selben System.

Bewährte Praktiken für das Aufgabenmanagement

Schreiben Sie Abnahmekriterien — Abnahmekriterien sollten spezifisch und überprüfbar sein. Schlecht: „Anmeldebildschirm funktioniert“. Gut: „Benutzer gibt E-Mail und Passwort ein, klickt auf Anmelden. Bei korrekten Daten — Navigation zum Hauptbildschirm. Bei falschen Daten — Fehlermeldung „Ungültige E-Mail oder ungültiges Passwort“ anzeigen“. Abnahmekriterien (AC) sind der Vertrag zwischen Entwickler, Tester und Produktmanager. Ohne AC erfüllt eine Aufgabe nicht die Definition of Ready (DoR) und sollte nicht in einen Sprint aufgenommen werden.

Verknüpfen Sie alles. Commits, PRs, Testfälle, Design-Mockups (Figma), Slack-Diskussionen — alles sollte mit der Aufgabe verknüpft sein. In Jira geschieht dies über Links in Kommentaren, in Linear über automatische PR-Verknüpfung. Die Ein-Klick-Regel: Von der Aufgabe zum Design/Code/Test — nicht mehr als ein Klick. Der Entwickler öffnet die Aufgabe und sieht sofort das Figma-Mockup, den PR-Link und die Testfälle. Dies beschleunigt laut Linear (2025) das Onboarding neuer Teammitglieder um 30%.

Erstellen Sie keine Geisteraufgaben. Eine Aufgabe ohne Beschreibung, ohne AC und ohne Priorität ist Müll. Wenn beim täglichen Standup niemand weiß, warum eine Aufgabe erstellt wurde, sollte sie gelöscht oder präzisiert werden. Die 48-Stunden-Regel: Wenn eine Aufgabe 48 Stunden lang ohne Aktivität im Status In Progress war, muss der Entwickler einen Kommentar zu den Gründen der Verzögerung hinterlassen. Laut Jira (2025) werden 60% der Aufgaben, die länger als 3 Tage inaktiv sind, letztendlich ohne Erledigung geschlossen.

Aufgabenzerlegung: Epics, User Stories und Unteraufgaben

Epic — ein großer Funktionsbereich, der viele Stories vereint. Beispiel: „Benutzer-Onboarding“ umfasst „Begrüßungsbildschirm“, „Interessenauswahl“, „Avatar-Upload“, „Benachrichtigungseinstellungen“. User Story — eine Aufgabe aus Benutzersicht. Format: „Als [Rolle] möchte ich [Aktion], um [Wert] zu erhalten“. Beispiel: „Als Benutzer möchte ich mich mit Biometrie anmelden, um nicht jedes Mal mein Passwort eingeben zu müssen“. User Stories werden vom Produktmanager oder Produktinhaber geschrieben.

Unteraufgabe (Sub-task) — Zerlegung technischer Arbeit innerhalb einer Story / Task. Beispiel für Story „Profilbildschirm“: Unteraufgabe 1: UI erstellen (XML / SwiftUI), Unteraufgabe 2: mit ViewModel verbinden, Unteraufgabe 3: Unit-Tests schreiben, Unteraufgabe 4: Snapshot-Tests, Unteraufgabe 5: UI-Tests (Espresso / XCUITest). Zerlegungsregel: Jede Unteraufgabe wird in 1–2 Tagen abgeschlossen. Schätzt ein Entwickler eine Unteraufgabe länger ein — weiter zerlegen. Unteraufgaben sind eine interne Teamtechnik, sie sind im Produkt-Backlog nicht sichtbar. Die Summe der Unteraufgaben-schätzungen ist nicht unbedingt gleich der Schätzung der übergeordneten Story (ein Teil der Arbeit ist Kommunikation, Code-Review, Testen).

Zerlegungspyramide: Epic (Quartal / Halbjahr) → Feature / Story (Sprint) → Task (1–3 Tage) → Sub-task (Mehrere Stunden). Die INVEST-Technik hilft, die Qualität der Zerlegung zu überprüfen. Wenn eine Aufgabe nicht Independent (von anderen abhängig) ist — deutet dies auf eine falsche Zerlegung hin. Wenn eine Aufgabe nicht Small (mehr als 8 Story Points) ist — muss sie weiter zerlegt werden. Häufiges Muster: Epic → 5–15 Stories → jede Story → 3–8 Sub-tasks. Die endgültige Epic-Schätzung = Summe der Story-Schätzungen, aber der erste Sprint hat in der Regel eine Fehlermarge von 20–30% bei den Schätzungen.

Häufige Fehler bei der Arbeit mit Aufgaben

Fehler 1: Aufgaben sind zu groß. Eine 2-Wochen-Aufgabe ist ein Epic, das zerlegt werden muss. Große Aufgaben lassen sich nicht in das tägliche Tracking integrieren; sie bleiben wochenlang in In Progress. Regel: Maximale Aufgabengröße — 2–3 Arbeitstage. Alles Größere muss zerlegt werden. Nebeneffekt: Der Entwickler spürt Fortschritt, indem er 2–3 Aufgaben pro Woche abschließt statt einer riesigen. Dies steigert die Motivation und die Planbarkeit des Zeitplans.

Fehler 2: Fehlende Abnahmekriterien. Der Entwickler hat die Funktion implementiert, der Tester hat geprüft — alles gut. Der Manager: „Wo ist der Bearbeiten-Button?“ — „Stand nicht in der Aufgabe“. Ohne AC versteht jede Seite die Aufgabe anders. Ergebnis: Nacharbeit, Konflikte, verpasste Termine. AC ist ein Vertrag: Wenn die Aufgabe keine Kriterien hat, ist sie nicht sprintreif. Beim Grooming wird als Erstes das Vorhandensein von AC geprüft. Fehlt AC, wird die Aufgabe zur Verfeinerung an den Produktmanager zurückgegeben.

Fehler 3: Technische Schulden vergessen. Das Team macht Sprint für Sprint nur Feature-Aufgaben. Sechs Monate später: Der Build dauert 15 Minuten, Gradle ist 3 Hauptversionen zurück, Tests schlagen auf CI aufgrund von Deprecation fehl. Lösung: 20% der Teamzeit für Tech Debt reservieren (Google-SRE-Praxis „SLO-basiertes Fehlerbudget“). Erstellen Sie mindestens eine Tech-Dept-Aufgabe pro Feature-Sprint. Verhältnis: Auf jeweils 3 Feature-Aufgaben — 1 Tech Debt oder Bug. Dies verhindert die Anhäufung technischer Schulden und erhält die Entwicklungsgeschwindigkeit.