Kanban i Extreme Programming

Transkript

1 Kanban i Extreme Programming N. Fors och N. Hansson D06, Lunds Tekniska Högskola [niklas.fors niklas.hansson.06]@gmail.com 2mars2010 Abstract Kanban is a scheduling approach from the work philosophy just-intime of Toyota. This paper describes the background of Kanban and how it can be used as a tool in agile software development. The purpose of agile Kanban is visual feedback, self-driven teams, continous improvement and when functionality is done, which corresponds well with the purpose in many agile software development methodologies. A Kanban board and the surrounding rules has been implemented and evaluated in a student project, integrated with the agile development methodology Extreme Programming.

2 Innehåll 1 Inledning 1 2 Bakgrund Toyota Production System Kanban Extreme Programming Kommunikation Feedback Förbättring Reflektion Baby Steps Flöde Ekonomi Informativt arbetsutrymme Kanban i agil mjukvaruutveckling Tillsammans med XP Kanban i studentprojekt Kanbanbrädet Resultat Överlämningsmoment Definition of Done Begränsningar i faser Kanbans effekt på XP Kanbans effekt på teamet Jämförelse med Toyotas Kanban Rekommendationer Stort Kanbanbräde nära teamet Inledande enkla Definition of Done Definition of Done utformad som checklista Inledande övervakning Utgå från den befintliga processen Lagom antal faser Ständig reflektion Relaterat arbete 10 A Fotografier 12

3 1 Inledning Extreme Programming (XP) är en agil mjukvaruutvecklingsmetod som fokuserar på att hantera förändringar. Kent Beck [BA04], grundaren till XP, förespråkar bland annat att ett team ska ha möjlighet att snabbt få en överblick över projektets framskridande, men anger ingen konkret implementation av detta. Kanban är en schemaläggningsmetod från produktionsindustrin som härstammar från bilföretaget Toyota. Metoden ger en snabb överblick om hur projektet ligger till och ger även teamet direkt återkoppling om hur de ska arbeta utifrån kundens behov. På senare tid har man börjat applicera Kanban i agil mjukvaruutveckling [PP03]. Kenji Hiranabe [Hir08] säger att den agila versionen av Kanban fokuserar på visuell feedback, självstyrande team och kontinuerlig förbättring. Dessa är även målsättningar hos XP och vi har därför undersökt hur Kanban kan användas för att se ett projekts framskridande. Kanban har implementerats och utvärderats i ett studentprojekt, tillsammans med arbetsmetoden XP. Kapitel 2 tar upp bakgrunden till Kanban och relevanta delar ur XP. Kapitel 3 beskriver hur Kanban kan appliceras i agil mjukvaruutveckling. Kapitel 4behandlardenkonkretaimplementationenavKanbaniettstudentprojekt. Kapitel 5 består av resultat från implementationen i studentprojektet. Kapitel 6innehållerrekommendationerfördensomvillintegreraKanbanmedenagil mjukvaruutvecklingsmetod. Avslutningsvis behandlar kapitel 7 relaterat arbete inom området. 2 Bakgrund Detta kapitel behandlar nödvändig bakgrund så som Kanbans ursprung och väsentliga bitar ur Extreme Programming. 2.1 Toyota Production System Året 1945 bestämde sig Toyota för att komma ikapp bilföretagen i USA, förklarar Poppendieck et al. [PP06]. Toyota insåg snabbt att de inte kunde applicera den amerikanska modellen för massproduktion för att uppnå detta mål. Kiichiro Toyoda, grundaren av företaget, hade som vision att delarna till företagets löpande band skulle inkomma Just-in-Time produktion av delarna ska ske precis innan de behövs. Det tog dock ett decennium innan man anammade Kiichiro Toyodas vision på hela företaget. Taiichi Ohno var den person som utvecklade Toyota Production System (TPS), vilket var det arbetssätt som förverkligade Toyodas vision. Vid framtagningen av TPS studerade Ohno bilföretaget Fords produktionssystem och hur stormarknader i USA hanterade deras inventarier. Ohno beskriver att TPS vilar på två grundpelare, Just-in-Time och Autonomation. Just-in-Time (JIT) innebär att man vill producera en del så sent som möjligt för att vara mer mottaglig för förändringar. Man vill att förändringar ska ske innan produktionen påbörjas och på så vis sker endast ytterst nödvändiga förändringar under själva produktionen. I JIT ingår Kanban som beskrivs närmare i kapitel

