Hur extreme Programming kan införas i industrin Jonas Carlqvist D03, Lunds Tekniska Högskola d03jc@efd.lth.se 22 februari 2006
Innehåll 1 Inledning 3 2 Svalt intresse från industrin 4 3 Starta förändringsprocessen 6 4 Hur får man teamet med sig? 8 5 Hur får man ledningen med sig? 9 6 Hur får man kunderna med sig? 9 7 Sammanfattning 10 8 Erkännanden 10 A Rekommenderad läsning 13 2
Sammanfattning Trots att agila metoder visat sig bra i många sammanhang och sedan länge nått utanför den akademiska skyddade verkstaden, uppfattas de fortfarande i mångt och mycket som suspekta ute i industrin. Varför är motståndet och oviljan så stor till att prova eller lära sig mer om alternativa arbetsmetoder? Med hjälp av intervjuer och litteratur kommer jag på de följande sidorna försöka samla de viktiga erfarenheter och argument som bör föras fram och beaktas vid införandet av extreme Programmings agila metoder i en befintlig organisation. 1 Inledning Vi lever i en värld där kraven på oss ständigt förändras i en allt snabbare takt. Möbler och andra varor som tidigare införskaffades för att hålla en hel livstid byts idag ut med jämna mellanrum. Vi tenderar också att både flytta och byta anställning oftare. Omsättningshastigheten ökar på många plan och utvecklingsprojekt är inte undantagna detta. Specifikationerna som du kommit överrens om med kunden kan nästa dag vara gamla och värdelösa då kunden hittar andra infallsvinklar i projektet, och applikationer som är skrivna uppfyller inte längre kundens verksamhetsbehov. Hur gör man för att lyckas med projekt i en sådan värld? Antingen kan man kämpa stenhårt med att försöka styra upp verkligheten så att den följer ens egna definierade projektplan eller så kan man försöka hänga med och dra nytta av förändringarna. Detta är något som extreme Programming på ett bra sätt möter upp. Genom att genomföra projekten med hjälp av ett ramverk av metoder som bygger på att förändringar faktiskt är naturliga får vi också goda förutsättningar att möta oväntade situationer och förändringar. Det medför också att kunden inte behöver betala mer än vad som faktiskt ger direkt nytta för honom eller henne. Endast businessvalue levereras. Hur kommer det sig då att det fortfarande inte är speciellt många ute i programvaruindustrin som arbetar med agila metoder och vad kan man själv göra för att få saker att hända? Det är några av de frågeställningar jag har sökt svaren på nedan. Vidare kommer jag även att presentera förslag på vilken typ av information som är lämplig att delge till intressenterna under förändringsarbetet. 3
2 Svalt intresse från industrin För många utvecklare i större organisationer är mjukvaruutveckling ett ständigt planerande och dokumenterande i all oändlighet. Innan ett projekt överhuvudtaget kommer igång med att skapa kundvärden ska specifikationer skrivas och estimeras, arkitektur designas, och möten ska hållas. Trots att man i början vet mycket lite om det slutgiltiga behovet från kundens sida satsar man stort med att lägga fram en så kallad BUFD (Big Upfront Design) späckad med detaljbeskrivningar. Flertalet utvecklare inser att det för många projekt hade varit bättre och snabbare med en annan arbetsmetodik, men de upplever det som svårt att sätta fingret på vad som behöver förändras. Varför tar det så lång tid för industrin att ta till sig extreme Programming som arbetsmetod? Troligen beror det på flertalet parametrar. Att vara ute tidigt inom ett visst område kan vara förknippat med stora kostnader. Det tar alltid en viss tid innan forskning och dess resultat når allmänheten och blir accepterat. Få vill vara först med att prova eftersom man ger sig ut på okända marker som är svåra att estimera kostnaden för. Först när rapporter om lyckade projekt börjar rapporteras i branschmedia så talas det mer i positiva ordalag om XP. E.M Rogers summerande 1962 bra och dåliga erfarenheter kring introduktionen av nya teknologier på marknaden i Diffusion of Innovations. Han delade upp intressenterna i olika grupper. Detta kan vi använda oss av för att förstå varför vår produkt extreme Programming ännu inte är helt accepterad av marknaden. Man kan tydligt se att de flesta produkter som kommer ut på marknaden följer ett visst etablerat livscykel-mönster. Alla produkter går igenom faserna Införande, Tillväxt, Mognad och Tillbakagång. I införandefasen är marknaden i stort sätt helt omedveten om produkten. Viss skepticism riktas mot produktens påstådda fördelar och forskningsresultat. En del motstånd kan skönjas. Köparna är vanligen innovatörer eller så kallade early adopters inom den egna organisationen som gärna tar risker. Om behovet av produkten accepteras av marknaden, så sker en tillväxt av användandet. När marknaden accepterar produkten till fullo har den mognat tillräckligt för att den ska få en större spridning. Tillväxten stabiliserar sig. Köparna under mognadsfasen är den riskmedvetna allmänheten som gärna följer med under förändringar, men leder dem sällan. Med specificerad budget köper de bara om tillräckliga bevis över produktens förträfflighet kan visas. Slutligen når produkten en tillbakagångsfas där marknaden tappar intresset till fördel för andra produkter. Vissa eftersläntrare kan fortfarande vara intresserade om de blir tvingade av andra och bevis på att risktagandet är helt obefintligt presenteras. 4
R&D Tech Transfer Best Practices Införande Tillväxt Tidig Mognad Sen Mognad Tillbakagång Technology Adoption Process Figur 1: Technology Adaption Process Analogin mot införandet av extreme Programming är tydlig. Med all sannolikhet befinner sig extreme Programming fortfarande under tillväxtfasen, vilket kan förklara det ännu svala mottagandet. Vad som också ska nämnas i sammanhanget är att som ovan nämnts, ökar omsättningshastigheten i en allt snabbare takt. Det tog ca 20 år för objektorienterad programmering att bli allmänt accepterat i industrin [10, LUCAS2005]. Införandet av extreme Programming tar troligen betydligt kortare tid än så, men det är fortfarande en lång väg tills att idéerna är helt accepterade av den stora massan. Erik Lundh menar att vi kan bedöma acceptansen avseende extreme Programming genom att snegla på de stora konsultbolagens tjänsteutbud. Den dagen då de stora drakarna börjar erbjuda extreme Programming tjänster i större skala, bör Kent Becks practices anses accepterade. Förutom Rogers livscykel-mönster, finns det även andra och mer påtagliga anledningar till problemet med att införa nya idéer. Ledningfolk som hört talas om extreme Programming avfärdar det direkt utan att titta närmare på om det verkligen fungerar. Flertalet av XP-praktikerna låter skrämmande och oklara till en början eftersom det inte är möjligt att kontrollera projektet med traditionella metoder. Därför är de snabba i sina slutsatser, och kör vidare i gamla hjulspår då de anser att deras befintliga utvecklingsmetoder fungerar tillräckligt bra. Att införa något helt nytt och relativt oprövat som senare visar sig dåligt är det få som vill stå till svars för. Anställda på nyckelbefattningar som till exempel projektledare och systemarkitekter kan tänkas motarbeta införandet av extreme Programming då de tror att de kommer att förlora sin status som nyckelperson. Även utvecklare som har nyckelkompetens kan se vissa practices som ett hot mot deras expertkunnande. 5
3 Starta förändringsprocessen Att introducera en ny ide är en learn-as-you-go process som kommer att ha fram- och motgångar under resans gång. Ett bra råd är att börja försiktigt och inse att det kommer att ta mycket tid i anspråk. Det finns ingen anledning att försöka sälja in idén till alla på en gång. Som David Hutton beskriver i The Change Agents Handbook: Your job is not to plant the entire forest, row by row - it is to plant clumps of seedings in hospitable places and to nurture them. As they mature, these trees will spread their seeds, and the forest will eventually cover the fertile land. The rocks will of course, remain barren regardless. Det är alltså med andra ord av stor vikt att hitta rätt personer som du kan övertyga och som sedan kan sprida dina idéer. Dessa innovatörer intresserar sig troligen för dig och dina idéer på ett tidigt stadium. Håll fast vid dessa genom att skapa långsiktiga relationer. Alla företag har sin egen kultur och givetvis spelar denna en stor roll då man inför något nytt. Det är inte lämpligt att införa alla förändringar på en gång, utan försök istället att analysera organisationen och hitta de infallsvinklar på dina idéer som du kan börja med [11, Hodgetts]. Vi eftersträvar hela tiden evolution framför revolution [12, Lundh]. Få gillar omvälvande förändringar. Genom att låta idéerna växa sig fram, så får personalen ett betydligt bättre helhetsgrepp och de kan känna sig mer involverade i processen. Paul Hodgetts beskriver i sin artikel Refactoring the Development Process: Experiences with the Incremental Adoption of Agile Practices två av sina dyrköpta erfarenheter med att försöka införa alla practices på en och samma gång. Vid båda tillfällena resulterade det i kraschade projekt där mycket lite av det förväntade värdet i projektet blev levererat och duktiga utvecklare valde att lämna företagen. Hodgetts drog slutsatsen att det blev för mycket att lära för teamet på en gång. Att både brottas med komplexiteten i projektet och samtidigt lära sig ett nytt sätt att arbeta resulterade i en långsam inlärningsprocess och reducerad utvecklingshastighet för teamet. Som innovatör är det lätt att ryckas med och bli exalterad inför något nytt och man vill gärna införa alla idéer på en gång. Gör inte detta misstag! Människor är vanligen negativa till snabba förändringar som sker i deras närhet. Det är lätt att bli uppfattad som en person med extrema åsikter och den negativa stämpeln kan sedan vara svår att bli av med. Försök istället att utnyttja två av Kent Becks välkända begrepp Baby Steps och Reflection [13, Beck]. Dela upp dina idéer i mindre delar och rangordna dessa. Fokusera på små men snabba segrar. Försök införa en liten, men betydelsefull del och följ sedan upp hur den togs emot. Att förändra människors synsätt tar lång tid, så förvänta dig inga snabba resultat. Blev inte din idé mottagen på förväntat sätt, så låt dig inte nedslås av 6
detta. Reflektera över hur det gick och förändra din strategi om det skulle behövas inför nästa tillfälle. Fira dina segrar! Dela upp i mindre delar Välj en viktig del Inför idén Reflektera Förändra strategi Nej Seger? Ja Fira! Figur 2: Flödesschema på hur nya iéer införs Hänsyn bör även tas till vid vilket tillfälle som förslaget läggs fram. Situationer då folk är stressade brukar vanligen inte vara en god idé. Att presentera förslaget för sina kolleger samma vecka som en stor release bör alltså undvikas. Faller idéerna väl ut, så kan det vara lämpligt att vid ett senare tillfälle starta upp en mindre studiecirkel för att öka förståelsen hos de som är intresserade. Det viktiga är att ingen expert på området är närvarande under mötena. Beroende på arbetsgivare kan dessa studiecirklar drivas under arbetstid alternativt sponsras med mat för att motivera deltagarna [1, Manns och Rising]. 7
4 Hur får man teamet med sig? De företag som diskuterats under intervjuerna, följer en tydlig linje - initiativet till agila metoder startar bland utvecklarna själva och inte från ledningshåll. Så är fallet även med företagen i artikeln Combining Agile Methods with Stage-Gate Project Management [9, Karlstrom och Runeson]. Det kan tyckas märkligt, då den normala synen på arbetsledning är att det är just chefen som ska strukturera upp de anställdas arbete. Det anser jag är en mycket viktig iakttagelse. Ofta börjar det med att någon eldsjäl som har blivit intresserad av extreme Programming delger sitt intresse till sina kolleger. Korridorsnacket går igång och utan ledningens egentliga godkännande börjar man med att praktisera några få av de olika praktikerna. TDD (Test-Driven Development) och parprogrammering verkar vara två av de första praktikerna som med framgång testas i skarpt läge. När utvecklarna själva sedan vill införa förändringarna i arbetssättet som officiella, möts de ofta med mycket liten uppbackning från ledningshåll [9, Karlstrom och Runeson]. Det okända anses farligt. De företag som lyckats bra med införandet av extreme Programming och dess practices låter alla processförändringar förankras av utvecklarna själva. Stödet från utvecklarnas sida är ett absolut måste för att de ska kunna känna sig delaktiga i besluten [4, Neubauer]. Att införa förändringar utan att de anställda själva är med på noterna kommer direkt att leda till sänkt trivsel och ett omotiverat team. Konkreta exempel som presenterats och diskuterats inom teamet har visat sig vara en fördelaktig metod [5, Neubauer]. Genom att visa fungerande och konkreta exempel hands-on för utvecklarna hur man går tillväga så ökar man förståelsen. Tänk på att utvecklare förstår både kod och diagram men är allergiska mot det senare. Starta i mycket liten skala med några få konkreta practices och bygg sedan på med med fler allt eftersom de visar sig mogna. När intresset väl är där kommer införandet av förändringarna att accelerera. Se till att utvecklarna har en ordentlig basträning innan de börjar praktisera. Utan basträningen kommer de snabbt att misslyckas och känna sig stressade vilket ökar risken för att de återgår till sina gamla arbetssätt. Uppmuntra förändringsarbetet och se till att utvecklarna inser att det är viktigt. Upptäcker utvecklarna något som man kan förbättra i processen, se till att engagera dig och ta tag i problemen. Se till att ge processförändringar den tid de kräver. Att förändra sitt arbetssätt är en mognadsprocess där resultatet kommer först efter en tids utövande. Uppmuntra teamet att söka sig till intressegrupper och studiecirklar inom området där de kan träffa andra som har likvärdiga problem. 8
5 Hur får man ledningen med sig? I större företag går fokus idag mot kontrollintensiva processcentrerade standarder som ISO och CMMI (Capability Maturity Model Index). Dessa är några som många på ledningsnivå känner till och anser vara bra då standarderna innehåller specificerade och enkla metoder för hur man mäter och följer upp arbete samt kvalitet. Agila metoder levererar resultat på ett annat sätt än vad ledningsfolket är vana vid vilket betyder att man inte heller vet hur man kan följa upp arbetet. Detta gör det är mycket svårt att sälja in behovet av agila metoder till ledning. Precis som i många andra sammanhang är det viktigt att prata med bönder på bönders vis. Lämpligt är att visa mätbara resultat som motiverar ett närmande mot extreme Programming, exempelvis [5, Neubauer]: Ta hjälp från en extern part som kan berätta om erfarenheter och kan ställa upp med know-how i ett framtida förändringsarbete. Antalet buggar och antalet rättade buggar i programvaran före och efter en release. Gärna tillsammans med jämförelsetal mellan XP-team och traditionell utveckling. Att hitta, rätta och testa programfel är dyrt och tar mycket tid i anspråk. Betona möjligheten med minskade ågärdstider. Traditionella projekt har en tendens att leverera sällan och då med dålig precision. Förklara hur extreme Programming kan lösa dessa problem. Att testa en programvara grundligt innan den tas i skarp drift är förknippat med stora kostnader. Påvisa fördelarna med test-first och unit-testning gällande den minskade tidsåtgång som dessa tekniker leder till. Andra saker som kan motivera övergång är påvisandet av hur nöjda kunderna blir då mängden businessvalue i leveranserna ökar. Om ledningen bestämmer sig för att organisationen ska följa det agila spåret, så vill de självklart känna delaktighet i förändringsprocessen. Det är ett ypperligt tillfälle att försöka få med dem projekten genom att låta dem agera kunder. Det krävs också av ledningen att den är så erfaren att den ser nyttan av investeringarna i processförbättringen. Trots att detta är en kostsam process bör man övertyga dem om att alla infrastrukturella förändringar som kan automatiseras, i det långa loppet sparar tid och resurser. 6 Hur får man kunderna med sig? För att ett extreme Programming team ska fungera optimalt bör kunderna vara något skolade i hur teamet hanterar projektet och kontakten med kunden. Detta är en pedagogisk fråga som om den sköts på rätt sätt kan ge framtida mycket nöjda kunder. Är kundens organisation och beställare istället av en mer strikt traditionell typ kan vissa brister i den förväntade kommunikationen mellan parterna uppstå. Det verkar dock inte upplevas som ett stort problem, då kundrollen istället tas över av någon kundansvarig inom den egna organisationen som sedan i sin tur får ta hand om alla kundkontakter. 9
Kunderna är givetvis intresserade av motsvarande saker som ledningen, men även: Genom att teamet snabbt får feedback på sitt arbete, så kan missförstånd rättas till relativt snabbt. Chansen ökar att den slutgiltiga produkten faktiskt kommer att användas. Genom att använda sig av ett XP-team kommer så småningom kunderna att kunna förbättra sina finansiella planeringar för projekten då teamet efter ett tag kommer att vara mycket duktiga att estimera tidsåtgång. 7 Sammanfattning Vi går mot en värld där omsättningshastigheten ökar i en allt snabbare takt. För att i längden överleva på en sådan marknad, så gäller det att förutom passande kunskap och kompetens även att man nyttjar en arbetsprocess som möter upp omvärldens nycker på ett bra och effektivt sätt. Ju snabbare feedback från marknaden, desto bättre produkter kan industrin tillverka, leverera och få betalt för före sina konkurrenter. Det är troligen här morgondagens vinnare finns. Trots flertalet rapporter om misslyckade förändringsprojekt, så ser framtiden mycket ljus ut där extreme Programming troligen spelar en viktig roll som enkel och billig metodik för högkvalitativa mindre projekt. Att införa extreme Programming i en organisation som tidigare inte använt sig av agila metodiker bedömer jag som fullt genomförbart om man har de rätta argumenten vid den rätta tidpunkten. Det kräver dock att man går försiktigt fram och tillgodoser de olika intressenternas behov för att de ska våga ta klivet in i ett nytt sätt att skriva programvara. En mycket intressant detalj som jag fick höra under resans gång är frånvaron av certifieringar inom extreme Programming motsvarande dem inom andra mer påkostade och kommersialiserade metodiker. Införandet av sådana är troligen är en viktig milstolpe mot metodikens erkännande ute i industrin. 8 Erkännanden Jag vill tacka alla de personer som tog sig tid och var villiga att ställa upp på intervjuer/diskussioner kring ämnet. Ni har hjälp mig mycket med era idéer och erfarenheter från verkliga projekt. 10
Referenser [1] Fearless Change: Patterns for Introducing New Ideas Mary Lynn Manns, Linda Rising Addison-Wesley Professional,2nd edition, 2005 [2] Små tuvor och stora lass. En liten bok om att förvandla en bra idé till ett bra IT-projekt Troed Troedson Paradigmmäklarna, Löberöd och SIGMA Pleon AB, Sundsvall, 2004 [3] Anonym Konsult med uppdrag på stora företag i Lund, 2006 [4] Peter Neubauer Utvecklingschef på Scan Coin i Malmö, 2006 [5] Snabbrörlig Utveckling på Scan Coin - bara Aglie räcker inte JayView nr 7, 2005 [6] Agile Breaks on Through to the Other Side Stephen Swoyer, 2005 http://www.adtmag.com/article.asp?page=1&id=10757 [7] Guidelines For introducing DSDM Into An Organisation - Envolving to a DSDM Culture DSDM Consortium 1998 [8] Technology Adoption Cycle Andrea Di Maio, 1997 http://www.cordis.lu/esprit/src/stcycle.htm [9] Combining Agile Methods with Stage-Gate Project Management Daniel Karlström and Per Runeson, Lund University IEEE Software, May/June 2005 [10] LUCAS - Center for Applied Software Research Jonas Wisbrant, 2005, Lund University http://www.lucas.lth.se/about/folderweb.pdf [11] Refactoring the Development Process: Experiences with the Incremental Adoption of Agile Practices Paul Hodgetts, 2004, Agile Logic, Inc. Proceedings of the Agile Development Conference (ADCŠ04) 11
[12] Erik Lundh Compelcon AB, Helsingborg [13] Extreme Programming Explained : Embrace Change Kent Beck, Addison-Wesley Professional 2004 12
A Rekommenderad läsning Nedan presenteras ett urval av referenser som rekommenderas att läsas för att få ammunition till att övertyga utvecklare, ledning och kunder. Overcoming Management Resistance to Pair Programming Innehåller What s In It For Me -tankar och empiriska data som kan användas för att motivera parprogrammering. http://www.aw-bc.com/samplechapter/0201745763.pdf The Costs and Benefits of Pair Programming Innehåller empiriska data som kan användas för att motivera parprogrammering. http://collaboration.csc.ncsu.edu/laurie/papers/xpsardinia.pdf Examining the Agile Cost of Change Curve Förklarar hur agila projekt på ett possitivt sätt påverkar kostnaden för förändringar. http://www.agilemodeling.com/essays/costofchange.htm Reexamining the Cost of Change Curve, year 2000 Förklarar hur agila projekt på ett possitivt sätt påverkar kostnaden för förändringar. http://www.xprogramming.com/xpmag/cost_of_change.htm Agility, Uncertainty, and Software Project Estimation Resultatet av studier på 120 kommersiella projekt. http://www.macs.ece.mcgill.ca/~radu/304428w03/agilityuncertaintyandestimation. pdf Sabre takes extreme measures Mätningar från Sabre Airline Solutions visar att både antalet buggar och utvecklingstid har minskat drastiskt efter införandet av extreme Programming. http://www.computerworld.com/developmenttopics/development/story/ 0,10801,91646,00.html Extreme Programming Kritiska röster mot XP http://www.softwarereality.com/extremeprogramming.jsp The Case Against Extreme Programming Kritik mot XP metoderna http://www.softwarereality.com/lifecycle/xp/case_against_xp.jsp TDD Research Findings Sammanfattning av mätningar utförda vid användande och införande av TTD http://weblogs.asp.net/mhawley/archive/2004/04/15/114005.aspx 13
Metrix and XP Förslag på olika sätt att mäta utvecklingshastighet, effektivitet osv i extreme Programming projekt. http://codebetter.com/blogs/ranjan.sakalley/archive/2005/04/05/ 61309.aspx 14