Zadanie i ticket — co to jest, systemy śledzenia i praca z zadaniami

Co to jest zadanie i ticket?

Zadanie (od ang. task) — jednostka pracy zarejestrowana w systemie śledzenia. Zawiera opis, priorytet (Critical, High, Medium, Low), wykonawcę, termin i status. W programowaniu mobilnym zadaniem może być „Dodanie ekranu profilu z awatarem”, „Implementacja paginacji kanału” lub „Aktualizacja wersji targetSdk do 35”. Każde zadanie jest przypisane do projektu, sprintu i konkretnego programisty lub zespołu.

Ticket (od ang. ticket) — szersze pojęcie. Ticketem może być raport o błędzie („Aplikacja ulega awarii przy obrocie ekranu na Android 14”), prośba o funkcję („Dodanie obsługi ciemnego motywu”), zgłoszenie do pomocy technicznej („Nie przychodzi powiadomienie push”) lub zadanie od menedżera („Przygotowanie raportu o crash rate za miesiąc”). Granica między zadaniem a ticketem jest rozmyta: w Jira oba pojęcia są połączone w Issue. Kluczowa różnica: zadanie to zawsze praca z wykonawcą, ticket może być prośbą bez konkretnego wykonawcy do momentu triażu.

W Scrum i Kanban zadania są głównym elementem backlogu. Każde zadanie powinno spełniać kryterium INVEST (Independent, Negotiable, Valuable, Estimable, Small, Testable). Niezależne zadania można realizować w dowolnej kolejności. Ocenialne — zespół może oszacować pracochłonność. Małe — mieszczą się w jednym sprincie. Testowalne — są jasne kryteria akceptacji. Duże zadania (epiki) są dzielone na mniejsze, aż speŃnią wszystkie kryteria.

Rodzaje zadań w programowaniu mobilnym

Feature — nowa funkcjonalność aplikacji. Przykład: „Ekran logowania przez biometrię (Face ID / Touch ID)”. Feature-zadania są zawsze powiązane z historią użytkownika i mają Kryteria Akceptacji. Ocena — w story points (1, 2, 3, 5, 8, 13). Bug — defekt znaleziony w procesie programowania lub testowania. Priorytet bug-ticketa określa się przez severity (crash → Critical, UI-bug → Medium, literówka → Low). W programowaniu mobilnym crash rate powyżej 0,1% to krytyczny błąd, wymagający natychmiastowej naprawy.

Tech Debt / Chore — zadania techniczne bez widocznego dla użytkownika efektu: aktualizacja bibliotek (Dependency Bump), refaktoryzacja (Migracja z ViewPager na ViewPager2), konfiguracja CI/CD, pisanie testów. Tech Debt zadania są często niedoceniane, chociaż według danych Stripe 2025, do 30% czasu zespołu mobilnego przeznacza się na utrzymanie i spłatę długu technicznego. Ignorowanie Tech Debt prowadzi do wzrostu liczby błędów i spowolnienia programowania nowych funkcji.

Dodatkowe typy: Spike (zadanie badawcze — zbadanie nowej technologii, napisanie POC), Task (dowolna praca niezwiązana z kodem — dokumentacja, przegląd designu), Improvement (ulepszenie istniejącej funkcjonalności — optymalizacja czasu ładowania ekranu). W Jira typy issues są konfigurowalne dla projektu. Standardowy zestaw dla zespołu mobilnego: Story, Bug, Task, Improvement, Epic. Epic — duży temat łączący kilka historii. Przykład: „E-commerce: koszyk i realizacja zamówienia”.

Cykl życia zadania: od utworzenia do zamknięcia

