Lean programvaruutveckling

Transkript

1 Lean programvaruutveckling Av Ludvig Hagmar eller Den 12:e Februari 2006 Abstract: Denna djupstudie behandlar den agila metoden Lean software development eller Lean programvaruutveckling som jag har översatt det till. Jag försöker ta reda på vad Lean är, hur man använder den, och diskuterar sedan i vilka likheter och skillnader den har till den agila metoden extreme Programming och om man kan kombinera de två metoderna.

2 Innehållsförteckning 1. INLEDNING VAD ÄR LEAN DEVELOPMENT? Bakgrund Lean developments 7 principer...4 Princip 1 : Eliminate waste...4 Seeing waste...4 Value stream mapping...5 Princip 2 : Amplify Learning...5 Feedback...5 Iterations...5 Synchronization...5 Setbased development...6 Princip 3 : Decide as late as possible...6 Options thinking...6 The last responsible moment...6 Making decisions...6 Princip 4 : Deliver as fast as possible...7 Pull systems...7 Queuing theory...7 Cost of delay...8 Princip 5 : Empower the team...8 Self-Determination...8 Motivation...8 Leadership...8 Expertise...9 Princip 6 : Build integrity in...9 Perceived integrity...9 Conceptual integrity...9 Refactoring...9 Testing...10 Princip 7 : See the whole...10 Measurements...10 Contracts LIKHETER MED EXTREME PROGRAMMING? SKILNADEN MOT EXTREME PROGRAMMING OCH KAN MAN ANVÄNDA BÅDE EXTREME PROGRAMMING OCH LEAN? extreme Programming metoder som inte finns i Lean Leanmetoder som ej finns i extreme Programming SLUTSATSER OCH FRAMÅTBLICKAR REFERENSLISTA... 13

3 1. Inledning What are you doing here? they asked. They were construction foremen, superintendents and project managers attending a course in construction planning from the Lean Construction Institute (LCI). Indeed, what was I doing there? I started to explain: In software development, we are told we should manage our projects like construction projects, where a building is designed at the start, cost and schedule are predictable, and customers get what they expect. Silence. You re kidding, right? No, honest, that s what we re told. Citat från Lean Construction 3/5/2002 [1] På senare år så har allt fler ifrågasatt den dominerande vatenfallsmetoden som det bästa sättet att utveckla programvara. Paralleller kan dras 50 år bak i tiden då dålig produktivitet oftast förklarades med lata arbetare. Det var då som Taiichi Ohno startade vad som skulle komma att revolutionerade bilindustrin. Det kallades för Lean Manufacturing och har sedan dess anammats av många biltillverkare och även annan industri även utanför Japan. Just den parallellen drog Mary Poppendieck när hon från Lean Manufacturing utvecklade Lean programvaruutveckling (Software development), en av de många agila metoder som dykt upp på senare år. Då jag själv har gått igenom ett projekt med den agila metodiken extreme Programming som jag tyckte var roligt så tyckte jag att det skulle bli intressant att titta närmare på en annan agil metod och se hur det fungerar och skiljer sig från extreme Programming. 2. Vad är Lean development? 2.1 Bakgrund Efter andra världskriget så skulle Japan moderniseras, och då var naturligtvis bilen den viktigaste saken att ha. Men japaner hade inte speciellt mycket pengar. Och marknaden var inte stor nog för att använda löpande band som Ford. Sakichi Toyoda som startat det företag som senare skulle kallas Toyota anställde Taiichi Ohno som skulle utveckla ett system för att producera bilar av hög kvalitet billigt. Han la stor vikt vid att undvika slöseri (waste). Stora lager skulle inte finnas utan man skulle istället imitera ett snabbköp genom att ha små kvantiteter av varje produkt som man sen fyllde på igen så fort någon tog något. För att undvika dålig kvalitet så testades varje del efter att den blivit behandlad och om ett fel upptäktes så stoppades all produktion.

