Asymmetrische of publieke-sleutelcryptografie kan een zware wissel trekken op de processor, zowel op het vlak van berekeningen als qua geheugenverkeer. Barco Silex legt uit hoe zijn...
Het waren pijnlijke jaren, maar het gaat weer de goede kant op met zijn bedrijf, vertelt CTO René Penning de Vries van NXP. Een gesprek...
Beveiliging is een onderwerp van extremen. Dat is precies wat het spannend maakt. Versleutelen is een kant van beveiliging die het meest tot de verbeelding spreekt. Ik herinner me het geheimschrift...
26 maart 2009
Lean Engineering gaat erover dat klanten krijgen wat ze echt willen in de kortst mogelijke tijd. Mark Robinson bespreekt de zeven verspillingen die dit ideaal in de weg staan en geeft tips om ze te vermijden.
Lean Engineering is, met de woorden van geestelijk vader Taiichi Ohno van Toyota, ‘the absolute elimination of waste’. Hij zei: ‘All we are doing is looking at the timeline from the moment a customer gives us an order to the point when we collect the cash. And we are reducing that timeline by removing the non value-added wastes.’ Deze quote is te vinden in het boek ‘Implementing lean software development - from concept to cash’ van Mary en Tom Poppendieck.
Lean Engineering is dus een manier om de efficiëntie van het softwareontwikkelproces te maximaliseren door de focus te leggen op het elimineren van verspilling. Maar wat is verspilling en hoe kunnen we het elimineren? Lean identificeert zeven types van verspilling: gedeeltelijk uitgevoerd werk, extra functionaliteit, opnieuw leren, overdracht, wisselen tussen meerdere taken, uitloop en fouten. In dit artikel zullen deze verspillingen een voor een de revue passeren.
1. Gedeeltelijk uitgevoerd werk
Lean Engineering vergelijkt werk dat niet af is met voorraad in het fabricageproces. Voorraad kan verloren of beschadigd raken en verouderen. Zo ook kan oude code beschadigd raken wanneer de oorspronkelijk auteur het team of bedrijf verlaat en anderen met minder kennis er wijzigingen in aanbrengen (in het bijzonder als de software slecht is ontworpen). Requirements kunnen verouderen als ze te vroeg zijn geschreven en de klantwensen inmiddels zijn veranderd. Ook ongeteste code is verspilling, omdat fouten zich opstapelen zolang de code ongetest blijft.
Onaf werk is ook niet verkoopbaar. Jaren geleden werkte ik als softwareontwikkelaar in een klein team. Net als 99 procent van alle ontwikkelaars vonden we het leuk om code te schrijven, maar niet om te testen, laat staan te documenteren. Maar ieder item op onze lijst van ongeveer twaalf requirements per increment vereiste alle drie die activiteiten: coderen, testen en documenteren. Dus wat deden we? Eerst schreven we de code – dat was leuk. Gevolg: na een paar weken hadden we twaalf gedeeltelijk werkende stukken. Onze projectleider heeft ons toen opgedragen om eerst één stuk volledig af te maken alvorens verder te gaan met de volgende deel. Als het project zou uitlopen, konden we zo in ieder geval enkele complete functionaliteiten op tijd opleveren.
De beste manier om gedeeltelijk gedaan werk te voorkomen, is om een systeem in te richten dat vertragingen zo veel mogelijk elimineert. Dit vereist een frequente en regelmatige uitrol van het lopende werk naar de klant, met een korte tijdlijn van aanvraag naar implementatie. Twee acties zijn aan te bevelen: stap over op een Agile-werkwijze, met regelmatige releases (iedere twee tot vier weken), waarbij de klant de prioriteit bepaalt van iedere uitgave, en analyseer het huidige proces, gebruikmakend van de Value Stream Map.
Figuur 1: Een typische Value Stream Map, met de stroom van klantvraag naar –oplossing
2. Extra functionaliteit
Het is niet raar dat het vijf jaar duurde voordat Vista uitkwam, en vervolgens nog minstens een jaar van bugfixes voordat het zo betrouwbaar was als zijn voorganger XP. Vanwege een overkill aan requirements is het product overladen met extra functionaliteit, die bovendien veelal ongebruikt blijft. Dit gebeurt niet alleen bij Microsoft. Ik heb ontwikkelaars en testers zien overwerken om een release af te ronden en vervolgens geconstateerd dat de gebruikers maar een klein gedeelte van de beschikbare functies gebruikten. Om nog maar eens uit Poppendieck te quoten: ‘If there isn’t a clear and present economic need for the feature, it should not be developed.’
In plaats van enorme requirementsdocumenten te maken (en daarmee de verspilling van gedeeltelijk uitgevoerd werk te introduceren) is het veel beter om eerst een minimaal pakket van functionaliteit overeen te komen. Laat de klant het product gebruiken zodra dit pakket is ontwikkeld, zodat deze direct al kosten kan beginnen te besparen ten opzichte van de huidige oplossing. Ontwikkel het minimale pakket incrementeel, geef het incrementeel vrij en laat de klant er regelmatig feedback op geven. De sleutel is: release snel en vaak. Bij ieder volgend pakket is het zaak om de vraag te stellen: is dit echt nodig? Als er enige twijfel is, ontwikkel de functionaliteit dan niet.
3. Opnieuw leren
Er zijn twee soorten van opnieuw leren: als een individu iets is vergeten en als een team iets vergeet. Jaren geleden was ik iedere avond verantwoordelijk voor het afsluiten van een magazijn. Ik had een aantal taken in verschillende ruimtes van het gebouw: deuren op slot, lichten uit en alarm aan. Op een avond maakte ik een fout en liet ik een buitendeur open. Niemand brak in, maar de wind activeerde een bewegingssensor, waardoor achtereenvolgens de politie werd gealarmeerd en mijn manager uit bed werd gebeld.
Mijn oplossing: ik maakte een checklist, die ik voortaan iedere avond gebruikte voordat ik vertrok. Het werk ging sneller en het gaf me ook een geruststellend gevoel – ik hoefde niet te vrezen dat ik iets was vergeten. Een checklist is een simpele manier om veel informatie in een bruikbaar formaat te gieten. Het is bruikbaar voor iedere zich herhalende taak, bijvoorbeeld bij het testen alvorens de software te leveren.
De verspilling van opnieuw leren doet zich ook voor als een team geen gebruik maakt van de informatie die het al heeft. Een teamlid zoekt bijvoorbeeld uit hoe de code werkt voor een exotische functie om een probleem op te lossen zonder zich te realiseren dat iemand anders hetzelfde probleem een paar maanden eerder al heeft opgelost in een ander gedeelte van de code. In grote bedrijven is het vaak nog erger. Ik heb meegemaakt dat verschillende afdelingen allemaal hun eigen methode ontwikkelden van automatisch testen.
Dit probleem is grotendeels te verhelpen door een interne wiki bij te houden. Wiki’s werken goed omdat de drempel om wijzigingen te maken laag is en het makkelijk is om bestaande informatie te vinden. Traditionele documentatie is shelfware, documentatie die niemand ooit zal lezen en die snel overbodig wordt – zoals de voorraad hierboven. Wikidocumentatie is levend, continu veranderend, uitdijend en verbeterend. Tegenwoordig, met uitstekende gratis of goedkope wikisoftware, is er echt geen excuus meer om geen bedrijfsbrede wiki te hebben, vooral niet voor een IT-bedrijf.
4. Overdracht
Hoe goed de documentatie ook is, zolang er overdracht is, zal er altijd sprake zijn van opnieuw leren. Er is overdracht als een persoon die een taak heeft zijn waarde aan het product toevoegt en het dan overdraagt aan de volgende persoon. Lean zegt dat overdracht mislukt omdat een persoon maar maximaal 50 procent van wat hij weet, kan overdragen aan een ander. In een keten wordt dit alleen nog erger: een klant vertelt de klantenservice wat hij wil (50 procent kennisverlies), die afdeling zet dit in een requirementsdocument (75 procent verlies), waarna de ontwikkelaars en testers de requirements interpreteren (88,5 procent verlies). Het zal meerdere iteraties duren voordat de klant krijgt wat hij wil. Gevolg: gedeeltelijk uitgevoerd werk en uitloop.
Er zijn drie oplossingen. De eerste is regelmatig leveren aan de klant en regelmatig feedback terugkrijgen. De tweede is kruisfunctionele teams creëren om de interne communicatie te verbeteren. Maak bijvoorbeeld een team van ontwikkelaars, testers en klantenservicemedewerkers in plaats van een team dat enkel bestaat uit ontwikkelaars. De derde oplossing is: vermijd overdracht. Het komt nogal eens voor dat één ontwikkelaar een fout onderzoekt en een ander die oplost. Het is veel efficiënter om dezelfde ontwikkelaar beide taken te laten doen – bij voorkeur met zo min mogelijk tijd tussen beide taken (om opnieuw leren te voorkomen).
5. Wisselen tussen meerdere taken
Stel er zijn drie taken: A, B en C, die ieder weer zijn opgesplitst in drie subtaken: 1, 2 en 3. En stel dat er twee volgordes zijn om deze taken uit te voeren: A1 A2 A3 B1 B2 B3 C1 C2 C3 en A1 B1 C1 A2 B2 C2 A3 B3 C3. Als iedere subtaak een dag duurt, dan is in de eerste volgorde taak A klaar na drie dagen, maar in de tweede volgorde is na zes dagen nog geen enkele taak af. En dan neemt dit voorbeeld nog niet eens de tijd mee die het duurt om fysiek (naar een andere locatie gaan) en mentaal (bepalen waar je was gebleven) te wisselen tussen de taken. Ten slotte kan de klant in de eerste volgorde A al gebruiken en feedback geven in de drie dagen dat er wordt gewerkt aan B.
Dit voorbeeld illustreert de verspilling die inherent is aan het wisselen tussen taken. Waarom wordt er dan toch zo veel gewisseld? Soms zijn mensen gewoon chaotisch, soms hebben ze chaotische managers die voordurend met prioriteiten schuiven. De meest voorkomende reden is echter: uitloop.
6. Uitloop
Verschillende kleine interne vertragingen tellen al snel op tot een grote uitloop voor de klant. Dit is tegenstrijdig met Lean: hoe langer de klant op zijn product moet wachten, hoe langer het duurt voordat je je geld krijgt. Maar dat is niet alles: de klant mag dan wel voorbereid zijn om op het product te wachten, de buitenwereld wacht niet. De wereld blijft veranderen en dus ook de klantrequirements. Veel van het geïmplementeerde is niet langer relevant. Daarnaast heeft de klant een heel pakket van extra eisen die hij geïmplementeerd wil zien. Dit leidt niet alleen tot nog meer uitloop (vicieuze cirkel), maar ook tot extra testinspanningen.
Vertraging betekent dat een klant niet krijgt wat hij wil wanneer hij het wil. En als de concurrent dit wel kan bieden, dan heb je een serieus bedrijfsrisico. Uitloop komt voor bij zowel nieuwe requirements als bugfixes. Overweeg deze vraag eens: als de klant een kritische fout vindt in het product, hoe lang duurt het dan voordat de fout onderzocht, opgelost, getest en vrijgegeven is? Uren? Dagen? Of weken?
Uitloop treedt op als werk zich opstapelt op één plek, bijvoorbeeld in de requirements- of de testfase. Daar ontstaan dan buffers met gedeeltelijk uitgevoerd werk. Daarnaast kan er vertraging optreden door extra werk (churn), bijvoorbeeld bij het repareren van fouten. De oplossing voor deze verspilling begint bij het zichtbaar maken van de uitloop. Dit kan weer met een Value Stream Map.
7. Fouten
Een lineaire toename van requirements veroorzaakt een exponentiële groei in complexiteit van de code, en dus in het aantal fouten. Eén manier om dit te voorkomen, is door extra requirements weg te laten. Hoe kan Lean Engineering nog meer helpen?
Lean gebruikt het concept van mistake proofing: maak het onmogelijk voor mensen om fouten te maken. Mijn twee jaar oude dochter houdt bijvoorbeeld van bellenblazen. Haar eerste flesje bellenblaas had een dop die je eraf schroeft en een stokje met een ring eraan om de bellen te blazen. Heel simpel, maar niet foutvrij: het was heel makkelijk voor haar om het stokje in de fles te laten vallen en moeilijk om het er weer uit te krijgen. Dus kwamen haar handen onder de bellenblaasvloeistof te zitten, of ze hield de fles op de kop. In de volgende versie zat het stokje vast aan de dop. Hierdoor kon mijn dochter het niet meer in de vloeistof laten vallen. Helaas hield ze nog steeds de fles op de kop, waardoor alle vloeistof eruit liep. De tweede versie was dus dichter bij, maar nog niet helemaal foutvrij. De derde en laatste fles had een stokje dat groter was dan de fles, zodat het niet helemaal in de vloeistof kon zakken. Ook had deze versie een slimme trechter in de fles, waardoor de vloeistof er niet uit kon lopen, ook niet als het flesje op de kop werd gehouden. Foutvrij? Niet helemaal: mijn dochter liep naar de zandbak en vulde de fles met zand.
Hoe kun je foutvrije software schrijven, zonder gebruik te maken van de traditionele (en verspillende) test-alles-aan-het-einde-aanpak? Door processen te introduceren die fouten vroeg vinden. Automatisering van de regressietests, ten minste één smoketest of een eenvoudige end-to-endtest maakt het mogelijk om vroeg en vaak te testen. Als je uitloop kunt voorkomen door fouten eerder op te lossen, zal dit een enorme hoeveelheid tijd schelen op de lange termijn. Wat hoor je liever van je testers: we hebben een fout gevonden in je code die je gisteren hebt geïntroduceerd, of we hebben een fout gevonden die je hebt geïntroduceerd sinds de laatste release, drie maanden geleden? Zoals het aloude spreekwoord zegt: voorkomen is beter dan genezen.
Mark Robinson is testmanager bij Topic Embedded Systems. Hij heeft succesvol Lean, Agile en diverse testverbeterprocessen geïmplementeerd bij verschillende klanten.
De Value Stream Map is een zeer eenvoudig maar krachtig gereedschap dat Lean-ontwikkelaars gebruiken om verspilling te identificeren en te verwijderen. Value Stream Maps zijn stroomdiagrammen van klantvraag naar klantoplossing. Een typisch voorbeeld is te zien in Figuur 1.
Om een Value Stream Map te maken, pak je een A3-vel en leg je het horizontaal op je bureau. Aan de linkerkant schrijf je de klantvraag, bijvoorbeeld het oplossen van een fout, en aan de rechterkant zet je hoe de klant de oplossing zal ontvangen, bijvoorbeeld als nieuwe softwareversie. Daartussen noteer je in aparte kaders, zoals in een flowchart, de stappen die moeten gebeuren om van links naar rechts te komen. Maak het niet ingewikkelder dan nodig in dit stadium – je wilt het totaalplaatje. Ga niet verder dan twaalf stappen, richt je op minder. Probeer het diagram af te ronden in dertig tot zestig minuten. In iedere stap in een Value Stream Map moet het duidelijk zijn wie verantwoordelijk is voor de betreffende actie. Je kunt zelfs specifieke namen toevoegen, bijvoorbeeld ‘Erik test de fout’.
Wat gebeurt er als de tester een nieuwe kritische fout vindt bij het toetsen van de eerste fout, of wanneer de fout niet goed is opgelost? En hoe vaak gebeurt dit? Schrijf je schatting op (als een percentage) van hoe vaak het proces fout gaat. Dit is churn (extra werk). Lean moedigt aan om je af te vragen ‘Waarom?’. Waarom doet dit extra werk zich voor? Mary Poppendieck zegt dat om tot de root cause van churn te komen je minimaal vijf keer moet vragen naar het waarom. In het voorbeeld van Figuur 1 is de totale efficiëntie 8 procent, aangenomen dat de fout de eerste keer is opgelost en geen nieuwe fouten introduceert. Als dit niet het geval is en het proces teruggaat naar het begin, gaat de efficiëntie drastisch naar beneden, omdat je kunt aantonen dat iedere stap verspilling is.
Zet bij iedere stap de tijd die het duurt om deze uit te voeren. Hoe lang heeft het Change Control Board (CCB) bijvoorbeeld nodig om een fout te prioriteren? Stel dat het CCB eens per week samenkomt en dertig fouten prioriteert in twee uur. Dan is de tijd om een fout te prioriteren gemiddeld vier minuten.
Teken vervolgens tussen iedere twee stappen een pijl en schrijf onder iedere pijl de doorlooptijd voordat de taak compleet is, bijvoorbeeld de wachttijd voordat een ontwikkelaar beschikbaar is. In Figuur 1 komt het CCB eens per week samen, dus in dit voorbeeld is de gemiddelde doorlooptijd voordat een fout is geprioriteerd tweeënhalve dag. Lean beschouwt deze tijd als verspilling. Van de tweeënhalve dag dat de fout in een buffer zit, wordt in dit voorbeeld maar vier minuten besteed om voortgang te boeken richting een oplossing. Dat geeft een efficiëntie van 0,3 procent.
Waarom komt het CCB maar eens per week samen? Als de leden dat dagelijks zouden doen en ze verwerken typisch zes fouten in vierentwintig minuten, dan zou de fout maar vier uur in de wacht staan, wat een efficiëntie oplevert van 1,7 procent. Dit is verder te verbeteren, bijvoorbeeld door in te stellen dat een lead-ontwikkelaar een mailtje krijgt wanneer een klant een nieuw foutrapport indient. Hij kan dan fouten prioriteren en toekennen zonder naar het CCB te gaan. Dit kan voor alle fouten of alleen wanneer hij de fout beschouwt als kritisch (wat dan een duidelijke definitie vereist van ‘kritisch’). Als de lead-ontwikkelaar zijn mailbox iedere twintig minuten controleert, dan wordt dit deel van het proces 40 procent efficiënt (omdat een fout gemiddeld tien minuten in de inbox staat).
Dit proces kunnen we voor iedere stap in de keten herhalen om zo de doorlooptijd en de tijd dat een klant wacht op een bugfix zo kort mogelijk te maken. Het beste is om niet te veel wijzigingen ineens te maken. Breng een verandering aan en evalueer de effectiviteit voordat je een andere wijziging doorvoert.
Dit voorbeeld bevat nog een andere verspilling: er is een onnodige overdracht tussen de ontwikkelaar die de fout onderzoekt en de ontwikkelaar die hem oplost. Dit leidt tot kennisverlies.
Een andere verborgen waarde van een Value Stream Map maken met je team is dat het helpt om de situatie vanuit klantperspectief te zien. Het is natuurlijk dat een intern team de software vanuit het eigen perspectief bekijkt – ontwikkelaars beschouwen de software bijvoorbeeld als een uitdagende puzzel. Met de ‘klantenbril’ op wordt echter duidelijk wat er echt toedoet: het klantprobleem oplossen en toegevoegde waarde leveren. Dit zal helpen creatiever te worden en oplossingen aan te dragen die echt voordelen bieden voor de klant.
© Bits & Chips | Deze pagina op internet: http://www.bits-chips.nl/nc/nieuws/bekijk/artikel/lean-engineering-en-de-zeven-verspillingen.html