4 Autonomation syftar till att man vill upptäcka avvikelser i produktionen så fort som möjligt. Vid en avvikelse stannar man då arbetet och åtgärdar problemet om ett sådant existerar. Produktionen startas sedan igen när problemet är åtgärdat. 2.2 Kanban Poppendieck et al. [PP03] beskriver att det är en stor utmaning i en stor och komplex fabrik att bestämma vad varje maskin ska producera och vad varje arbetare ska göra för att maximera prestandan. På 1980-talet gjordes det ett försök med att schemalägga arbetet med hjälp av mjukvara. Problemet var då att fabriken upplevdes som nervös, det vill säga att varje liten förändring ifabrikenresulteradeiatthelaschematgenereradesom.detnyaschematvar väldigt olikt det gamla schemat eftersom programmet inte tog hänsyn till att det kostade tid och pengar att flytta om arbetare till nya positioner. Systemet hade således stora problem med att hantera förändringar i fabriken på ett smidigt sätt. Just-in-time förändrade detta med hjälp av flera olika vertyg, där bland annat Kanban ingår. Poppendieck et al. [PP03] förklarar ett Kanbansystem på följande sätt. När en order i en fabrik mottages skickas den direkt till paketeringsstationen. Arbetarna på paketeringsstationen går till hyllorna där delarna till ordern ska ligga. Varje del har ett Kanbankort, som representerar delen, vilket lämnas på hyllplatsen för delens plats. Kanbankortet hämtas från hyllplatsen av den station som gör delen. Därefter produceras delen, Kanbankortet bifogas på den och överlämnas till hyllplatsen på paketeringsstationen. Samma systematik gäller hela fabriken, det vill säga att stationen innan paketeringsstationen också lämnar över Kanbankort för att visa stationens behov för andra stationer. 2.3 Extreme Programming Kent Beck [BA04], grundaren av Extreme Programming (XP), definerar värderingar, principer och praktiker i den andra upplagan av XP. De beskriver hur XP fungerar och vad metodiken ska leda till hos det aktuella teamet och dess projekt. De delar av XP som är relevanta för den här rapporten tas upp i detta avsnitt så som Beck beskriver dem Kommunikation Kommunikation är grunden till mjukvaruutveckling som ett team, då kommunikation ofta är både orsaken och lösningen till ett problem. Dålig kommunikation kan vara det som hindrar kunskap och information att flöda inom teamet och därmed orsakar problem. Bra kommunikation däremot medför att kunskap och idéer förmedlas inom teamet och en lösning kan hittas. Dessutom kan kommunikation förmedla en lagkänsla och samhörighet Feedback Feedback indikerar på hur arbetet går och något som ett XP-team bör sträva efter att få så mycket som möjligt av. Då förutsättningar, krav och andra faktorer ändras hela tiden ger all feedback teamet bättre möjligheter att följa 2

5 förändringarna. Feedback är även en kritisk del av kommunikation om systemets utformning som sker genom till exempel tester Förbättring Det finns ingenting som är perfekt, men man kan alltid sträva efter det. Målet med XP är att ett team alltid bör sträva efter förbättring Reflektion Reflektion är ett sätt att få feedback från teamet i sig och för teamet att förbättra sig ytterligare. Konversationer, självständiga reflektioner och gruppreflektioner inom teamet är tillsammans med statistik över projektets framskridande bra mått på hur teamets arbete fungerar. Kombinerat med analys av data kring projektets framskridande kan teamet se vad som kan förbättras Baby Steps Att arbeta i så små steg som möjligt gör att problemställningen blir uppdelad imindresamtmeröverkomligabitarochlösningenväxerfram.arbetsbördan blir då mindre, ty man behöver bara göra precis så mycket som behövs för att se att man är på rätt väg Flöde Mjukvaruutveckling beskrivs som ett flöde av värdefull mjukvara. Systemet ska växa fram istället för att byggas i stora bitar. Detta växande implementeras av månadslånga releasebyggen, veckolånga iterationer och kontinuerlig integration av nya delar. Målet för ett XP-team är att hålla flödet uppe och om det upphör, att se till att återställa det direkt Ekonomi Kunden vill ha ut ett ekonomiskt värde ur sitt projekt och det är teamets ansvar att ge kunden en produkt. Flödet av systemet som växer fram ger kunden en konstant växande produkt, som har ett ekonomiskt värde som växer fram redan från början Informativt arbetsutrymme Ett informativt arbetsutrymme kan ge teamet översikt över projektets framskridande och annan viktig information. Ett mål är att arbetsutrymmet ska ge en observatör översikt över hur arbetet går inom 15 sekunder. Arbetsutrymmet bör även underlätta upptäkter av begynnande problem och flaskhalsar. 3 Kanban i agil mjukvaruutveckling Poppendieck et al. [PP03] anpassade Toyotas arbetssätt till mjukvaruutveckling och kallar det för Lean Software Development. Den är klassad som en agil mjukvaruutvecklingsmetod och har som mål att eliminera slagg, iterera mot 3