4 För att öka effektiviteten så skapades standardiserade arbetsrutiner av arbetarna själva. Utvecklingen sågs som en stafett där man hjälptes åt om saker blev försenade. Det var grunden för vad som kom att kallas för Lean Manufacturing. Men det är svårt att ta upp det utan att även nämna Total Quality Management (TQM) som Dr. W. Edwards Deming lärde ut i Japan då de Amerikanska företagarna skyllde kvalitetsbrister på lata anställda. Det han talade om handlade om att skapa en arbetsmiljö som uppmuntrade anställda att skapa hög kvalitet i sitt arbete. Han förespråkade även långsiktiga relation med leverantörer som baserade sig på tillit var mycket bättre än kortsiktiga avtal som gick till den som erbjöd lägst pris. 2.2 Lean developments 7 principer Mary Poppendiek ger sju principer för Lean programvaruutveckling. [2] De är baserade på de principer som finns inom Lean Manufactoring men ampassade då programvaruutveckling och biltillverkning är två helt olika saker. Det ena är en kreativ process där man skapar och det andra är att skapa något som man redan vet hur det ska fungera och se ut. Det kan jämföras med en kock som antingen skapar ett recept eller tillagar en måltid efter ett recept. Om man ser närmare på den metaforen så överensstämmer vattenfallsmetoden ganska bra med att följa ett recept medan agila metoder påminner om att skapa ett recept. Mary Poppendiek tar även i sin bok upp så kallade verktyg som man kan använda för att implementera principerna. Jag kommer ta upp dem som underrubriker till principerna. Princip 1 : Eliminate waste En stor anledning till att de agila metoderna dök upp berodde på att allt större projekt ofta krävde enorma mängder pappersarbete. Detta tog upp stora delar av tiden för utvecklare som i allt mindre utsträckning höll på med de processer som gav något värde (kodning, analys, testning, felsökning mm) och mer sysslade med dokumentation som i många fall aldrig skulle bli läst. Lean manufactoring däremot grundar sig däremot på iden att allt onödigt ska bort. Seeing waste Det första verktyget till denna praktik är att se slöseri och onödigt arbete. För att göra det så kan man använda sig av The Seven Wastes of Manufacturing som Poppendiek har omvandlat till The Seven Wastes of Software development [2] som jag ska ta upp här under: Partially done work Kan bli förlegat och kanske inte passar in när det väl ska integreras. Det kanske inte ens fungerar. Extra processes Onödigt pappersarbete främst. Fråga dig själv, behöver någon det här. Kommer det att användas. Men allt pappersarbete är inte onödigt. Avvakta dock helst med dokumentation tills det som dokumenteras har implementerats. Extra features Kan verka smart men i en värld av ständigt ändrade krav så kan det visa sig vara helt bortkastad tid. Så om koden inte behövs nu, implementera den inte nu.

5 Task switching Det enklaste sättet att göra två arbetsuppgifter är att göra den ena först och den andra efteråt. Parallella uppgifter leder oftast till mycket längre arbetstid. Waiting Att sitta still utan att göra något är nog det mest uppenbara slöseriet. Är dock delvis i konflikt med principen Decide as late as possible. Motion Att utvecklare ska behöva röra på sig för att fråga medutvecklare, experter eller kunden om saker är ett slöseri. Defects Desto längre det går innan ett fel upptäcks och fixas desto längre tid tar det. Value stream mapping Det andra verktyget är ett väldigt praktiskt tipps för hur man hittar bortslösad tid. Rita upp en graf över din tid och vad du gjorde och dela upp det i tid du skapade något av värde och övrigt. Utifrån den så kan du sen enkelt se vad det är som tar mest tid från dig. Princip 2 : Amplify Learning Att programmera är att lära sig. Man testar experimentella lösningar, man gör fel och upptäcker nya sätt att lösa problem. Att utgå ifrån att allt görs rätt från början är att försöka följa receptet (som jag diskuterade i Lean developments 7 principer ) medan man om man vill skapa ett recept snarare bör satsa på en mer iterativ process. Det är i alla fall det tillvägagångssätt man bör följa om man anser att kvalitet är kvalitet för användaren och inte hur bra man har följt kraven. Feedback Som ett verktyg för Amplify Learning så nämns Feedback först. Feedback, från kunden och andra källor kan aldrig vara dåligt. Men man är rädd för det naturligtvis då man vet att det i de flesta fall leder till extra arbete. Hela tanken med feedback är att hitta saker som kan eller bör ändras. Men ju längre man väntar med feedback desto större blir ändringarna, alternativt att man levererar en produkt som kunden inte vill ha/inte fungerar. Poppendiek[2] ger en del tips på hur man kan få bra feedback: Kör tester så fort koden är skriven. Testa nya idéer genom att skriva kod. Visa ett antal potentiella användarskärmar och få deras input. Vill man ta reda på vilket verktyg man ska använda så ta de tre främsta och testa dem. Iterations Att arbeta i iterationer är en vanlig idé bland agila metoder. Man arbetar i ett antal veckor med målet att få ett visst antal funktioner (features) att fungera. Sen får kunden något väldigt konkret som han kan ge bättre feedback till. Synchronization

