Kanban-tavlen er et af de værktøjer , der kan bruges ved implementering af Kanban- udviklingsstyringsmetoden .
Disse tavler kan ses som en variation af traditionelle kanban-kort. I stedet for signalkort, som normalt angiver efterspørgsel eller gennemløb, bruges magneter, plastikpoletter, farvede pucke eller klistermærker sammen med brættet til at repræsentere arbejdsemner og processer. [1] Hvert af disse objekter repræsenterer et trin i produktionsprocessen og bevæger sig over hele linjen, efterhånden som den skrider frem. Denne bevægelse svarer til bevægelsen af produktionsprocessen. [2] Tavlen er normalt opdelt i tre logiske sektioner: "venter", "igangværende arbejde" og "afsluttet arbejde". Medarbejdere flytter notater til den sektion af tavlen, der svarer til opgavens status. [3]
Kanban-metoden kan bruges til at organisere mange områder af livet. Der er mange variationer af Kanban-brættet.
De enkleste tavler består af tre kolonner: "to do" ( engelsk to-do ), "in progress" ( in progress ), "done" ( done ). [fire]
Den mest populære fortolkning af kanban-tavlen til agil udvikling eller såkaldt lean-udvikling omfatter følgende kolonner i henhold til status for opgaverne: diskuteret ( backlog ), aftalt ( klar ), kode skrevet ( kodning ), testet ( test ), bekræftet ( godkendelse ) og færdig ( færdig ). Det er også almindelig praksis at navngive kolonner anderledes, for eksempel: næste, udvikling, udført, klientgodkendelse, push-ændringer til produktionsserver [5] .
Udover muligheden for at omdøbe kolonner/statusser på Kanban-tavlen, er det også muligt at øge antallet af kolonner, men dette sker med betingelsen om at opdele de eksisterende.
Selvom kanban-tavlen oprindeligt blev implementeret i en fysisk form, er mange hold, især distribuerede, kommet til at forstå anvendeligheden af online-boards [12] .
Udviklingen af online boards i Kanban-stil har fået et nyt løft for nylig. Dette skyldes behovet for at arbejde eksternt ved hjælp af Kanban-metoden .
I udviklingsprocesser, som i andre aktivitetsområder, er det ikke altid muligt umiddelbart at “mærke efter” den rigtige vej, ofte skal man opleve mange torne. Et produkts eller services fremtidige levetid afhænger af valget af en passende udviklingsmetodologi. Vi har samlet 13 fordele ved at implementere Kanban til softwareudvikling.
Lad os analysere det følgende eksempel i betragtning af to situationer.
Den første situation - lad os forestille os en transportørfabrik i sovjettiden, hvis aktiviteter direkte afhang af statsplanen. Denne plan definerede klart mængden af produkter til produktion. Som et resultat, overfyldte varehuse på grund af det faktum, at udarbejderne af statens planlægningskommission ofte kunne begå fejl med efterspørgslen. Produktet havde ikke tid til at sælge.
Den anden situation er Toyotas showroom i disse dage. Køber vælger model og betaler. Toyota har dog ikke din bilfarve på lager på nuværende tidspunkt. Ordren sendes til Toyotas hovedkontor. Du får at vide, hvornår bilen bliver leveret. Først fra det øjeblik begyndte bilen at blive produceret. Specielt til dig. Der er et princip: først salg, så produktion. Med andre ord virker just in time (JIT). Først mål og deadlines, derefter planen og arbejdet.
Toyotas lagerbeholdning vil ikke være overfyldt, da de i den første situation ikke behøver at opbevare præfabrikerede dele i lange perioder. Dette skyldes, at det, der produceres lige nu på linjen, er den krævede sats for en nyligt solgt maskine.
En af nøglekomponenterne i JIT-princippet er Kanban. Kanban-tavler og -kort er en slags trafiklys i just-in-time-systemet. Kanban gør det muligt for virksomheder at reagere på kundernes behov i stedet for at forudsige behov, som det var tilfældet i den første beskrevne situation.
Du kan projektere et lignende eksempel til softwareudviklingsområdet:
I stedet for reservedele – udviklingsopgaver eller fejl. Testeren får flere opgaver at kontrollere. Når QA løber tør for opgaver at gennemgå, skal han underrette programmørerne for at modtage nye opgaver fra dem. Hvis programmører ikke har tid til at afslutte nye opgaver, forbliver testeren simpelthen uden arbejde i nogen tid.
Den omvendte situation sker også: QA har mange opgaver, og han/hun har ikke tid til at tjekke alt i tide. I dette tilfælde er udgivelsesdatoen for produktet også forsinket.
Inden for softwareudvikling er balancering af Kanban meget vanskeligere end i produktion. Det påvirker arbejdets detaljer: Hvis maskinerne producerer den samme type dele, så arbejder programmørerne med koden ved deres egen indsats fra hjernen, hvori der er omkring 100 milliarder neuroner og én, men en væsentlig menneskelig faktor.
Jeg opdagede fordelene ved Kanban til fulde i 2008, hvorefter jeg bruger Kanban boards overalt: fra personlig planlægning, udvikling og endda implementering af Kanban i et keramisk værksted.
Her er 13 grunde til, at du bør implementere Kanban i it-virksomheder, der beskæftiger sig med softwareudvikling:
Skift til Kanban-tavler fra almindelige opgavelister viste os straks en flaskehals: en stor kø af opgaver akkumuleret i kolonnen Test. Vores QA kunne ikke klare kontrolopgaver. Han tog opgaver til verifikation med lang forsinkelse. Efter at testeren havde returneret opgaven til revision, havde programmøren allerede formået at glemme den. Jeg var nødt til at se på koden igen og huske detaljerne. Som du kan forestille dig, er dette dyrebar tid. Holdet havde brug for endnu en tester.
Kanban-tavlen giver dig mulighed for at se flaskehalse i din proces, hvor der dannes køer. I Hygger.io begrænser WIP hjælp til denne opgave. Har du flere eller færre opgaver, end du har brug for, er kolonnen fremhævet med henholdsvis rødt eller gult.
Rækkefølgen, hvori funktioner frigives, er ofte vigtig. I prioriterede lister er det svært at styre rækkefølgen præcist. Hvis en programmør har fem opgaver med hovedprioritet på samme tid, vil det være svært for ham at finde ud af, hvilken af disse opgaver han skal påtage sig først.
Kanban-tavlen tilbyder bare en vej ud af en situation, hvor orden betyder noget. Denne visuelle løsning er en lodret søjle med opgaver. Jo højere opgaven er, jo vigtigere er den. Kanban involverer i øvrigt prioritering som et af de vigtige aspekter af metodikken. Kravene ændrer sig konstant, mange opgaver kan miste deres relevans og "gå ned". Nogle opgaver kan tværtimod "stige kraftigt". Lederen skal hele tiden "holde fingeren på pulsen", så programmørerne gør det mest nødvendige.
Kanban lærer dig at fokusere på de vigtigste ting. Noget der virkelig tilføjer værdi til produktet. Vi var i stand til at "sænke" en masse ubrugelige fejl og forbedringer. Dette gav et resultat.
At skelne vigtige fejl fra mindre er ikke en nem opgave for en produktmanager, men det er her Swimlanes-funktionen kommer til undsætning. Disse er de vandrette kolonner på Kanban-tavlen. Som regel har programmører sådanne Swimlanes på tavlen:
Systemet ligner Eisenhower-kvadranten. Vigtige og presserende sager er Blockers. Vigtigt, men ikke presserende - Opgaver og fejl. Uvigtigt og presserende, såvel som ligegyldigt og ikke-haster - dette er en dag. I øvrigt er manglen på vandrette søjler en af de faktorer, der bekræfter, hvad Trello mangler til Agile udvikling.
Programmøren skal være fokuseret på sit arbejde. Derfor er det godt, når han modtager en kø af opgaver, og han ikke behøver at tænke på, hvad han så skal gøre, det har lederen allerede tænkt over. Du skal bare påtage dig den næste opgave eller fejl.
Nogle gange involverer Kanban uafhængig udvælgelse af alle opgaver af programmører fra oven. Så bør det faglige niveau for alle mennesker være lige, så det ikke sker, at den sværeste opgave "falder" på juniorspecialisten.
Mine opgaver-filteret hjælper dig med at sætte fokus på dine opgaver. Det hjælper dig med hurtigt at se dine opgaver på tavlen.
For dine øjne - hele billedet af projektet. Ved at åbne tavlen kan du hurtigt få svar på vigtige spørgsmål:
Kanban hjælper dig med at blive mere fleksibel. Dette er især nødvendigt, når produktet er frigivet og modtager en masse nyttig feedback. Disse er supportmeddelelser, adfærdsanalyser, a/b-testresultater, anmeldelser osv. Så snart vi "uploader" en ny funktion til produktion, begynder vi straks at ændre den baseret på feedback. Tidligere ønskede programmøren ikke at udføre "venstre" opgaver, da han var bange for at "udfylde" sprint-deadlines. Ifølge Kanban fungerer en programmør som en processor: én cyklus – én opgave.
Jo hyppigere cyklusser, jo mere fleksibelt bliver udviklingsteamet. For vores team er den ideelle takt 8-12 timer. Store opgaver skal nedbrydes.
Scrum tog meget tid på at evaluere funktioner før starten af spurten. Med Kanban er der ikke behov for evaluering. Når vi gør det, så bliver det gjort.
Scrum involverer meget kommunikation. Begyndelsen af spurten ledsages af planlægning: analyse og evaluering af opgaver. Stand-ups er påkrævet hver uge. Efter sprintens afslutning afholdes et retrospektiv. Som følge heraf tager al kommunikation omkring 30 % af tiden. Men denne gang kunne holdet bruge på arbejde.
Med Kanban begynder teamet at arbejde mere konsekvent. Nu tjekker testeren funktionen næsten umiddelbart efter, at programmøren har lavet den. Tilsvarende på andre områder: designere, UX, redaktører, salg.
Tidligere kontrollerede QA en funktion, ikke når programmøren lavede den, men efter lang tid. I løbet af denne tid lykkedes det programmøren at glemme alt i verden, inklusive detaljerne i denne opgave.
I Scrum "uploader" vi funktioner til produktionen først i slutningen af spurten. Cirka en gang hver 3. uge. I Kanban, næsten umiddelbart efter accept af testeren. En gang hvert par dage.
Så vi finder hurtigt ud af, om funktionen er kommet ind hos brugerne eller ej. Hvis ikke, er der opstået en fejl et sted. Og det er vigtigt for os at være de første til at lave fejl. Det betyder ikke, at vi elsker at lave fejl. Men hvis vi er de første til at vide om fejlen, vil vi være de første til at vide og beslutte, hvad vi skal gøre.
Ingen grund til konstant at "trække" programmører. Vi åbnede Kanban-bestyrelsen, kiggede hurtigt på, hvem og hvad der gør, alle statusser, og du kan trygt vende tilbage til ledelsen. Og programmøren fortsætter med at være i en tilstand af forandring og i forventning om at tage nye højder.
Tidligere vidste programmører ikke, hvad deres kolleger lavede. Nu med Kanban kan en programmør, ligesom en leder, gå til bestyrelsen og se, hvad kollegerne laver. De har brug for sådanne oplysninger for at koordinere den fælles indsats på projektet.
Tidligere var programmøren involveret i flere opgaver på én gang parallelt. Jeg kunne vælge en opgave efter mit humør, eller jeg kunne helt glemme alt om, hvad jeg lavede om fredagen i mandags.
Nu begrænser WIP-grænser og panoramaudsigt programmøren korrekt: han kan ikke udføre mere end én opgave på én gang.
Som konklusionDet kan virke som om, vi insisterer på, at Kanban er bedre end Scrum. Men det er det ikke. Alt har sin tid. Hyggers erfaring tyder på, at Scrum er velegnet i starten af produktudviklingen, og Kanban er velegnet, når produktet allerede er kommet på banen.
Kanban er ikke et vidundermiddel for enhver virksomhed. Hvis du sætter stigen mod den forkerte væg, uanset hvor stejlt du klatrer op på den, ender du alligevel det forkerte sted. Derfor er Kanban en nødvendig, men ikke tilstrækkelig betingelse for et produkts eller projekts succes.