Planview-bloggen

Din väg till smidighet i affärsverksamheten

Work Management för team

Identifiering av flaskhalsar med hjälp av köer

Publicerad Av Tommy Norman

Varje process har oundvikligen en flaskhals: Det finns något steg som har lägre kapacitet än de steg som föregår eller följer efter det. Det kan bero på att det finns färre resurser för detta steg eller att det tar längre tid att genomföra än de andra stegen i processen. Oavsett detta är denna flaskhals den begränsande faktorn för hela systemets kapacitet.

Flaskhalsar utgör ett allvarligt hot mot flödet. De främjar slösaktiga vanor som att byta sammanhang, vilket gör att leveransen av värde blir långsammare. Det första steget för att eliminera en flaskhals är att identifiera den, men det är ofta lättare sagt än gjort.

En väl utformad Kanban-tavla kan ge värdefulla insikter om teamets flöde - var ni levererar snabbt och var arbetet hopar sig. Genom att införa köbanor kan du hjälpa dig att hitta den specifika orsaken till flaskhalsarna, så att du kan närma dig kontinuerlig leverans.

Grundläggande layout av kretskortet

Nedanstående exempel på ett bräde visar en enkel process för att utveckla en programvarufunktion. Det börjar med en backlog för allt nytt arbete som kommer in i teamets arbetsflöde. Därefter följer de fyra grundläggande stegen i detta arbete: Analysera, utveckla, testa och distribuera. Varje kort på denna tavla representerar oberoende funktioner som teamet levererar.

Kanban främjar ett pull-system, där teamet bara tar in nytt arbete när de har tillräckligt med kapacitet. Detta säkerställer att teamet och individerna inom teamet håller sig under sina WIP-gränser (läs vår serie i tre delar om WIP-gränser här).

I det här exemplet är det dubbelt så mycket arbete i utvecklingsfilen som i någon annan fil, vilket kan tyda på en flaskhals i utvecklingen. Det är viktigt att ha ett samtal om arbetet för att förstå hur verkligheten ser ut. En del av arbetet i utvecklingsfilen kan vara i gång, men en del av arbetet kan också vänta på att flyttas över till nästa fil. Den här styrelsens utformning skiljer inte mellan dessa två tillstånd.

Lägga till köbanor

Vi kan göra denna avgränsning genom att lägga till två delsträckor för varje arbetssträcka: I gång och Färdiga. Dessa nya Done-underfiler representerar arbete i kö som väntar på att dras in i nästa fil när det finns kapacitet. Du kan också höra att köbanor kallas buffertbanor eller väntbanor. Genom att lägga till dessa köbanor kan vi se att utvecklingen inte har problem med för mycket arbete, utan att våra testare är överväldigade och inte har kapacitet att ta fram nytt arbete.

Genom att visualisera våra köer kan vi omedelbart se den verkliga flaskhalsen - i teststeget, inte i utvecklingssteget som vi kanske hade trott.

Undvika dubbla köer

När du ser fördelarna med dessa köbanor för "färdig" kan du bli frestad att lägga till fler köbanor, t.ex. en köbana uppströms (redo) för att identifiera arbete som teamet har tagit fram men ännu inte påbörjat. Motstå denna frestelse. Det skapar dubbla köer som representerar samma tillstånd som det föregående steget Done. Om du lägger till dessa körfält kan det bli svårare att se flaskhalsar, eftersom arbetet som samlas upp kan vara fördelat på två körfält och kanske inte är lika uppenbart.

Dubbla köer kan också uppmuntra grupper att skjuta arbete från sin Done lane till den nedströms belägna Ready lane, vilket gör att vi går ifrån det pull-system som vi försöker främja med Kanban.

Avslutande reflektioner

Med köbanor är det lätt att se skillnaden mellan arbete som verkligen pågår och arbete som väntar på att dras in i nedströmsbanan. När du har lagt till köbanor kan du implementera WIP-gränser som exakt återspeglar den verkliga kapaciteten i ditt team. Den här förståelsen för teamets unika process hjälper dig att fortsätta att maximera flödet - och närma dig kontinuerlig leverans.

Relaterade inlägg

Skrivet av Tommy Norman

Tommy är Lean/Agile Coach på LeanKit och ser till att vi lever upp till de värderingar och principer som ligger bakom vår produkt. Han är chef för användargruppen Agile Nashville och Music City Agile-konferensen och talar ofta vid lokala och nationella evenemang. Tommy är en 9 gånger Microsoft MVP. Hans Agile-utbildningsserie har varit den mest sålda Agile-videon på Safari Books Online de senaste två åren. Du kan kontakta honom på @tommynorman.