Karel van de Meent is trainer en senior consultant bij DNV-Cibit op het gebied van prestatieverbeteringen. Hij heeft ervaring bij de ontwikkeling van realtime embedded systemen. Als projectleider van multidisciplinaire projecten heeft hij ervaren welke methodes en technieken succesvol zijn en welke niet.

6 September 2011

Hoewel Agile al jaren aan een opmars bezig is, blijven veel embedded-bedrijven via het traditionele watervalmodel ontwikkelen – vooral als ze ook hardware ontwerpen. Karel van de Meent legt uit wat Agile inhoudt en hoe embedded-bedrijven van de verschillende methodes kunnen profiteren – en hoe traditionele modellen als CMMI Agile kunnen aanvullen.

In tien jaar tijd is het aantal embedded systemen vertienvoudigd tot meer dan vijfhonderd per gezin. Negentig procent van de chips zit in huishoudelijke apparaten zoals wasmachines en afstandsbedieningen. De prestaties en stabiliteit per systeem zijn in die tijd sterk toegenomen en de time-to-market is drastisch ingekort. De bedrijven die in deze omstandigheden weten te overleven of hier zelfs in vooroplopen, onderscheiden zich in hun vermogen te anticiperen op veranderingen, hun openheid voor continue verbeteringen en hun duidelijke visie en stabiele basis van waaruit ze ontwikkelen.

In de embedded-wereld wordt traditioneel nog veel met de waterval ontwikkeld, met de nodige problemen. Veel tijd gaat zitten in het doorlopen van alle fases, informatie gaat verloren door de vele overdrachten, wijzigingen hebben grote impact op de kosten en de doorlooptijd. Tegelijkertijd blijkt dat de opdrachtgever last heeft van ’voortschrijdend inzicht‘ en de ontwikkelaar inzichten wil bijsturen naarmate hij meer bekend raakt met de technologie en de omstandigheden. Zeker naarmate de doorlooptijd van een project groter is. Elke wijziging die een klant wil, wordt aangegrepen om zo veel meerwerk en extra doorlooptijd te claimen dat ook de eigen tegenvallers worden verdisconteerd in de aanbieding voor ’extra werk‘.

Om deze problemen op te lossen, moet met een aantal paradigma‘s worden gebroken. Een (onterecht) gevoel van ’alles onder controle‘ moet worden omgebogen naar een situatie waarin intensief wordt samengewerkt en ieder dat doet waar hij goed in is. En naar iteratief werken en snelle leercycli, zodat eenvoudig met wijzigingen kan worden omgegaan en het geleerde direct kan worden toegepast. Een Agile-werkwijze.

Vrijbrief

Binnen Agile zijn verschillende methodes, processen en technieken beschikbaar, elk met hun eigen kracht maar gebruikmakend van dezelfde principes. Zo is Scrum het best toepasbaar voor de ontwikkeling van software in teams. Een goed Scrumteam bestaat uit mensen die verschillende disciplines afdekken en als vakmensen prima in staat zijn hun eigen werk te doen. Het draait hierbij meer om het team en het maken van afspraken over de samenwerking met elkaar en met de buitenwereld dan om in detail vast te leggen hoe een software-engineer software moet maken. Door de korte lijnen is het eenvoudig om toelichtingen te vragen (aan degene die het betreft of aan het team) indien niet helemaal duidelijk is wat verwacht wordt. Eisen worden vastgelegd in user stories waarin de relatie tussen eis, stakeholder en doel helder is, zodat het team de eis goed kan beoordelen en in kan schatten op kosten, risico en realiseerbaarheid. Dat voorkomt onnodig complexe of zelfs verkeerde oplossingen doordat de engineer iets anders ontwikkelt dan gewenst. De documentatie die moet worden gemaakt, kan zich meer richten op het product dan op het vastleggen van alle tussenstappen.

 advertorial 

Free webinar ‘Modernizing your code base with C++20’

As many production tool chains now adopt C++20 features, the potential this brings is unlocked. What advantages can recent versions offer to your code base? In this webinar we’ll look at the great improvements C++ has gone through and how features like concepts and ranges can transform your code. Register for video access.

