![]() Stim ca Metoda Kanban poate fi utilizata in domenii diferite, cu rezultate de fiecare data extraordinare, atunci cand este aplicata corect. In acest articol mi-am propus sa arat, intr-o prima faza, cum se poate utiliza Kanban in Agile Project Management. Pentru ca nu pot ca intr-un singur articol, sa explic un proces care de multe ori se poate dovedi complex, cum este cel de Agile Project Management, am ales sa ignor pentru moment, subiecte precum: popularea backlog-ului, stabilirea produsului minim viabil (minimum viable product), estimarea sau stabilirea marimii si componentei echipei. M-am concentrat pe cei 5 pasi care asigura o aplicare Kanban rapida si eficienta. Acest lucru nu inseamna ca celelate subiecte sunt neinteresante, insa am ales sa le expun in alte articole. Sa incepem cu Imaginea de ansamblu: PRIMUL PAS: “Cartografiaza” lucrarile si fluxul de lucru Inainte de a incepe sa utilizam Kanban, este necesar sa evaluam ce tipuri de lucrari avem de efectuat, frecventa si efortul necesar. In multe echipe exista lucrari de genul: raspunsuri la cererile clientilor, dezvoltarea de cod, discutii in echipa privind specificatiile, testare, rezolvarea unor “bug-uri”, imbunatatiria unor module software, etc. Al 2-lea pas al cartografierii, este sa “punem pe hartie” pasii din cadrul fluxului de lucru ce proceseaza lucrarile, din momentul cand am luat cunostinta de ele, pana in momentul cand, din punct de vedere al clientului si echipei, o lucrare poate fi considerata finalizata. Ca si exemplu, in figura de mai jos, am reprezentat un flux de lucru pentru un proiect pe care il am in derulare. Nu este un flux de lucru care are ceva special si cred ca el se gaseste in multe proiecte de dezvoltare software. Acum ca stim tipologia lucrarilor si fluxul de lucru necesar, este momentul sa asiguram vizibilitatea lucrarilor de efectuat si a fluxului de lucru. AL 2-LEA PAS: “Vizualizeaza” fluxul de lucru si lucrarile Vizualizeaza fluxul de lucru este o operatiune simpla. Cautam un perete liber, montam un whiteboard, desenam un tabel ce reprezinta fluxul de lucru si am terminat. Un exemplu il aveti mai jos. In ceea ce priveste lucrarile, nici aici nu este foarte complicat. Este esential sa hotaram ce informatii sunt necesare pentru a fi inscrise pe POST-IT-urile ce vor fi plasate pe whiteboard si care reprezinta lucrarile. In mod obisnuit, eu pun o mica descriere a lucrarii, data de finalizare daca exista una fixa, o indicatie despre persoana responsabila (un mic avatar este recomandat - face whiteboard-ul ceva mai viu), data de intrare a lucrarii in Backlog si un indicator despre starea lucrarii (ma intereseaza, ca "dintr-o privire", sa stiu daca nu cumva lucrarea este blocata sau are vreo alta problema). Mai utilizez ceva. Folosesc POST-IT-uri de culori diferite pentru a face, de exemplu, diferenta dintre lucrari normale, lucrari urgente si bug-uri. Este de retinut, ca atat whiteboard-ul, cat si structura informatiei de pe POST-IT-uri, se pot schimba in raport cu lucrarile pe care le are de efectuat echipa si in raport de modalitatea in care se doreste vizualizarea diverselor etape din lucrari. In multe cazuri, pentru a face diferenta intre proiecte diferite sau intre categorii de lucrari, whiteboard-urile prezinta linii orizontale, asa numitele swimlanes. Daca se utilizeaza o versiune electronica de Kanban si nu una fizica, atunci cu siguranta ca posibilitatile de captare de informatie si reprezentare, cresc exponenetial. Sa nu ne lasam inselati. Panoul Kanban nu este un sistem informatic gen ERP, destinat retinerii de informatii si de prelucrare a lor. Kanban este un sistem de management destinat dezvoltarii evolutive a modului nostru de lucru. Poate de aceea, in multe cazuri, informatiile pe care le-am indicat mai sus pentru a fi trecut pe POST-IT-uri, sunt suficiente. De ce avem nevoie de vizualizare? Pentru a observa rapid blocajele si problemele din fluxul de lucru. Pentru a nu mai sta sa dezbatem la nesfarsit, daca o problema este reala sau nu. O vedem clar in panoul Kanban. Nu mai avem ce discuta. Era sa uit. Este necesar sa adaugam cate doua sub-coloane (numite “In Lucru”, “In Asteptare”) in fiecare coloana, mai putin in prima si ultima. De ce? Asa vom vizualiza, spre exemplu, momentul in care am terminat multe lucrari in “Implementare” (sunt in “Implementare / In Asteptare”) si datorita unor probleme, ele asteapta exagerat de mult timp sa intre la “Validare”. Aceasta este metoda de vizualizare a blocajelor. AL 3-LEA PAS: Limiteaza lucrarile aflate in progres Prin lucrari aflate in progres, inteleg acele lucrari de care ne-am apucat, dar nu le-am terminat. Legea firii spune ca, daca te apuci de prea multe lucrari odata, atunci le vei termina mai tarziu decat daca te apuci de un numar mai mic si le finalizezi. De aici si invatatura “incepe sa finalizezi, opreste-te sa incepi”. Limitarea se face prin impunerea unui numar maxim de lucrari ce se pot afla in fiecare coloana (nu conteaza in ce subcoloane), in afara de prima si ultima coloana. Acest numar se identifica si se valideaza experimental in cele mai multe cazuri si este propriu fiecarei echipe. Exista desigur si metode de determinare iniatiala a limitei, insa nu voi intra in detalii in acest articol. Nu va temeti sa puneti o limita, chiar si la bunul simt. Singurele doua reguli sunt ca “UNU nu este un raspuns” dar si “lipsa limitarii sau o limita prea mare nu sunt raspunsuri”. Daca puneti UNU veti ajunge extrem de repede sa spuneti ca limita este prea mica. Limitarea actioneaza ca un declansator sau ca o alarma timpurie ca ceva nu merge bine. Daca in “Implementare” am atins limita (toate lucrarile sunt finalizate din punct de vedere implementare si se gasesc in “Implementare / In Asteptare”) si in acelasi timp am atins-o si in “Validare” (lucrarile se gasesc in “Validare / In Lucru”), atunci avem cea mai puternica indicatie ca “Validarea” actioneaza ca o constrangere pentru fluxul de lucru. Poate ca in loc sa mai implementam alte module, ar trebui sa ii ajutam pe colegii din “Validare”. AL 4-LEA PAS: Defineste notiunea de FINALIZAT De multe ori in serviciile profesionale planeaza asa, ca o umbra, notiunea de finalizare a unei etape de lucru. Care sunt criteriile ce valideaza ca o etapa a fost cu adevarat finalizata? In multe sisteme de dezvoltare software se foloseste criteriul de finalizare a unei portiuni de produs (finalizare user story, spre exemplu), dar eu cred ca mult mai de valoare este sa stim ca fiecare etapa din realizarea unui produs s-a incheiat cu succes. In acest pas vom defini ce criterii, care o data validate, ne permit sa trecem dintr-o etapa in alta. AL 5-LEA PAS: Sedinte tip STANDUP Se numesc asa, pentru ca in mod obisnuit se desfasoara in picioare, in fiecare zi, in fata panoului Kanban. Au durata extrem de scurta, de 15 - 30 minute. Rolul nu este de a gasi rezolvari la problemele pe care le avem. Rolul este de a identifica problemele in echipa si eventual de a lua decizii rapide acolo unde se poate. Rezolvarea problemelor mai dificile urmeaza sedintei si se face in grupuri mai mici. Deasemenea sunt sedinte de aliniere si coordonare. In sedintele STANDUP membrii echipei inteleg care sunt problemele cu care se confrunta echipa. Metodologia folosita consta in parcurgerea panoului Kanban de la dreapta la stanga, in observarea “gatuirilor” si intarzierilor, in semnalarea problemelor (daca o lucrare are probleme, acest lucru trebuie semnalizat pe POST_IT-ul corespunzator, inainte de inceperea sedintei), in constatarea efectului urgentelor si in analiza scurta a performantelor (timp de finalizare lucrari, eficienta fluxului de lucru, etc.). De retinut ca totul trebuie pregatit inainte de inceperea sedintei. Acest lucru consta in plasarea tuturor informatiilor in panoul Kanban si in actualizarea graficelor de performanta. Uzual, in cazul multor echipe, analiza performantelor se face separat, o data pe saptamana, intr-o sedinta dedicata. Am incercat, in acest articol, sa ofer cateva indicatii privind utilizarea Kanban in Agile Project Management. Sigur ca mai sunt multe de spus, insa le voi lasa pentru articole viitoare. Orice feedback este bine venit, pe adresa eugen.dragomir@learningmanager.ro.
Pentru a deveni un profesionist in utilizarea Kanban, certificat de Lean Kanban University, inscrie-te la Cursul Acreditat KANBAN FOUNDATIONS I - KANBAN SYSTEM DESIGN Comments are closed.
|
Categorii
All
Arhiva
September 2018
|
Contacteaza-l pe Eugen: +40 744 596 212 / eugen.dragomir@learningmanager.ro
Contacteaz-o pe Carmen: +40 744 535 704 / carmen.dragomir@learningmanager.ro |