Kanban

 
11 juli 2009

Een vrij bekende term uit de bedrijfskundige resource planning is overgewaaid naar de software engineering: Kanban. Kanban is een manier van plannen van resources die niet klassiek vanuit de supply-chain redeneert maar vanuit de vraaggerichte demand-chain. Je produceert dus je (half) frabricaat op basis van de vraag van de consument. Hierover is veel gepubliceerd en veruit het meest bekende voorbeeld van toepassing van dit principe is bij Toyota, die hier al sinds de jaren vijftig (!) van de vorige eeuw mee bezig is (wat lopen we toch achter bij volwassen sectoren).

Daarnaast publiceert collega Rob Vens al langer over toepassing van demand-chain redenering in systeemontwerpen zelf. Ik heb dit nu zelf meerdere keren in de praktijk toegepast en ik kan uit eigen ervaring zeggen dat deze manier van redeneren erg goed werkt om via deze methode user stories (of use cases, of scenario’s, kies er maar een) te verwerken in een bestaand structureel model. Dit werkt door vanuit je doel terug te redeneren en levert op die manier vrijwel vanzelf een optimaal executiepad.

De laatste reincarnatie van dit concept kom ik de laatste tijd steeds vaker tegen als ‘het nieuwe SCRUM’, onder de noemer Kanban zelf dus. Het is de nieuwste (nou ja, dat zal wel niet) telg in de Agile ontwikkelmethodiekenfamilie en wordt in verschillende publicaties gebracht als de meest agile manier van werken. O.a. timeboxing wordt overboord gegooid en er wordt aan een kleinere set (of maar één) userstories tegelijk gewerkt. Ik ben er nog niet helemaal uit hoe dit exact gaat werken maar interessant is het zeker. Ook in softwareontwikkeltrajecten zelf heb je namelijk vraag en aanbod, dus ze hebben een punt.

Benieuwd wanneer in deze context andere gerelateerde Japanse termen wordt omarmd als Kaizen, Muda,  Mura, Muri,… Onze bedrijfsnaam Sogyo is blijkbaar zo gek nog niet ;).


Werken met ?
Kijk dan bij onze mogelijkheden voor starters en/of ervaren IT'ers.


Categorieën: Project- & procesmanagement, Development

Tags: , , , ,