Lean-softwareontwikkeling

Lean softwareontwikkeling, of de originele Engelse term Lean software development (LSD), is een combinatie van de best practices van lean manufacturing, lean IT en de agile-softwareontwikkeling.

Oorsprong

De naam lean software development komt van een boek met dezelfde naam geschreven in 2003 door Mary Poppendieck en Tom Poppendieck. het boek beschrijft de traditionele lean principes in een aangepaste vorm, evenals de 22 gereedschappen die hierbij volgens hen gebruikt kunnen worden. Zij vergelijken deze gereedschappen met de best practises van agile. De betrokkenheid van de Poppendiecks in de agile gemeenschap, versterkt door hun aanwezigheid en presentaties op allerlei conferenties, inclusief de video's daarvan, heeft bijgedragen aan de verspreiding van hun gedachtegoed. Op het ogenblik is er mede daardoor een pro-lean subcultuur aan het ontstaan binnen de agile gemeenschap.

Lean principes

Lean softwareontwikkeling kan worden samengevat in zeven principes, die erg lijken op de principes van de leanproductie:

1. Voorkom verspilling
2. Versterk het leereffect
3. Beslis zo laat mogelijk
4. Lever zo snel mogelijk
5. Geef het team verantwoordelijkheid
6. Kwaliteit
7. Zie het geheel

Voorkom verspilling

Alles wat geen waarde toevoegt voor de klant wordt gezien als verspilling (muda). Onder andere:

• Onduidelijke requirements
• Bureaucratie
• Langzame interne communicatie
• Vertragingen in het softwareontwikkelproces
• Onnodige code en functionaliteit
• Te weinig tests

Om verspilling te kunnen verwijderen moet men deze eerst herkennen. Een value stream mapping techniek wordt vaak gebruikt om verspilling op te sporen en vervolgens te verwijderen. Dit moet een aantal keren gebeuren totdat zelfs processen die aanvankelijk essentieel leken, verwijderd kunnen worden. Bijvoorbeeld; als sommige activiteiten overgeslagen kunnen worden, of als het resultaat ook op een andere manier zonder deze activiteit behaald kan worden, dan kan dit proces verwijderd worden. Programmeerwerk dat gedeeltelijk gedaan is en niet afgemaakt, is verspilling en kan verwijderd worden. Het maken en onderhouden van extra ongevraagde features en functionaliteit die weinig gebruikt wordt, is verspilling. Het wachten op andere activiteiten, teams, mensen of processen, is verspilling. Fouten en slechte kwaliteit zijn verspilling. Management overhead die geen echte waarde toevoegt, is verspilling.

Versterk het leereffect

Het ontwikkelen van software is een continue leerproces wat nog toeneemt door het samenwerken in teams. De beste aanpak voor een verbetering van de softwareontwikkeling is het versterken van het leereffect. Het opstapelen van fouten moet voorkomen worden door zo vroeg mogelijk te testen, bij voorkeur nog voor er geprogrammeerd wordt. In plaats van meer documentatie te maken of een gedetailleerde planning kunnen beter verschillende ideeën uitgeprobeerd worden. Door deze aan de gebruiker te tonen wordt sneller duidelijk wat hun wensen zijn.

Het leerproces wordt versneld door het gebruik van korte verbetercycli, gekoppeld aan refactoring en integratietesten. Door korte feedback sessies bij elke korte verbetercyclus/iteratie wordt het iedereen snel duidelijk wat de mogelijkheden en wensen zijn, wat ten goede komt aan het leereffect en de toekomstige verbeteringen. Gedurende deze korte sessies leren zowel de vertegenwoordigers van de klant / gebruiker en het ontwikkelteam meer van het probleemgebied zodat zij gericht op zoek kunnen naar mogelijke oplossingen. Op deze manier begrijpen de klanten beter wat ze willen, gebaseerd op wat aan hen opgeleverd wordt en de ontwikkelaars leren beter hoe ze deze wensen kunnen realiseren.

