zondag 23 juni 2013

KANBAN in s/w development (2)

KANBAN in s/w development wijkt af van  Kanban in productie. Hoewel het beide visuele planning systemen zijn met kaarten, zijn er ook significante verschillen.






Let goed op de flow in de onderstaande videos. De Kanban in productie is duidelijk een 'pull'. En hoewel het gezegd wordt in de video in KANBAN in s/w development een 'pull' is, is het duidelijk een 'do-not-over-push'!

Kanban in productie


KANBAN in s/w development



Er zijn nog een paar andere grote verschillen.

Kanban in productie, vanwege het moeten kunnen reageren op onvoorspelbare vraag, vereist dat de beschikbare capaciteit groter is dan de gevraagde capaciteit. In simpel Nederlands: mensen en machines moeten stil staan van tijd tot tijd; overcapaciteit.

In productie is het precies bekend wat er moet gebeuren in elke stap: zowel het (tussentijdse) resultaat is gedefineerd als hoe gewerkt moet worden. Elke medewerker met de juiste training kan halverwege het proces op een werkstation instappen en zonder veel na te denken het werk direct overnemen. Standardissatie, routine, meer van het zelfde zijn hierbij sleutelbegrippen.

Zowel overcapaciteit als standaardisatie zijn twee vereisten voor Kanban in productie. Echter overcapaciteit en standaardisatie zijn niet aanwezig in s/w development.

Het 'do-not-overpush' mechanisme is niet aanwezig in Kanban voor productie. Het 'kaart'-mechanisme in Kanban voor productie maakt het onmogelijk om meer te vragen dan het aantal 'kaarten' dat beschikbaar is. Het aantal beschikbare kaarten is gelimiteerd door het ontwerp van het systeem.

Er is echter één vereiste dat noodzakelijk is voor KANBAN in s/w development die niet vaak benoemd wordt:: use cases moeten onafhankelijk zijn.

Korte iteratie cycli reduceren de afhankelijkheid tussen use cases in en zelfs tussen iteratie cycli. Echter naar mate de iteratie cycli langer worden, gaan afhankelijkheden tussen use cases meer en meer een rol spelen en limiteert het de werkbaarheid van KANBAN voor ICT zoals het nu is.

Zelfs met, misschien wel door, korte iteratie cycli, moet men bereidt zijn om werk na een poosje 'weg te gooien' of 'opnieuw' te doen door de komst van additionele, nieuwe of veranderingen in use cases. Deze vorm van verspilling is de noodzakelijke consequentie van het niet 'ver' in de toekomst te kijken.

Overigens er zijn heel veel goede redenen waarom het beter is niet ver in de toekomst te kijken. Doorgaans de verspilling die voortvloeit uit de korte tijd horizon is vele malen kleiner dan de verspilling die voortvloeit uit een lange en vaak zelfs gemiddelde tijdshorizon.

Geen opmerkingen:

Een reactie posten