Kanban-tavlan är ett av verktygen som kan användas vid implementering av Kanban - utvecklingshanteringsmetoden .
Dessa brädor kan ses som en variant på traditionella kanban-kort. Istället för signalkort, som vanligtvis indikerar efterfrågan eller genomströmning, används magneter, plastpolletter, färgade puckar eller klistermärken tillsammans med tavlan för att representera arbetsobjekt och processer. [1] Vart och ett av dessa objekt representerar ett steg i produktionsprocessen och rör sig över hela linjen när den fortskrider. Denna rörelse motsvarar rörelsen i produktionsprocessen. [2] Styrelsen är vanligtvis indelad i tre logiska sektioner: "väntar", "pågående arbete" och "avslutat arbete". Anställda flyttar anteckningar till den sektion av styrelsen som motsvarar uppgiftens status. [3]
Kanban-metodik kan användas för att organisera många områden i livet. Det finns många varianter av Kanban-brädan.
De enklaste brädorna består av tre kolumner: "att göra" ( engelska to-do ), "pågår" ( pågår ), "klar" ( klar ). [fyra]
Den mest populära tolkningen av kanban-tavlan för agil utveckling eller så kallad lean-utveckling inkluderar följande kolumner beroende på status för uppgifter: diskuterad ( backlog ), överenskommen ( klar ), kod skriven ( kodning ), testad ( testning ), bekräftad ( godkännande ) och gjort ( klar ). Det är också vanligt att namnge kolumner annorlunda, till exempel: nästa, utveckling, klar, klientgodkännande, push-ändringar till produktionsservern [5] .
Förutom möjligheten att byta namn på kolumner/statusar på Kanban-kortet, är det också möjligt att öka antalet kolumner, men detta sker med villkoret att dela upp de befintliga.
Även om kanban-tavlan ursprungligen implementerades i en fysisk form, har många team, särskilt distribuerade sådana, kommit att förstå användbarheten av onlinetavlor [12] .
Utvecklingen av brädor i Kanban-stil online har fått ett nytt uppsving nyligen. Detta beror på behovet av att arbeta på distans med hjälp av Kanban-metoden .
I utvecklingsprocesser, som inom andra verksamhetsområden, är det inte alltid möjligt att omedelbart ”känna efter” rätt väg, ofta får man uppleva många törnen. En produkts eller tjänsts framtida livslängd beror på valet av en lämplig utvecklingsmetodik. Vi har samlat 13 fördelar med att implementera Kanban för mjukvaruutveckling.
Låt oss analysera följande exempel, med tanke på två situationer.
Den första situationen - låt oss föreställa oss en transportörsfabrik i sovjettiden, vars verksamhet var direkt beroende av den statliga planen. Denna plan definierade tydligt mängden produkter för produktion. Som ett resultat, överfulla lager på grund av det faktum att utarbetarna av den statliga planeringskommissionen ofta kunde göra misstag med efterfrågan. Produkten hann inte sälja.
Den andra situationen är Toyotas showroom nu för tiden. Köparen väljer modell och betalar. Toyota har dock inte din fordonsfärg i lager just nu. Beställningen skickas till Toyotas huvudkontor. Du får veta när bilen ska levereras. Först från det ögonblicket började bilen tillverkas. Speciellt för dig. Det finns en princip: först försäljning, sedan produktion. Med andra ord, just in time (JIT) fungerar. Mål och deadlines först, sedan planen och arbetet.
Toyotas lager kommer inte att vara överlager, eftersom de i det första läget inte kommer att behöva hålla förtillverkade delar under långa perioder. Detta beror på att det som produceras just nu på linjen är den kurs som krävs för någon nyligen såld maskin.
En av nyckelkomponenterna i JIT-principen är Kanban. Kanban-tavlor och kort är typ av trafikljus i just in time-systemet. Kanban gör det möjligt för företag att vara reaktiva mot kundernas behov istället för att förutsäga behov, som var fallet i den första situationen som beskrivs.
Du kan projicera ett liknande exempel på området för mjukvaruutveckling:
Istället för reservdelar – utvecklingsuppgifter eller buggar. Testaren får flera uppgifter att kontrollera. När QA tar slut på uppgifter att granska måste han meddela programmerarna för att få nya uppgifter från dem. Om programmerare inte har tid att slutföra nya uppgifter förblir testaren helt enkelt utan arbete under en tid.
Den omvända situationen händer också: QA har många uppgifter och han/hon hinner inte kontrollera allt i tid. I det här fallet försenas även produktens releasedatum.
Inom mjukvaruutveckling är det mycket svårare att balansera Kanban än i produktionen. Det påverkar detaljerna i arbetet: om maskinerna producerar samma typ av delar, arbetar programmerarna med koden genom sina egna ansträngningar från hjärnan, där det finns cirka 100 miljarder neuroner och en, men en betydande mänsklig faktor.
Jag upptäckte fördelarna med Kanban till fullo 2008, varefter jag använder Kanban-brädor överallt: från personlig planering, utveckling och till och med implementering av Kanban i en keramisk verkstad.
Här är 13 skäl till varför du bör implementera Kanban i IT-företag som är engagerade i mjukvaruutveckling:
Att byta till Kanban-kort från vanliga uppgiftslistor visade oss omedelbart en flaskhals: en stor kö av uppgifter samlades i kolumnen Testning. Vår QA klarade inte av att kontrollera uppgifter. Han tog uppgifter för verifiering med lång fördröjning. Efter att testaren returnerade uppgiften för revision hade programmeraren redan lyckats glömma den. Jag var tvungen att titta på koden igen och komma ihåg detaljerna. Som du kan föreställa dig är detta dyrbar tid. Laget behövde ytterligare en testare.
Kanban-tavlan låter dig se flaskhalsar i din process där köer bildas. I Hygger.io begränsar WIP hjälp med denna uppgift. Om du har fler eller färre uppgifter än vad du behöver är kolumnen markerad i rött respektive gult.
Ordningen i vilken funktioner släpps är ofta viktig. I prioriterade listor är det svårt att exakt hantera ordningen. Om en programmerare har fem uppgifter med huvudprioritet samtidigt, blir det svårt för honom att ta reda på vilken av dessa uppgifter som ska ta sig an först.
Kanban-styrelsen erbjuder bara en väg ut ur en situation där ordning spelar roll. Denna visuella lösning är en vertikal kolumn med uppgifter. Ju högre uppgiften är, desto viktigare är den. Kanban, förresten, innebär att prioritera som en av de viktiga aspekterna av metodiken. Kraven förändras ständigt, många uppgifter kan förlora sin relevans och "gå ner". Vissa uppgifter kan tvärtom "stiga" kraftigt. Chefen måste hela tiden "hålla fingret på pulsen" så att programmerarna gör det mest nödvändiga.
Kanban lär dig att fokusera på de viktigaste sakerna. Något som verkligen tillför mervärde till produkten. Vi kunde "sänka" en massa värdelösa buggar och förbättringar. Detta gav ett resultat.
Att skilja viktiga buggar från mindre är inte en lätt uppgift för en produktchef, men det är här Swimlanes-funktionen kommer till undsättning. Dessa är de horisontella kolumnerna på Kanban-tavlan. Som regel har programmerare sådana Swimlanes på tavlan:
Systemet liknar Eisenhower-kvadranten. Viktiga och brådskande ärenden är Blockers. Viktigt men inte brådskande - Uppgifter och buggar. Oviktigt och brådskande, såväl som oviktigt och icke-brådskande - det här är Someday. För övrigt är avsaknaden av horisontella kolumner en av faktorerna som bekräftar vad Trello saknar för Agile utveckling.
Programmeraren måste vara fokuserad på sitt arbete. Därför är det bra när han får en kö av uppgifter och han inte behöver tänka på vad han ska göra härnäst, det har chefen redan tänkt på. Du behöver bara ta på dig nästa uppgift eller bugg.
Ibland involverar Kanban det oberoende urvalet av alla uppgifter av programmerare från ovan. Då ska alla människors professionella nivå vara lika, så att det inte händer att den svåraste uppgiften "faller" på juniorspecialisten.
Filtret Mina uppgifter hjälper dig att fokusera på dina uppgifter. Det hjälper dig att snabbt se dina uppgifter på tavlan.
Framför dina ögon - hela bilden av projektet. Genom att öppna tavlan kan du snabbt få svar på viktiga frågor:
Kanban hjälper dig att bli mer flexibel. Detta är särskilt nödvändigt när produkten släpps och får mycket användbar feedback. Dessa är supportmeddelanden, beteendeanalys, a/b-testresultat, recensioner etc. Så fort vi "laddar upp" en ny funktion till produktionen börjar vi omedelbart ändra den baserat på feedback. Tidigare ville programmeraren inte göra "vänster" uppgifter, eftersom han var rädd för att "fylla upp" sprintdeadlines. Enligt Kanban fungerar en programmerare som en processor: en cykel - en uppgift.
Ju mer frekventa cykler, desto mer flexibelt blir utvecklingsteamet. För vårt team är den idealiska takten 8-12 timmar. Stora uppgifter måste brytas ner.
Scrum tog mycket tid på att utvärdera funktioner innan sprinten började. Med Kanban behövs ingen utvärdering. När vi gör det, då kommer det att göras.
Scrum innebär mycket kommunikation. Början av sprinten åtföljs av planering: analys och utvärdering av uppgifter. Stand-ups krävs varje vecka. Efter sprintens slut hålls en retrospektiv. Som ett resultat tar all kommunikation cirka 30 % av tiden. Men den här gången kunde laget lägga på arbete.
Med Kanban börjar teamet arbeta mer konsekvent. Nu kontrollerar testaren funktionen nästan direkt efter att programmeraren har gjort den. Likaså inom andra områden: designers, UX, redaktörer, försäljning.
Tidigare kontrollerade QA en funktion inte när programmeraren gjorde den, utan efter en lång tid. Under denna tid lyckades programmeraren glömma allt i världen, inklusive detaljerna i denna uppgift.
I Scrum "laddar vi upp" funktioner till produktionen först i slutet av sprinten. Ungefär en gång var tredje vecka. I Kanban, nästan omedelbart efter godkännande av testaren. En gång varannan dag.
Så vi kommer snabbt att ta reda på om funktionen har kommit in hos användarna eller inte. Om inte, har ett fel inträffat någonstans. Och det är viktigt för oss att vara först med att göra misstag. Det betyder inte att vi älskar att göra misstag. Men om vi är de första att veta om felet kommer vi att vara de första att veta och besluta vad vi ska göra.
Inget behov av att ständigt "dra" programmerare. Vi öppnade Kanban-styrelsen, tittade snabbt på vem och vad som gör, alla statusar, och du kan säkert återgå till ledningen. Och programmeraren fortsätter att vara i ett tillstånd av förändring och i väntan på att ta nya höjder.
Tidigare visste inte programmerare vad deras kollegor gjorde. Nu med Kanban kan en programmerare, precis som en chef, gå till styrelsen och se vad kollegor gör. De behöver sådan information för att samordna gemensamma ansträngningar i projektet.
Tidigare var programmeraren engagerad i flera uppgifter samtidigt parallellt. Jag kunde välja en uppgift efter mitt humör, eller så kunde jag helt glömma bort vad jag gjorde i fredags i måndags.
Nu begränsar WIP-gränser och panoramavy programmeraren korrekt: han kan inte göra mer än en uppgift samtidigt.
Som en slutsatsDet kan tyckas som om vi insisterar på att Kanban är bättre än Scrum. Men det är inte. Allt har sin tid. Hyggers erfarenhet tyder på att Scrum lämpar sig väl i början av produktutvecklingen, och Kanban lämpar sig väl när produkten redan kommit in på arenan.
Kanban är inte ett universalmedel för alla företag. Om du sätter stegen mot fel vägg, oavsett hur brant du klättrar på den, hamnar du ändå på fel plats. Därför är Kanban en nödvändig men inte tillräcklig förutsättning för att en produkt eller ett projekt ska lyckas.