Open (To Do) — zadanie utworzone, ale nierozpoczęte. Zawiera opis, Kryteria Akceptacji, priorytet. W tym statusie zadanie powinno przejść grooming (doprecyzowanie i ocenę) przed trafieniem do sprintu. In Progress — programista rozpoczął pracę. W programowaniu mobilnym ważne jest łączenie commitów i pull requestów z zadaniem: w Jira przez Smart Commits (APP-123 #comment naprawa błędu), w GitHub/GitLab przez słowa kluczowe w opisie PR (Closes APP-123).

In Review — kod wysłany do przeglądu. Automatyczne sprawdzenia: CI (Gradle build, lint, testy jednostkowe), SonarQube (jakość kodu), Danger (changelog, testy). Programista nie może rozpocząć następnego zadania, dopóki obecne jest w Review — to zapobiega wielozadaniowości. QA / Testing — tester sprawdza na rzeczywistych urządzeniach (Android — różne wersje systemu i rozmiary ekranu, iOS — różne modele iPhone). Jeśli znaleziono błędy — zadanie wraca do In Progress z komentarzem.

Done (Closed) — zadanie zakończone: kod scalony z main/master, przeszedł testowanie, gotowy do wydania. Niektóre zespoły dodają status Deployed — zadanie dotrze do użytkownika dopiero po wydaniu wersji w sklepach. Ważne jest zamykanie zadań z komentarzem o wyniku: jaka wersja, jaki PR, jakie metryki się zmieniły. Według danych Linear (2025), zespoły, które zamykają zadania z opisem wyniku, o 40% rzadziej wracają do tych samych zadań.

Cykl życia może obejmować status Blocked — zadanie nie może zostać wykonane z powodu zewnętrznej zależności (czekamy na projekt, odpowiedź z backendu, aprobatę menedżera). Blocked zadania powinny mieć komentarz z przyczyną i datą następnego sprawdzenia. Cotygodniowy przegląd Blocked-zadań pomaga identyfikować systemowe opóźnienia w procesie programowania. Blokery dłuższe niż 2 tygodnie wymagają eskalacji na poziom menedżera produktu.

Systemy śledzenia zadań

Jira — standard branżowy dla zespołów od 10 osób. Obsługuje tablice Scrum i Kanban, zaawansowaną konfigurację workflow, niestandardowe pola, automatyzacje, integrację z Bitbucket/GitHub. Wady: nadmiarowość dla małych zespołów, wolny interfejs, skomplikowana konfiguracja. Dla projektów mobilnych Jira konfiguruje się za pomocą: wtyczki Mobile-specific fields (Platform, OS version, Device model), integracji z TestFlight i Firebase Test Lab, automatyzacji tworzenia wersji wydaniowych. Jira — wybór projektów korporacyjnych z biurokratycznymi procesami.

Linear — nowoczesny tracker dla zespołów produktowych. Szybki interfejs, pierwszorzędna obsługa skrótów klawiszowych, wbudowany Cycle (odpowiednik sprintu), integracja z GitHub i Slack. Zalety: szybkość tworzenia zadań przez CMD+K, automatyczne przypisanie do faz (Triaged → Backlog → Upcoming → Current → Completed), wbudowana dokumentacja i roadmaps. Linear wybierają startupy i zespoły produktowe, które ceną szybkość działania. W 2025 roku Linear używa 40% nowych projektów mobilnych.

Trello — prosta tablica kanban dla małych zespołów (2-5 osób). Karty z listami kontrolnymi, etykietami, terminami. Wada: brak sprintów, ograniczona analityka, trudne skalowanie. YouGile — rosyjski odpowiednik Trello z tablicami kanban, czatem i wideorozmowami. Asana — tracker z naciskiem na projekty i harmonogramy. Wybór trackera zależy od wielkości zespołu, budżetu i preferencji: Jira dla enterprise, Linear dla zespołów produktowych, Trello/YouGile dla startupów. Ważne: narzędzie powinno być jednolite dla całego zespołu — projektanci, programiści, testerzy, menedżerowie pracują w jednym systemie.

Najlepsze praktyki prowadzenia zadań

Piszcie Kryteria Akceptacji — kryteria akceptacji powinny być konkretne i sprawdzalne. Źle: „Ekran logowania działa”. Dobrze: „Użytkownik wprowadza email i hasło, naciska Zaloguj się. Jeśli dane są poprawne — przejście do ekranu głównego. Jeśli niepoprawne — wyświetlany jest błąd „Nieprawidłowy email lub hasło””. Kryteria Akceptacji (AC) to kontrakt między programistą, testerem i product managerem. Bez AC zadanie nie spełnia Definition of Ready (DoR) i nie powinno trafiać do sprintu.

Linkujcie wszystko. Commity, PR, przypadki testowe, makiety (Figma), dyskusje w Slack — wszystko powinno być powiązane z zadaniem. W Jira robi się to przez linki w komentarzach, w Linear — przez automatyczne powiązanie PR. Zasada jednego kliknięcia: od zadania do projektu/kodu/testów — nie więcej niż jedno kliknięcie. Programista otwiera zadanie i od razu widzi makietę w Figma, link do PR i przypadki testowe. To przyspiesza onboardingu nowych członków zespołu o 30% według danych Linear (2025).

Nie twórzcie zadań-widm. Zadanie bez opisu, bez AC i bez priorytetu to śmieć. Jeśli na codziennym stand-upie nikt nie pamięta, po co utworzono zadanie — należy je usunąć lub doprecyzować. Zasada 48 godzin: jeśli zadanie było w statusie In Progress bez aktywności przez 48 godzin — programista powinien zostawić komentarz o przyczynach opóźnienia. Według danych Jira (2025), 60% zadań bezczynnych dłużej niż 3 dni ostatecznie zamyka się bez wykonania.

Dekompozycja zadań: epiki, historie użytkownika i podzadania

Epic — duży obszar funkcjonalny łączący wiele historii. Przykład: „Onboarding użytkownika” obejmuje „Ekran powitania”, „Wybór zainteresowań”, „Ładowanie awatara”, „Konfiguracja powiadomień”. User Story — zadanie z punktu widzenia użytkownika. Format: „Jako [rola], chcę [działanie], aby [wartość]”. Przykład: „Jako użytkownik, chcę zalogować się przez biometrię, aby nie wpisywać hasła za każdym razem”. User Story pisze product manager lub właściciel produktu.

Podzadanie (Sub-task) — dekompozycja pracy technicznej wewnątrz Story / Task. Przykład dla Story „Ekran profilu”: Sub-task 1: Stworzenie UI ekranu (XML / SwiftUI), Sub-task 2: Połączenie z ViewModel, Sub-task 3: Napisanie testów jednostkowych, Sub-task 4: Testy Snapshot, Sub-task 5: Testy UI (Espresso / XCUITest). Zasada dekompozycji: każde podzadanie kończy się w 1-2 dni. Jeśli programista ocenia podzadanie na dłużej — dzielimy dalej. Podzadania to wewnętrzna technika zespołu, nie są widoczne w backlogu produktowym. Suma ocen podzadań niekoniecznie równa się ocenie nadrzędnej Story (część pracy — komunikacja, code review, testowanie).

Piramida dekompozycji: Epic (Quarter / Half-year) → Feature / Story (Sprint) → Task (1-3 dni) → Sub-task (Kilka godzin). Technika INVEST pomaga sprawdzić jakość dekompozycji. Jeśli zadanie nie jest Independent (zależy od innych) — to sygnał, że dekompozycja jest nieprawidłowa. Jeśli zadanie nie jest Small (więcej niż 8 story pointów) — trzeba dzielić dalej. Common pattern: Epic → 5-15 Stories → każda Story → 3-8 Sub-tasków. Końcowa ocena epika = suma ocen Stories, ale pierwszy sprint zwykle daje odchylenie 20-30% w ocenach.

Typowe błędy przy pracy z zadaniami

Błąd 1: zbyt duże zadania. Zadanie na 2 tygodnie pracy to epik, który trzeba zdekomponować. Duże zadania nie nadają się do codziennego śledzenia, wiszą w In Progress tygodniami. Zasada: maksymalny rozmiar zadania — 2-3 dni pracy. Wszystko większe — dekomponować. Efekt uboczny: programista czuje postęp, zamykając 2-3 zadania tygodniowo zamiast jednego gigantycznego. To zwiększa motywację i przewidywalność terminów.

Błąd 2: brak Kryteriów Akceptacji. Programista zrobił funkcję, tester sprawdził — wszystko ok. Menedżer: „A gdzie przycisk edycji?” — „W zadaniu nie napisano”. Bez AC każda strona rozumie zadanie po swojemu. Efekt: przerabianie, konflikty, zerwane terminy. AC — kontrakt: jeśli w zadaniu nie ma kryteriów — nie jest gotowe do sprintu. Na groomingu pierwszym krokiem jest sprawdzenie obecności AC. Jeśli AC nie ma — zadanie wraca do dopracowania przez Product Managera.

Błąd 3: zapominanie o Tech Debt. Zespół robi tylko Feature-zadania sprint za sprintem. Po pół roku: kompilacja trwa 15 minut, Gradle jest przestarzały o 3 główne wersje, testy padają na CI z powodu deprecation. Rozwiązanie: rezerwować 20% czasu zespołu na Tech Debt (praktyka Google SRE „SLO-based error budget”). Zakładajcie co najmniej jedno Tech Debt zadanie na każdy Feature-sprint. Proporcja: na każde 3 Feature-zadania — 1 Tech Debt lub Bug. Zapobiega to narastaniu długu technicznego i utrzymuje szybkość programowania.