6 perfektion, hantera förändringar och få snabb utveckling samt förbättring genom att ge makten till teamen. Slagg är sådant som påverkar projektet eller produkten negativt och/eller inte tillför något, till exempel buggar, pappersarbete, överlämningsrutiner, väntan och halvfärdigt arbete. Poppendieck et al.[pp03] definierar 22 olika verktyg för att lyckas med dessa mål, varav en del kan kännas igen från andra agila metoder, till exempel feedback, refaktorisering och iterationer. Det finns även nya verktyg, som till exempel pull system, somharblivitanpassadtillmjukvaruutveckling.dåkanbanbrädet är den synliga delen av pull system har det fått ge namn åt hela tankesättet kring verktyget och dess omkringliggande tankegångar. Precis som i industriversionen är det kundens behov som drar genom arbetet och Poppendiecks anpassning består här av att kunden prioriterar vilken systemfunktionalitet den vill ha i början av varje iteration. Kunden får beskriva varje funktionalitet på ett kort, som sedan teamet ger en tidsestimering på varje korts implementation. Därefter får kunden prioritera vilken ordning korten ska implementeras under iterationen. Detta medför att utvecklarna vet under iterationen vilka kort som är viktigast och som representerar kundens behov. Teamet blir så kallat självstyrande då arbetet dras genom av kundens utvalda kort och inte av någon projektledare. Korten sätts upp på ett Kanbanbräde, som visar vilka kort som väntar, är klara och vem som arbetar på vad. Denna visuella representation är nödvändig för att teamet ska kunna vara självstyrande. Kanbanbrädet består av de olika faser som ett kort kan befinna sig i och det visualiserar projektets framskridande just nu samt eventuella problem. Med hjälp av Kanbanbrädet kan alla se vad som måste göras utan någon ledning och Poppendieck et al. [PP06] ser detta som en så kallad dashboard, enplatsdärallakansehurprojektetgår. Hiranabe [Hir08] anser att den agila versionen av Kanban fokuserar framförallt på att göra teamet självstyrande, ge visuell representation av projektets aktuella status och på att stimulera processförbättring (Kaizen). Kaizen är Toyotas term och arbetssätt för processförbättring och den inkluderas även i Poppendiecks Lean Software Development [PP03]. Kaizen innebär att teamet ska sträva att bli bättre hela tiden och Poppendieck et al. [PP06] rekommenderar att teamet ska integrera detta i sitt dagliga arbete. Teamet bör dels reflektera kontinuerligt över vad som kan förbättras och dels ha gruppreflektioner där man tar ett steg från vardagsaktiviteter och endast fokuserar på förbättring. På så sätt utvecklas teamet och det anpassar sig till situationen och eventuella förändringar. Ett slagg som Poppendieck et al. [PP03] nämner halvfärdigt arbete. Halvfärdigt arbete bidrar inte med något värde till kunden, tar upp plats för annan funktionalitet och binder kapital. Poppendieck et al. [PP06] motiverar det som slagg då halvfärdigt arbete kan innehålla dolda fel eller innebära avsaknad av dokumentation eller tester som inte märks förrän det har integrerats. Kanban minimerar halvfärdigt arbete genom att lägga in så kallade begränsningar för mängden arbete som pågår (Work In Progress, WIP). Detta innebär att om teamet ska få påbörja ett kort i en fas måste de färdigställa högre prioriterade kort först. Begränsningarna minimerar WIP och förhindrar att för många kort påbörjas, då man relativt sällan behöver ha fler kort igång än antalet utvecklare. 4