Door in korte iteraties te werken (twee tot vier weken) kan snel businesswaarde worden gecreëerd. Door dagelijks even met elkaar de voortgang door te nemen, wordt het student syndrome voorkomen waarbij pas met de taak wordt begonnen als de deadline nadert. De opdrachtgever geeft aan wat de belangrijkste eisen zijn. Die worden als eerste opgepakt en al snel is het resultaat te zien door de functionaliteit te demonstreren. De stakeholders kunnen terugkoppelen of het voldoet aan de verwachtingen, of waar aanpassingen gewenst zijn. Die kunnen eventueel al in de volgende iteratie worden meegenomen. Ook kunnen er nieuwe inzichten zijn ontstaan in de tussentijd, bijvoorbeeld nieuwe of juist vervallen eisen. Omdat de eisen die nog niet boven aan de prioriteitenlijst staan ook nog niet in detail zijn uitgewerkt en zijn ingepland, is het relatief eenvoudig om het project bij te sturen.

Valkuil is hierbij wel dat het een vrijbrief is voor uitloop en overschrijding van kosten, maar een goede product owner vertegenwoordigt de stakeholders en managet de productbacklog actief, zodat de minder belangrijke eisen en wensen ook kunnen vervallen of naar een andere release worden verplaatst. Een iteratie moet worden afgemaakt zoals afgesproken, dus er moeten geen wijzigingen worden doorgevoerd binnen een lopende iteratie. In de praktijk blijkt dat bijna de helft van alle functionaliteit die traditioneel wordt ontwikkeld niet of nauwelijks wordt gebruikt. Dat kan dus worden voorkomen met een Scrum-aanpak.

Inception

Ook voor hardware- en firmwareontwikkeling is een aantal Agile-principes goed te gebruiken. Het teamwork, het werken met iteraties, de story‘s en het kiezen van prioriteiten zijn hier net zo goed van toepassing. Bij hardwareontwikkeling lijkt een iteratieperiode van twee tot vier weken te kort, maar dat is slechts een extra paradigma. Veel hardware wordt bijvoorbeeld ontwikkeld door verder te bouwen op bestaande hardware, met FPGA‘s en via simulatietooling. Ook hardware is dan functie voor functie te realiseren in plaats van alles van tevoren te specificeren. Via rapid prototyping kunnen printboards al in een vroeg studium bijdragen aan deelleveringen, hoewel er bij het ontwerp dan wel rekening moet worden gehouden met hergebruik.

Bij hardware kan het wel gebeuren dat sommige specifieke eisen moeilijker in story‘s zijn vast te leggen. Maar meestal zijn dan wel de bovenliggende eisen in de wie-wat-waarom-vorm te vatten. Als bijvoorbeeld een eis aan de hardware wordt gesteld omdat een bepaald land afwijkende specificaties heeft, dan kan de ontwikkelaar beter inschatten of de verwachte kosten voor die eis wel opwegen tegen de baten en dat bespreekbaar maken.

Dit roept de vraag op of er ook Agile-manieren zijn om een complex systeem, een complete enterprisearchitectuur of een mechanisch ontwerp op te pakken. Een pure Scrum-benadering schiet hier te kort, maar binnen Agile-varianten als Rup of DAD zijn fases gedefinieerd voor dit soort projecten zoals de opstart (inception), de bouw (construction) en de overgangfases (transition). Bij Scrum wordt vaak de eerste iteratie gebruikt om op te starten en de laatste voor de oplevering.

In de opstartfase is het de bedoeling om goed na te denken over de aanpak. Door erop te vertrouwen dat het grootste deel met een Agile-aanpak kan worden gebouwd, zal dat zeker lukken. Er is wel vakmanschap nodig om onderscheid te kunnen maken tussen delen die zich daar wel en niet voor lenen zonder dat alle details vooraf bekend zijn. Het maakt daarbij niet uit of het om software of hardware gaat.

Onderhoudsfase

