b'\n_START_ARTICLE_\nLean-softwareontwikkeling\n_START_PARAGRAPH_\nLean 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.\n_START_SECTION_\nOorsprong\n_START_PARAGRAPH_\nDe 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.\n_START_SECTION_\nVersterk het leereffect\n_START_PARAGRAPH_\nHet 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\xc3\xabn uitgeprobeerd worden. Door deze aan de gebruiker te tonen wordt sneller duidelijk wat hun wensen zijn._NEWLINE_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._NEWLINE_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.\n_START_SECTION_\nBeslis zo laat mogelijk\n_START_PARAGRAPH_\nHet 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 maken. 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._NEWLINE_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.\n_START_SECTION_\nLever zo snel mogelijk\n_START_PARAGRAPH_\nIn 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._NEWLINE_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 \xe2\x80\x93 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 \xe2\x80\x93 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._NEWLINE_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 \xc3\xa9\xc3\xa9n 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.\n_START_SECTION_\nGeef het team verantwoordelijkheid\n_START_PARAGRAPH_\nEr 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._NEWLINE_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 verstoord .\n_START_SECTION_\nKwaliteit\n_START_PARAGRAPH_\nDe 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._NEWLINE_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\xc3\xafsoleerde ontwikkeling iets wordt opgeleverd wat de klant onaangenaam verrast of zelfs verbijstert._NEWLINE_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.'