7 3.1 Tillsammans med XP Kanbans mål och verktyg överlappar med många andra agila metoder. Bassi et al. [SBG07] skriver att idéen bakom storybräden hos agila metoder kommer ursprungligen från Kanbanbräden. De anser att Kanbanbrädet uppfyller XP:s två värden kommunikation och feedback genom att underlätta organisation av arbetet och ge återkoppling på hur arbetet fortgår. De diskuterar även om hur Kanban är relaterat till de tre principerna baby steps, flöde och ekonomi hos XP då målet med Kanban är att med mindre deluppgifter få ett konstant flöde av mjukvara. Genom att välja de av kunden högst prioriterade delarna först kan teamet bättre möta det ekonomiska behovet hos kunden. Kanban i sig innehåller även nya mål och verktyg som kan vara till nytta för ett agilt mjukvaruutvecklingsteam. Man kan däremot inte säga att Kanban härmar eller kan ersätta XP, Scrum eller andra agila metoder. De behandlar olika områden med olika tillvägagångssätt. Deras gemensamma egenskaper innebär att man kan med fördel kombinera Kanban med en annan agil metod. Det är detta som har utförts i ett studentprojekt. 4 Kanban i studentprojekt Kanban har implementerats i ett studentprojekt. Författarna till denna rapport har haft rollen som coacher, vilket har varit en del av en kurs vars namn är Coaching av programvaruteam. Rollensomcoachbestodavattpraktisktintroducera och vägleda ett team till arbetsmetoden XP, med målet att de i slutändan ska kunna arbeta självständigt. Teamet bestod av studenter som gick en kurs med namnet Programvaruutveckling i grupp - projekt. Projektets ägare var en fiktiv kund som agerades av en anställd på institutionen för datavetenskap. Den fiktiva kunden saknade teknisk kunskap och ville ha ett tävlingssystem för motocross. Teamets uppgift var att tillgodose kundens behov med hjälp av XP-metoden. Upplägget för projektet var sex iterationer, där varje iteration bestod av ett planeringsmöte på 2 timmar, 4 timmar självständig fördjupning (spike) och 8timmararbetsdag.Påplaneringsmötetprioriteradekundenvilkastorieshan ville att teamet skulle arbeta med på arbetsdagen. Vidare skulle teamet göra totalt tre releaser till kunden under de sex iterationerna. Kanban användes under planeringsmötet och arbetsdagen. 4.1 Kanbanbrädet Kanbanbrädet utformades utifrån kapitel 3 och anpassades efter XP. I figur 1 visas en schematisk bild över Kanbanbrädet. Storykorten fungerar som Kanbankort och som man kan se i figuren finns det fem faser som storykorten kan befinna sig i: To Do, Utveckling, Granskning, Klar för release och Done Done. För de tre mellersta faserna finns det en Definition of Done (DoD), som förklarar när man kan flytta en story till nästa fas. Definition of Done är en term som är hämtad från Scrum. Kniberg [Kni07] berättar hur Definition of Done kan användas för att förmedla till hela teamet när en story är klar. De tre olika fasernas Definition of Done i teamets implementation följer nedan: Utvecklingsfasen, Definition of Done: 5

8 Enhetstester gjorda JavaDoc skriven Kod refaktoriserad Alla tester godkända Storyfunktionalitet färdig (Alla tasks färdiga) Granskningsfasen, Definition of Done: System byggt med storyns funktionalitet Funktionalitet användartestad av annat par Kod kontrollerad av annat par Klar för release-fasen, Definition of Done: Kundens godkännande Figur 1: Kanbanbräde, schematisk bild. Här syns de fem olika faser som en story/task kan befinna sig i och vilka utvecklare som arbetar på respektive kort. På Kanbanbrädet placeras storykorten med avseende på deras prioritet, för att utvecklarna lätt och snabbt ska kunna se deras prioritet. Högre prioritet innebär högre placering på Kanbanbrädet. Som man kan se i figur 1 har till exempel story 1högreprioritetänstory2. Varje fas betraktas som en egen station. I figuren är det i huvudsak två stationer där arbete sker, i utvecklings- och granskningsfasen. När man är färdig med en story i en fas flyttas det aktuella storykortet över till nästa fas. Det är, som tidigare beskrivit, Definition of Done som anger när en story är klar och redo för nästa fas. Exempelvis, det är ett par som utvecklar en story och är färdiga, det vill säga uppfyller kraven enligt Definition of done. Då flyttas storykortet över till granskningsfasen, där ett annat par tar hand om storyn 6

