Dagens programvaruteam är, åtminstone i sina processer, mer smidiga! De är villiga att tänka utanför uppsatta parametrar för att följa vad som fungerar för dem. De är angelägna om att lära sig och anta nya tekniker för projektledning och projektprocesser.
En projektledningsmetod som heter Kanban har genomfört rundorna inom mjukvaruindustrin under ganska många år och har vunnit valuta under de senaste fem åren. Tillsammans med Agile-metoder har antagandet av Kanban-metoden gett företag mycket att fira.
Men det finns också kritiken att Kanban inte är något annat än en förhärlig uppgiftslista. Så vad handlar det om? Låt oss ta reda på.
Vad är Kanban?
Om ditt företag är redo att gå längre än den traditionella mjukvaran projektledning strategi, idag, det finns ingen brist på projektledningstekniker.
För det första finns det Agile Project Management-systemet, som fokuserar på icke-linjära, iterativa metoder för mjukvaruutveckling. Användningen av smidiga metoder framgår av Scrum, som fokuserar på en mer flexibel strategi för projektledning.
Agile har också länkar till andra projekthanteringsramar som Kanban och Extreme Programming. Av dessa har Kanban uppnått mycket popularitet. Vem vill ju inte ha en process som utvecklats av japanerna?
Kanban är ett koncept som utvecklats vid Toyota Manufacturing Plant för att uppnå just-in-time (JIT) produktion som sänker kostnaderna och möjliggör mindre resursutnyttjande. I sitt hjärta följer det "pull" -principen för arbete, vilket innebär att uppgifter eller produkter måste "dras" av krav och efterfrågan, och inte "skjuts" uppifrån och ner. Det utvecklades för att säkerställa bättre lagerhållning för bilkomponenter i Toyota-anläggningar, baserat på efterfrågan. Detta innebar att när efterfrågan ökade skulle förfrågningarna fyllas i.
Konceptet anpassades till mjukvaruindustrin med några förändringar av David Anderson i hans bok 2010, Kanban . Sedan dess har den använts för olika projekt med stor framgång. Det kan vara till stor hjälp i komplexa projekt som kan drabbas av överbelastning på ena sidan av utvecklingscykeln.
I grunden behandlar Kanban-systemet programvaruprocessen som en pipeline. Låt oss säga att en mjukvaruprocess har tre typer av uppgifter: analys, utveckling, testning och slutligen distribution. Låt oss säga att det finns tjugo uppgifter som måste slutföras.
När det gäller ett traditionellt projektledningssystem om, till exempel,
- Det finns 25 berättelser totalt
- Analytiker kan hantera fem berättelser i veckan
- Utvecklare kan hantera fem berättelser i veckan
- Testare är begränsade till tre berättelser i veckan
I den här situationen staplar arbetet helt enkelt upp i testarens slut. I slutet av vecka 1 kommer situationen att vara följande:
- Endast tre berättelser har gått vidare till distributionen.
- Utvecklare och analytiker arbetar med tre berättelser, eftersom testare inte kan ta utvecklarnas resultat och testa detsamma.
- Arbetet staplas upp och lämnar utvecklare och analytiker och projektledaren i en fix.
Analytikerna och utvecklarna kan nu helt enkelt tippa tummen! Eller kanske deras chef inser att de är lediga och omfördelar dem till ett annat projekt, där en liknande situation kan uppstå. Så det finns två projekt som nu fastnar i testfasen!
Problemen i en sådan situation är inte svåra att se. Vad är poängen med att utveckla tio berättelser (eller programvara) när de inte kommer att testas snart?
Nu vidare till Kanban-metoden.
Kanban-metoden är ett extremt enkelt koncept. Det följer en enkel logik med att använda en "pull-metod" för att ta bort flaskhalsarna först och begränsa Works in Progress (WIP) för bättre arbetsprocesser.
I sin enklaste form hjälper Kanban, bokstavligen, "visual board" genom att "dra" objekt från en to-do-lista, snarare än att arbeta med tidslinjer. Kanban-metoden hjälper till att identifiera flaskhalsarna så att processflödet hanteras bättre.
En grundläggande Kanban-styrelse har en lista med uppgifter som ska utföras, uppgifter som pågår och uppgifter som är slutförda.
I programvarahantering kan uppgifterna dock vara lite mer komplexa. De flesta Agile-projekt har också en liknande styrelse. I ett Kanban-bräde markeras distributionsstegen tydligt, tillsammans med ett nummer för varje kolumn. Detta nummer representerar det maximala antalet uppgifter eller berättelser som ett visst steg kan hantera.
Vårt exempel på ett Kanban-bräde skulle se ut så här i början av den andra veckan. Detta innebär att utvecklare och analytiker inte kommer att arbeta med det optimala antalet berättelser den veckan. Det skulle vara uppenbart att arbetet börjar staplas i testarens slut. Och organisationer kan säkerställa att team arbetar tillsammans för att få testet gjort. Alternativt kan de titta på andra modeller av processflöde så att detta inte händer.
När projekt hanteras genom Kanban-systemet, finns det mindre utrymme för att få uppstoppat arbete. Berättelser tas upp enligt den maximala tillgängliga bandbredden.
I en typisk Kanban-uppsättning kommer arbetet att tas upp enligt den tillgängliga bandbredden och arbetet dras in av team, så att de alltid har maximal kapacitet. Systemet möjliggör också ett snabbt spår, för uppgifter som är brådskande, så att de rör sig genom kortet med minimal ansträngning.
Ta en titt på detta Kanban-bräde.
Det är tydligt att alla steg arbetar med maximal effektivitet. Och den uppgift som finns på ”Fast Track” redovisas också.
Kanban är inte den enda metoden som används för att öka effektiviteten genom att begränsa WIP. Det finns andra system som uppnår samma resultat - till exempel CONWIP (Constant Works in Progress) och DBR (Drum-Buffer-Rope) -system, som främst är avsedda för tillverkningsindustrier.
Men Kanban är det system som bäst har modifierats för att passa programvaruindustrin.
Hur skiljer sig Kanban från smidiga metoder?
I sitt hjärta är Kanban en metodik som använder vissa delar av Agile Project Management. Många projekt inom Agile-ramverket har sina rötter i Lean-strategier. Skillnaden mellan Kanban Methodology och Agile Project Management är inte så svartvitt som förespråkarna för de två metoderna skulle få oss att tro. De har mer gemensamt än skillnader.
Den smidiga ramen är inte en absolut. Frågan är inte om lag är smidiga eller inte. Lag har ofta smidighet i varierande grad. En av metoderna för att ha mer smidighet i din mjukvaruutvecklingsprocess är att använda Kanban.
Några skillnader finns mellan Kanban och Agile-metoder. Några av funktionerna i Kanban-utvecklingen, som skiljer sig lite från Agile, är:
- Tidslinjer är inte en viktig faktor . Detta är ett tufft koncept att svepa våra huvuden runt, eftersom det verkar mycket icke-intuitivt. ”Hur arbetar du utan tidsfrister?” Frågar folk ofta. Men om varje medlem av teamet är engagerade på sin maximala effektivitet, upphör tiden att vara en faktor.
- Berättelser (uppgifter) är större än i vanliga Agile-system. Vanligtvis är historiernas längd och komplexitet längre än med ett typiskt Scrum-projekt. Eftersom fokus inte är på uppskattning av tiden, utan helt enkelt på att få processen att gå vidare, har Kanban råd att arbeta med större berättelser.
- Det finns ingen betydande förändring i befintliga processer. Principerna för Kanban för mjukvaruutveckling, som beskrivs av dess grundare, David Anderson, i sin blogg innehåller följande grundläggande principer:
-
- Börja med vad du gör nu
- Håller med att fortsätta stegvis, evolutionär förändring
- Respektera den aktuella processen, roller, ansvar och titlar
- Varje berättelse mäts i cykeltid . Projektet utvärderas inte med den traditionella Agile-beräkningen av hastighet (antalet berättelser som avslutats under en viss tid) utan genom cykeltid. Detta innebär att Kanban lägger tonvikt på hur lång tid det tog att slutföra en uppgift. Du kan ofta se en ticker på många Kanban-tavlor som nämner hur många dagar teamet tar för att avsluta en berättelse. Denna uppskattning matas in i nästa cykel.
Kanban: En styrelse, men vad annat?
Så, Kanban är ett bräde som visar oss hur berättelserna ordnas - är det till och med en så stor sak, frågar många. Det är faktiskt en hel del diskussioner om vad Kanban är och kan göra.
Är Kanban bara en metod för att hantera arbetsflödet? Eller är det något man kan använda tillsammans med Agile-metoder för maximal effektivitet? Eller kan det vara ett helt nytt sätt att hantera arbetsflöden?
Varje lag använder Kanban som de anser vara lämpliga för sin särskilda situation. Hur som helst, Kanban har potential att fungera som ett sätt att leva för mjukvaruutveckling, om den används till sin optimala nivå.
Oavsett om det används för att hantera arbetsflöde eller som ett nytt paradigm i mjukvaruutveckling förnekar det inte att det hjälper till att hantera WIP.
För att Kanban ska fungera bäst är det viktigt att tänka på det inte bara som att hantera WIP, utan som ett projekthanteringsram. Vissa grundläggande riktlinjer hjälper processen.
- Optimera lag så att inget lag startar något de inte kan avsluta. Detta hjälper processen.
- Motstå inte ändringar från det ursprungliga Kanban-systemet. Om ditt projekt klarar bra med tidsfrister och tidslinjer, integrera detsamma som du skulle göra. Detta ger en hälsosammare och mer robust utvecklingsmiljö.
- Stäng inte av teamarbetet. Kanban kan verka som, men är inte, en modell baserad på individer som arbetar isolerat. Teamarbete måste vara en integrerad del av Kanban mjukvaruutveckling.
- Tänk utanför lådan. Tänk på förändringar i arbetsflödet. Många team väljer nu Testdriven utveckling, med Acceptans Testdriven utveckling, där godkännandestesterna genomförs först med användningsfall, som sedan driver de nödvändiga funktionerna och utvecklingen.
hybrider
Eftersom fler och fler företag använder projekthanteringsverktygen som är bäst lämpade för deras specifika situation, är det inte förvånande att två av de bästa metoderna för projektledning: Scrum och Kanban, har integrerats till mycket framgång.
Hybriden, kallad Scrumban, gör intrång i många projekt.
Om en organisation redan använder Scrum, men tycker att det är svårt att hålla projektet tillsammans, antingen med att sprinten inte fungerar bra, för att testa att de inte är lufttäta, kan det vara dags att överväga Scrumban.
För att förklara det enkelt involverade Scrumban att ta ett förstoringsglas till sprinten. Det handlar inte bara om spurterna som en del av projektet, det handlar om vad som händer inom sprinten. Scrumban hjälper till att undersöka hur en berättelse behandlas inom en sprint, och det kan göra hela skillnaden.
Scrumban, eller någon av dess varianter, är en minimal förändring från befintlig praxis. Det vackra med att använda Kanban är att det kan användas med praktiskt taget alla typer av projekthanteringsmodeller: vattenfall, agile eller något däremellan.
Komma igång med Kanban
Det är lätt att komma igång med Kanban-systemet. Det är också möjligt att implementera Kanban på ett minimalt sätt som en rättegång för en viss del av ett projekt.
- Kartlägga mjukvaruutvecklingsprocessen. Gör en tydlig karta över hela processen. Hur fungerar projektet - från den ursprungliga designen, till utvecklingen, till testen, till förändringar i funktioner, i verkligheten?
- Lista ned stegen där Kanban kommer att användas. Använd stegen som är helt under din kontroll. Detta innefattar vanligtvis analys-, utvecklings-, gransknings- och testfaser.
- Arbeta med viktiga punkter som:
- Gränser till pågående arbeten för varje steg.
- Processer för snabbt / blockerat arbete
- Uppskattningar av baksidan av kuvertet med avseende på cykeltiden
- Frekvensen för Kanban styrelse / process / uppskattning granskning
- Köp en whiteboard och en bunt med Post-It-anteckningar.
- Komma igång
- Granska vid behov.
- Upprepa
Så gå vidare och kom igång med Kanban!
Var inte rädd om det inte visar sig som du ursprungligen hade tänkt dig. Hela idén bakom Agile-metodik är att tillgodose förändringar i människor och processer! Låt oss veta om dina erfarenheter av Kanban-metoden.
Rekommenderade artiklar
- 6 bästa användbara ett projektledningskontor (PMO)
- 8 användbara steg för att bygga sofistikerade berättelsekartor för ditt projekt
- De 5 viktiga värdena för extrem programmering (kraftfull)