Managementul proiectelor cu agenți AI: de la obiectiv la sarcini verificabile
Seria II: De la infrastructură la proiecte agentice în producție. Episodul 06 din 20.
În episodul anterior am transformat infrastructura portalului B2B fictiv în configurații verificabile. Acum trebuie să organizăm munca astfel încât oamenii și agenții AI să știe ce rezultat urmăresc, ce pot modifica și cum demonstrează că au terminat. Decizia principală este simplă: nu delegăm o intenție vagă, ci o sarcină delimitată, cu responsabil pentru acceptare și dovezi observabile.
Un agent poate propune un plan, poate lucra în repository și poate raporta blocaje. Nu stabilește singur prioritatea comercială, termenul promis clientului sau compromisul acceptabil între viteză, cost și risc. Aceste decizii rămân la persoanele care răspund de produs și proiect.
De la obiectiv la rezultat verificabil
Obiectivul descrie schimbarea utilă, nu activitatea tehnică. Pentru portal, formularea „implementăm încărcarea documentelor” este prea largă. O variantă mai bună ar fi: „un furnizor autorizat poate atașa un document PDF unei solicitări, iar operatorul poate vedea fișierul și evenimentul de audit”.
Din obiectiv stabilim și limitele. În scenariul nostru ipotetic, prima versiune nu extrage automat conținutul documentului, nu acceptă alte formate și nu migrează arhiva veche. Aceste excluderi reduc interpretările diferite și împiedică agentul să extindă lucrarea fără o decizie.
Un backlog este lista ordonată a lucrărilor cunoscute. Nu este o colecție în care toate elementele au aceeași prioritate. Ordinea trebuie să reflecte valoarea, riscul și dependențele. Ghidul Scrum definește Product Goal ca ținta față de care se planifică, iar backlogul descrie ce ar putea îndeplini acea țintă. O firmă nu trebuie să adopte Scrum integral pentru a folosi ideea utilă: întâi clarificăm rezultatul, apoi ordonăm lucrările.
Un backlog mic, ordonat după dependențe
Pentru funcționalitatea de încărcare, echipa poate porni cu următoarele pachete:
Ordine | Sarcină | Depinde de | Dovadă principală |
|---|---|---|---|
1 | Confirmarea regulilor de acces și retenție | decizie de produs | decizie înregistrată și cazuri aprobate |
2 | Contractul API pentru încărcare | sarcina 1 | schemă revizuită și exemple de erori |
3 | Stocarea fișierului și evenimentul de audit | sarcina 2 | teste automate și jurnal verificat |
4 | Interfața de încărcare și afișare | sarcinile 2 și 3 | scenariu cap-coadă trecut |
5 | Activarea controlată | sarcinile 3 și 4 | plan de revenire și verificare în mediul țintă |
O dependență arată că o sarcină este blocată de alta. GitHub Issues, de exemplu, permite sub-sarcini și relații de tip „blochează”, dar instrumentul este secundar. O tablă cu multe coloane nu repară o ordine greșită. Dacă regula de acces nu este decisă, agentul nu ar trebui să inventeze rolurile și să continue cu implementarea.
Fișa de sarcină pentru om sau agent
Aceeași fișă trebuie să poată fi citită de un coleg și de un agent de dezvoltare. O variantă minimă conține:
- rezultatul dorit: comportamentul observabil după finalizare;
- contextul autorizat: documente, fișiere și decizii care sunt surse de adevăr;
- ce intră și ce nu intră: limitele modificării;
- dependențe: decizii, servicii sau sarcini care trebuie încheiate înainte;
- criterii de acceptare: condiții concrete pe care rezultatul trebuie să le îndeplinească;
- verificări obligatorii: teste, analiză statică, scenarii manuale sau capturi relevante;
- responsabil pentru acceptare: persoana care compară rezultatul cu nevoia;
- condiții de oprire: situații în care agentul cere clarificare în loc să presupună.
GitHub recomandă pentru agentul său de programare probleme clar descrise, criterii de acceptare complete și indicații despre zona de cod. Recomandarea este specifică produsului, dar principiul este general: o sarcină executabilă reduce spațiul de interpretare. Nu înseamnă că trebuie prescrisă fiecare linie de cod. Agentul poate propune soluția tehnică în limitele arhitecturii și poate explica alternativele.
Pentru sarcina de stocare, un criteriu verificabil ar fi: „un utilizator fără drept de acces primește refuz, iar fișierul nu este salvat”. „Să fie sigur” nu este suficient, deoarece nu indică un comportament care poate fi testat.
Criterii de acceptare și Definition of Done
Criteriile de acceptare aparțin unei anumite cerințe. Ele descriu exemplele și condițiile care trebuie demonstrate. Definition of Done, adică definiția comună a lucrului finalizat, se aplică tuturor schimbărilor relevante: cod revizuit, teste trecute, documentație actualizată, fără secrete în commit și cu procedură de lansare, de exemplu.
Ghidul Scrum definește Definition of Done drept descrierea formală a stării în care rezultatul îndeplinește măsurile de calitate ale produsului. Pentru echipa portalului, „agentul a terminat” este doar o afirmație de progres. Starea devine „gata pentru acceptare” când există diff-ul, rezultatele verificărilor și explicația deciziilor. Devine „finalizat” numai când responsabilul confirmă criteriile și definiția comună.
Studiul SWE-bench arată de ce problema nu se reduce la generarea de cod: sarcini reale pot necesita coordonarea schimbărilor în mai multe funcții, clase și fișiere, într-un mediu de execuție. Benchmarkul verifică rezolvarea unor probleme asociate cu issue-uri și modificări reale, dar nu reprezintă o garanție pentru proiectul unei firme. Lecția practică este că evaluarea trebuie legată de repository, teste și comportamentul cerut, nu de cât de convingător sună raportul agentului.
Ce poate actualiza agentul
Agentul de dezvoltare poate propune descompunerea lucrării, poate lega modificarea de sarcină, poate marca verificările executate și poate semnala un blocaj. Dacă descoperă o incompatibilitate de API, actualizează starea cu dovezi și cere o decizie. Nu schimbă singur scopul, nu declară acceptată propria lucrare și nu mută un termen comercial.
Separăm acest rol de agentul integrat în portal. Agentul din aplicație ar putea, într-un episod ulterior, clasifica solicitări sau extrage informații din documente. El este o funcționalitate a produsului, cu propriile cerințe și riscuri. Agentul de dezvoltare lucrează la proiect și livrează modificări pentru review. Confuzia dintre cele două duce la permisiuni, indicatori și responsabilități greșite.
Ritmul de control pentru o echipă mică
O firmă mică nu are nevoie de ceremonii grele. Poate folosi un ritm scurt:
- responsabilul de produs confirmă obiectivul, limitele și ordinea;
- agentul sau dezvoltatorul propune planul și identifică dependențele;
- echipa acceptă planul doar ca ipoteză de execuție, nu ca estimare garantată;
- lucrarea produce artefacte și dovezi pe o ramură separată;
- o persoană verifică rezultatul și decide acceptarea, corecția sau oprirea.
Termenele se estimează separat, folosind capacitatea reală a echipei și necunoscutele descoperite. Un agent care execută repede o etapă nu elimină timpul pentru clarificări, integrare, review sau remedierea efectelor secundare.
Piesa adăugată proiectului este fișa reutilizabilă de sarcină și backlogul ordonat după dependențe. Ele transformă delegarea într-un contract de lucru verificabil. În episodul următor vom pregăti repository-ul astfel încât agenții să găsească instrucțiunile, arhitectura și mediile de test necesare acestor sarcini.
Surse
- GitHub Docs, Best practices for using GitHub Copilot to work on tasks, pentru delimitarea sarcinilor, criteriile de acceptare și contextul de repository, documentație consultată la 8 octombrie 2026.
- GitHub Docs, Planning and tracking work for your team or project, pentru sub-sarcini și dependențe.
- Schwaber și Sutherland, The 2020 Scrum Guide, versiunea oficială curentă indicată de autori, pentru Product Goal, backlog și Definition of Done.
- Jimenez et al., SWE-bench: Can Language Models Resolve Real-world GitHub Issues?, ICLR 2024, pentru complexitatea evaluării sarcinilor software reale.
Următorul pas
Vrei să transformi o idee într-un backlog pe care oamenii și agenții îl pot executa și verifica? Discută cu echipa i8.