6 Ett problem med att implementera funktioner är att man om man flera som arbetar med dem kommer att behöva ändra i samma kod vilket tvingar fram gemensamt ägd kod. För att det ska fungera så krävs det synkronisering. Det kan uppnås genom frekvent testning, genom bra kommunikation, eller någon av de andra metoder som finns. Och det skadar ju inte att kombinera metoder. Setbased development Setbased development är inte ett alternativ till iterativ utveckling utan snarare något man bör göra varje iteration. Man utvecklar flera alternativ till ett problem och använder sig av de bästa egenskaperna hos varje. Detta hjälper även till med nästa princip( Decide as late as possible ). Princip 3 : Decide as late as possible Om du inte har beslutat dig för en lösning än så kan inte kunden förstöra något genom att ändra sig. Dessutom så är det enklare att göra bra beslut om du har mer information. Options thinking Undvik att göra några radikala beslut tills du måste och utveckla något som kan vidareutvecklas i flera riktningar. Mycket svårare är det inte. The last responsible moment The last responsible moment är ett uttryck som myntades av the Lean construction institute [9] och betyder i princip den punkt då du om du inte tar ett beslut utesluter ett alternativ och därmed tar ett beslut genom att inte ta ett beslut. Det kan vara svårt att avvakta med beslut så länge men det kan vara ett mål. Dock så ska man inte avvakta med beslut längre än det är praktiskt. Making decisions När man till slut ska göra sitt beslut så kanske det kommer naturligt. För den erfarne programmeraren känns det kanske inte ens som ett beslut, han bara vet vad han ska göra. Men när det kommer till problem man har mindre erfarenhet av så kan man titta på de 7 principerna: Eliminate waste Amplify learning Decide as late as possible Deliver as fast as possible Empower the team Build integrity in See the whole

7 Princip 4 : Deliver as fast as possible En sak som förenklar Decide as late as possible rejält är att man har förmågan att leverera snabbt. Från ett kundperspektiv så är det inte heller svårt att förstå fördelen med att få varan snabbt efter att man har efterfrågat den. Tanken är att man låter kunden avvakta sina beslut så länge som möjligt och sen när han väljer något så levererar man det innan hinner ändra sig. Pull systems Det finns två sätt att se till att folk arbetar så effektivt som krävs för att kunna leverera snabbt. Antingen talar man om för dem vad de ska göra eller ge dem det som krävs för att ta reda på det själva. Och ska det fungera effektivt så är det egentligen bara det andra alternativet som fungerar. Tanken är att man låter kunden inför varje iteration skriva ner på lappar vad för funktionalitet han vill ha. Därefter så estimerar utvecklarna hur lång tid var och en av de kostar (i tid). Och därefter så prioriterar kunden vad som bör göras först. Korten enbart räcker inte för att utvecklarnas ska veta vad som de ska göra utan de bör även ha ett 15-minutersmöte varje dag där alla är närvarande och diskuterar vad de gjort dagen innan, vad de kommer att göra under dagen och om de behöver hjälp. Om det leder till djupare diskussioner så kan det tas i separata möten mellan de inblandade. För att det här ska fungera så bör iterationen vara kortare än en månad. Queuing theory Det är inte helt ovanligt att små flaskhalsar förhindrar att man snabbt levererar. Kanske fungerar utvecklingen perfekt men testningen tar åratal, eller så är det en del av projektet som stannar upp allt annat. Köteori ger en del svar på hur man ska minska flaskhalsarna eller kanske ännu viktigare, tiden som varje funktionalitet spenderar i kön. Det finns ett antal tillvägagångssätt för det. De uppenbara är naturligtvis att skaffa fler parallella processare. Men billigare tillvägagångssätt är att skapa ett jämnt flöde in i processen. I exemplet med testare så kan man t ex Se till att de tidigt får testa delar så att de inte bara blir överbelastade samtidigt med alla tester i slutet av iterationen. Det andra är ett sätt att minska tiden i kön genom ett jämnt flöde som processas. T ex att man försöker undvika att en uppgift blir liggande för att utvecklaren som skulle ta den har kört fast med en annan uppgift. Dock så kan det komma till ett läge där ett led i utvecklingen är så pass underdimensionerat jämfört med övriga att det leder till antingen bortkastat arbete eller undermålig kvalitet trots att man utnyttjar ovanstående tekniker. I det fallet så är det ekonomiskt oförsvarbart att inte utöka den delen.

