12 Kanban

Välkommen till del 12 i avsnittet Processorer och modeller. Den här delen kommer att tala om den agila metoden Kanban. Vi har i tidigare delar tittat på ganska stora spel för att få agil process till Scrum som definierar hur vi ser på processen och styr den. Kanban blir ännu mindre och fokuserar ännu mer på CV flödet på arbets paket. Och hur hanterar vi det för att just förhålla oss till det här med Sustainable Pays som är Magic modell? Och Kanban har sitt ursprung i just in time filosofin hos Toyota. Här i början av 2000 talet anpassades de här tankarna till mjukvaruutveckling. Detta är någonting som fokuserar just på flödet av arbets paket som vi skulle tänka arbets paket som någonting det knyter ner till exempel och kopplar till en sprint back i Scrum eller någonting som definierar vad jobbar någon med just nu? Det kan vara behöver inte knyta samtidigt Scrum, men det är idag väldigt vanligt att man knyter samman Scrum och Kanban. Det kallas till och med för samband ibland och det här är ett sätt att säga att hur många som har arbetat paket får vara igång i varje fas där man ser olika faser i utvecklingen. Detta tar också hänsyn till att de här arbets paketen innebär någonting som de ska driftsätta. Arbets paket är något som ska införlivas och integreras i produkten och jag uppskattar den här lilla serien som ett sätt att introducera. Vad kan man kan vara? Och här ser vi att vi har vår back logg här. Vår back logg har ett antal arbets paket, i det här fallet A, B, C och så vidare. Det är inte nödvändigt ordning, men för att skilja dem åt finns ett antal arbets paket som ska göra. Vi har vår produkt under eller någon form av. Stramas som är den som prioriterar. Vad ska vi göra just nu? Och sedan i det här så har vi ett antal faser i det här. Vi har de faser. Det här är det som vi har valt ut till nästa del. Vi har det som är under utveckling och där skiljer vi på pågående och vad som är färdigt i det här. Och sen har vi det som vi håller på att driftsätta. Och så har vi var det färdigt driftsattes i igång och här ska vi lägga märke till de små numren som säger att här har vi ett antal siffror och det här talar om hur många arbets paket och finnas. Vi har prioriterat och valt ut två arbets paket här i utveckling. Finnas två arbets paket. I vår driftsättning arbetar vi endast med ett arbets paket åt gången. De här gränserna ska man då inte överskrida dem. Är någonting valt har vi valt två saker och vi inte kan flytta fram något av dem till utveckling, för där finns en ledig plats. Eller bryr vi oss om att prioritera mer från vår backlinjen så länge? Så i detta så har vi ett utvecklingsteam. Vi har vår också här som sysslar med driftsättning. Så det första som sker här, vi väljer ut två arbets paket så har vi väljer att jobba med AB. Det är de mest intressanta sakerna här. Eftersom det nu finns lediga platser i vår utveckling för de två delarna så kan vi flytta in och börja jobba med det här och vi har folk nog i vårt team. Så när a B flyttas in här till utveckling och uppfyller de två platserna vi har här så kunde vi välja sedan två nya delar som hör till släktet. Så är det här så är vi nu igång och börjar jobba. Och sedan kan vi säga att om vi jobbar och går och blev kvar så då är det någonting vi kan börja med att driftsätta. Och eftersom vi flyttade ut så hade vi plats att plocka in och se här. Så under tiden är frågan om vi börjar driftsätta. Nu stötte vi på ett problem när vi ska göra vår bild här och sätta ihop av med resten och integrerar i det vi har. Så får vi på något blev det fungerande här och det är klart vi håller på med det här så vi är inga problem. Men så länge vi har plats för hem till undersläktet som kan stå här och fundera lite och ja, så ska vi ta tag i det här nu. Nej, för att vi har vår gräns på 2. Vi har inte gjort färdigt deployment här så att det fortfarande väntar på det här. Då är tanken att man som team hjälp så som man kan gå frågar liksom. Här är det stopp i det play. Hur kan vi hjälpa till med det här? Hämta kaffe och sen tala om att som 17 betyder det här frasen vi får i felmeddelanden. Ni har skrivit koden, hjälp oss reda ut vad det här är. Så nu står vi här och jobbar med det här och sen vi som har utveckling. Vi blir klara nu med C, så ja, vad ska vi göra här? Kan vi börja med? Det kan vi inte för vi har fortfarande problem med att inte lösa den så att här står vi och väntar på någonting. Jaha, så kan vi då reda ut. Hur kan vi hjälpa till med detta om fler kockar? Sämre soppa så vi behöver inte fler problem just nu. Vi har sett det här problemet innan så ta tag i ett skrivet test så att vi inte får det här problemet i fortsättningen igen så att vi kan anpassa oss och nyttja tiden till att förbättra vår process när någonting tar stopp. Och kommer då vår chef som känner att det här är ingen tekniske chef så gå och hämta kaffe och se till att vi inte blir störda, det vill säga honom. Några andra som kommer att säga är ni inte färdiga? Nu har vi inte pluggat det här och prata med dem och ta hand om det. Och någon gång sedan som vi liksom löst och då kunde vi ta hand om play B och C och så kan det här då flyta på. Tanken här är just att man förhåller sig till den här stan till exempel. Ingen blir översvämmad med arbete och stressad av att nu ligger där, liksom det bara fylls på i B och C. Och så kommer det också allting annat, utan man hjälps åt som ett team att hela flödet ska fungera. Och. En lite grann skräckhistoria om det här är något vi ska. Vi använder Kanban, men limits ska vi inte ha. Då har man inte förstått att hela vitsen med Kanban är limits. Att det är den här begränsningen om man plockar bort begränsningen från Kanban, det man ofta talar om som sin Kanban board som är just vad som pågår. Har man ingen limit på den är det bara en lista. Och vem gör vad utan hela vitsen med Kanban kommer in med begränsar? Hur mycket får pågå samtidigt? Så det här är ett sätt att visuellt också skapa den här översikten. Vem gör vad? Man kan se spår av detta, till exempel med kollektivt ägande och ansvar i detta. Så det här är en väldigt liten process som fokuserar på. Hur håller vi ett rimligt arbetsflöde och hur skapar vi en översikt av det här arbetsflödet? Kanban är en process som vi ofta kombinerar med någonting annat för som vi säger inte kan någonting om. Hur gör vi inom utvecklingen till exempel? Så det här är ett sätt att skapa en liten kort process för att stödja arbetsflöde som är nyttigt på många olika sätt, från små projekt till stora projekt och dessa släkter develop to play. Beroende på organisation så kan man skapa fler sådana här faser om man vill som passar organisationen. Man kan också ha en större båt där man delar in det här ett team och ser Team AS flöde, Team BS flöde och så vidare. Så detta kan man göra flexibelt på olika sätt. Så Kanban är en väldigt liten process men som ändå adresserar en viktig agil princip om sustainable pays. Om översikt och ett gemensamt ansvar i det här.