Gantt și Jira: cum țineți planul și munca aliniate

În multe companii proiectul există de două ori. Planul, cu faze, dependențe și date de livrare, se află într-o diagramă Gantt pregătită de managerul de proiect. Munca, cu tichete, sprinturi și atribuiri, se află în Jira. Atâta timp cât cele două rămân separate, cineva trebuie să copieze manual progresul de la unul la celălalt, iar datele planului se învechesc repede.

Acest articol explică de ce Jira singur nu este suficient pentru planificare, cum funcționează sincronizarea bidirecțională dintre Planitude și Jira Cloud și ce limite merită cunoscute înainte de activare.

Două instrumente, două întrebări diferite#

Jira răspunde la întrebarea la ce lucrează echipa chiar acum? Backlog-urile, tablourile și sprinturile sunt construite pentru asta. Un plan răspunde la o altă întrebare: când vom termina și care sarcini nu își permit nicio întârziere?

Pentru a răspunde la a doua întrebare sunt necesare durate, dependențe cu anticipare și întârziere (lead și lag), calendare cu sărbători, constrângeri și un calcul care propagă fiecare modificare în aval. Dacă instalarea noului server întârzie trei zile, testarea, instruirea și punerea în producție trebuie să se mute automat, iar managerul de proiect trebuie să știe imediat dacă data de livrare se mai menține.

Ce îi lipsește lui Jira pentru planificare#

Jira nu este lipsit de instrumente de planificare. Cronologia (timeline) afișează dependențele dintre elementele legate prin tipul de legătură „Blocks” și, când datele a două elemente legate se suprapun, linia dependenței devine roșie pentru a semnala o posibilă întârziere^[1]. Conform paginii de prețuri Atlassian, dependențele sunt gestionate în cadrul unui singur proiect în planurile Free și Standard și între proiecte în planul Premium^[2].

Un avertisment nu este însă o recalculare: datele rămân așa cum au fost introduse, iar calea critică nu se numără printre funcțiile descrise. Rezultatul este că planul trăiește în altă parte, într-un fișier sau într-un alt instrument, și se desincronizează. Pentru o comparație completă a celor două instrumente, consultați Planitude vs Jira.

Cum funcționează sincronizarea bidirecțională#

Integrarea conectează un proiect Planitude cu un proiect Jira Cloud. Autentificarea folosește Atlassian OAuth 2.0: Planitude nu vă vede niciodată parola, stochează token-urile criptat și le reînnoiește cu token-urile de reîmprospătare rotative oferite de Atlassian, care expiră după 90 de zile de inactivitate^[3].

La prima conectare alegeți alinierea inițială:

1. Trimiteți planul în Jira: se creează un issue pentru fiecare sarcină și o legătură „Blocks” pentru fiecare dependență;
2. Importați din Jira: fiecare issue existent devine o sarcină la finalul planului, cu data de început, durata, progresul și persoana responsabilă;
3. Ambele: mai întâi importul, apoi se trimit sarcinile care nu există încă în Jira.

De atunci înainte, modificările circulă în ambele sensuri. De la Planitude la Jira, fiecare modificare a planului este detectată și trimisă în câteva secunde, indiferent de unde provine: grila, diagrama Gantt, un import sau asistentul AI. De la Jira la Planitude, modificările sosesc prin webhook-urile înregistrate de integrare, pe care Planitude le reînnoiește înainte de expirarea de 30 de zile stabilită de Atlassian^[4], iar o verificare la fiecare cinci minute preia eventualele evenimente ratate.

Sarcinile recapitulative pot rămâne doar în Planitude sau pot deveni Epic-uri, cu sarcinile subordonate ca issue-uri copil.

Cine deține ce: regula câmpurilor#

O sincronizare fiabilă are nevoie de o regulă simplă pentru fiecare câmp. În Planitude este aceasta:

Logica reflectă munca reală: planul decide când, echipa decide cât de avansată este o sarcină și cine o execută. Starea este tradusă în procent printr-o hartă editabilă: pe categorii, de făcut este 0%, în desfășurare este 50%, finalizat este 100%. Dacă o sarcină este deja la 30% și issue-ul ei trece în „In Progress”, progresul ei nu este suprascris cu un 50% fix.

Persoanele sunt asociate automat după e-mail, atunci când utilizatorul Jira îl face vizibil; în caz contrar, alegeți manual corespondența pe pagina integrării.

Dependențe, conflicte și ștergeri#

Dependențe. Legăturile final-început devin legături „Blocks”: predecesorul îl blochează pe succesor. Legăturile început-început, final-final și început-final nu au echivalent în Jira și rămân doar în Planitude. Legăturile „Blocks” adăugate manual în Jira nu sunt nici importate, nici șterse.

Date modificate în Jira. Deoarece datele sunt calculate de plan, o dată modificată în Jira este readusă la valoarea din plan, iar modificarea respinsă apare în jurnalul integrării. Pentru a muta o sarcină, o mutați în plan: motorul recalculează și toate sarcinile care depind de ea.

Conflicte. Pentru fiecare câmp, Planitude compară trei valori: ultima valoare convenită, valoarea curentă din plan și valoarea curentă din Jira. Dacă doar una dintre părți s-a modificat, modificarea merge la cealaltă. Dacă ambele s-au modificat la valori diferite, câștigă proprietarul câmpului, iar conflictul este înregistrat cu ambele valori. Regula depinde doar de date, nu de ceasurile celor două servere.

Ștergeri. Niciuna dintre părți nu șterge nimic în cealaltă. O sarcină ștearsă în Planitude lasă issue-ul în Jira cu eticheta planitude-unlinked; un issue șters în Jira lasă sarcina în plan, iar pagina oferă două acțiuni: recrearea lui în Jira sau oprirea sincronizării.

Conectarea Jira pas cu pas#

1. Deschideți proiectul în Planitude și alegeți ⋯ › Integrări › Jira.
2. Faceți clic pe Conectează Jira și acordați accesul pe ecranul de consimțământ Atlassian.
3. Dacă contul dumneavoastră vede mai multe site-uri, alegeți-l pe cel potrivit, apoi proiectul Jira.
4. Verificați opțiunile: tipul implicit de issue, sarcinile recapitulative ca Epic-uri sau nu, câmpul pentru data de început, eticheta pentru issue-urile create de Planitude.
5. Alegeți alinierea inițială: trimitere, import sau ambele.
6. Verificați secțiunea Persoane și completați eventualele corespondențe negăsite după e-mail.

Planitude scrie în Jira în numele persoanei care a conectat proiectul, deci aceasta are nevoie de permisiunile Jira pentru a răsfoi proiectul, a crea, a edita, a atribui și a lega issue-uri și a le face tranziții. Proprietarii și editorii proiectului Planitude pot configura integrarea; persoanele cu acces doar de citire văd numai starea ei. Celelalte integrări disponibile sunt descrise pe pagina Integrări.

Limite cunoscute#

• Doar Jira Cloud: Jira Data Center și Server nu sunt acceptate.
• Doar dependențe final-început; o singură persoană responsabilă per issue (persoana cu cele mai multe unități pe sarcină).
• Date la granularitate de zi: orele rămân în Planitude.
• Atlassian permite unei aplicații OAuth 5 webhook-uri per utilizator și per site^[4]: după al cincilea proiect conectat de aceeași persoană pe același site, modificările din Jira sosesc prin verificarea la cinci minute.
• Cu opțiunea „doar sarcini terminale”, o sarcină care devine recapitulativă este tratată ca eliminată, iar issue-ul ei primește eticheta planitude-unlinked.

Întrebări frecvente#