Ghid Scrum | 33. Plăci Scrumban și Kanban în Scrum

Scrum și Kanban sunt metode de lucru în echipă care au multe asemănări. Cu toate acestea, există și diferențe pe care am dori să le discutăm astăzi. De asemenea, panourile Kanban sunt adesea adoptate de echipele Scrum. Acest lucru se datorează faptului că sunt foarte practici în vizualizarea muncii în echipă și a progresului acesteia. Prin combinarea celor mai bune dintre ambele metodologii, a apărut o tehnică numită Scrumban. Este popular în proiectele care combină dezvoltarea produsului cu livrarea de servicii, unde Sprinturile lungi și întâlnirile Scrum relativ formale nu sunt întotdeauna potrivite.

Scrumban și panouri Kanban în Scrum – cuprins:

1. Introducere
2. Kanban vs Scrum
3. Panouri Kanban în Scrum
4. Scrumban
5. rezumat

Introducere

Kanban este o metodă inițiată în Japonia. A apărut în anii 1950 și a fost în primul rând un instrument de gestionare a producției continue, astfel încât să nu creeze stocuri și surplus, ci să proceseze resursele în mod continuu. La începutul secolului 21, Kanban a fost adaptat la nevoile dezvoltării software de către David J. Anderson.

Kanban vs Scrum

Modul general de lucru în Kanban diferă de Scrum în primul rând prin realizarea unei abordări mai puțin formale. În Kanban, nu există îndrumări atât de detaliate despre, de exemplu, lucrul în Sprinturi, rolurile de Product Owner, Scrum Master și Development Team. Acest lucru este posibil deoarece Kanban se concentrează pe continuitatea sarcinilor , cum ar fi furnizarea unui anumit tip de serviciu, care sunt mai repetabile și nu necesită o planificare atât de complexă.

Cu toate acestea, scopul și modalitățile de lucru sunt similare. Scopul Kanban este de a livra clientului la timp un produs de cea mai înaltă calitate. Principiile privind modalitățile de lucru comune ambelor metode pot fi formulate după cum urmează:

1. Munca ar trebui să fie lină și fără timpi de nefuncționare – în Scrum, acest lucru se realizează prin succesiunea continuă de Sprinturi, în timp ce în Kanban munca este continuă datorită fluxului lin al sarcinilor. Ele formează o coadă, din care dezvoltatorii aleg (trag) câteva sarcini de finalizat.
2. Echipa ar trebui să se concentreze doar pe sarcinile selectate – folosind terminologia Kanban, echipa ar trebui să „reducă munca în curs”. În Scrum, echivalentul este Poveștile utilizatorilor alese din Product Backlog pentru a le pune în Sprint Backlog
3. Progresul sarcinilor ar trebui să fie vizibil pentru toate persoanele implicate – în Kanban, acestea sunt vizualizate de panouri, care sunt adesea prezentate în echipele Scrum.

Panouri Kanban în Scrum

O tablă Kanban este un instrument utilizat pe scară largă pentru vizualizarea muncii în echipă. Este un tabel cu mai multe coloane. În fiecare dintre ele, există sarcini cu un anumit statut. Categorizarea sarcinilor se bazează pe o regulă simplă: într-una dintre coloane este plasat un card cu o descriere a sarcinii – sau echivalentul său virtual. Versiunea minimă a panourilor Kanban conține trei coloane:

• A face
• În curs
• Terminat – la ultima coloană merg sarcinile care îndeplinesc Definiția Finalizării, despre care am scris aici.

Mai jos puteți găsi un exemplu de panou kanban dintr-un sistem de management de proiect all-in-one – Firmbee.com

De obicei, există mai multe coloane. Dacă există mai multe sarcini de finalizat, există de obicei o coloană suplimentară intitulată „selectat pentru finalizare” între coloanele „de finalizat” și „în curs” . În timp ce coloana „de făcut” servește drept Backlog de produse, despre care am scris aici, coloana „selectat pentru finalizare” servește drept Backlog Sprint, pe care îl descriem în detaliu în acest articol.

A doua adăugare comună este o coloană „în curs de revizuire” sau „pentru aprobare”. De obicei este inserat între coloanele care conțin sarcinile „în curs” și cele „finalizate”. Conține sarcini finalizate de echipa de dezvoltare care așteaptă aprobarea de la Product Owner. Sarcina Proprietarului de Produs este să verifice conformitatea acestora cu criteriile de acceptare și să obțină aprobarea finală de la Client. În această situație, doar sarcinile acceptate în final sunt mutate în ultima coloană.

Scrumban

Datorită popularității uriașe a Scrum și Kanban, a apărut hibridul lor, combinând cele mai bune dintre ambele moduri de lucru. Scrumban funcționează cel mai bine în organizațiile care conectează crearea de Produse cu furnizarea de servicii, implicând adesea implementarea Produsului la Client. Din cauza reducerii întâlnirilor și comunicării, Echipa poate fi mai mare.