9 och granskar den. Detta överlämningsmoment finns för att sprida kunskap om implementationen och för att fler utvecklare ska kontrollera koden. Vidare kan faser ha begränsningar. I figuren kan man se att utvecklingsfasen maximalt får innehålla 4 stories och granskningsfasen maximalt 2. Då ett par blir blockerat, på grund av begränsningarna, ska de se om ett annat par behöver hjälp. Om inget annat par behöver hjälp ska de förbättra systemets kvalitet och arbeta med andra aktiviteter som är gynnsama för teamet, till exempel refaktorisering, användartester och förbättring av enhetstester. Den intresserade läsaren kan se fotografier på Kanbanbrädet från projektet iappendixa. 5 Resultat Resultatet har baserats på studier av teamets beteende i olika situationer samt medlemmarnas reflektioner. Någon jämförelse mellan olika teams produktivitet har inte skett på grund av att det är många faktorer som kunde påverka, till exempel variationer i tidigare kunskap. Coacherna och teamet har upplevt Kanban som ett effektivt verktyg och har en positiv upplevelse kring arbetssättet. Härefter följer mer ingående slutsatser kring resultatet. 5.1 Överlämningsmoment Istudentprojektetfannsettöverlämningsmomentmellanutvecklings-ochgranskningsfasen. När en story var färdig i utvecklingsfasen överlämnades den till ett annat par för granskning. Granskningen skedde med avseende på kodkvalitet, kontroll av funktionalitet och uppdatering av manual. Om ett granskade par hittade brister i storyn fanns det två sätt att hantera det på beroende på vad det var för brist. Om större delar av funktionaliteten saknades återfördes storyn till utvecklingsfasen och det granskande paret fick återuppta utvecklingen. Däremot om det var mindre buggar åtgärdade det granskade paret dem. Under studentprojektets första veckor fanns inte detta överlämningsmoment på grund av att det var många andra delmoment som skulle introduceras. Teamet har därför upplevt en förbättring av systemets kvalitet när detta moment infördes. 5.2 Definition of Done Användningen av Definition of Done har fungerat som en påminnelse om vad som behöver göras för ett storykort i varje fas. Det har inneburit mindre risk för bortglömda delmoment. Teamet har upplevt att det har höjt systemets kvalitet och att det har underlättat överlämningen mellan faserna genom att garantera vilka delmoment som är utförda för ett storykort. Coacherna har observerat hur utvecklare, som har gått fram till Kanbanbrädet i tron om att vara färdiga, har studerat Definition of Done och på så sätt upptäckt ej gjorda delmoment. Det var inte uppenbart vad som skulle ingå i Definition of Done från början utan det är något som bör reflekteras över och utvecklas under arbetets gång. Coacherna och teamet har tagit fram sina Definition of Done enligt detta tankesätt. När olika centrala moment eller behov har identifierats har dessa lagts till. Exempelvis uppstod kundens behov för en manual först efter ett par veckor. 7

