Lean Utveckling
Lite Historia
Begreppen Lean (på engelska) i sammanhanget jag använder det i denna text (som filosofin man hade på Toyota) kommer från 1991 och nämndes i boken The Machine That Changed the World: The Story of Lean Production av James Womack, Daniel Jones och Daniel Roos.
Efter bara ett par år landade begreppen inom mjukvaruindustrin när Lean dök upp på två av varandra oberoende håll: på ESPRIT-konferensen i Stuttgart 1992 och 1993 när Robert "Bob" Charette undersökte riskhantering i mjukvaruprojekt.
Toyota Production System och Lean Produktion
Överblick
Lean tillverkning började på Toyota på sent 1940-tal och blev en filosofi med fokus på att eliminera faktorer i en process som inte tillför värde - slöseri. Muda på japanska, waste på engelska och slöseri på svenska. Syftet är mer värde för mindre arbete.
Slöseri - Waste - Muda, Mura & Muri
Enligt modellen och filosofin finns det tre huvudtyper av slöseri: muda, mura och muri, och de kan förklaras som:
- muda: slöseri, eller arbete som inte tillför värde (non-value-adding work)
- muri: överbelastning (overburden)
- mura: ojämnhet (unevenness), då i betydelsen att till exempel arbetsinsatsen vid ett tillfälle eller en plats är hög och på en annan låg.
Utifrån detta kan man då identifiera 8 (eller tidigare 7) typer av slöseri - det vill säga arbete som inte tillför värde, överbelastning eller ojämnhet:
- Överproduktion: Tillverkning av mer produkter än vad som behövs, eller att tillverka dem tidigare än vad som behövs. Detta är det värsta av slöserierna eftersom det orsakar flera andra slöserier.
- Transport: Vid varje förflyttning riskerar man att godset skadas, blir försenat eller tappas bort. Dessutom tillför transporten inte värde till godset eller produkten. Man kan ju tänka sig att en leverans har ett värde, men slöseriet avser onödig förflyttning.
- Lager: Råmaterial, pågående arbete och färdiga produkter har alla ett värde i sig. Att investera i dessa för att "bara samla på hög" är ett slöseri.
- Rörelse: Här tänker man sig inte transport utan snarare rörliga delar i en produktionsprocess: borrar, kugghjul, eller moment personal utför. Kan man minska denna typ av slöseri minskar man slitage på material och kan även slippa till exempel musarm eller tennisarmbåge hos personalen.
- Väntan: gods som inte processas eller transporteras väntar. Ett outnyttjat värde. En mycket intressant analogi i mjukvaruvärlden kommer senare i denna text - det visar sig att något konstigt händer med till exempel avvikelserapporter som väntar.
- Överarbete: att göra mer än kunden kräver eller betalat för.
- Omarbete (defekter): Att reparera, retrofitta eller på något annat sätta göra om en defekt produkt skapar inte mervärde för kunden. Även detta slöseri får en viktig följdsats i texten nedan.
- Oanvänd förmåga: Att inte ta till vara på sina anställdas kreativitet kan leda till missade förbättringar.
Principer, Värderingar, Mål
Några värderingar och begrepp som återkommer inom Toyota Production System och Lean Produktion är:
- Ständiga förbättringar
- Utmaning - ha mål, var modig och kreativ för att nå målen
- Kaizen (Förbättringspotential) - förbättra processen
- Gå till källan (Genchi Genbutsu) - hitta källans fakta innan beslut fattas
- Respektera Människor
- Respekt - respektera, förstå, ta ansvar och bygg förtroende
- Teamwork - samarbeta, dela möjligheter, maximera individuella och teamets prestation
- Mentorskap
- Senpai & kohai - ett slags mentorskap som tydligen är vanligt i Japan.
- Sensei - en slags lärare.
- Dessa roller går i princip ut på att den mer erfarne ska lära den lite mindre erfarne om arbetet och även förmedla värderingar och filosofi.
Punkter som karakteriserar lean produktion är typiskt (här direkt från Svenska Wikipedia):
- Långsiktiga mål
- Basera beslut på långsiktigt tänkande även då det sker på bekostnad av kortsiktiga finansiella mål.
- Rätt process ger rätt resultat
- Skapa kontinuerliga processflöden för att föra upp problem till ytan.
- Använd dragande system för att undvika överproduktion.
- Jämna ut arbetsbelastningen.
- Skapa en kultur där processer stoppas för att reda ut problem.
- Standardiserat arbete är grund för ständiga förbättringar och för medarbetarnas medverkan.
- Använd visuell styrning så att inga problem döljs.
- Använd bara pålitlig, väl beprövad teknik som passar medarbetare och processer.
- Öka värdet i organisationen genom att utveckla anställda och partners
- Se till att ledningen känner verksamheten på djupet, lever enligt företagets filosofi och lär andra att göra det.
- Utveckla människor och arbetslag som följer företagets filosofi.
- Respektera partners och leverantörer genom att hjälpa dem att bli bättre.
- Lös problemens rotorsak för att lära organisationen
- Gå och se med egna ögon för att bättre förstå en situation.
- Fatta beslut långsamt och i samförstånd. Överväg alla alternativ och genomför sedan valt beslut snabbt.
- Bli en lärande organisation genom att ständigt reflektera och förbättra.
5S Metoden
Ett annat begrepp som kanske inte tillhör Lean Produktions kärna, en som tilltalar mig är 5S metoden. Det är den oläsliga allitterationen seiri, seiton, seiso, seiketsu, & shitsuke som är de 5 S'en. En möjlig översättning till svenska (igen från svenska wikipedia) är sortera (seiri), systematisera (seiton), städa (seiso), standardisera (seiketsu) och se till (shitsuke). En alternativ översättning (igen: wikipedia) tycker jag är: Inventering, Placering, Initialrengöring, Rutiner och Disciplin.
I princip handlar det om ordning och reda på arbetsplatsen och i sitt arbete.
OPDCA - Observe, Plan, Do, Check, Adjust
En utvidgning av en tidigare modell utan O (plan, do, act, check). OPDCA är en processförbättringsprocess (jag älskar det ordet: process-förbättrings-process) eller en metod för hur man förbättrar sina processer. Stegen bildar en cykel (eller hjul, eller cirkel) som går runt och på så sätt förbättrar man sina arbetsmetoder. Stegen äro:
- Observation (Finns inte alltid med): Förstå nuläget. Jag skulle vilja lägga in mät här, men det kan vara så att det hör hemma mer i do-steget.
- Plan: Skapa en plan, mål och förväntat utfall.
- Do: Genomför planen och mät (samla in data föra).
- Check: Mät och samla in efter-data. Fick du förväntat utfall? Blev genomförandet som väntat? Samla in data som kanske behöver användas i flera OPDCA-cykler för att se långsiktiga trender.
- Adjust (eller Act): Genomför åtgärder för att rätta till det som inte blev bra (om det inte blev bra).
Som kuriosa kan man nämna att OPDCA i princip är en förlängning av den vetenskapliga metoden som Francis Bacon beskrev den år 1620: hypotes, experiment, utvärdering.
Sammanfattning
Lean Produktion går ut på designa arbetsprocessen så att man minskar slöseriet (arbetet som inte tillför värde, överbelastningen och ojämnheten). Långsiktiga och sunda värderingar går ofta hand i hand med lean och kaizen eller ständiga förbättringar är ett centralt begrepp.
Lean Utveckling
Hur förhåller sig då lean produktion till att utveckla mjukvara på ett leant sätt?
Exempel: Slöseri
Vi börjar med att titta på exempel på slöseri (min översättning och tolkning av engelska Wikipedia):
- Överproduktion, till exempel att implementera delsystem som inte behövs eller borde behövas.
- Transport, till exempel att låta ett större team än vad som behövs resa för att lösa tekniska problem. Med bättre kvalitet kanske resan kunde undvikits?
- Lager, till exempel för onödigt många (fysiska) servrar. Kanske flera konkurrerande administrativa system som tidrapportering i excel och på webb; eller källkodshantering i git, avvikelserapporter i bugzilla och kravhantering i team foundation server.
- Rörelse, kanske regressioner, eller upprepade "brandkårsutryckningar" för att lösa problem i IT-miljön.
- Väntan, till exempel lång svarstid från servrar, långsamma applikationer eller onödiga manuella steg.
- Överarbete, till exempel att rapportera tekniska detaljer som cyklomatisk komplexitet till en administrativ chef (eller en ekonom).
- Omarbete (eller snarare defekter) kan ge upphov till till exempel säkerhetsproblem och dålig mjukvara.
- Oanvänd förmåga kan leda till att personal inte ser problem eller förbättringspotential, eller att anställda vantrivs, eller att personal används till fel saker.
Boken Lean Software Development
Referensverket inom Lean Utveckling är Lean Software Development av Mary Poppendieck och Tom Poppendieck, ISBN: 9780321150783, från Addison-Wesley 2003. Samma författare har även skrivit en rad andra böcker inom Lean. De som finns på Adlibris är:
- Lean Software Development (2003)
- Implementing Lean Software Development (bara Tom, 2006)
- Leading Lean Software Development: Results Are Not the Point (2009)
- The Lean Mindset: Ask the Right Questions (2013)
Principer från boken
- Eliminera slöseri (Eliminate waste), till exempel:
- ingen onödig kod
- inga onödiga krav
- tydliga krav
- ingen ofullständig testning (för att undvika upprepad testning)
- minska byråkratin
- snabba upp intern kommunikation
- Bygg in kvalitet och integritet (Build integrity in, eller Build Quality in). Till exempel med
- regelbunden refaktorering
- parprogrammering
- test-driven utveckling
- konstant feedback
- minimera tid mellan faser
- frekvent integrering
- automatisering
- inte bara kvalitet - det finns flera aspekter av ett projekt, till exempel tid, kostnad, omfattning och resurser. Hitta en bra balans.
- Skapa kunskap (Amplify learning, eller Create Knowledge). Kunskapsspridning kan förbättras med parprogrammering, kanske genom dokumentation i en wiki, kommenterad kod och kodgranskning.
- Fatta beslut sent (Decide as late as possible). Det kan till exempel vara onödigt att fatta vissa beslut så fort som möjligt "av princip". Vissa beslut är det bra att skjuta på.
- Leverera snabbt (Deliver as fast as possible).
- Respektera personalen (Empower the team). Personalen är inte bara en resurs som kan allokeras och vari man placerar en lista med arbete. De anställda har drivkrafter och man bör ge dem uppmärksamhet, lyssna på dem och ta tillvara på kaizen-möjligheter.
- Se helheten (See the whole). Två exempel ursprungligen från Mary och Tom Poppendieck:
- Kunden vill ha en ny funktionalitet "igår". Utvecklarna hör "fixa det snabbt - det får kosta vad det vill". Resultatet blir slafsig kod med mycket buggar. Komplexiteten i koden ökar och defekterna kommer.
- Testarna är överbelastade. Antingen testar man inte allt, eller så testas kod långt efter den skrevs. I båda fallen blir utvecklare utan feedback. Testarna är överbelastade. Kvaliteten sjunker.
Lean Systems Society
David J. Anderson startade Lean Systems Society och jag sammanfattar här en underbar artikel han skrev på MSDN 2011 som uppdaterades 2012 som handlar om Lean Utveckling. Han använder begreppet "knowledge work", kanske kunskapsarbete, och att det är stora skillnader mellan att bygga bilar och kunskapsarbete. Lean Utveckling ska därför inte direktöversättas från Lean produktion.
Värderingar
- Acceptera att vi är människor. Människor kan vara känslomässiga, sociala och kan utsättas för trötthet och stress. Processer som lyckas tar hänsyn till det, och utgår inte ifrån att människor är kalla, logiska maskiner.
- Acceptera att komplexitet och osäkerhet är naturligt inom kunskapsarbete. Arbetsflödet kan vara oförutsägbart och mål, syfte och avgränsningar kan ändras över tiden. Processen behöver klara detta.
- Arbeta mot ett bättre ekonomiskt utfall. Kunder förtjänar bättre och bättre produkter. Anställda förtjänar en bra lön. Investerar och ägare förtjänar avkastning på sina investeringar.
- Möjliggör ett bättre socialt utfall. Ekonomisk vinst får inte gå ut på sociala värden som arbetsmiljö. En utmärkt arbetsplats möjliggör utmärkt arbete.
- Hitta, omfamna och ifrågasätt idéer från olika discipliner.
- Är man värdebaserad ökar man chansen att få snabba och djupa positiva förbättringar.
Principer
- Se hela systemet. Ibland "optimera helheten" (det kan vara farligt att bara optimera en del - helheten kan bli suboptimal). Vi behöver se hela processen och vad vi interagerar mot - vad vill till exempel kunden ha? En följd av att blir att processförbättringar sker systematiskt - till exempel med OPDCA.
- Emergent Outcomes can be Influenced by Architecting the Context of a Complex Adaptive System
- Respektera personalen (som en del av systemet). Inom kunskapsarbete är det ofta så att personalen kan mer inom domänen de arbetar inom än sina chefer så personalens vilja att självorganisera och föreslå kaizen events (processförbättringar).
- Använd den vetenskapliga metoden (se OPDCA ovan) för att förbättra processen. En viktig del är att samla in statistik och visualisera processen.
- Uppmuntra ledarskap. Till skillnad från chefskap (och ansvar över personal och budget) menar författaren att man ska stötta personalens förmåga till visioner, strategier, taktiker, innovation och så vidare. Ledarskap hos personal kan ge positiva kaskadeffekter.
- Visualisera (arbetet, flödet och miljön). Kunskapsarbete är osynligt och det är svårt att styra sådant som är osynligt. Kan man visualisera hur arbetet flödar genom processen kan man mäta och styra det. Något som återkommer inom lean är att man med visualisering kan se var man har ojämnheter (ni minns slöseriet mura?).
- Minska flödestiden (cykeltiden). Inom Lean Utveckling har man upptäckt att tiden det tar från att analysera en ny finess eller ett nytt krav tills det är redo för släpp till kund med fördel kan mätas i kalendertid. Här tycker jag mig se en koppling till slöseriet väntan. Det finns ett par anledningar till detta:
- Tydligen är det så att lång cykeltid leder till en ökad mängd avvikelser/buggar i koden. Detta är en viktig skillnad mellan kunskapsarbete och till exempel tillverkning där man ofta blir effektiv av att jobba i stora omgångar "batchar". Det låter kontraintuitivt att buggar skulle växa i sovande kod - snarare har det att göra med missförstånd, dålig kommunikation och att man glömmer ursprungliga syften med lång cykeltid.
- En annan anledning är att problem som fixas så fort de hittas ofta går fortare att lösa. En bugg som lagas när den hittas kanske tar 20 minuter, men en bugg som vilar ett par dar kanske tar tre timmar att reparera. Skillnaden i tid är slöseri.
- En tredje anledning till kort cykeltid är att varje iteration genom processen tillför värde.
- En fjärde anledning som jag funderat på och som jag är osäker på om författaren kanske lagt någon annanstans är att en process med låg cykeltid svarar bättre på förändringar.
- Bli effektivare genom att minska slöseriet. Några exempel från artikeln är:
- Overhead - varje arbete som tillför värde omges av arbete som inte gör det.
- Överflödig kommunikation.
- Omarbete - typiskt från buggar.
- Man kan se över andelen arbete som tillför värde av det totala arbetet.
- Batchstorleken kan ses över (se ovan).
Typiska tekniker
- Cumulative Flow Diagrams
- Visual Controls
- Virtual Kanban Systems
- Small Batch Sizes / Single-piece Flow
- Automation
- Kaizen Events
- Daily standup meetings
- Retrospectives
- Operations Reviews
Lean vs Agile vs XP vs Scrum vs V-model
Ett sätt att se på det är att se lean, agilt, scrum och xp som delar av samma sak. Lean kan vara företagsledningens syn på det som hos mjukvaruavdelningen blir agilt eller scrum. De enskilda utvecklarna använder kanske metoder från XP. En del hävdar att om man går agilt så får man lean på köpet. Andra hävdar bestämt att till exempel V-modellen kan anpassas för lean. Jag väljer att inte ta ställning i denna text - men tycker ni kan ta en titt på ett utkast jag tidigare gjorde om en Agil Testprocess som jag inte kan sluta tänka på. Den har med lite V-modellen och lite agilt.
Jag känner att jag även behöver nämna Kanban som har sina rötter i lean. Fem viktiga principer inom kanban är att:
- Visualisera arbetsflödet.
- Minska mängden pågående arbete
- Hantera flödet
- Gör processpolicys explicita
- Förbättra samarbetet
För en lite djupare analys av lean, kanban och scrum kan jag vart tipsa om The Lean of Scrum av David Starr skrivet på MSDN: [1].
Lean Testing
Inom Lean Utveckling verkar det inte finnas någon motsvarighet till den klockrena Boken Agile Testing och de Agila Testkvadranter. Istället verkar principer för testning man finner i agilt dyka upp lite här och där. På samma sätt som inom agil testning finner man en önskan om snabb och ständig feedback. Jag tänker mig även att testdriven utveckling vore bra eftersom det ofta leder till mindre komplex kod.
Referenser
- Toyota and Lean
- Lean software development
- Lean vs agile vs scrum vs v-model
Denna sida tillhör Kategori Test
Se även Agil Testprocess och Beräkna Testinsats
Se även Boken This Is Lean