Een andere aanpak van de communicatie en het leerproces is wat men noemt "set-based development", of ook de Theory of constraints. In deze aanpak worden de randvoorwaarden van de toekomstige oplossing aangegeven en krijgt het ontwikkelteam de mogelijkheid om daarbij oplossingen te zoeken, zonder dat die direct al door de klant verder beperkt wordt. Dit bevordert de ontwikkeling van de oplossing door een dialoog met de klant in plaats van door een dictaat van de klant. Het bevordert de inschakeling van het creatieve oplossingsvermogen van de ontwikkelaars en verhoogt daarmee hun motivatie.

Beslis zo laat mogelijk

Het ontwikkelen van software heeft altijd een element van onzekerheid. Betere resultaten kunnen bereikt worden door gebruik te maken van een meersporenbeleid, waarbij tegelijkertijd gewerkt wordt aan meerdere mogelijke oplossingsrichtingen, waardoor de uiteindelijke de beslissingen zo lang mogelijk uitgesteld worden totdat zij gemaakt kunnen worden gebaseerd op feiten in plaats van op onzekere aannames en voorspellingen. Hoe ingewikkelder het systeem is, hoe flexibeler het ontwikkelproces moet zijn, zodat het mogelijk is om onomkeerbare dure beslissingen zo laat mogelijk te nemen. De stapsgewijze iteratieve aanpak gaat uit van dit principe; de mogelijkheid om op wijzigingen te reageren en vergissingen te corrigeren, vergissingen die erg duur kunnen worden wanneer zij pas laat in het proces onderkend worden.

In de flexibele agile aanpak krijgt de klant al in een vroeg stadium tussenproducten en opties te zien, waardoor zij beter zicht krijgen op de mogelijkheden en onmogelijkheden, waarbij definitieve beslissingen worden uitgesteld totdat de klanten beter bewust zijn van wat zij willen. Dit maakt het ook mogelijk om nog vrij laat te kunnen reageren op veranderingen in de wensen, ter voorkoming van dure vroege technische beslissingen. Dit betekent niet dat men helemaal niet moet plannen, integendeel, planning moeten zich concentreren op de verschillende mogelijkheden en moeten zich aanpassen aan de huidige situatie. Plannen moeten ook inzicht geven door de verschillende mogelijkheden voor snelle actie. Het evalueren van verschillende mogelijkheden is een effectieve aanpak zodra men begrijpt dat het openhouden van de verschillende mogelijkheden ook geld kost, maar wel flexibiliteit biedt om laat te kunnen beslissen.

Lever zo snel mogelijk

In het tijdperk van de snelle technische ontwikkeling is het niet de grootste die overleeft, maar de snelste. Hoe sneller het eindproduct wordt opgeleverd zonder grote fouten, hoe sneller er feedback komt en hoe sneller dat meegenomen kan worden in de volgende verbeterslag. Hoe korter de iteraties, hoe sneller er gecommuniceerd wordt en hoe sneller er geleerd wordt door het team. Door deze snelheid kunnen beslissingen uitgesteld worden. Snelheid zorgt voor de realisatie van de huidige wensen van de klant en niet wat zij gisteren nodig hadden. Dit geeft hun de mogelijkheid om de besluitvorming uit te stellen totdat zij beter weten wat ze willen. Klanten kunnen het meestal wel waarderen wanneer er snel (tussen)resultaten worden opgeleverd.

De Just in time productie ideologie kan ook worden toegepast bij softwareontwikkeling. Dit kan worden bereikt door het team zichzelf te laten organiseren en de taken onderling te verdelen. In het begin van het proces en de iteratie komt de klant met de benodigde input. Dit kan worden gedaan in de vorm van kleine kaartjes met userstories – vervolgens schatten de ontwikkelaars hoeveel tijd nodig is om dit uit te voeren. Hierdoor verandert de organisatie van het werk in een self-pulling system – elke morgen gedurende de "stand-up meeting", vertelt elk lid van het team wat hij gisteren gedaan heeft, wat hij vandaag gaat doen en wat morgen. Hierbij wordt commentaar gevraagd van de anderen. Hierdoor wordt duidelijk wat iedereen doet en hoe men samenwerkt, wat voordelig is voor de teamcommunicatie.

