Úkol a ticket — co to je, systémy sledování a práce s úkoly

Co je to úkol a ticket?

Úkol (z angl. task) — jednotka práce zaznamenaná v systému sledování. Obsahuje popis, prioritu (Critical, High, Medium, Low), řešitele, termín a status. V mobilním vývoji může být úkolem „Přidání profilové obrazovky s avatarem”, „Implementace stránkování feedu” nebo „Aktualizace verze targetSdk na 35”. Každý úkol je vázán na projekt, sprint a konkrétního vývojáře nebo tým.

Ticket (z angl. ticket) — širší entita. Ticketem může být hlášení chyby („Aplikace padá při otáčení obrazovky na Android 14”), žádost o funkci („Přidání podpory tmavého režimu”), kontaktování technické podpory („Push oznámení nepřichází”) nebo úkol od manažera („Příprava reportu o crash rate za měsíc”). Rozdíl mezi úkolem a ticketem je nejasný: v Jire jsou oba pojmy sjednoceny v Issue. Klíčový rozdíl: úkol je vždy práce s řešitelem, ticket může být žádost bez konkrétního řešitele do okamžiku triáže.

Ve Scrum a Kanban jsou úkoly hlavním prvkem backlogu. Každý úkol by měl splňovat kritérium INVEST (Independent, Negotiable, Valuable, Estimable, Small, Testable). Nezávislé úkoly lze realizovat v libovolném pořadí. Odhadnutelné — tým může odhadnout pracnost. Malé — vejdou se do jednoho sprintu. Testovatelné — mají jasná akceptační kritéria. Velké úkoly (epicy) se dělí na menší části, dokud nejsou splněna všechna kritéria.

Typy úkolů v mobilním vývoji

Feature — nová funkcionalita aplikace. Příklad: „Obrazovka přihlášení pomocí biometrie (Face ID / Touch ID)”. Feature úkoly jsou vždy vázány na user story a mají Akceptační kritéria. Odhad — v story points (1, 2, 3, 5, 8, 13). Bug — defekt nalezený v procesu vývoje nebo testování. Priorita bug ticketu se určuje podle severity (crash → Critical, UI-bug → Medium, překlep → Low). V mobilním vývoji je crash rate nad 0,1% kritická chyba vyžadující okamžitou opravu.

Tech Debt / Chore — technické úkoly bez viditelného efektu pro uživatele: aktualizace knihoven (Dependency Bump), refaktorování (Migrace z ViewPager na ViewPager2), nastavení CI/CD, psaní testů. Tech Debt úkoly jsou často podceňovány, i když podle údajů Stripe 2025 jde až 30% času mobilního týmu na údržbu a splácení technického dluhu. Ignorování Tech Debt vede k nárůstu počtu chyb a zpomalení vývoje nových funkcí.

Další typy: Spike (výzkumný úkol — studium nové technologie, napsání POC), Task (jakákoli práce nesouvisející s kódem — dokumentace, revize designu), Improvement (zlepšení stávající funkcionality — optimalizace doby načítání obrazovky). V Jire se typy issues nastavují podle projektu. Standardní sada pro mobilní tým: Story, Bug, Task, Improvement, Epic. Epic — velké téma spojující několik příběhů. Příklad: „E-commerce: košík a dokončení objednávky”.

Životní cyklus úkolu: od vytvoření do uzavření