8 Cost of delay Det är inte alltid som man bara kan tänka på hur man kan uppnå minst antal kr/timme för att bestämma utvecklingstakten. Det är inte helt dumt att besöka marknadsavdelningen och höra hur mycket man tjänar på att producera produkten snabbare innan man bestämmer sig för om man ska köpa in dyra verktyg eller liknande som kan öka förmågan att leverera snabbt. Princip 5 : Empower the team I Lean programvaruutveckling så händer saker snabbt och mycket hänger på att utvecklarna är motiverade och kunniga nog för att kunna ta beslut. Det kan jämföras med brandmän som sällan ringer upp sina chefer och frågar hur man ska ta sig igenom dörren till den instängda mannen som håller på att dö. Self-Determination Self-Determination handlar om att låta utvecklarna själva bestämma över hur utvecklingen ska ske. Låter man utvecklare ta besluten och få mer ansvar så kommer de också känna sig mycket mer engagerade i projektet. Motivation Motivation kommer ofta från en kombination av att kunna påverka sin situation och av att känna att man gör något meningsfullt. Det är svårt att känna sig motiverad av ett arbete som man vet aldrig kommer att leda till någon nytta. Forskning har visat att motivation kräver: Tillhörighet Medlemmarna i teamet måste känna respekt för varandra och se framgångar som kollektiva. Säkerhet Ett enkelt sätt att döda motivationen är att skapa ett klimat som inte tillåter misstag. Det är svårt att känna sig motiverad när man är rädd för att ta initiativ. Kompetens Medlemmarna i teamet måste känna att de kan klara av sitt jobb. En känsla av framåtskridande Medlemmarna i teamet måste kunna få possitiv feedback och känna att det går framåt. Det är viktigt att ha mål och att fira det när man når dem. Om man väl når en hög motivation så får man se upp med att medlemmarna i teamet inte blir för överentusiastiska och börjar jobba dygnet runt. Det kan ju verka bra först men kan leda till ett klimat där folk förväntas lägga all sin tid på teamet. Dessutom så kommer ett sådant team att sakna flexibiliteten att öka sin produktionshastighet när det behövs. Leadership

9 Ledarens roll är viktig. Men det handlar inte om att planera alla utvecklares tid och säga vad de ska göra. Det handlar snarare om att skapa en miljö som skapar motiverade utvecklare och att se till att de Leana principerna används. Expertise Det är viktigt att ha experter på de olika områden man rör sig i. Då kan man använda sig av dem för att sprida kunskapen vidare inom organisationen. Princip 6 : Build integrity in Build integrity in är den princip som handlar mest om hur man ska bygga sitt program. Det finns två sorters integritet för ett system, uppfattad (perceived) och konceptuell (conceptual). Ett system med uppfattad integritet är precis vad en kund vill ha även om han inte visste att han ville ha det. Det handlar om att göra det som kunden vill ha. Konceptuell integritet är ett system som är konsekvent och välfungerade. Det är att bygga det system som kunden vill ha bra. Dessa två saker behövs för att man ska kunna säga att ett system har integritet. Perceived integrity Hur uppnår man då upplevd integritet? Kundkontakt är naturligtvis ett måste. Kunden har ofta svårt att specificera exakt vad han är ute efter från början, men om han får se exempel så kommer han kunna säga vad han är ute efter. Därför så bör mindre system utvecklas av ett team som har tillgång till en kund eller de som ska använda systemet i slutändan. Det bör också utvecklas i iterationer där systemet efter varje iteration utvärderas av folk som kan ge bra feedback. En annan bra ide är att låta kunden testa programmet. Vid stora system så bör det finnas en master developer som är väldigt kunnig både tekniskt och om kundens behov. Han ska sen kunna representera kunden för utvecklarna. Conceptual integrity För att hålla systemet konsekvent och felfritt så bör man använda sig av standarder. Det kan även vara bra att se på två av de verktyg som nämndes i princip 2 Amplify Learning, dvs. Synchronization och Setbased development. Refactoring Eftersom man utvecklar iterativt och designen utvecklas allteftersom så är det oundvikligt att designen efter ett tag kommer att börja tappa mycket av den konceptuella integriteten. Därför måste man refaktorisera. Det finns många källor till hur man ska refaktorisera bra. Men det man bör tänka på är de egenskaper som ett system med god konceptuell design har: Enkelhet Tydlighet Lämplighet för användning Ingen onödig upprepning Extra funktioner som inte behövs

