Cele mai bune practici și greșeli tipice ale fluxurilor de lucru Jira

Despre

conţinut

  • Acasă
  • Vita
  • acreditări
  • Servicii de consultanță
  • Antrenament în casă
  • Antrenamente deschise
  • a lua legatura
  • imprima

Fluxuri de lucru Jira: cele mai bune practici și greșeli tipice

Când merg la o companie, am întotdeauna o listă cu cele mai bune practici și greșeli tipice pentru începători pentru Jira. Această listă este foarte apreciată de clienții mei, deoarece erorile pot fi adesea evitate și fiecare eroare este evaluată critic, în special în faza inițială a unui nou sistem. În următoarea serie de articole voi împărtăși o parte din această listă cu comunitatea Jira și aștept cu nerăbdare noi sugestii și comentarii.

cele

Suprainginerie

Fluxurile de lucru Jira sunt de obicei modelate pe procese de lucru reale într-o companie. Această abordare este corectă până acum - dar ar trebui făcut un echilibru sensibil între cartarea fluxului de lucru real și ușurința maximă în Jira. Acest pas este unul dintre cele mai complexe și necesită o anumită experiență a posibilităților și limitărilor Jira. Din experiența mea, regula de aur pentru fluxurile de lucru în Jira este:

Pe cât este necesar, cât mai puțin posibil!

(Sau, de asemenea, principiul „KISS”: păstrați-l scurt și simplu). Cu alte cuvinte: cât mai mulți pași ai fluxului de lucru, dar cât mai puțini. Care dintre etapele reale de lucru sunt necesare ca etapă a fluxului de lucru în Jira nu poate fi răspuns în principiu, deoarece trebuie întotdeauna să se ia în considerare circumstanțele specifice ale companiei și ale angajaților. Cu toate acestea, există câteva întrebări care pot fi utilizate pentru a verifica dacă este necesar un pas:

  • Există o schimbare de responsabilitate?
  • Poate doar anumite persoane sau grupuri de utilizatori să efectueze acest pas?
  • Notificările trebuie trimise?
  • Trebuie să pot filtra pentru acest pas, adică poate vedea o prezentare generală a tuturor proceselor din starea conectată?

Cu cât răspunsul la aceste întrebări este mai mare cu „da”, cu atât acest pas ar trebui să fie mai sigur în Jira. Adesea, prea mulți pași sunt încorporați într-un flux de lucru în faza de concepție, ceea ce duce la suprainginerie menționată la început. Un astfel de flux de lucru este corect din punct de vedere tehnic, dar complexitatea acestuia provoacă neînțelegere în rândul utilizatorilor - rezultatul este funcționarea incorectă și respingerea noului instrument. Un exemplu negativ:

Compania fictivă RequirementsUnlimited ar dori să implementeze managementul cerințelor interne cu Jira. Prin urmare, creează un flux de lucru care reflectă procesul tehnic atunci când este înregistrată o cerință. Primii 4 pași pentru tipul de activitate „Cerință” sunt: ​​Deschis, În coordonare, Aprobat, Programat.

Sună destul de bine până acum. Cu toate acestea: pentru a accepta o nouă cerință, sunt necesari 4 pași ai fluxului de lucru, prin care utilizatorul trebuie să „facă clic” în caz de îndoială. Deci, aici ar trebui să verificați dacă toți pașii sunt cu adevărat necesari. Cu RequirementsUnlimited există de ex. singura diferență dintre starea „Aprobat” și „Programat” este că procesul este atribuit unei versiuni specifice (în Jira, o versiune soluție) în această tranziție de stare. Când a fost întrebat de ce este necesară o stare separată pentru acest lucru, managerul de proiect răspunde: „Vreau să pot filtra ce procese sunt recunoscute, dar nu sunt încă planificate!”. Cu aceste informații, puteți recomanda acum cu o conștiință curată să ștergeți pasul „Programat”: Puteți utiliza, de asemenea, un filtru pentru a afișa toate procesele care au starea „Aprobat” și nu sunt atribuite niciunei versiuni de soluții. Dacă opțiunea de filtrare a fost singura cerință pentru pasul „Programat”, aceasta poate fi ștearsă și filtrele existente pot fi ajustate.

În exemplu, poate suna banal la început dacă fluxul de lucru are un pas mai mult sau mai puțin - în fluxuri de lucru mai mari și mai complexe, cu toate acestea, fiecare pas suplimentar creează un nou nivel de complexitate și dependențe. Menținerea acestui nivel scăzut este scopul unui flux de lucru curat și ușor de utilizat.

Denumire greșită la tranzițiile de stare

O sursă populară de utilizare slabă a fluxurilor de lucru este denumirea tranzițiilor de stare. La crearea unui flux de lucru funcțional, există tendința de a denumi tranzițiile de stare în funcție de ceea ce s-a întâmplat în ultima stare, în loc de ceea ce se va întâmpla în următoarea stare. Trebuie să știți că numele tranzițiilor de stare sunt afișate utilizatorului ca pași disponibili ai fluxului de lucru:

În cele mai multe cazuri, utilizatorii Jira știu ce tocmai s-a întâmplat cu procesul și, în schimb, vor să vadă în afișarea pașilor disponibili la ce stare ulterioară va duce fiecare pas. Un exemplu negativ:

O tranziție de statut „Votarea s-a încheiat” duce inevitabil la întrebările „Ce înseamnă asta?”, „Ce se întâmplă dacă fac clic pe ea acum?” Rezultatul este încă o dată incertitudine și o funcționare incorectă. În acest exemplu, tranziția de stare ar trebui să fie mai bine după cum urmează:

Cu denumirea „Proces de proces”, utilizatorul poate vedea imediat starea ulterioară în care îl va conduce acțiunea sa. Prin urmare, regula pentru denumirea tranzițiilor de stare este: Numele unei tranziții de stare trebuie să indice starea ulterioară în care se desfășoară procesul.

Acestea au fost doar două dintre numeroasele exemple care ar trebui luate în considerare la proiectarea și configurarea fluxurilor de lucru în Jira (printre altele: utilizarea stării rezolvate și închise, tranziții de stare globală, atribuirea condițiilor fluxului de lucru și multe altele). În acest moment, desigur, întrebarea mea finală: ce erori sau probleme ați întâmpinat când ați creat fluxuri de lucru? Aștept cu nerăbdare comentariul tău!

Articole similare

28 noiembrie 2012 de Sebastian Höhne
Categorii: Jira | Tags: Cele mai bune practici, Jira, Workflow | 7 comentarii