Sarcină și ticket — ce este, sisteme de urmărire și lucrul cu sarcini

Ce este o sarcină și un ticket?

Sarcină (din engl. task) — o unitate de lucru înregistrată într-un sistem de urmărire. Conține descriere, prioritate (Critical, High, Medium, Low), executant, termen limită și status. În dezvoltarea mobilă, o sarcină poate fi „Adăugarea ecranului de profil cu avatar”, „Implementarea paginării feedului” sau „Actualizarea versiunii targetSdk la 35”. Fiecare sarcină este legată de un proiect, sprint și un dezvoltator sau echipă specifică.

Ticket (din engl. ticket) — o entitate mai largă. Un ticket poate fi un raport de bug („Aplicația se blochează la rotirea ecranului pe Android 14”), o cerere de funcție („Adăugarea suportului pentru tema întunecată”), o sesizare la suportul tehnic („Notificarea push nu ajunge”) sau o sarcină de la manager („Pregătirea raportului de crash rate pe lună”). Diferența dintre sarcină și ticket este neclară: în Jira ambele concepte sunt unite în Issue. Diferența cheie: sarcina este întotdeauna o muncă cu executant, ticketul poate fi o cerere fără executant specific până la triaj.

În Scrum și Kanban, sarcinile sunt elementul principal al backlogului. Fiecare sarcină trebuie să îndeplinească criteriul INVEST (Independent, Negotiable, Valuable, Estimable, Small, Testable). Sarcinile independente pot fi implementate în orice ordine. Estimabile — echipa poate estima volumul de muncă. Mici — se încadrează într-un singur sprint. Testabile — au criterii de acceptare clare. Sarcinile mari (epicele) se divid în părți mai mici până la îndeplinirea tuturor criteriilor.

Tipuri de sarcini în dezvoltarea mobilă

Feature — o nouă funcționalitate a aplicației. Exemplu: „Ecran de autentificare prin biometrie (Face ID / Touch ID)”. Sarcinile Feature sunt întotdeauna legate de o user story și au Criterii de Acceptare. Estimare — în story points (1, 2, 3, 5, 8, 13). Bug — un defect găsit în procesul de dezvoltare sau testare. Prioritatea ticketului bug se determină prin severity (crash → Critical, UI-bug → Medium, greșeală de tipar → Low). În dezvoltarea mobilă, o rată de crash peste 0.1% este un bug critic și necesită remediere imediată.

Tech Debt / Chore — sarcini tehnice fără efect vizibil pentru utilizator: actualizarea bibliotecilor (Dependency Bump), refactorizare (Migrarea de la ViewPager la ViewPager2), configurarea CI/CD, scrierea testelor. Sarcinile Tech Debt sunt adesea subestimate, deși conform datelor Stripe 2025, până la 30% din timpul echipei mobile este dedicat întreținerii și achitării datoriei tehnice. Ignorarea Tech Debt duce la creșterea numărului de buguri și încetinirea dezvoltării noilor funcții.

Tipuri suplimentare: Spike (sarcină de cercetare — studierea unei noi tehnologii, scrierea unui POC), Task (orice muncă nelegată de cod — documentație, revizuire de design), Improvement (îmbunătățirea funcționalității existente — optimizarea timpului de încărcare a ecranului). În Jira, tipurile de issues se configurează pe proiect. Setul standard pentru o echipă mobilă: Story, Bug, Task, Improvement, Epic. Epic — un subiect mare care unește mai multe story-uri. Exemplu: „E-commerce: coșul de cumpărături și finalizarea comenzii”.

Ciclul de viață al sarcinii: de la creare la închidere