10 Testing Ska man kunna refaktorisera ordentligt och vara säker på att koden behåller sin konceptuella integritet så behöver man tester. Skillnaderna mellan enhets, system eller integrationstester är inte så viktiga och kan kallas utvecklartester. Sen så finns det ju också kundens tester, för att hålla den uppfattade integriteten hög, som traditionellt kallas för acceptanstester. Men eftersom det ger en känsla av att de bara körs i slutet av projektet så föredrar Poppendiek[2] att det kallas för kundtester. Princip 7 : See the whole Ett problem som ofta uppstår i organisationer är att varje del endast ser till sig själv och hur de kan optimeras. Men sådana optimeringar är allt för ofta destruktiva för det stora hela. Målet måste vara att motivera folk till samarbete och få dem att känna sig delaktiga och ansvarskännande för hela projektet. Measurements En del av problemet med lokal optimering ligger i att man mäter saker som inte gynnar projektet i stort. Kan man inte mäta hur hela projektet går så bör man kanske undvika att mäta alls. Contracts När det kommer till kontrakt så är Lean programvaruutveckling av samma åsikt som övriga agila metoder att Customer collaboration over contract negotiation. Dvs. att det är bättre att skapa ett förtroende och arbeta för den gemensamma nyttan än att leta efter bästa sätt att lura ens motpart på några kronor hit eller dit. Långsiktigt så lönar det sig. 3. Likheter med extreme Programming? Likheterna mellan Lean och extreme Programming är många. De utvecklades på helt olika sätt, men likheterna är ändå uppenbara. Jag tänker här gå igenom extreme Programmings olika praktiker och diskutera likheterna: Code and design simply - Det är ingenting som läggs stor kraft på att markera. Men enkelhet i designen tas upp som viktigt för att få konceptuell integritet i sitt system. Refactor mercilessly - Även refaktoriseringen är något som Lean buntar ihop i sin princip Build integrity in. Dock så kan man ju säga att extreme Programming verkar lägga större vikt vid det när det lägger upp det som en av sina praktiker och även anser att man bör göra det mercilessly. Develop coding standards Även den nämnd angående den konceptuella integriteten. Develop a common vocabulary Nämns inte direkt men kan tänkas ingå i den konceptuella integriteten då den handlar om att få ett konsekvent system. Adopt test-driven development Medan Lean markerar vikten av tester ganska tydligt så sägs det ingenting om att skriva testerna före koden. Practice pair programming Lean nämner inte parprogrammering.

11 Adopt collective code ownership Är något som Lean förespråkar kraftigt och ofta. Det går att genomföra Lean utan gemensamt kodägande, men det är inget att rekommendera. Integrate continually Nämns inte speciellt men är ju en naturlig sak om man har gemensam kod. Add a customer to the team Lean lägger stor vikt vid kundens närvarande och delaktighet. Speciellt när det gäller att få en uppfattad integritet. Play the planning game I verktyget Pull systems så föreslås något som i princip är identiskt med planning game. Release regularly Även här är de båda metoderna rörande överens om att det behövs iterativ utveckling med frekventa releaser. Lean anser att ens iterationer helst inte bör vara längre än en månad. Work at a sustainable pace Har själv svårt att tro att det är något som gått hem hos de japaner som utvecklade Lean. Men i Lean programvaruutveckling så nämns att för hög arbetsbörda kan leda till en pressad arbetssituation och mindre flexibilitet. Det nämns dock mest i förbifarten Det kan tyckas att det är svårt att jämföra då Lean-principerna är betydligt mer abstrakta än extreme Programmings praktiker och att man då borde titta på extreme Programmings values. Det är dock även där ett glapp då de är betydligt mer abstrakta än Lean-principerna. De är Communication, Feedback, Simplicity och Courage och är alla även värden som är närvarande överallt i Lean. 4. Skilnaden mot extreme Programming och kan man använda både extreme Programming och Lean? De stora skillnaderna ligger i hur de olika metoderna presenteras. extreme Programming är betydligt mer konkret än Lean. Poppendieks bok[2] presenterar ett antal verktyg, men själv tycker jag att extreme Programmings praktiker är betydligt mer konkreta. Dock så finns det en del saker i båda metodiker som inte berörs i den andra. Ja ska gå igenom några av dem här och diskutera huruvida de kan läggas till i den metod som de inte finns i. Därmed inte sagt att allt som kan läggas till bör läggas till. Det finns alltid en risk att det blir alltför plottrigt med många praktiker. Bättre då att försöka titta på de värden som extreme Programming och Lean har gemensamt och ampassa dem till det problem du står inför. 4.1 extreme Programming metoder som inte finns i Lean Test-driven development Om det är något man märker när man läser artiklar kritiska mot extreme Programming är att de flesta erkänner att Test-driven development är en nyttig praktik var den än används. Om det beror på att Test-driven development är en av de bästa metoderna i extreme Programming och är universellt genomförbar eller att det helt enkelt är den som är lättast att acceptera för folk som ogillar agila metoder kan diskuteras. Jag väljer att tro på båda orsakerna. Och jag har