Een ander basis idee in het Toyota's Productontwikkelingssysteem dat is overgenomen in het lean gedachtegoed en vervolgens in lean softwareontwikkeling is het "set-based design". Als er bijvoorbeeld een nieuw remsysteem nodig is voor een auto kunnen drie verschillende teams bezig gaan om hiervoor een oplossing te bedenken. Elk team hoort wat de eisen en wensen zijn inclusief de beperkingen en gaat daarmee aan de gang om een mogelijke oplossing te ontwikkelen. Als een bepaalde oplossing onmogelijk lijkt gaat men er niet meer mee verder. Aan het einde van de ontwikkelperiode worden de overblijvende ontwerpen vergeleken en wordt er één gekozen, misschien met een paar aanpassingen gebaseerd op wat men bij de andere ontwerpen geleerd heeft. Een uitstekend voorbeeld van het uitstellen van een beslissing tot het laatst mogelijke moment. Het ontwikkelen van software kan ook gebruikmaken van deze werkwijze om het risico te verminderen dat geschapen wordt door het maken van grote systeemontwerpen voorafgaand aan het bouwproces. Grote ontwerpen die gemaakt worden op een moment dat men daar eigenlijk nog onvoldoende kennis voor heeft.

Geef het team verantwoordelijkheid

Er is het traditionele beeld over besluitvorming in organisaties, namelijk dat de managers het personeel precies vertellen hoe ze het werk moeten doen. Dat werkt uitstekend zolang managers ook precies weten wat er moet gebeuren, dat is het geval in goed voorspelbare omgevingen, maar daarvoor zijn vaak al oplossingen / standaardprogrammas ontwikkeld. In een zogenaamde "Work-Out" techniek worden de rollen omgedraaid en wordt managers geleerd om te luisteren naar de ontwikkelaars, zodat zij beter kunnen uitleggen welke acties genomen moeten worden, evenals dat zij suggesties kunnen leveren voor verbeteringen. Binnen de lean aanpak is men een aanhanger van het gezegde: "vind goede mensen en laat hen het werk doen", verder moeten deze mensen aangemoedigd worden, moeten fouten gesignaleerd worden en moeten hindernissen weggenomen worden, maar er moet niet precies voorgeschreven worden wat er elke seconde gedaan moet worden, want dat is een verspilling van het creatieve oplossende vermogen van de ontwikkelaar.

Een andere vergissing is om mensen te zien als "poppetjes". Mensen zijn misschien een "poppetje" vanuit een statistich standpunt, maar in softwareontwikkeling, net als elders, willen mensen niet gezien worden als "poppetje", zo hebben mensen meer nodig dan alleen een lijst van taken en de verzekering dat zij niet gestoord worden bij de uitvoering van hun werk. Mensen hebben vaak zoiets nodig als motivatie en een hoger doel om voor te werken. Een bereikbaar doel, waarbij het team zelf kan aangeven hoe zij dat aanpakken. De ontwikkelaars moeten daarom ook met de klant/gebruikers kunnen praten; de teamleider moet hen faciliteren en ondersteunen in moeilijke situaties en moet voorkomen dat scepticisme het goede groepsproces verstoort. .

Kwaliteit

De klant moet een goede algehele indruk hebben van het gehele systeem: hoe het verkocht wordt in advertenties, hoe het afgeleverd wordt, gebruikt, de toegankelijkheid, hoe gebruikersvriendelijk het is, of de prijs goed is en hoe goed ermee problemen opgelost kunnen worden. Dit moet op elkaar aansluiten en dat is de integrale kwaliteit die de klant ervaart.

