EVEOPMENT METEN BLIJFT WETEN! - Boncode...middel om tot een goed softwareproduct te komen, geen...
2
59 DEVELOPMENT DEVELOPMENT 58 50 JAAR AG CONNECT • DECEMBER 2017 50 JAAR AG CONNECT • DECEMBER 2017 3. GESTANDAARDISEERDE PROCESSEN IT-projecten werden groter tot groots en meeslepend. Kosten liepen uit de hand. De financieel directeur werd zenuwachtig, was niet blij. Klanten kregen oplossingen die ze niet bedoelden. Het antwoord op deze out-of-controlsituatie was PRINCE2. IT’ers gingen samen met de gebruikers- organisatie gestructureerd werken. PRINCE2 gaf de manager, boekhouder en controller het gevoel van controle. Managers moesten op de hoogte gehouden worden, via dikke rapportages. Als er iets misging, werd een exceptionrapport gemaakt. Alles moest in fases, via omschreven processen. Besturing kwam terecht bij ‘de stuurgroep’. De senior engineer, supplier, user deden hun intrede. IT werd een gecontroleerd proces, op standaardwijze uitgevoerd, top-down, duidelijk, helder. Al was het organisatorisch wel wat omvangrijk af en toe. 4. BEHEERSBARE EN MEETBARE IT De volgende ronde waren de KPI’s. Men ging meten en administreren. De ontwikkelaars moesten met de billen bloot. Uren boeken, want dat was voortgang en sturing. Als de helft van de Het thema van dit nummer is vijftig jaar IT. Van die vijftig jaar hebben de auteurs ruim dertig jaar mee mogen maken. Terugkijkend zijn zij, net als collega- IT’ers, door een aantal fases heen gegaan. Fases van toenemende volwassenheid. Methoden als COBIT bewijzen in dit opzicht hun diensten. Als rode draad door dit artikel loopt het meetbaar maken van IT en het sturen daarop. De volgende volwassenheidsniveaus worden gebruikt: 1. Ad hoc, 2. Intuïtief en herhaald hetzelfde kunnen doen, 3. Gestandaardiseerde processen, 4. Meetbare en beheerste processen en 5. Excellent. Meten is gelieerd aan een hoge mate van volwassenheid: niveau 4. Of kunnen we meten vergeten? 1. AD HOC Vroeger was alles beter. Of toch niet? In de begindagen van IT had de ont- wikkelaar vrijheid en was het geregeld chaos. Maar dat gaf niet. Anderhalve man en een paardenkop zaten op domme terminals administratieve programma’s te schrijven. Boekhoudingen en leden- administraties werden geautomatiseerd, we waren op stoom en de klant was blij. Sterker nog, zij waren onder de indruk van de IT-specialist. IT’ers waren introvert en misschien zijn zij dat nog steeds. Metrieken? Niet nodig, uren verstookt was, betekende het dat de helft van de toepassing klaar was. Nu weten we beter. Taken en functies werden opgesplitst. Alles werd een vak. Je was projectleider of ontwerper, systeemanalist of pro- grammeur, tester of documentalist. En er kwam management, overleg, en nog meer management en overleg. De klanten moesten wachten op onze bigbanginvoering, alles zou anders worden daarna. En zij hebben gewacht. Soms lang. Of nog langer. Voorzien van rapportages rond uren, uren per fase, uren per moduul en functiepunten. En als het bijna af was, kwam de bood- schap dat het nog niet af was. En dan kwam er een onderhandeling over meer uren, over tijd en geld. 5. EXCELLENT HAALDEN WE NET NIET IT werd steeds belangrijker en ging processen overnemen. Systemen werden robuust. IT maakte steeds meer mogelijk op alle fronten van de maatschappij. Het leidde tot een versnelling van financiële dienstverlening, meer efficiëntie bij de overheid en enorme informatie- voorziening voor het individu. En toch waren gebruikers vaak niet blij. Kregen ze niet wat ze eigenlijk bedoelden. IT moest sneller ontwikkeld worden, vaker, effectiever, wendbaarder. geen aanleiding voor. Architectuur werd door hardware-eisen afgedwongen en was dus eenduidig. Projectmanagement? We deden het gewoon. IT’ers waren professionals, de pioniers. We waren god. 2. INTUÏTIEF WERKEND EN HERHAALD HETZELFDE KUNNEN DOEN Tja, dat kon natuurlijk niet lang duren. Projecten werden groter. Moeten we niet eerst nadenken? Moeten we iets van structuur aanbrengen, een fasering? De informatieanalyse deed haar intree. Methoden als SDM kwamen op. Er werden omvangrijke documenten gemaakt, met veel tekst en schema’s. We legden die voor aan de gebruiker/klant en vroegen om een handtekening. Dan was tenminste duidelijk wat men wilde. En vervolgens ging de ontwikkelaar gewoon lekker aan de gang en creëerde de software die voldeed aan de beelden in zijn hoofd. Er kwamen ontwikkelteams die ervaring kregen. IT kwam in de tweede volwassen- heidsfase: het wiel hoefde niet elke keer opnieuw uitgevonden te worden. Men herhaalde dezelfde trucs tig keer – er werd geplakt en geknipt. Maar individuele kennis en vaardigheden bleven, net als in de ad-hocfase, fundamenteel voor het resultaat. De systemen werden sneller en iets gebruiksvriendelijker. Diverse bedrijven en professionals worstelen met het vinden van nieuwe meetmethoden die passen bij agile werken. Maar, zeggen Joost Koen en Erik Pepping, in plaats van uitputtende metingen aan het proces, is het veel effectiever om aan het product en het gebruik ervan te meten. Het niveau ‘Excellent’ komt meer dan ooit in beeld. door Joost Koen en Erik Pepping beeld Shutterstock JOOST KOEN ([email protected]) is medeoprichter van Boncode Software Remediation BV, dat zich richt op verduurzaming en vernieuwing van bestaande software- systemen op basis van meten, analyseren en verbeteren. ERIK PEPPING is als consultant/ interim-manager betrokken bij Boncode Software Remediation BV. AUTEURS METEN BLIJFT WETEN! OM IT EFFECTIEF IN TE ZETTEN, IS HET METEN VAN DE TOEGEVOEGDE BUSINESSWAARDE ESSENTIEEL
Transcript of EVEOPMENT METEN BLIJFT WETEN! - Boncode...middel om tot een goed softwareproduct te komen, geen...
59
DEVELOPMENTDEVELOPMENT
5850 JAAR AG CONNECT • DECEMBER 2017 50 JAAR AG CONNECT • DECEMBER 2017
3. GESTANDAARDISEERDE PROCESSENIT-projecten werden groter tot groots en meeslepend. Kosten liepen uit de hand. De financieel directeur werd zenuwachtig, was niet blij. Klanten kregen oplossingen die ze niet bedoelden. Het antwoord op deze out-of-controlsituatie was PRINCE2. IT’ers gingen samen met de gebruikers-organisatie gestructureerd werken. PRINCE2 gaf de manager, boekhouder en controller het gevoel van controle. Managers moesten op de hoogte gehouden worden, via dikke rapportages. Als er iets misging, werd een exceptionrapport gemaakt. Alles moest in fases, via omschreven processen. Besturing kwam terecht bij ‘de stuurgroep’. De senior engineer, supplier, user deden hun intrede. IT werd een gecontroleerd proces, op standaardwijze uitgevoerd, top-down, duidelijk, helder. Al was het organisatorisch wel wat omvangrijk af en toe.
4. BEHEERSBARE EN MEETBARE ITDe volgende ronde waren de KPI’s. Men ging meten en administreren. De ontwikkelaars moesten met de billen bloot. Uren boeken, want dat was voortgang en sturing. Als de helft van de
Het thema van dit nummer is vijftig jaar IT. Van die vijftig jaar hebben de auteurs ruim dertig jaar mee mogen maken. Terugkijkend zijn zij, net als collega- IT’ers, door een aantal fases heen gegaan. Fases van toenemende volwassenheid. Methoden als COBIT bewijzen in dit opzicht hun diensten. Als rode draad door dit artikel loopt het meetbaar maken van IT en het sturen daarop. De volgende volwassenheidsniveaus worden gebruikt: 1. Ad hoc, 2. Intuïtief en herhaald hetzelfde kunnen doen, 3. Gestandaardiseerde processen, 4. Meetbare en beheerste processen en 5. Excellent. Meten is gelieerd aan een hoge mate van volwassenheid: niveau 4. Of kunnen we meten vergeten?
1. AD HOCVroeger was alles beter. Of toch niet? In de begindagen van IT had de ont-wikkelaar vrijheid en was het geregeld chaos. Maar dat gaf niet. Anderhalve man en een paardenkop zaten op domme terminals administratieve programma’s te schrijven. Boekhoudingen en leden-administraties werden geautomatiseerd, we waren op stoom en de klant was blij. Sterker nog, zij waren onder de indruk van de IT-specialist. IT’ers waren introvert en misschien zijn zij dat nog steeds. Metrieken? Niet nodig,
uren verstookt was, betekende het dat de helft van de toepassing klaar was. Nu weten we beter.Taken en functies werden opgesplitst. Alles werd een vak. Je was projectleider of ontwerper, systeemanalist of pro-grammeur, tester of documentalist. En er kwam management, overleg, en nog meer management en overleg.De klanten moesten wachten op onze bigbanginvoering, alles zou anders worden daarna. En zij hebben gewacht. Soms lang. Of nog langer. Voorzien van rapportages rond uren, uren per fase, uren per moduul en functiepunten. En als het bijna af was, kwam de bood-schap dat het nog niet af was. En dan kwam er een onderhandeling over meer uren, over tijd en geld.
5. EXCELLENT HAALDEN WE NET NIETIT werd steeds belangrijker en ging processen overnemen. Systemen werden robuust. IT maakte steeds meer mogelijk op alle fronten van de maatschappij. Het leidde tot een versnelling van financiële dienstverlening, meer efficiëntie bij de overheid en enorme informatie-voorziening voor het individu. En toch waren gebruikers vaak niet blij. Kregen ze niet wat ze eigenlijk bedoelden. IT moest sneller ontwikkeld worden, vaker, effectiever, wendbaarder.
geen aanleiding voor. Architectuur werd door hardware-eisen afgedwongen en was dus eenduidig. Projectmanagement? We deden het gewoon. IT’ers waren professionals, de pioniers. We waren god.
2. INTUÏTIEF WERKEND EN HERHAALD HETZELFDE KUNNEN DOENTja, dat kon natuurlijk niet lang duren. Projecten werden groter. Moeten we niet eerst nadenken? Moeten we iets van structuur aanbrengen, een fasering? De informatieanalyse deed haar intree. Methoden als SDM kwamen op. Er werden omvangrijke documenten gemaakt, met veel tekst en schema’s. We legden die voor aan de gebruiker/klant en vroegen om een handtekening. Dan was tenminste duidelijk wat men wilde. En vervolgens ging de ontwikkelaar gewoon lekker aan de gang en creëerde de software die voldeed aan de beelden in zijn hoofd.Er kwamen ontwikkelteams die ervaring kregen. IT kwam in de tweede volwassen-heidsfase: het wiel hoefde niet elke keer opnieuw uitgevonden te worden. Men herhaalde dezelfde trucs tig keer – er werd geplakt en geknipt. Maar individuele kennis en vaardigheden bleven, net als in de ad-hocfase, fundamenteel voor het resultaat. De systemen werden sneller en iets gebruiksvriendelijker.
Diverse bedrijven en professionals worstelen met het vinden van nieuwe meetmethoden die
passen bij agile werken. Maar, zeggen Joost Koen en Erik Pepping, in plaats van uitputtende metingen
aan het proces, is het veel effectiever om aan het product en het gebruik ervan te meten. Het niveau
‘Excellent’ komt meer dan ooit in beeld. door Joost Koen en Erik Pepping beeld Shutterstock
JOOST KOEN ([email protected]) is medeoprichter van Boncode Software Remediation BV, dat zich richt op verduurzaming en vernieuwing van bestaande software-systemen op basis van meten, analyseren en verbeteren.
ERIK PEPPING is als consultant/interim-manager betrokken bij Boncode Software Remediation BV.
AUTEURS
METENBLIJFT WETEN!
OM IT EFFECTIEF IN TE ZETTEN,
IS HET METEN VAN DE TOEGEVOEGDE BUSINESSWAARDE
ESSENTIEEL
2004• Facebook wordt opgericht; aanvankelijk
een ‘smoelenboek’ voor de universiteit van techneut Mark Zuckerberg.
50 JAAR AG CONNECT • DECEMBER 2017 50 JAAR AG CONNECT • DECEMBER 201761
MANAGEMENTMANAGEMENT
60
managerial controle moet dan ook worden beantwoord met een wedervraag: waarom is het aantal uren op dit (unieke) product te veel? En als we er een bepaald budget voor overhebben, moeten we dan niet eerder denken aan vermindering van de scope als we het niet halen? Het werd kennelijk onderschat.De mondige IT’er pareert: investeer in het team, stimuleer een cultuur van samenwerking. Investeer in het kennis-niveau van de individuele leden, dan gaat het creëren van unieke producten sneller. En of het sneller is dan de vorige keer weten we niet, als we eerlijk zijn. Softwareontwikkeling betreft eigenlijk altijd een uniek stuk werk. Als het niet uniek is, is het commodity en moeten we het gewoon kopen.
METEN BLIJFT WETENMonitoring impliceert meten ten opzichte van een norm. Dit geeft de mogelijkheid om ‘factbased’ inzicht te krijgen, excepties te onderkennen en waar nodig bij te sturen. In plaats van afrekenen is de passende attitude in de agile wereld om samen voortdurend naar verbetering te streven. Een ontwikkelproces is een
MONITORINGAgile werkwijzen werden en worden ingevoerd. Standaard en toch flexibel, gericht op samenwerking met de klant, teamvorming, kortcyclisch ontwikkelen, open communicatie. Weg met de rigide langdurige processen en projecten. En weg met het meten?Soms krijgen wij die indruk. Het begrip ‘productiviteit’ wordt direct geassocieerd met de afrekencultuur die te vaak het gevolg was van de introductie van KPI’s. Hoeven we de stap naar het vierde niveau, waarin meten cruciaal staat, niet meer te maken? Zijn we volwassen genoeg?Diverse bedrijven en professionals worstelen met het vinden van nieuwe meetmethoden passend bij agile werk-wijzen. Op control ingestelde besturen verwachten nog te vaak dezelfde metingen: Productiviteit per team? Productiviteit per medewerker? Hoeveel functiepunten? Hoe doen we het ten opzichte van andere spelers in het domein?Voor een agile georganiseerde IT-afdeling valt het niet mee deze cijfers op te hoesten. Dit strookt niet met de net verworven cultuur van vertrouwen, hulpvaardigheid, vakmanschap. Verondersteld wordt dat specialisten zelf de beste afwegingen maken om een kwalitatief goed product te maken en niet belast worden met veel administratieve rompslomp.De vraag om uren te schrijven vanwege
middel om tot een goed softwareproduct te komen, geen doel. In plaats van uitputtende metingen aan het proces, is het veel effectiever om aan het product en het gebruik van het product te meten. Deze metingen geven vanzelf richting aan het ontwikkel-, test- en beheerproces.Om de toekomstbestendigheid te garanderen, is het belangrijk om de intrinsieke kwaliteit van het software-product te meten en normen te stellen. Normen die je natuurlijk in overleg met de betrokkenen bepaalt. De intrinsieke kwaliteit betreft bijvoorbeeld de code-kwaliteit en de softwarearchitectuur die feitelijk geïmplementeerd is. Juist deze laatste is bepalend voor de toekomst-bestendigheid (zie ‘Softwarearchitectuur onderbelicht’ van Jeroen Meetsma, AG Connect februari 2017).Om IT effectief in te zetten, is het meten van de toegevoegde businesswaarde
essentieel. Wat brengt de software concreet op in termen van geld, efficiëntie of marktuitbreiding? Essentieel is te denken vanuit de klant en het liefst de eindgebruiker. Dit is een leerproces, zowel voor business- als IT-mensen.
EXCELLENTHet volwassenheidsniveau ‘Excellent’ komt meer dan ooit in beeld. IT’ers zijn zich in toenemende mate bewust van het primaat van de klant. We gaan van een focus op techniek en projectmatigheid naar de creatie van concrete producten. De klant heeft daar direct baat bij. Inzet van IT wordt cruciaal voor de concurrentie positie van een bedrijf. De focus ‘naar buiten’ van de van oudsher introverte IT en het voorkomen van grootse en meeslepende projecten maken excellent acteren mogelijk.
“Inzet van IT is cruciaal voor
concurrentiepositie”
Normen bepaal je in overleg met de betrokkenen
REACTIES EN BIJDRAGENVoor reacties en nieuwe bijdragen van IT-experts: Henk [email protected]
In het maturitymodel zien we twee verschuivingen die min of meer gelijk opgaan. Van het meten op output naar productgebaseerde outcomemetingen. De efficiency van de IT neemt toe.
WIE IS IN CONTROLE?
METEN
NIETS
ENGINEERS
UREN / VOORTGANG
MANAGERS / AUDITORS
FP, VELOCITY / STORYPOINTS
IT / BUSINESS
INTRINSIEK / BUSINESS VALUE / KLANTTEVREDENHEID
KLANT / EINDGEBRUIKER
BUSI
NES
S VA
LUE
LEAN THINKING
COST OF BUSINESS VALUE DELIVERY
CHAOS PROJECT ORIENTED AGILE ORIENTEDPRODUCT ORIENTED, CONTINUOUS VALUE DELIVERY