Scrumban pune mai puțin accent pe valorile utilizate în mod obișnuit în Scrum, cum ar fi Burndown Chart. Cu toate acestea, folosește pilonii Scrum ai necesității de îmbunătățire continuă a procesului de lucru și adaptarea acestora la condițiile și nevoile clientului.

Când lucrați în Scrumban, însă, munca nu este împărțită în Sprinturi. Întâlnirile Scrum au loc la fiecare 3, 6 sau 12 luni.

Programarea lucrărilor urmează principiul „On-Demand”, adică așa cum se întâmplă. Poveștile utilizatorilor sunt plasate direct în prima coloană a panoului Kanban care conține sarcini „de făcut”. Astfel, servește drept Sprint Backlog, despre care am scris mai detaliat în acest articol. Ca și în Sprint Backlog, sarcinile cele mai urgente sunt plasate în partea de sus a listei de sarcini. Cu toate acestea, pentru proiecte mai complexe, managerul de proiect poate menține o listă separată de activități corespunzătoare Product Backlog, din care selectează sarcinile de plasat în prima coloană.

La mutarea sarcinilor din prima în a doua coloană, se aplică regula „Trage” . Înseamnă că sarcinile nu sunt delegate unui anumit Dezvoltator. Fiecare persoană alege o sarcină din coadă și o execută independent.

Numărul de sarcini plasate în coloana din mijloc, „de finalizat” este de obicei limitat în funcție de dimensiunea echipei, astfel încât, dacă este posibil, toată lumea se ocupă de o singură sarcină la un moment dat.

rezumat

Scrum și Kanban, deși sunt folosite în scopuri similare, sunt moduri diferite de lucru. Scrum funcționează cel mai bine în proiecte creative și inovatoare realizate de echipe Scrum mici. Kanban, pe de altă parte, a fost creat pentru a funcționa într-un mediu continuu și fără întreruperi pentru a oferi servicii similare. Scrum folosește adesea panouri Kanban ca metodă de a vizualiza munca depusă. Combinația dintre ambele a rezultat în Scrumban, care funcționează cel mai bine ca un cadru pentru organizațiile care își vând produsele și oferă clienților servicii bazate pe acestea.

Dacă vă place conținutul nostru, alăturați-vă comunității noastre de albine ocupate pe Facebook, Twitter, LinkedIn, Instagram, YouTube, Pinterest.

Autor: Caroline Becker

În calitate de manager de proiect, Caroline este expertă în găsirea de noi metode de a proiecta cele mai bune fluxuri de lucru și de a optimiza procesele. Abilitățile ei de organizare și capacitatea de a lucra sub presiunea timpului o fac cea mai bună persoană pentru a transforma proiectele complicate în realitate.

Vizualizați toate postările

Ghid Scrum:

1. Glosar de termeni de bază, roluri și noțiuni
2. Ce este Scrum?
3. Valorile Scrum
4. Cum implementezi Scrum în compania ta?
5. Echipa Scrum - ce este și cum funcționează?
6. Cine este un proprietar de produs?
7. Cele mai frecvente greșeli ale Product Ownerului
8. Cine este Scrum Master?
9. Caracteristicile unui bun Scrum Master
10. Cele mai frecvente greșeli ale Scrum Master
11. Ce statistici și valori ar trebui să urmărească Scrum Master?
12. Cooperare între Product Owner și Scrum Master
13. Echipa de dezvoltare în Scrum
14. Cele mai frecvente greșeli ale dezvoltatorilor
15. Artefacte Scrum
16. Scaling Scrum
17. Sprint Backlog
18. Ce este Product Backlog?
19. Ce sunt User Stories?
20. Crearea celei mai bune povești de utilizator cu INVEST
21. Cele mai frecvente greșeli ale User Story
22. Criterii de acceptare a poveștii utilizatorului
23. Estimare și Story Points în Scrum
24. Planificarea Pokerului
25. Joc de estimare a echipei
26. Definirea creșterii
27. Evenimente Scrum
28. Ce este Sprint în Scrum?
29. Angajamentele echipei Scrum - Obiectiv de produs, obiectiv de sprint și definiția finalizării
30. Ce este un grafic Burndown?
31. Cum se creează și se interpretează un grafic de ardere?
32. Avantajele și dezavantajele diagramei de ardere
33. Panouri Kanban în Scrum și Scrumban
34. Viteza în Scrum - Viteza echipei de dezvoltare
35. Scrum zilnic
36. Planificarea sprintului
37. Sprint Review
38. Ce este o retrospectivă Sprint?
39. Greșeli frecvente în timpul unei retrospective de sprint
40. Creșterea backlog-ului de produse