10 Denna implementerades och för att hålla den uppdaterad lades uppdateringsmomentet till på en relevant fas Definition of Done. 5.3 Begränsningar i faser Imittenavstudentprojektetimplementeradesfasernasbegränsningaravantalet pågående stories. Dess mål var att minimera antalet pågående stories och på så sätt minimera mängden halvfärdigt arbete. Det uppfyllde sitt syfte, men vissa par blev blockerade på grund av beroende mellan stories. Systemets storlek medförde att dessa par, trots förbestämda rutiner vid blockering, blev stillasittande då krockar i källkoden lätt uppstod. Det kan även vara så att begränsningarna var för snäva för antalet utvecklare och om det hade funnits mer tid så kunde teamet ha optimerat dessa. Begränsningarna togs därför bort men tankesättet att minimera antalet pågående stories behölls i teamet. 5.4 Kanbans effekt på XP Definition of Done och begränsningarna på Kanbanbrädets faser uppmuntrade till XP:s principer baby steps, flöde av mjukvara och ekonomi. Begränsningarna medförde att kundens viktigaste behov implementerades först och i ett jämnt flöde. För att underhålla detta flöde krävdes det att funktionaliteten delades upp i mindre bitar, baby steps. Ett exempel på detta är när teamet fick ouppdelad funktionalitet i form av feedback från kunden baserat på tidigare versioner av systemet. När teamet missbedömde storleken av sådan kundkritik stannade dess Kanbankort upp i en fas längre än förväntat och teamet tog då ett beslut om att dela upp uppgiften i mindre delar. Detta beteende visade även på hur Kanbanbrädet medförde kommunikation kring systemet och arbetets gång samt feedback på hur arbetet fortgick. Bassi et al. [SBG07] berättar, som nämnts itidigareavsnitt,attdessafemdelaravxpkanunderstödjasmedkanban och vi har konstaterat att ytterligare tre delar av XP kan understödjas med Kanban. Kanbanbrädet fungerade som en central del av teamets informativa arbetsutrymme då det gav en tydlig bild av hur arbetet fortgick. Kanban som arbetsmetod motiverar att teamet ska utvecklas och bli bättre. Förbättring är centralt inom XP då ett team ska sträva efter att perfektion och både XP och Kanban använder reflektion kring arbetsprocessen, teamet och själva systemet som verktyg till att förbättras. Teamet har under projektets gång reflekterat kring hur arbetet har fortgått, vilka problem som har uppstått och hur dessa skulle lösas. Detta har lett till flera delar av Kanbanbrädet och arbetet kring detta har utvecklats till det bättre. Exempel på detta är hur Definition of Done har vuxit med fler punkter och att Kanbanbrädet befinner sig skrivande stund i sin åttonde version från projektets start. 5.5 Kanbans effekt på teamet Kanbanbrädets visuella feedback på vad som har gjorts, görs och ska göras har medfört att teamet har blivit självstyrande. Vi har observerat under projektets gång hur utvecklarna har blivit självständigare och mot slutet av projektet hur de förde funktionalitet genom de olika faserna och överlämningsmomentet på egen hand. Vår roll i projektet blev till slut att sätta upp nya Kanbankort på 8

11 tavlan i prioritetsordning och att fungera som moderatorer i reflektionsdiskussioner. 5.6 Jämförelse med Toyotas Kanban Man kan även jämföra vår agila version av Kanban med Toyotas originalversion. Hiranabe [Hir08] sammanfattar Toyotas Kanban i nio egenskaper: Fysisk Det är något man kan flytta och hålla i handen. Begränsar halvfärdigt arbete Det förhindrar överproduktion. Drag Kanban drar funktionalitet från kundens behov till produkt. Självinriktande Tavlan representerar vad som ska göras och medför till att rätt delar utvecklas utan detaljstyrning. Visuell Projektets framskridande och tillstånd representeras på ett tydligt sätt. Signal Representationen fungerar som en signal till vad som ska göras härnäst. Processförbättring Representationen visar på problem och stimulerar till förbättring av processen. Fäste Kanbankortet kan fästas på och flyttas tillsammans med fysiska delar som levereras. Hiranabe hävdar att agila varianter av Kanban fokuserar framförallt på självstyrande, visuell represenation och processförbättring samt innehåller egenskaperna fysisk och signal. Hiranabe säger att det kan vara möjligt att uppnå alla de resterande också, med undantag för egenskapen fäste, men att det kräver anpassning av iterationsplaneringar. Vi anser att den agila Kanban som har implementerats istudentprojektetuppfyllerallalistadeegenskaperutommöjlighetenattfästa Kanbankort på delar och har hjälpt till att öka kvalitet, utveckling och självständighet hos teamet. Vi anser därför att vår variant av Kanban har bibehållt sin utformning och att den har fyllt sin funktion väl. 6 Rekommendationer Detta kapitel behandlar rekommendationer för de som ska integrera Kanban med deras nuvarande process. Rekommendationerna är baserade på erfarenheter från studentprojektet, där Kanban användes tillsammans med XP. 6.1 Stort Kanbanbräde nära teamet Det kan vara svårt att få teamet att hålla Kanbanbrädet konstant uppdaterat och även att använda Kanbanbrädet för att följa projektets aktuella status. Ett stort kanbanbräde som placeras nära teamet minskar tröskeln för att utvecklarna ska gå fram till brädet. Kanbanbrädet bör vara så stort att det kan läsas av alla berörda i arbetsutrymmet, som på så sätt får överblick över brädet utan att behöva lämna sin arbetsstation. 9