Bij Conceptuele kwaliteit gaat het erom of de afzonderlijke onderdelen van het systeem goed samenwerken, dat het een goede balans is van flexibiliteit, onderhoudbaarheid, efficiency en dat het doel bereikt wordt. Dit kan bereikt worden door het probleemgebied goed te begrijpen en het tegelijkertijd op te lossen, niet eerst begrijpen en later oplossen. De hiervoor benodigde informatie wordt ontvangen in kleine gedeelten, niet in een groot geheel zoals bij de traditionele methoden, en bij voorkeur in face-to-face communicatie, zonder (veel)geschreven documentatie. De stroom van informatie moet in beide richtingen constant zijn, van klant naar ontwikkelaar en terug. Op die manier wordt vermeden dat er na een lange periode van geïsoleerde ontwikkeling iets wordt opgeleverd wat de klant onaangenaam verrast of zelfs verbijstert.

Een goede manier om te komen tot een goede integrale architectuur is refactoring. Hoe meer toeters en bellen aan het geheel worden toegevoegd, hoe moeilijker het wordt om het verder te verbeteren. Bij Refactoring gaat het erom dat het simpel blijft en duidelijk. Herhalingen in de programmacode zijn tekenen van een slecht ontwerp en dat zou vermeden moeten worden. Het gehele geautomatiseerde bouwproces moet begeleid worden door een complete bij voorkeur geautomatiseerde set van tests, met dezelfde versies en naamgeving als het systeem waar het voor is ontworpen. Aan het eind van elke iteratie moet de kwaliteit bevestigd worden door grondig en bij voorkeur geautomatiseerd testwerk, waardoor verzekert wordt dat het systeem doet wat de klant wil dat het systeem doet. Geautomatiseerde tests horen bij het productieproces dus als zij geen waarde toevoegen zijn ze ook verspilling. Geautomatiseerd testen moet geen doel op zich zijn, maar een middel om een doel te bereiken namelijk de vermindering van verspilling.

Zie het geheel

Softwaresystemen zijn tegenwoordig meer dan een verzameling onderdelen, ook belangrijk is hoe die onderdelen samenwerken. Fouten in software hebben de neiging om zich op te stapelen tijdens de ontwikkeling. Door het opknippen van grotere gedeelten in kleinere brokken wordt het allemaal beter behapbaar. Ook standaardisatie draagt bij aan het verminderen van fouten en het inzichtelijk maken van de programmatuur, waardoor er minder fouten gemaakt worden en als ze gemaakt worden kunnen ze eerder gevonden worden. Ook wordt het mogelijk om de achterliggende oorzaken van fouten te vinden zodat die oorzaken weggenomen kunnen worden waardoor fouten worden voorkomen. Hoe groter het uiteindelijke systeem is, hoe meer organisaties betrokken zijn bij de ontwikkeling en hoe meer onderdelen door verschillende teams gemaakt worden, hoe belangrijker het is om duidelijk te maken wie wat doet en wie waarvoor verantwoordelijk is. Anders wordt het moeilijk om een systeem te maken waarin alles goed samenwerkt. Bij een langere ontwikkelperiode is het belangrijker om een sterker netwerk te hebben met onderaannemers dan te gaan voor korte termijn winsten, omdat dit ten koste gaat van lange termijn win-win relaties.

Het "Lean" denken moet door iedereen in een project goed begrepen worden voordat het wordt toegepast. "Zie het grote geheel, maak kleine stappen, test meteen en leer snel" (Think big, act small, fail fast; learn rapidly) – deze woorden vatten goed samen wat er in een lean project gebeurt en wat hun effect is op het softwareontwikkelproces. Alleen als alle lean principes samen worden toegepast, gecombineerd met een boel "gezond verstand" met betrekking tot de werkomgeving, alleen dan is er een basis voor succes in softwareontwikkeling.

Bronnen, noten en/of referenties

• Ladas, Corey (January 2008), Scrumban: Essays on Kanban Systems for Lean Software Development. Modus Cooperandi Press. ISBN 0-578-00214-0. Gearchiveerd op 26 oktober 2012. Geraadpleegd op 8 september 2023.