Open (To Do) — úkol vytvořen, ale nezahájen. Obsahuje popis, Akceptační kritéria, prioritu. V tomto statusu by měl úkol projít groomingem (upřesnění a odhad) před vstupem do sprintu. In Progress — vývojář zahájil práci. V mobilním vývoji je důležité propojit commity a pull requesty s úkolem: v Jire přes Smart Commits (APP-123 #comment oprava chyby), v GitHub/GitLab pomocí klíčových slov v popisu PR (Closes APP-123).

In Review — kód odeslán k revizi. Automatické kontroly: CI (Gradle build, lint, unit testy), SonarQube (kvalita kódu), Danger (changelog, testy). Vývojář nemůže vzít další úkol, dokud je aktuální v Review — to zabraňuje multitaskingu. QA / Testing — tester kontroluje na reálných zařízeních (Android — různé verze OS a velikosti obrazovky, iOS — různé modely iPhone). Pokud jsou nalezeny chyby, úkol se vrací do In Progress s komentářem.

Done (Closed) — úkol dokončen: kód sloučen do main/master, prošel testováním, připraven k vydání. Některé týmy přidávají status Deployed — úkol se dostane k uživateli až po vydání buildu v obchodech. Důležité je uzavírat úkoly s komentářem o výsledku: jaká verze, jaký PR, jaké metriky se změnily. Podle údajů Linear (2025) se týmy, které uzavírají úkoly s popisem výsledku, vracejí ke stejným úkolům o 40% méně často.

Životní cyklus může zahrnovat status Blocked — úkol nelze provést kvůli externí závislosti (čekáme na design, odpověď z backendu, schválení manažera). Blokované úkoly by měly mít komentář s důvodem a datem příští kontroly. Týdenní revize blokovaných úkolů pomáhá identifikovat systémová zpoždění v procesu vývoje. Blokátory delší než 2 týdny vyžadují eskalaci na úroveň produktového manažera.

Systémy sledování úkolů

Jira — průmyslový standard pro týmy od 10 lidí. Podporuje Scrum a Kanban tabule, pokročilé nastavení workflow, vlastní pole, automatizace, integraci s Bitbucket/GitHub. Nevýhody: nadbytečnost pro malé týmy, pomalé rozhraní, složitá konfigurace. Pro mobilní projekty se Jira konfiguruje pomocí: pluginu Mobile-specific fields (Platform, OS version, Device model), integrace s TestFlight a Firebase Test Lab, automatizace vytváření release buildů. Jira — volba korporátních projektů s byrokratickými procesy.

Linear — moderní tracker pro produktové týmy. Rychlé rozhraní, prvotřídní podpora klávesových zkratek, vestavěný Cycle (obdoba sprintu), integrace s GitHub a Slack. Výhody: rychlost vytváření úkolů přes CMD+K, automatické rozdělení do fází (Triaged → Backlog → Upcoming → Current → Completed), vestavěná dokumentace a roadmaps. Linear volí startupy a produktové týmy, které oceňují rychlost práce. V roce 2025 používá Linear 40% nových mobilních projektů.

Trello — jednoduchá kanban tabule pro malé týmy (2-5 lidí). Karty s kontrolními seznamy, štítky, termíny. Nevýhoda: žádné sprinty, omezená analytika, obtížné škálování. YouGile — ruský analog Trello s kanban tabulemi, chatem a videohovory. Asana — tracker zaměřený na projekty a časové osy. Výběr trackeru závisí na velikosti týmu, rozpočtu a preferencích: Jira pro enterprise, Linear pro produktové týmy, Trello/YouGile pro startupy. Důležité: nástroj by měl být jednotný pro celý tým — designéři, vývojáři, testeři, manažeři pracují v jednom systému.

Nejlepší praktiky vedení úkolů

Pište Akceptační kritéria — akceptační kritéria by měla být konkrétní a ověřitelná. Špatně: „Přihlašovací obrazovka funguje”. Dobře: „Uživatel zadá email a heslo, stiskne Přihlásit. Pokud jsou údaje správné — přechod na hlavní obrazovku. Pokud nesprávné — zobrazí se chyba „Nesprávný email nebo heslo””. Akceptační kritéria (AC) jsou smlouvou mezi vývojářem, testerem a produktovým manažerem. Bez AC úkol nesplňuje Definition of Ready (DoR) a neměl by vstupovat do sprintu.

Propojujte vše. Commity, PR, testovací scénáře, designové makety (Figma), diskuse ve Slack — vše by mělo být propojeno s úkolem. V Jire se to dělá pomocí odkazů v komentářích, v Linear — přes automatické propojení PR. Pravidlo jednoho kliknutí: od úkolu k designu/kódu/testům — ne více než jedno kliknutí. Vývojář otevře úkol a okamžitě vidí maketu ve Figma, odkaz na PR a testovací scénáře. To zrychluje onboarding nových členů týmu o 30% podle údajů Linear (2025).

Nevytvářejte úkoly-přízraky. Úkol bez popisu, bez AC a bez priority je odpad. Pokud si na denním standupu nikdo nepamatuje, proč byl úkol vytvořen — je třeba ho smazat nebo upřesnit. Pravidlo 48 hodin: pokud byl úkol ve statusu In Progress bez aktivity po dobu 48 hodin — vývojář by měl zanechat komentář o důvodech zpoždění. Podle údajů Jira (2025) se 60% úkolů nečinných déle než 3 dny nakonec uzavře bez provedení.

Dekompozice úkolů: epicy, user story a podúkoly

Epic — velká funkční oblast spojující několik příběhů. Příklad: „Onboarding uživatele” zahrnuje „Úvodní obrazovku”, „Výběr zájmů”, „Nahrání avataru”, „Nastavení oznámení”. User Story — úkol z pohledu uživatele. Formát: „Jako [role], chci [akce], abych [hodnota]”. Příklad: „Jako uživatel, chci se přihlásit pomocí biometrie, abych nemusel pokaždé zadávat heslo”. User Story píše produktový manažer nebo vlastník produktu.

Podúkol (Sub-task) — dekompozice technické práce uvnitř Story / Task. Příklad pro Story „Profilová obrazovka”: Sub-task 1: Vytvoření UI obrazovky (XML / SwiftUI), Sub-task 2: Propojení s ViewModel, Sub-task 3: Napsání unit testů, Sub-task 4: Snapshot testy, Sub-task 5: UI testy (Espresso / XCUITest). Pravidlo dekompozice: každý podúkol je dokončen za 1-2 dny. Pokud vývojář odhaduje podúkol déle — dělíme dále. Podúkoly jsou interní technikou týmu, nejsou viditelné v produktovém backlogu. Součet odhadů podúkolů se nemusí rovnat odhadu rodičovské Story (část práce — komunikace, code review, testování).

Pyramida dekompozice: Epic (Kvartál / Pololetí) → Feature / Story (Sprint) → Task (1-3 dny) → Sub-task (Několik hodin). Technika INVEST pomáhá kontrolovat kvalitu dekompozice. Pokud úkol není Independent (závisí na jiných) — je to signál, že dekompozice je nesprávná. Pokud úkol není Small (více než 8 story points) — je třeba dělit dále. Běžný vzor: Epic → 5-15 Stories → každá Story → 3-8 Sub-tasků. Konečný odhad epiku = součet odhadů Stories, ale první sprint obvykle vykazuje odchylku 20-30% v odhadech.

Typické chyby při práci s úkoly

Chyba 1: příliš velké úkoly. Úkol na 2 týdny práce je epic, který je třeba dekomponovat. Velké úkoly nelze začlenit do denního sledování, visí v In Progress týdny. Pravidlo: maximální velikost úkolu — 2-3 dny práce. Vše větší — dekomponovat. Vedlejší efekt: vývojář cítí pokrok uzavíráním 2-3 úkolů týdně místo jednoho obřího. To zvyšuje motivaci a předvídatelnost termínů.

Chyba 2: absence Akceptačních kritérií. Vývojář udělal funkci, tester zkontroloval — vše v pořádku. Manažer: „A kde je tlačítko pro úpravu?” — „V úkolu není napsáno”. Bez AC každá strana chápe úkol po svém. Výsledek: přepracování, konflikty, zmeškané termíny. AC — smlouva: pokud v úkolu nejsou kritéria — není připraven na sprint. Při groomingu se nejprve kontroluje přítomnost AC. Pokud AC chybí — úkol se posílá k přepracování Product Managerovi.

Chyba 3: zapomínáme na Tech Debt. Tým dělá pouze Feature úkoly sprint za sprintem. Po půl roce: kompilace trvá 15 minut, Gradle je zastaralý o 3 hlavní verze, testy padají na CI kvůli deprecation. Řešení: rezervovat 20% času týmu na Tech Debt (praxe Google SRE „rozpočet chyb založený na SLO”). Založte alespoň jeden Tech Debt úkol na každý Feature sprint. Poměr: na každé 3 Feature úkoly — 1 Tech Debt nebo Bug. To zabraňuje hromadění technického dluhu a udržuje rychlost vývoje.