Tabloul Kanban este unul dintre instrumentele care pot fi folosite la implementarea metodei de management al dezvoltării Kanban .
Aceste plăci pot fi văzute ca o variație a cardurilor tradiționale kanban. În loc de carduri de semnal, care indică de obicei cererea sau debitul, împreună cu tabla sunt folosiți magneți, jetoane din plastic, pucuri colorate sau autocolante pentru a reprezenta elementele de lucru și procesele. [1] Fiecare dintre aceste obiecte reprezintă o etapă a procesului de producție și se mișcă peste tot pe măsură ce progresează. Această mișcare corespunde mișcării procesului de producție. [2] Tabloul este de obicei împărțit în trei secțiuni logice: „în așteptare”, „lucrări în curs” și „lucrări finalizate”. Angajații mută notele în secțiunea tablei care corespunde stării sarcinii. [3]
Metodologia Kanban poate fi folosită pentru a organiza multe domenii ale vieții. Există multe variante ale plăcii Kanban.
Cele mai simple panouri constau din trei coloane: „de făcut” ( în engleză to-do ), „în curs” ( în curs ), „terminat” ( terminat ). [patru]
Cea mai populară interpretare a plăcii kanban pentru dezvoltarea agilă sau așa-numita dezvoltare lean include următoarele coloane în funcție de starea sarcinilor: discutat ( backlog ), agreat ( gata ), cod scris ( codificare ), testat ( testare ), confirmat ( aprobare ) și gata ( gata ). De asemenea, este o practică obișnuită să denumești coloanele diferit, de exemplu: următorul, dezvoltarea, finalizarea, aprobarea clientului, modificările push către serverul de producție [5] .
Pe lângă posibilitatea de a redenumi coloanele / stările de pe panoul Kanban, este posibilă și creșterea numărului de coloane, dar acest lucru se întâmplă cu condiția împărțirii celor existente.
Deși panoul kanban a fost implementat inițial într-o formă fizică, multe echipe, în special cele distribuite, au ajuns să înțeleagă utilitatea plăcilor online [12] .
Dezvoltarea de plăci online în stil Kanban a primit un nou impuls recent. Acest lucru se datorează necesității de a lucra de la distanță folosind metodologia Kanban .
În procesele de dezvoltare, ca și în alte domenii de activitate, nu este întotdeauna posibil să „simți” imediat calea corectă, de multe ori trebuie să experimentezi o mulțime de spini. Viața viitoare a unui produs sau serviciu depinde de alegerea unei metodologii de dezvoltare adecvate. Am adunat 13 beneficii ale implementării Kanban pentru dezvoltarea de software.
Să analizăm următorul exemplu, luând în considerare două situații.
Prima situație - să ne imaginăm o fabrică de transportoare în perioada sovietică, ale cărei activități depindeau direct de planul de stat. Acest plan a definit clar cantitatea de produse pentru producție. Ca urmare, depozitele supraaglomerate din cauza faptului că redactorii Comisiei de Stat de Planificare ar putea greși adesea cu cererea. Produsul nu a avut timp să se vândă.
A doua situație este showroom-ul Toyota în aceste zile. Cumpărătorul alege un model și plătește. Cu toate acestea, Toyota nu are în stoc culoarea vehiculului dvs. în acest moment. Comanda este trimisă la sediul central Toyota. Vi se va spune când va fi livrată mașina. Abia din acel moment mașina a început să fie produsă. Special pentru tine. Există un principiu: prima vânzare, apoi producție. Cu alte cuvinte, just in time (JIT) funcționează. Mai întâi obiectivele și termenele limită, apoi planul și munca.
Inventarul Toyota nu va fi suprasolicitat, deoarece în prima situație, acestea nu vor trebui să dețină piese prefabricate pentru perioade lungi de timp. Acest lucru se datorează faptului că ceea ce este produs chiar acum pe linie este rata necesară pentru o mașină recent vândută.
Una dintre componentele cheie ale principiului JIT este Kanban. Plăcile și cardurile Kanban sunt un fel de semafoare în sistemul just in time. Kanban permite companiilor să fie reactive la nevoile clienților în loc să prezică nevoile, așa cum a fost cazul în prima situație descrisă.
Puteți proiecta un exemplu similar în zona de dezvoltare software:
În loc de piese de schimb - sarcini de dezvoltare sau erori. Testerul primește mai multe sarcini de verificat. Când QA rămâne fără sarcini de revizuit, el trebuie să notifice programatorii pentru a primi sarcini noi de la ei. Dacă programatorii nu au timp să termine sarcini noi, testerul rămâne pur și simplu fără muncă pentru o perioadă de timp.
Se întâmplă și situația inversă: QA are o mulțime de sarcini și el/ea nu are timp să verifice totul la timp. În acest caz, data de lansare a produsului este, de asemenea, întârziată.
În dezvoltarea de software, echilibrarea Kanban este mult mai dificilă decât în producție. Afectează specificul muncii: dacă mașinile produc același tip de piese, atunci programatorii lucrează cu codul prin propriile eforturi ale creierului, în care există aproximativ 100 de miliarde de neuroni și unul, dar un factor uman semnificativ.
Beneficiile Kanban le-am descoperit la maxim în 2008, după care folosesc plăci Kanban peste tot: de la planificarea personală, dezvoltarea și chiar implementarea Kanban într-un atelier de ceramică.
Iată 13 motive pentru care ar trebui să implementați Kanban în companiile IT care sunt implicate în dezvoltarea de software:
Trecerea la panouri Kanban din listele obișnuite de sarcini ne-a arătat imediat un blocaj: o coadă mare de sarcini acumulate în coloana Testare. QA-ul nostru nu a putut face față sarcinilor de verificare. A luat sarcini pentru verificare cu o mare întârziere. După ce testerul a returnat sarcina pentru revizuire, programatorul reușise deja să o uite. A trebuit să mă uit din nou la cod și să-mi amintesc detaliile. După cum vă puteți imagina, acesta este un timp prețios. Echipa avea nevoie de un alt tester.
Tabloul Kanban vă permite să vedeți blocajele din procesul dvs. în cazul în care se formează cozi. În Hygger.io, limitele WIP ajută la această sarcină. Dacă aveți mai multe sau mai puține sarcini decât aveți nevoie, coloana este evidențiată cu roșu sau, respectiv, galben.
Ordinea în care sunt lansate funcțiile este adesea importantă. În listele prioritizate, este dificil să gestionezi cu precizie comanda. Dacă un programator are cinci sarcini cu prioritate principală în același timp, îi va fi dificil să-și dea seama care dintre aceste sarcini să le asume mai întâi.
Placa Kanban oferă doar o ieșire dintr-o situație în care ordinea contează. Această soluție vizuală este o coloană verticală cu sarcini. Cu cât sarcina este mai mare, cu atât este mai importantă. Kanban, de altfel, implică stabilirea priorităților ca unul dintre aspectele importante ale metodologiei. Cerințele se schimbă constant, multe sarcini își pot pierde relevanța și „scădea” în jos. Unele sarcini pot, dimpotrivă, să „crească” brusc. Managerul trebuie să „țină degetul pe puls” în mod constant pentru ca programatorii să facă tot ce este necesar.
Kanban te învață să te concentrezi asupra lucrurilor principale. Ceva care aduce cu adevărat valoare produsului. Am reușit să „coborâm” o mulțime de erori inutile și îmbunătățiri. Aceasta a dat un rezultat.
Distingerea erorilor importante de cele mai mici nu este o sarcină ușoară pentru un manager de produs, dar aici este locul în care funcția Swimlanes vine în ajutor. Acestea sunt coloanele orizontale de pe panoul Kanban. De regulă, programatorii au astfel de Swimlanes pe tablă:
Sistemul este similar cu cadranul Eisenhower. Chestiuni importante și urgente sunt Blockers. Important, dar nu urgent - Sarcini și erori. Neimportant și urgent, precum și neimportant și neurgent - aceasta este Someday. Apropo, lipsa coloanelor orizontale este unul dintre factorii care confirmă ceea ce îi lipsește Trello pentru dezvoltarea Agile.
Programatorul trebuie să fie concentrat pe munca sa. Prin urmare, este bine când primește o coadă de sarcini și nu trebuie să se gândească la ce să facă în continuare, managerul s-a gândit deja la asta. Trebuie doar să vă asumați următoarea sarcină sau eroare.
Uneori, Kanban implică selectarea independentă a oricăror sarcini de către programatori de sus. Atunci nivelul profesional al tuturor oamenilor ar trebui să fie egal, astfel încât să nu se întâmple ca sarcina cea mai dificilă să „cade” asupra specialistului junior.
Filtrul Sarcinile mele vă ajută să vă concentrați asupra sarcinilor dvs. Vă ajută să vă vedeți rapid sarcinile pe tablă.
În fața ochilor tăi - întreaga imagine a proiectului. Prin deschiderea forumului, puteți obține rapid răspunsuri la întrebări importante:
Kanban te ajută să devii mai flexibil. Acest lucru este necesar mai ales atunci când produsul este lansat și primește o mulțime de feedback util. Acestea sunt mesaje de asistență, analize comportamentale, rezultate a/b test, recenzii etc. De îndată ce „încărcăm” o nouă caracteristică în producție, începem imediat să o modificăm pe baza feedback-ului. Anterior, programatorul nu dorea să facă sarcini „la stânga”, fiindu-i frică să „umple” termenele limită de sprint. Potrivit Kanban, un programator funcționează ca un procesor: un ciclu - o sarcină.
Cu cât ciclurile sunt mai frecvente, cu atât echipa de dezvoltare devine mai flexibilă. Pentru echipa noastră, tactul ideal este de 8-12 ore. Sarcinile mari trebuie descompuse.
Scrum a luat mult timp pentru evaluarea caracteristicilor înainte de începerea sprintului. Cu Kanban, nu este nevoie de evaluare. Când o vom face, atunci se va face.
Scrum implică multă comunicare. Începutul sprintului este însoțit de planificare: analiza și evaluarea sarcinilor. Stand-up-urile sunt necesare în fiecare săptămână. După încheierea sprintului, are loc o retrospectivă. Drept urmare, toată comunicarea durează aproximativ 30% din timp. Dar de data aceasta echipa ar putea cheltui pe muncă.
Cu Kanban, echipa începe să lucreze mai constant. Acum, testerul verifică caracteristica aproape imediat după ce programatorul a făcut-o. La fel, în alte domenii: designeri, UX, editori, vânzări.
Anterior, QA a verificat o caracteristică nu atunci când a făcut-o programatorul, ci după mult timp. În acest timp, programatorul a reușit să uite totul din lume, inclusiv detaliile acestei sarcini.
În Scrum, „încărcăm” funcții în producție numai la sfârșitul sprintului. Aproximativ o dată la 3 săptămâni. În Kanban, aproape imediat după acceptarea de către tester. O dată la câteva zile.
Deci vom afla rapid dacă caracteristica a intrat în utilizatori sau nu. Dacă nu, a apărut o eroare undeva. Și este important pentru noi să fim primii care greșesc. Asta nu înseamnă că ne place să facem greșeli. Dar dacă suntem primii care știm despre eroare, vom fi primii care știm și vom decide ce să facem.
Nu este nevoie să „trageți” constant programatori. Am deschis panoul Kanban, ne-am uitat rapid la cine și ce face, toate stările și vă puteți întoarce în siguranță la management. Și programatorul continuă să fie într-o stare de flux și în așteptarea de a atinge noi culmi.
Anterior, programatorii nu știau ce fac colegii lor. Acum, cu Kanban, un programator poate, la fel ca un manager, să meargă la bord și să vadă ce fac colegii. Au nevoie de astfel de informații pentru a coordona eforturile comune asupra proiectului.
Anterior, programatorul a fost angajat în mai multe sarcini simultan în paralel. Aș putea alege o sarcină în funcție de starea mea de spirit, sau aș putea uita complet de ceea ce am făcut vineri, luni.
Acum limitele WIP și vizualizarea panoramică limitează corect programatorul: el nu poate face mai mult de o sarcină simultan.
Ca o concluziePoate părea că insistăm că Kanban este mai bun decât Scrum. Dar nu este. Toate la timpul lor. Experiența lui Hygger sugerează că Scrum este foarte potrivit la începutul dezvoltării produsului, iar Kanban este potrivit atunci când produsul a intrat deja în arena.
Kanban nu este un panaceu pentru orice afacere. Dacă așezi scara pe peretele greșit, indiferent cât de abrupt ai urca-o, tot ajungi în locul nepotrivit. Prin urmare, Kanban este o condiție necesară, dar nu suficientă pentru succesul unui produs sau proiect.