Open (To Do) — sarcina este creată, dar neîncepută. Conține descriere, Criterii de Acceptare, prioritate. În acest status, sarcina trebuie să treacă prin grooming (clarificare și estimare) înainte de a intra în sprint. In Progress — dezvoltatorul a început lucrul. În dezvoltarea mobilă este important să legați commiturile și pull requesturile de sarcină: în Jira prin Smart Commits (APP-123 #comment reparare bug), în GitHub/GitLab prin cuvinte cheie în descrierea PR (Closes APP-123).

In Review — codul trimis la revizuire. Verificări automate: CI (Gradle build, lint, teste unitare), SonarQube (calitatea codului), Danger (changelog, teste). Dezvoltatorul nu poate începe următoarea sarcină cât timp cea curentă este în Review — acest lucru previne multitaskingul. QA / Testing — testerul verifică pe dispozitive reale (Android — versiuni diferite de OS și dimensiuni de ecran, iOS — diferite modele de iPhone). Dacă se găsesc buguri, sarcina revine la In Progress cu un comentariu.

Done (Closed) — sarcina finalizată: codul integrat în main/master, testat, gata de lansare. Unele echipe adaugă statusul Deployed — sarcina ajunge la utilizator doar după publicarea buildului în magazine. Este important să închideți sarcinile cu un comentariu despre rezultat: ce versiune, ce PR, ce metrici s-au schimbat. Conform datelor Linear (2025), echipele care închid sarcinile cu descrierea rezultatului revin cu 40% mai rar la aceleași sarcini.

Ciclul de viață poate include statusul Blocked — sarcina nu poate fi executată din cauza unei dependențe externe (așteptăm designul, răspunsul de la backend, aprobarea managerului). Sarcinile Blocked trebuie să aibă un comentariu cu motivul și data următoarei verificări. Revizuirea săptămânală a sarcinilor Blocked ajută la identificarea întârzierilor sistemice în procesul de dezvoltare. Blocajele mai lungi de 2 săptămâni necesită escaladare la nivelul managerului de produs.

Sisteme de urmărire a sarcinilor

Jira — standardul industriei pentru echipe de la 10 persoane. Suportă tablele Scrum și Kanban, configurarea avansată a workflowului, câmpuri personalizate, automatizări, integrare cu Bitbucket/GitHub. Dezavantaje: redundanță pentru echipe mici, interfață lentă, configurare complexă. Pentru proiecte mobile, Jira se configurează cu: pluginul Mobile-specific fields (Platform, OS version, Device model), integrarea cu TestFlight și Firebase Test Lab, automatizarea creării buildurilor de lansare. Jira — alegerea proiectelor corporative cu procese birocratice.

Linear — un tracker modern pentru echipe de produs. Interfață rapidă, suport de primă clasă pentru comenzi rapide de tastatură, Cycle încorporat (analog sprintului), integrare cu GitHub și Slack. Avantaje: viteza de creare a sarcinilor prin CMD+K, distribuirea automată pe faze (Triaged → Backlog → Upcoming → Current → Completed), documentație și roadmaps încorporate. Linear este ales de startupuri și echipe de produs care prețuiesc viteza de lucru. În 2025, 40% din noile proiecte mobile folosesc Linear.

Trello — o tablă kanban simplă pentru echipe mici (2-5 persoane). Carduri cu liste de verificare, etichete, termene. Dezavantaj: nu are sprinturi, analitică limitată, greu de scalat. YouGile — analogul rusesc al Trello cu table kanban, chat și apeluri video. Asana — tracker cu focus pe proiecte și cronograme. Alegerea trackerului depinde de mărimea echipei, buget și preferințe: Jira pentru enterprise, Linear pentru echipe de produs, Trello/YouGile pentru startupuri. Important: instrumentul trebuie să fie unitar pentru întreaga echipă — designeri, dezvoltatori, testeri, manageri lucrează într-un singur sistem.

Cele mai bune practici de gestionare a sarcinilor

Scrieți Criterii de Acceptare — criteriile de acceptare trebuie să fie concrete și verificabile. Rău: „Ecranul de autentificare funcționează”. Bine: „Utilizatorul introduce emailul și parola, apasă Autentificare. Dacă datele sunt corecte — trecerea la ecranul principal. Dacă sunt incorecte — se afișează eroarea „Email sau parolă incorectă””. Criteriile de Acceptare (AC) sunt un contract între dezvoltator, tester și product manager. Fără AC, sarcina nu îndeplinește Definition of Ready (DoR) și nu trebuie să intre în sprint.

Legătuiți totul. Commiturile, PRurile, cazurile de test, machetele de design (Figma), discuțiile din Slack — totul trebuie să fie legat de sarcină. În Jira acest lucru se face prin linkuri în comentarii, în Linear — prin legarea automată a PR. Regula unui singur click: de la sarcină la design/cod/teste — nu mai mult de un click. Dezvoltatorul deschide sarcina și vede imediat macheta în Figma, linkul PR și cazurile de test. Aceasta accelerează onboard-ingul noilor membri ai echipei cu 30% conform datelor Linear (2025).

Nu creați sarcini-fantomă. O sarcină fără descriere, fără AC și fără prioritate este gunoi. Dacă la standupul zilnic nimeni nu își amintește de ce a fost creată sarcina — trebuie ștearsă sau clarificată. Regula celor 48 de ore: dacă sarcina a fost în statusul In Progress fără activitate timp de 48 de ore — dezvoltatorul trebuie să lase un comentariu despre motivele întârzierii. Conform datelor Jira (2025), 60% din sarcinile inactive mai mult de 3 zile se închid în final fără a fi executate.

Descompunerea sarcinilor: epice, user story-uri și subsarcini

Epic — o arie funcțională mare care unește mai multe story-uri. Exemplu: „Onboardingul utilizatorului” include „Ecranul de bun venit”, „Selectarea intereselor”, „Încărcarea avatarului”, „Configurarea notificărilor”. User Story — o sarcină din perspectiva utilizatorului. Format: „Ca [rol], vreau să [acțiune] pentru a [valoare]”. Exemplu: „Ca utilizator, vreau să mă autentific prin biometrie pentru a nu introduce parola de fiecare dată”. User Story este scrisă de product manager sau de proprietarul produsului.

Subsarcină (Sub-task) — descompunerea muncii tehnice în cadrul Story / Task. Exemplu pentru Story „Ecranul de profil”: Sub-task 1: Realizarea UI al ecranului (XML / SwiftUI), Sub-task 2: Conectarea la ViewModel, Sub-task 3: Scrierea testelor unitare, Sub-task 4: Teste Snapshot, Sub-task 5: Teste UI (Espresso / XCUITest). Regula descompunerii: fiecare subsarcină se finalizează în 1-2 zile. Dacă dezvoltatorul estimează subsarcina mai mult — împărțim și mai mult. Subsarcinile sunt o tehnică internă a echipei, nu sunt vizibile în backlogul de produs. Suma estimărilor subsarcinilor nu este neapărat egală cu estimarea Story părinte (o parte din muncă — comunicare, code review, testare).

Piramida descompunerii: Epic (Trimestru / Semestru) → Feature / Story (Sprint) → Task (1-3 zile) → Sub-task (Câteva ore). Tehnica INVEST ajută la verificarea calității descompunerii. Dacă sarcina nu este Independentă (depinde de altele) — este un semnal că descompunerea este incorectă. Dacă sarcina nu este Small (mai mult de 8 story pointuri) — trebuie împărțită mai departe. Model comun: Epic → 5-15 Stories → fiecare Story → 3-8 Sub-taskuri. Estimarea finală a epicului = suma estimărilor Stories, dar primul sprint are de obicei o eroare de 20-30% în estimări.

Greșeli tipice la lucrul cu sarcinile

Greșeala 1: sarcini prea mari. O sarcină de 2 săptămâni de lucru este un epic care trebuie descompus. Sarcinile mari nu sunt potrivite pentru urmărirea zilnică, stau în In Progress săptămâni întregi. Regula: dimensiunea maximă a sarcinii — 2-3 zile de lucru. Orice mai mare — descompuneți. Efect secundar: dezvoltatorul simte progresul închizând 2-3 sarcini pe săptămână în loc de una gigantică. Aceasta crește motivația și predictibilitatea termenelor.

Greșeala 2: lipsa Criteriilor de Acceptare. Dezvoltatorul a făcut funcția, testerul a verificat — totul ok. Managerul: „Dar unde este butonul de editare?” — „În sarcină nu s-a scris”. Fără AC fiecare parte înțelege sarcina în felul său. Rezultat: refacere, conflicte, termene ratate. AC — contract: dacă în sarcină nu există criterii — nu este gata pentru sprint. La grooming, primul lucru verificat este prezența AC. Dacă AC lipsește — sarcina se trimite la revizuire Product Managerului.

Greșeala 3: uităm de Tech Debt. Echipa face doar sarcini Feature sprint după sprint. După șase luni: compilarea durează 15 minute, Gradle este învechit cu 3 versiuni majore, testele cad pe CI din cauza deprecării. Soluția: rezervați 20% din timpul echipei pentru Tech Debt (practica Google SRE „bugget de erori bazat pe SLO”). Creați cel puțin o sarcină Tech Debt pentru fiecare sprint Feature. Proporția: la fiecare 3 sarcini Feature — 1 Tech Debt sau Bug. Aceasta previne acumularea datoriei tehnice și menține viteza de dezvoltare.