De 2e dag van LAC 2011 begon met een leuk filmpje over een jongen van 12 jaar die apps maakt. De achterliggende gedacht hiervan was: de ontwikkelingen gaan snel, en voor je het weet wordt je ingehaald door de volgende generatie.
Dit werd verder uitgewerkt in de keynote van Jan Bosch. Hij heeft onder andere bij Nokia gewerkt, maar is ook bij grote bedrijven van Silicon Valey geweest om te leren hoe ze daar software ontwikkelen. Hij benadrukte dat het vooral gaat om speed, speed, speed. Alleen bedrijven die snel kunnen ontwikkelen, aanpassen en innoveren zijn succesvol. 1 van de redenen dat het slecht met Nokia gaat is dat ze te langzaam zijn, zichzelf niet kunnen veranderen. Dit komt onder andere doordat ze te grote ontwikkelteams heeft. Andere bedrijven zoals Google, Facebook, LinkedIn, Amazon etc hebben meerdere kleine teams volgens de 2 pizza rule: een team moet genoeg hebben aan 2 pizza’s. Uiteraard verschilt dit per persoon :-) dus ter verduidelijking: niet groter dan 6 á 7 personen. Geef elk team zijn eigen verantwoordelijkheid en doel, en zorg voor een goed test systeem. De programmeurs moeten niet bang zijn om te veranderen, dus straf hem ook niet als een bug in de software zit: dit is de verantwoordelijkheid van het test systeem! Dus als je het voor elkaar krijgt om Google.com onderuit te krijgen, ben je juist goed bezig. Op deze manier kun je contineous deployen: code inchecken, automatisch testen en gelijk live! Dit is de ultime ontwikkel methode, waarbij je erg snel kunt veranderen en je ook geen versies meer hebt. Uiteraard moet je eerst contineous intergration en je test systeem goed hebben werken.
En wat betreft architectuur? Deze moet simple simple simple. Als het te ingewikkkeld wordt: opnieuw beginnen. Voor een ingewikkeld systeem een ingewikkelde architectuur maken kan elke “idioot”, maar je bent pas knap als je een simpele architectuur kunt maken!
Innoveren is ook erg belangrijk. De meeste bedrijven zijn te veel bezig met efficiëntie, terwijl dit maar relatief weinig oplevert. Als voorbeeld: je kunt beter voor 10% meer omzet zorgen dan 10% van het R&D budget bezuinigen. Een manier van innoveren is meerdere dingen tegelijk proberen, en de gebruiker laten bepalen welke het beste is. Keuzes maken op basis van data in plaats van de opinie van enkele programmeurs. Dit houdt in dat je verschillende gebruikers verschillende versies geeft en dan meet welke het beste werkt. Zo heeft Google 500 (!) verschillende kleurtinten blauw geprobeerd, en 1 speciale blauwtint zorgde voor een spectaculaire omzetgroei...
Het was een “prikkelende” keynote :-), hij was onder andere van mening dat een crisis juist goed is, omdat je juist dan extra gewongen wordt om te veranderen en innoveren en zorgt dat je scherp blijft.
Nu is bijvoorbeeld contineous deployen niet voor elk bedrijf nodig of uitvoerbaar, maar het geeft wel aan dat “het internet” continue veranderd. Dit kan ook verder doorgevoerd worden, zodat je over enkele jaren een eerste versie van een telefoon of auto koopt, en de software hiervan elke dag geupdate wordt: agile product ontwikkeling.
Deze keynote was zo ongeveer het beste van de dag, de andere sessies vielen een beetje tegen. Zo was er een sessie over een nieuwe manier van ontwikkelen volgens “principles”: bepaalde principles staan vast (soort wetmatigheden) die je niet kunt veranderen, andere principles komen voort uit bijvoorbeeld wensen van gebruikers. Belangrijk is weer te weten “het waarom”. De kernprincipes zijn belangrijk en geen lijvig dictatuur document maken.
Het was een beetje vaag en abstract, waarbij het verzande in een discussie over de exacte betekenis van “requirements” en andere muggenzifterij over woordgebruik. Vervolgens was de tijd om en kon de persoon in kwestie zijn verhaal niet afmaken...
Ik ben toen maar geswitched naar een andere sessie, waarbij uitgelegd werd hoe ze bij het UMC Radboud ziekenhuis innoveren, onder andere door de patient centraal te stellen en om feedback te vragen. Iedereen mag ideeen indienen, die gescreend worden en de beste worden uitgevoerd. De architectuur staat niet vast: anders kun je niet veranderen.
Daarna een leuk ervaringsverhaal van de ‘Port of Rotterdam’. Deze haven is erg belangrijk, en de software moest nodig vernieuwd worden (oa ivm uitbreiding van havengebied). De eerste 2 pogingen op de klassieke manier mislukte, waarna ze het over de andere boeg gooiden: geen Waterfall maar Agile, geen externe partij maar weer zelf een (klein) ontwikkelteam samen stellen. Dit team zelf de verantwoordelijkheid geven en zelf laten beslissen, ze niet te veel te beperken en eigen intiatief aanmoedigen. Dit zorgt voor creativiteit en gaan ze extra goed voor “hun kind” zorgen en worden ze enthousiast en betrokken.
Geen starre architectuur maar “just in time” wat op dat moment nodig is. Over een maand veranderd er wel weer iets of komt er iets bij dus niet te veel vooruit werken.
Een valkuil is om te veel op features te richten, maar dit zorgt voor “quality dept”: je architectuur gaat achter lopen, terwijl deze elke keer bijgewerkt moet worden als je iets tegenkomt of ergens mee bezig bent. Ze herkenden veel van de keynote van die morgen: speed, simple, kleine teams, agile, etc.
Tja, wat sommige bedrijven al niet doen om mensen te trekken... In plaats van inhoudelijke tips en trucs over architectuur hadden ze Hans Kazan ingehuurd. Deze hield vooral een verhaal over zichzelf en deed een paar goochel trucs. Niet echt waar ik van hou: of goochelaars zijn erg goed in het mensen voor de gek houden (maar hoe doen ze dat dan?), of het is echt magisch... En dan moet ik denken aan de tovenaars in de bijbel: die konden net als Mozes in Egypte stokken in slangen veranderen. En ja, ik ben een nuchtere noordeling, maar ik heb genoeg meegemaakt om te weten dat er meer is dan alleen een aarde.
Maar goed, weer “on topic”, ik was blij dat deze sessie ten einde was. Nog een sessie gevolgd over de ontwikkeling voor het Landelijk Register Kinderopvang. Echter weinig inhoudelijk en technisch, en ook hierin discussies over andere details, zodat de tijd weer snel voorbij was :-(.
Wel leuk om te horen dat ze het project binnen 2 maanden gereed hadden door Agile (SCRUM) te gebruiken. Anders was het (net als zoveel andere (overheids)projecten) niet gelukt. Ook het opsplitsen van verschillende onderdelen maakte het overzichtelijk en eenvoudiger.
Als laatste nog weer geprobeerd om wat van “principles” op te steken, zoals die door het Kadaster intern gebruikt wordt. Ook hier een algemeen verhaal en meer bedrijfsmatig, leuk om te horen hoe zij het doen, maar niet nuttig (lees: technisch) voor mijzelf.
Tot slot nog een tip (die ik bij het LAC opgedaan heb): als je mooie gelikte presentaties wilt laten zien, iets anders dan Powerpoint, probeer dan een http://prezi.com/. Presentaties worden dan niet meer saai en lineair maar interactief, met mooie zoom en scroll effecten, bijvoorbeeld deze (druk op de play knop om 1 stap vooruit te gaan, of ergens in de presentatie zelf om daar naar toe te springen).
Dit werd verder uitgewerkt in de keynote van Jan Bosch. Hij heeft onder andere bij Nokia gewerkt, maar is ook bij grote bedrijven van Silicon Valey geweest om te leren hoe ze daar software ontwikkelen. Hij benadrukte dat het vooral gaat om speed, speed, speed. Alleen bedrijven die snel kunnen ontwikkelen, aanpassen en innoveren zijn succesvol. 1 van de redenen dat het slecht met Nokia gaat is dat ze te langzaam zijn, zichzelf niet kunnen veranderen. Dit komt onder andere doordat ze te grote ontwikkelteams heeft. Andere bedrijven zoals Google, Facebook, LinkedIn, Amazon etc hebben meerdere kleine teams volgens de 2 pizza rule: een team moet genoeg hebben aan 2 pizza’s. Uiteraard verschilt dit per persoon :-) dus ter verduidelijking: niet groter dan 6 á 7 personen. Geef elk team zijn eigen verantwoordelijkheid en doel, en zorg voor een goed test systeem. De programmeurs moeten niet bang zijn om te veranderen, dus straf hem ook niet als een bug in de software zit: dit is de verantwoordelijkheid van het test systeem! Dus als je het voor elkaar krijgt om Google.com onderuit te krijgen, ben je juist goed bezig. Op deze manier kun je contineous deployen: code inchecken, automatisch testen en gelijk live! Dit is de ultime ontwikkel methode, waarbij je erg snel kunt veranderen en je ook geen versies meer hebt. Uiteraard moet je eerst contineous intergration en je test systeem goed hebben werken.
En wat betreft architectuur? Deze moet simple simple simple. Als het te ingewikkkeld wordt: opnieuw beginnen. Voor een ingewikkeld systeem een ingewikkelde architectuur maken kan elke “idioot”, maar je bent pas knap als je een simpele architectuur kunt maken!
Innoveren is ook erg belangrijk. De meeste bedrijven zijn te veel bezig met efficiëntie, terwijl dit maar relatief weinig oplevert. Als voorbeeld: je kunt beter voor 10% meer omzet zorgen dan 10% van het R&D budget bezuinigen. Een manier van innoveren is meerdere dingen tegelijk proberen, en de gebruiker laten bepalen welke het beste is. Keuzes maken op basis van data in plaats van de opinie van enkele programmeurs. Dit houdt in dat je verschillende gebruikers verschillende versies geeft en dan meet welke het beste werkt. Zo heeft Google 500 (!) verschillende kleurtinten blauw geprobeerd, en 1 speciale blauwtint zorgde voor een spectaculaire omzetgroei...
Het was een “prikkelende” keynote :-), hij was onder andere van mening dat een crisis juist goed is, omdat je juist dan extra gewongen wordt om te veranderen en innoveren en zorgt dat je scherp blijft.
Nu is bijvoorbeeld contineous deployen niet voor elk bedrijf nodig of uitvoerbaar, maar het geeft wel aan dat “het internet” continue veranderd. Dit kan ook verder doorgevoerd worden, zodat je over enkele jaren een eerste versie van een telefoon of auto koopt, en de software hiervan elke dag geupdate wordt: agile product ontwikkeling.
Deze keynote was zo ongeveer het beste van de dag, de andere sessies vielen een beetje tegen. Zo was er een sessie over een nieuwe manier van ontwikkelen volgens “principles”: bepaalde principles staan vast (soort wetmatigheden) die je niet kunt veranderen, andere principles komen voort uit bijvoorbeeld wensen van gebruikers. Belangrijk is weer te weten “het waarom”. De kernprincipes zijn belangrijk en geen lijvig dictatuur document maken.
Het was een beetje vaag en abstract, waarbij het verzande in een discussie over de exacte betekenis van “requirements” en andere muggenzifterij over woordgebruik. Vervolgens was de tijd om en kon de persoon in kwestie zijn verhaal niet afmaken...
Ik ben toen maar geswitched naar een andere sessie, waarbij uitgelegd werd hoe ze bij het UMC Radboud ziekenhuis innoveren, onder andere door de patient centraal te stellen en om feedback te vragen. Iedereen mag ideeen indienen, die gescreend worden en de beste worden uitgevoerd. De architectuur staat niet vast: anders kun je niet veranderen.
Daarna een leuk ervaringsverhaal van de ‘Port of Rotterdam’. Deze haven is erg belangrijk, en de software moest nodig vernieuwd worden (oa ivm uitbreiding van havengebied). De eerste 2 pogingen op de klassieke manier mislukte, waarna ze het over de andere boeg gooiden: geen Waterfall maar Agile, geen externe partij maar weer zelf een (klein) ontwikkelteam samen stellen. Dit team zelf de verantwoordelijkheid geven en zelf laten beslissen, ze niet te veel te beperken en eigen intiatief aanmoedigen. Dit zorgt voor creativiteit en gaan ze extra goed voor “hun kind” zorgen en worden ze enthousiast en betrokken.
Geen starre architectuur maar “just in time” wat op dat moment nodig is. Over een maand veranderd er wel weer iets of komt er iets bij dus niet te veel vooruit werken.
Een valkuil is om te veel op features te richten, maar dit zorgt voor “quality dept”: je architectuur gaat achter lopen, terwijl deze elke keer bijgewerkt moet worden als je iets tegenkomt of ergens mee bezig bent. Ze herkenden veel van de keynote van die morgen: speed, simple, kleine teams, agile, etc.
Tja, wat sommige bedrijven al niet doen om mensen te trekken... In plaats van inhoudelijke tips en trucs over architectuur hadden ze Hans Kazan ingehuurd. Deze hield vooral een verhaal over zichzelf en deed een paar goochel trucs. Niet echt waar ik van hou: of goochelaars zijn erg goed in het mensen voor de gek houden (maar hoe doen ze dat dan?), of het is echt magisch... En dan moet ik denken aan de tovenaars in de bijbel: die konden net als Mozes in Egypte stokken in slangen veranderen. En ja, ik ben een nuchtere noordeling, maar ik heb genoeg meegemaakt om te weten dat er meer is dan alleen een aarde.
Maar goed, weer “on topic”, ik was blij dat deze sessie ten einde was. Nog een sessie gevolgd over de ontwikkeling voor het Landelijk Register Kinderopvang. Echter weinig inhoudelijk en technisch, en ook hierin discussies over andere details, zodat de tijd weer snel voorbij was :-(.
Wel leuk om te horen dat ze het project binnen 2 maanden gereed hadden door Agile (SCRUM) te gebruiken. Anders was het (net als zoveel andere (overheids)projecten) niet gelukt. Ook het opsplitsen van verschillende onderdelen maakte het overzichtelijk en eenvoudiger.
Als laatste nog weer geprobeerd om wat van “principles” op te steken, zoals die door het Kadaster intern gebruikt wordt. Ook hier een algemeen verhaal en meer bedrijfsmatig, leuk om te horen hoe zij het doen, maar niet nuttig (lees: technisch) voor mijzelf.
Tot slot nog een tip (die ik bij het LAC opgedaan heb): als je mooie gelikte presentaties wilt laten zien, iets anders dan Powerpoint, probeer dan een http://prezi.com/. Presentaties worden dan niet meer saai en lineair maar interactief, met mooie zoom en scroll effecten, bijvoorbeeld deze (druk op de play knop om 1 stap vooruit te gaan, of ergens in de presentatie zelf om daar naar toe te springen).
Geen opmerkingen:
Een reactie posten