12 svårt att förstå varför det inte nämns av Lean. Men jag kan absolut inte se någon anledning att inte använda Test-driven development när man använder Lean. Pair programming Parprogrammering är en betydligt mer kontroversiell praktik. Jag är fullt införstådd med fördelarna av parprogrammering och det kan anses överensstämma med Leanprincipen Amplify learning. Men det kan också anses att vara i konflikt med Deliver as fast as possible. Konflikten ligger emellan behovet av kommunikation, kodförståelse och lärande och behovet av snabb utveckling. Den här praktiken kan användas med Lean men jag har inget bra svar på huruvida den bör användas med Lean. Det är något som måste bestämmas utifrån vilka behov som är störst lokalt. 4.2 Leanmetoder som ej finns i extreme Programming Empower the team Något som extreme Programming nämner väldigt lite är hur man skapar motiverade och handlingskraftiga utvecklare. Det beror nog på att extreme Programming är från en utvecklares perspektiv. Därför ser jag inga problem med att använda det. Deliveras fast as possible och decide as late as possible Dessa två principer tar jag tillsammans då der är beroende av varandra. extreme Programming nämner redan många saker som de nämner så de ska gå enkelt att kombinera. Speciellt verktygen Options thinking och Queuing theory är konkreta saker som kan komma till nytta när man använder extreme Programming. Setbased development Är något som inte nämns speciellt av extreme Programming men som låter väldigt extreme Programming. Kanske inget man nödvändigt bör använda generellt då de kan leda till onödigt arbete, men definitivt något som kan användas till vissa problem. Eliminate Waste Om ditt extreme Programming -projekt är perfekt så kommer du inte ha någon nytta av det här då extreme Programming precis som Lean inte gillar onödigt arbete. Men då få saker är perfekta så ges här två bra verktyg för att ta reda på var i ens projekt som saker inte funkar så väl som det borde. 5. Slutsatser och Framåtblickar Lean programvaruutveckling har sina rötter 50 år tillbaka i tiden, men är väldigt likt de övriga agila metoder som kommit fram på senare år. Den har många likheter med extreme Programming, och de olikheter som finns är inte så stora att man inte, om man velat, skulle kunnat skapa LeXstrean programming. Efter att ha läst kursen Programvaruutveckling i grupp på Lunds tekniska högskola som är ett projekt i extreme Programming så kan det diskuteras om den kursen hade kunnat göras med Lean programvaruutveckling i stället. Det enkla svaret är: Ja, med modifikation. Modifikationen hade i så fall varit att lärarna på kursen hade behövt göra en ordentlig konkretisering Lean för de oerfarna utvecklarna som läser kursen. Det är också därför som kursen bör fortsätta att använda extreme Programming då extreme Programming är en av de mest konkreta och enkla metodiker som finns.

13 6. Acknowledgements Slutligen så vill jag tacka Marcus Jacobsson, Ola Bodin, Anders Nyman och Görel Hedin som har granskat min djupstudie och gett mig många bra kommentarer. 7. Referenslista [1] [2] Lean Software Development: An Agile Toolkit for Software Development av Mary och Tom Poppendieck ISBN: Addison-Wesley 2003 [3] Extreme Programming Pocket Guide av chromatic ISBN: O Reilly Media, Inc 2003 [4] Agile vs Lean Software Development [5] Publications and Working Papers på poppendieck.com [6] The Competitive Edge of Risk Entrepreneurs [7] Agile Software Development: The Business of Innovation 07 [8] Lean Programming [9] Lean Construction Institute