Een andere aanpak onder de Agile-paraplu is het uit de productiehoek afkomstige Lean. Deze methode is gericht op dingen die een toegevoegde waarde hebben. Een schone en opgeruimde werkplek bijvoorbeeld. Uit onderzoek blijkt dat de productiviteit hier veel hoger is dan in een rommelige omgeving. Ook in de ontwikkeling zijn veel Lean-aspecten toe te passen. De aanpak bevat een hele gereedschapskist om bijvoorbeeld een efficiënte werkomgeving te maken (5S), fouten te voorkomen (Poka Yoke), processtappen op elkaar af te stemmen (Kanban) en processtappen te optimaliseren (VSM).

Een variant die hier verder op ingaat is Six Sigma. Bij een Six Sigma-proces mogen niet meer dan 3,4 fouten per miljoen mogelijkheden voorkomen. Zo‘n zware eis is voor de meeste organisaties niet nodig en kan duur zijn. Wel is het goed om te beseffen dat het herstellen van fouten heel kostbaar kan zijn. Volgens de wet van Boehm nemen de kosten exponentieel toe naarmate een fout later in het ontwikkelproces wordt gevonden en aangezien een product zich typisch voor tachtig procent van de levenscyclus in de onderhoudsfase bevindt, is het zeer renderend om fouten in een zo vroeg mogelijk stadium te verwijderen of, beter nog, te voorkomen.

Six Sigma heeft een vijfstappenaanpak (DMAIC) om de prestaties te verbeteren. Voor elke stap zijn er meerdere tools beschikbaar. Omdat Six Sigma vooral uitgaat van feiten zoals historische data en meetgegevens, sluit dit goed aan bij het iteratieve werken. Elke iteratie biedt namelijk de mogelijkheid om data te verkrijgen en de effecten te zien van bijsturing in de volgende iteratie.

Honderd procent

Al deze zaken gaan vooral in op snelle resultaten, continu leren en verbeteren. Voor leergierige mensen kan dat aantrekkelijk zijn, maar het werkt alleen als er binnen het bedrijf een cultuur heerst die openstaat voor het leren van fouten zonder represailles. Grote dynamiek brengt bovendien het risico van onzekerheid en instabiliteit met zich mee, omdat niet meer kan worden uitgegaan van historische data.

Ook bestaat er het gevaar dat de methode aan haar eigen succes ten onder gaat. Vaak besluit een organisatie om de aanpak organisatiebreed in te voeren als een project succesvol met een Agile-methode is afgerond. De pioniersfase wordt dan als volwassen manier van werken behandeld. Alle aspecten van verandermanagement komen dan om de hoek kijken: weerstand tegen veranderen, bestaande processen en tools die niet meer passen, mensen weten niet meer wat ze moeten doen, enzovoorts. Om dat in de hand te houden, is het belangrijk om als organisatie duidelijk te hebben wat de langetermijn- en afgeleide doelstellingen zijn. Verlies nooit uit het oog waar het echt om gaat in de organisatie.

Ook een traditioneel model als CMMI is zeer geschikt om te borgen dat vanuit een stabiele basis verder wordt gegaan. CMMI biedt de mogelijkheid om in stappen in volwassenheidsniveaus te groeien, of delen kunnen worden gebruikt als checklist voor het goed inrichten van specifieke activiteiten. Om bijvoorbeeld een deel van het werk uit te besteden, kan supplier agreement management worden gebruikt, dat op het tweede niveau van ’CMMI for development‘ is beschreven. Tip: leg bij de contractonderhandelingen vooral het doel en de businesswaarde vast, zodat het werk een vaste prijs en einddatum heeft maar de exacte inhoud en wijzigingen via intensieve samenwerking en iteraties worden afgestemd.

Het toepassen van Agile-principes is al snel renderend. Indien de principes volledig worden toegepast zoals bedoeld, zijn prestatieverbeteringen van meer dan honderd procent goed haalbaar. En zelfs als het het ideaal niet bereikt kan worden, zijn snel goede rendementen te bereiken.