12 6.2 Inledande enkla Definition of Done IbörjankandetvarasvårtattbestämmavadsomskaingåiDefinitionofDone. Därför bör man inledningsvis börja med att definera Definition of Done som några få enkla punkter. Detta utgör sedan en grund för teamet att bygga vidare på. 6.3 Definition of Done utformad som checklista Det kan vara svårt att avgöra när man uppfyller alla krav i en fas, enligt Definition of Done. Stora brödtexter medför att det är svårt att få en överblick och tar lång tid att läsa. Definition of Done bör därför utformas som en checklista med korta punkter, som snabbt går att läsa. Punkterna bör även vara otvetydiga så att det inte lämnas utrymme för missförstånd. 6.4 Inledande övervakning IbörjankandetsaknasdisciplinförattuppfylladeolikafasernasDefinition of Done och att hålla Kanbanbrädet uppdaterat. Man bör därför inledningsvis övervaka och följa upp de olika utvecklarnas arbete på Kanbanbrädet. Detta kan man göra genom att ställa frågor om till exempel tavlan är uppdaterad eller om de olika kraven hos Definition of Done är uppfyllda. Detta uppmuntrar till aktivt tänkande kring arbetsprocessen. 6.5 Utgå från den befintliga processen Det kan vara svårt att identifiera de olika faser som ska finnas på Kanbanbrädet. Man kan inledningsvis identifiera olika delmoment eller behov i den befintliga processen som är tydligt avskilda från varandra. Exempelvis kan man välja en analysfas där teamet delar upp funktionalitet i stories. Exempelvis kan man välja en granskningsfas om man vill ha en fas för granskning av programkod som utförs av andra utvecklare än de som har skrivit den. 6.6 Lagom antal faser Utvecklarnas disciplin kan reduceras om antalet faser är för många. Därför bör man applicera det svenska ordet lagom på antalet faser. 6.7 Ständig reflektion Behov och mål kan ofta förändras som medför att arbetssätt blir föråldrade. Ständig reflektion och strävan efter förbättring leder till tidig upptäckt av problemområden som då direkt kan åtgärdas. Förändring till det bättre är alltid positivt. 7 Relaterat arbete IdennarapportstuderarvihurKanbankanintegrerasiXP.Viharbarahittat ett tidigare arbete om detta ämne, skrivet av Bassi et al. [SBG07], som endast behandlar det på en översiktlig nivå. Liknande arbeten finns dock tillsammans 10

13 andra agila metoder. Ett exempel på detta är Henrik Kniberg som har skrivit om hur Kanban kan användas tillsammans med Scrum. Kniberg använder liknande fasuppdelning och Definition of Done som i kapitel 4. Tack Vi skulle vilja tacka teamet (Team01, ) för deras deltagande. Vi vill även tacka Måns Engfors och Björn Johnsson för att ha prövat Kanban i ett parallellt studentprojekt och för deras åsikter ur ett coachperspektiv. Referenser [BA04] Kent Beck and Cynthia Andres. Extreme Programming Explained: Embrace Change. Addison-Wesley,secondedition,2004. [Hir08] Kenji Hiranabe. Kanban applied to software development: from agile to lean. hiranabe-lean-agile-kanban, Nerladdad [Kni07] Henrik Kniberg. Scrum and xp from the trenches. com/minibooks/scrum-xp-from-the-trenches, Nerladdad [PP03] Mary Poppendieck and Tom Poppendieck. Lean Software Development. Addison-Wesley,2003. [PP06] Mary Poppendieck and Tom Poppendieck. Implementing Lean Software Development. Addison-Wesley,2006. [SBG07] Danilo Sato, Dairton Bassi, and Alfredo Goldman. Extending Extreme Programming With Practices From Other Agile Methodologies. University of Sao Paulo,

14 A Fotografier Figur 2: Kanbanbrädet som användes i studentprojektet. 12

15 Figur 3: En story är färdig och ska flyttas 13