Lean development can be summarized by seven principles, very close in concept to lean manufacturing principles:
- Eliminate waste
- Amplify learning
- Decide as late as possible
- Deliver as fast as possible
- Empower the team
- Build integrity in
- Optimize the whole
Eliminate wasteEdit
Lean philosophy regards everything not adding value to the customer as waste (muda). Such waste may include:
- Partially done work
- Extra features
- Relearning
- Task switching
- Waiting
- Handoffs
- Defects
- Management activities
In order to eliminate waste, one should be able to recognize it. If some activity could be bypassed or the result could be achieved without it, it is waste. Partially done coding eventually abandoned during the development process is waste. Extra functies zoals papierwerk en functies die niet vaak door klanten worden gebruikt, zijn verspilling. Het wisselen van mensen tussen taken is verspilling. Wachten op andere activiteiten, teams, processen is verspilling. Het opnieuw leren dat nodig is om het werk af te maken is verspilling. Defecten en lagere kwaliteit zijn verspilling. Managerial overhead die geen echte waarde produceert is verspilling.
Een waardestroom mapping techniek wordt gebruikt om verspilling te identificeren. De tweede stap is het aanwijzen van bronnen van verspilling en deze te elimineren. Het verwijderen van verspilling moet iteratief plaatsvinden totdat zelfs schijnbaar essentiële processen en procedures zijn geliquideerd.
Leerproces versterken
Softwareontwikkeling is een continu leerproces gebaseerd op iteraties bij het schrijven van code. Softwareontwerp is een probleemoplossend proces waarbij de ontwikkelaars die de code schrijven betrokken zijn en wat ze hebben geleerd. De waarde van software wordt gemeten in gebruiksgeschiktheid en niet in conformiteit met de eisen.
In plaats van meer documentatie of gedetailleerde planning toe te voegen, zouden verschillende ideeën kunnen worden uitgeprobeerd door code te schrijven en te bouwen. Het proces van het verzamelen van gebruikerseisen kan worden vereenvoudigd door schermen aan de eindgebruikers te presenteren en hun input te krijgen. De opeenstapeling van defecten moet worden voorkomen door tests uit te voeren zodra de code is geschreven.
Het leerproces wordt versneld door gebruik te maken van korte iteratiecycli – elk gekoppeld aan refactoring en integratietests. Meer feedback via korte feedbacksessies met klanten helpt bij het bepalen van de huidige fase van ontwikkeling en het bijsturen van inspanningen voor toekomstige verbeteringen. Tijdens die korte sessies leren zowel de klantenvertegenwoordigers als het ontwikkelingsteam meer over het domeinprobleem en bedenken ze mogelijke oplossingen voor verdere ontwikkeling. Zo krijgen de klanten een beter inzicht in hun behoeften, gebaseerd op het bestaande resultaat van de ontwikkelingsinspanningen, en leren de ontwikkelaars hoe ze beter aan die behoeften kunnen voldoen. Een ander idee in het communicatie- en leerproces met een klant is set-based ontwikkeling – dit concentreert zich op het communiceren van de beperkingen van de toekomstige oplossing en niet van de mogelijke oplossingen, waardoor het ontstaan van de oplossing wordt bevorderd via dialoog met de klant.
Beslis zo laat mogelijkEdit
Aangezien software-ontwikkeling altijd gepaard gaat met enige onzekerheid, zouden betere resultaten moeten worden bereikt met een set-based of options-based benadering, waarbij beslissingen zo veel mogelijk worden uitgesteld totdat ze kunnen worden genomen op basis van feiten en niet op basis van onzekere veronderstellingen en voorspellingen. Hoe complexer een systeem is, hoe meer capaciteit voor verandering erin moet worden ingebouwd, zodat belangrijke en cruciale verbintenissen kunnen worden uitgesteld. De iteratieve aanpak bevordert dit principe – de mogelijkheid om zich aan veranderingen aan te passen en fouten te corrigeren, die zeer kostbaar kunnen zijn als zij pas na de vrijgave van het systeem worden ontdekt.
Met ontwikkeling op basis van sets: Als er bijvoorbeeld een nieuw remsysteem voor een auto nodig is, kunnen drie teams oplossingen voor hetzelfde probleem ontwerpen. Elk team leert de probleemruimte kennen en ontwerpt een mogelijke oplossing. Als een oplossing onredelijk wordt geacht, wordt deze geschrapt. Aan het eind van een periode worden de overgebleven ontwerpen vergeleken en wordt er één gekozen, misschien met enkele wijzigingen op basis van de lessen van de anderen – een goed voorbeeld van het uitstellen van een verbintenis tot het laatst mogelijke moment. Softwarebeslissingen zouden ook van deze praktijk kunnen profiteren om het risico te minimaliseren dat wordt veroorzaakt door een groot ontwerp vooraf. Bovendien zouden er dan meerdere implementaties zijn die correct werken, maar toch verschillend zijn (qua implementatie, intern). Deze zouden kunnen worden gebruikt om fouttolerante systemen te implementeren die alle inputs en outputs gelijktijdig controleren op correctheid, over de meerdere implementaties heen.
Een agile software-ontwikkelingsaanpak kan het bouwen van opties voor klanten eerder laten plaatsvinden, waardoor bepaalde cruciale beslissingen worden uitgesteld totdat klanten zich beter bewust zijn van hun behoeften. Dit maakt ook latere aanpassing aan veranderingen mogelijk en het voorkomen van kostbare eerdere technologie-gebonden beslissingen. Dit betekent niet dat er geen planning aan te pas moet komen – integendeel, planningsactiviteiten moeten worden geconcentreerd op de verschillende opties en de aanpassing aan de huidige situatie, alsmede op het verduidelijken van verwarrende situaties door het vaststellen van patronen voor snelle actie. Het evalueren van verschillende opties is effectief zodra men zich realiseert dat ze niet gratis zijn, maar de nodige flexibiliteit bieden voor late besluitvorming.
Zo snel mogelijk leveren
In het tijdperk van snelle technologische evolutie is het niet de grootste die overleeft, maar de snelste. Hoe sneller het eindproduct zonder grote gebreken wordt opgeleverd, hoe sneller feedback kan worden ontvangen en verwerkt in de volgende iteratie. Hoe korter de iteraties, hoe beter het leren en de communicatie binnen het team. Met snelheid kunnen beslissingen worden uitgesteld. Snelheid verzekert de vervulling van de huidige behoeften van de klant en niet wat ze gisteren nodig hadden. Dit geeft hen de kans om hun beslissing over wat ze echt nodig hebben uit te stellen tot ze meer kennis hebben. Klanten hechten waarde aan een snelle levering van een kwaliteitsprodukt.
De ideologie van de just-in-time produktie zou kunnen worden toegepast op de ontwikkeling van software, waarbij rekening wordt gehouden met de specifieke eisen en de omgeving. Dit wordt bereikt door het gewenste resultaat te presenteren en het team zichzelf te laten organiseren en de taken te laten verdelen om het gewenste resultaat voor een specifieke iteratie te bereiken. Aan het begin levert de klant de benodigde input. Dit kan eenvoudig worden gepresenteerd in kleine kaarten of verhalen – de ontwikkelaars schatten de tijd die nodig is voor de uitvoering van elke kaart. Zo verandert de werkorganisatie in een zelf-trekkend systeem – elke ochtend tijdens een stand-up meeting bekijkt elk lid van het team wat er gisteren gedaan is, wat er vandaag en morgen gedaan moet worden, en vraagt om input van collega’s of de klant. Dit vereist transparantie van het proces, wat ook bevorderlijk is voor de teamcommunicatie.
De mythe die aan dit principe ten grondslag ligt, is dat haastige spoed verspilling in de hand werkt. Echter, lean implementatie heeft voorzien dat het een goede praktijk is om snel te leveren om de output op zijn vroegst te zien en te analyseren.
Empower the teamEdit
Er is een traditionele overtuiging in de meeste bedrijven over de besluitvorming in de organisatie – de managers vertellen de werknemers hoe ze hun eigen werk moeten doen. Bij de lean-methode worden de rollen omgedraaid – de managers wordt geleerd hoe ze naar de ontwikkelaars moeten luisteren, zodat ze beter kunnen uitleggen welke acties kunnen worden ondernomen, en ook suggesties voor verbeteringen kunnen geven. De lean aanpak volgt het agile principe “bouw projecten op rond gemotiveerde individuen en vertrouw erop dat zij de klus klaren”, waarbij vooruitgang wordt aangemoedigd, fouten worden ontdekt en belemmeringen worden weggenomen, maar geen micromanagement wordt toegepast.
Een andere misvatting is dat mensen als middelen worden beschouwd. Mensen mogen dan wel resources zijn vanuit het oogpunt van een statistisch datablad, maar in software-ontwikkeling, en in elke organisatorische business, hebben mensen iets meer nodig dan alleen een lijst met taken en de verzekering dat ze niet gestoord zullen worden tijdens het voltooien van de taken. Mensen hebben motivatie nodig en een hoger doel om voor te werken – een doel binnen de haalbare werkelijkheid, met de zekerheid dat het team zijn eigen verplichtingen kan kiezen. De ontwikkelaars moeten toegang krijgen tot de klant; de teamleider moet steun en hulp bieden in moeilijke situaties, en ervoor zorgen dat scepsis de teamgeest niet bederft. Het respecteren van mensen en het erkennen van hun werk is één manier om het team mondiger te maken.
Bouw integriteit inEdit
De klant moet een totaalervaring van het systeem hebben. Dit is de zogenaamde waargenomen integriteit: hoe het wordt geadverteerd, geleverd, ingezet, benaderd, hoe intuïtief het gebruik is, de prijs en hoe goed het problemen oplost.
Conceptuele integriteit betekent dat de afzonderlijke componenten van het systeem goed samenwerken als een geheel met balans tussen flexibiliteit, onderhoudbaarheid, efficiëntie en responsiviteit. Dit kan worden bereikt door het probleemdomein te begrijpen en het tegelijkertijd op te lossen, niet opeenvolgend. De benodigde informatie wordt ontvangen in kleine brokjes – niet in één grote brok – bij voorkeur door persoonlijke communicatie en niet in geschreven documentatie. De informatiestroom moet constant zijn in beide richtingen – van klant naar ontwikkelaars en terug, om zo de grote stressvolle hoeveelheid informatie na lange ontwikkeling in isolatie te vermijden.
Een van de gezonde wegen naar integrale architectuur is refactoring. Hoe meer functies worden toegevoegd aan de oorspronkelijke code base, hoe moeilijker het wordt om verdere verbeteringen toe te voegen. Refactoring gaat over het behouden van eenvoud, duidelijkheid en een minimaal aantal functies in de code. Herhalingen in de code zijn tekenen van slechte codeontwerpen en moeten vermeden worden. Het volledige en geautomatiseerde bouwproces zou vergezeld moeten gaan van een volledige en geautomatiseerde suite van ontwikkelaars- en klantentests, met dezelfde versiebeheer, synchronisatie en semantiek als de huidige staat van het systeem. Aan het eind moet de integriteit worden geverifieerd met grondige tests, om er zeker van te zijn dat het systeem doet wat de klant ervan verwacht. Geautomatiseerde tests worden ook beschouwd als onderdeel van het produktieproces, en als zij geen toegevoegde waarde hebben, moeten zij als afval worden beschouwd. Geautomatiseerd testen moet geen doel zijn, maar eerder een middel om een doel te bereiken, met name het verminderen van defecten.
Optimaliseer het Geheel
Moderne software systemen zijn niet slechts de som van hun onderdelen, maar ook het product van hun interacties. Defecten in software hebben de neiging zich op te hopen tijdens het ontwikkelingsproces – door de grote taken te ontleden in kleinere taken, en door de verschillende fasen van ontwikkeling te standaardiseren, moeten de hoofdoorzaken van defecten worden gevonden en geëlimineerd. Hoe groter het systeem, hoe meer organisaties bij de ontwikkeling betrokken zijn en hoe meer onderdelen door verschillende teams worden ontwikkeld, hoe groter het belang van goed gedefinieerde relaties tussen de verschillende leveranciers, om een systeem te produceren met soepel op elkaar inwerkende componenten. Gedurende een langere periode van ontwikkeling is een sterker netwerk van onderaannemers veel gunstiger dan winstoptimalisatie op korte termijn, die geen win-win relaties mogelijk maakt.
Lean thinking moet goed worden begrepen door alle leden van een project, voordat het wordt geïmplementeerd in een concrete, real-life situatie. “Think big, act small, fail fast; learn rapidly” – deze slogans vatten het belang samen van het begrijpen van het vakgebied en de geschiktheid van het implementeren van lean principes gedurende het gehele software ontwikkelingsproces. Alleen wanneer alle lean principes samen worden geïmplementeerd, in combinatie met een sterk “gezond verstand” met betrekking tot de werkomgeving, is er een basis voor succes in softwareontwikkeling.