Översikt över lättviktsmetodiker

Översikt över lättviktsmetodiker Magnus Gäfvert Sven Hedlund 16 maj, 2002 Sammanfattning På många håll har man upptäckt att traditionella metodiker för mjukvaruutvecklingsprojekt inte alltid fungerar bra. En ny klass av metodiker som betecknas lättviktsmetodiker (LVM) har under senare tid lanserats som en lösning till detta. Gemensamt för alla LVM är att de innehåller ett minimum av administration, och att de lägger större fokus på människor än på processer och verktyg. I den här studien presenteras en översikt och diskussion av befintliga LVM. Studiens målgrupp är främst programvaruutvecklare med liten erfarenhet av LVM. 1. Inledning På många håll har man upptäckt att traditionella metodiker för mjukvaruutvecklingsprojekt inte alltid fungerar bra. Projekt drabbas ofta av förseningar och budgetöverskridanden, och havererar ibland fullständigt på grund av oväntade problem som dyker upp. En ny klass av metodiker som betecknas lättviktsmetodiker (LVM) har under senare tid lanserats som en lösning till detta. Gemensamt för alla LVM är att de innehåller ett minimum av administration, och att de lägger större fokus på människor än på processer och verktyg. I den här studien presenteras en översikt och diskussion av befintliga LVM. Studiens målgrupp är främst programvaruutvecklare med liten erfarenhet av LVM. Metodikerna som behandlas är: Adaptive Software Development Crystal Family Dynamic System Development Method Feature Driven Development Lean Programming Open Source Pragmatic Programming Rational Unified Process Scrum 1

Extreme Programming I avsnitt 2 diskuteras begreppet lättviktsmetodiker. Befintliga metodiker beskrivs kortfattat utifrån sina grundprinciper i avsnitt 3. Olika metodikers lämplighet för olika typer av projekt diskuteras också, liksom vilka idéer som kan lyftas ur en lättviktsmetodik och användas i andra sammanhang. En strukturerad jämförelse mellan metodikerna som belyser skillnader och gemensamma drag följer i avsnitt 4. 1.1 Metod Information som är direkt tillgänglig på webben ligger till grund för studien. Endast i undantagsfall används kommersiellt publicerat material. Insamling av information har i första hand skett med hjälp av sökmotorer på webben. 1.2 Definitioner För att undvika missförstånd beskriver vi här några begrepp som är centrala vid diskussion av projekt och metodiker: Ett projekt är en temporär ansträngning för att skapa en unik produkt. I den här rapporten är produkten ett mjukvarusystem, som vi i fortsättningen refererar till som systemet. En metod är en systematisk procedur. Med metodik menas en samling relaterade metoder eller tekniker. En metodik för ett projekt betecknar alltså de metoder som används för att genomföra projektet. Det är också vanligt att beskriva projekt utifrån processer. Processer är en serie av åtgärder som genererar ett resultat. Projekt består av processer. En metodik kan alltså också beskrivas som en samling relaterade processer. 2. Lättviktsmetodiker kontra traditionella metodiker Ett problem med traditionella metodiker, som till exempel vattenfallsmetodiken, är att de betraktar mjukvaruprojekt som väsentligen deterministiska. Utgångspunkten är att det på förhand går att sätta upp krav och specifikationer som sedan ligger fasta under projektets gång, och att det utifrån dessa går att fastställa en plan för projektets utförande. Tillvägagångssättet är sekventiellt med specifikationsfas, planeringsfas och utförandefas efter varandra. Mjukvaruprojekt innehåller stora osäkerheter i form av krav som kan ändras, teknologi som kan ändras, och affärsmässiga förutsättningar som kan ändras. Därför är den deterministiska modellen av mjukvaruprojekt inte särskilt bra. Om beställaren vill ändra kraven innebär det att planeringen faller, och man får göra om planen. Samma sak gäller om andra oförutsedda händelser inträffar som stjälper planeringen. I traditionella metoder använder man sig av omfattande processer för övervakning och styrning av projektet för att hantera avvikelser och försöka hålla projektet i linje med planen. När avvikelser upptäcks får man allokera om resurser eller ändra i tidsplanen. Ändringar i specifikationer kräver omplanering. Resultatet blir att man måste komplettera den sekventiella processen med återkoppling och iterationer. Den tunga administrativa apparat som traditionella metodiker kräver tar kraft från det produktiva arbetet. Det har identifierats som ett problem, och har resulterat i nya LVM, där man skär ner administrationen 2

till ett minimum. Samtidigt har man uppmärksammat att behovet av den tunga administrationen ligger i den traditionella synen på projekten som deterministiska. Därför har man i de nya metodikerna också en ny syn på projektens natur, där man utgår från att osäkerheten är stor och att projekten alltid utsätts för förändringar. Därför lägger man vikt vid att metoderna ska vara anpassningsbara, och man överger i stort sett modellen med inledande specifikations- och planeringsfaser, och låter dessa löpa mer eller mindre parallellt med utförandefasen. Notera att LVM inte är mindre metodiska, de är bara mindre tungrodda än traditionella metodiker. Representanter för några LVM upptäckte att de hade mycket gemensamt, och formulerade utifrån det ett manifest, The Manifesto for Agile Software Development [24, 25] (se appendix A). Här myntades begreppet lättrörliga metodiker (eng. agile) som ersättning för lättviktsmetodiker. Med den nya beteckningen betonar man metodikernas anpassningsbarhet framför minimalismen. Begreppen är tätt kopplade till varandra, och i forsättningen används endast beteckingen lättviktsmetodiker. Manifestet uttrycker principerna bakom några LVM, men som förmodligen är representativa för LVM i allmänhet. Grunden för manifestet är fyra prioriteringar: Individer och samspel framför processer och verktyg. Ett bra samspel mellan skickliga medarbetare betyder mer än vilka processer och verktyg som används. Teamet bör vara samlat på en plats. Samverkan med kunden framför kontrakt. På förhand gjorda kontrakt eller överenskommelser kan fungera som ramar för projektet, men endast genom fortlöpande samarbete kan man förstå och leverera det kunden vill ha. En kundrepresentant bör finnas på plats och vara med i teamet. Fungerande mjukvara framför omfattande dokumentation. Omfattande dokumentation kan vara bra, men allra viktigast är att leverera fungerande mjukvara. Mycket dokumentation kan ersättas med direkt kommunikation mellan medarbetare. Anpassning till förändringar framför planföljning. Ett programutvecklingsprojekt blir ofta utsatt för nya krav som kan bero på förändrade affärsmässiga villkor eller ny teknik. Dessa förändringar leder till att den ursprungliga planen måste förändras eller överges. Inkrementellt arbete med kort planeringshorisont och frekventa utgåvor underlättar anpassning till förändringar. Listan ska läsas som att vänsterledet i punkterna uttrycker en preferens, medan högerledet beskriver något som är viktigt, men av lägre prioritet. Högerleden ovan är sådant som betonas i traditionella metodiker. Tillsammans med prioriteringarna finns i manifestet en samling principer som följs i LVM. Bland annat ska man leverera fungerande mjukvara tidigt och ofta. Det ger en trygghet för kunden, dels för att hon kan följa hur systemet utvecklas, men också för att hon har ett användbart system i det fall projektet avbryts. Man ska också göra saker så enkelt som möjligt, så att det blir lättare att ändra om det skulle behövas. 3

3. Befintliga lättviktsmetodiker 3.1 Adaptive Software Development Centrala idéer Adaptive Software Development (ASD) [13, 14, 15] addresserar behovet av en metodik som hanterar snabba förändringar under ett projekt. Huvudstrategin för att åstadkomma en anpassningbar projektmiljö är att flytta fokus från processer till produkter och resultat. Det kräver en iterativ metodik där resultatet av varje iteration utgör grunden för styrning av programutvecklingsprocessen. Varje iteration består av tre faser: spekulation, kollaboration och lärande. Spekulationen motsvarar planering, men ordvalet betonar att osäkerheten är stor. I spekulationsfasen diskuteras och definieras vad som ska uppnås under iterationen. I den följande kollaborationsfasen arbetar teamet tillsammans för att uppnå det som föreslogs från spekulationsfasen. I lärandefasen utvärderas resultatet tillsammans med spekulationerna och nästa iteration förbereds. Varje iteration, som kallas en adaptiv cykel, är fokuserad på uppdraget från beställaren. Uppdraget betraktas som ramar för projektet snarare än som ett mål. Den adaptiva cykeln är komponentorienterad. Med det menas att i slutet av cykeln är det framför allt intressant vilka programkomponenter som har färdigställts. Vilken process som har lett fram till resultatet är av mindre betydelse. Med programkomponenter menas samlingar av programfunktioner. I iterationen betonas vikten av att göra om lika mycket som att göra. Felaktigheter betraktas alltså inte nödvändigtvis som misslyckanden, utan en oundviklig väg till färdig produkt. Man fixerar slutdatum för iterationer och projektet. Sedan ser man till att hålla dessa datum genom att anpassa vilken funktionalitet som levereras. Planeringen av en adaptiv cykel bygger på analys av risker och osäkerheter. Sammantaget påstås detta leda till att ASD är förändringstolerant. Kommentarer Kärnan i ASD tycks vara observationen att det inte går att planera i en osäker miljö. En central idé är att man under en iteration koncentrerar sig på resultatet, och lägger liten vikt vid vilka processer som leder dit. ASD tycks ge väldigt lite hjälp i hur man konkret ska organisera det arbetet. I ASD förordas inga särskilda metoder eftersom en metod som regel har ett begränsat tillämpningsområde. ASD är ämnat att användas i många olika slags projekt, och man uppmuntras att använda de metoder som man själv tycker fungerar. Små till medelstora projekt föreslås delas upp i iterationer om 4-8 veckor. Metodiken är tänkt att kunna skalas upp även till stora projekt. 3.2 Crystal Family Centrala idéer Crystal Family (CF) [3, 4, 5, 6, 7, 8, 9] är en familj av metodiker anpassade för olika slags projekt. Detta kommer av observationen att ingen enskild metodik fungerar för alla typer av projekt. Ur familjen väljer man en grundmetodik utifrån två kriterier: projektets storlek, och projektets kritikalitet. Med projektets storlek avses antalet medarbetare, och med kritikalitet avses hur svåra konsekvenser ett fel i det levererade systemet får. Dessa konsekvenser sträcker sig i en skala från 4

irritation hos användaren till måttlig ekonomisk skada, svår ekonomisk skada och förlust av människoliv. Man kan betrakta CF som en samling mallar för att konstruera en metodik som passar ett specifikt projekt. De olika metodikerna som presenteras i CF är avsedda att modifieras och kalibreras för varje nytt projekt. Ett primärt mål med CF är att finna en metodik för projektet som är så lätt som möjligt. Personlig kommunikation ska vara en viktig del av metodiken. Fyra grundprinciper ligger bakom konstruktionen av metodikerna i CF: Det krävs en tyngre metodik när fler människor är inblandade. Detta följer av att metodikens primära syfte är att koordinera människor. En liten ökning av metodiktyngden ger en relativt stor kostnadsökning. För vissa projekt krävs en tyngre metodik. Man ska vara medveten om att kostnaden då blir signifikant större. Mer formalism krävs för projekt med stor kritikalitet. man kan motivera kostnaden för att införa en tyngre metodik när konsekvenserna av fel i systemet är svåra. Kommunikation öga-mot-öga är den effektivaste formen. Det är lättare att genomföra ett projekt när medarbetarna är direkt tillgängliga för varandra. I stora projekt när medarbetarna är utspridda ökar kostnaden för kommunikation. Kommentarer I CF har man strukturerat och förpackat erfarenheter av vilka metoder som har fungerat i olika typer av projekt. Det kan ge hjälp att hitta en metodik med rätt omfattning för ett visst projekt. Det är oklart i beskrivningarna av CF hur iterationerna ser ut i detalj, och i vilket grad projektet planeras. Inga metoder utesluts egentligen från CF, eftersom användaren har stor frihet att konstruera sin metodik. CF ger en vägledning om vilka delar av projektet som behöver struktureras med metoder, men vilka specifika metoder man ska välja lämnas öppet. För alla projekt anmodas inkrementell utveckling med korta inkrement om en till tre måndader. CF ska kunna appliceras på nästan alla typer av projekt. 3.3 Dynamic System Development Method Centrala idéer I början av 1990-talet lanserades begreppet Rapid Application Development (RAD). RAD skulle skilja sig från traditionella utvecklingsmetodiker genom att vara anpassat för en snabb och dynamisk affärsmiljö. RAD tolkades väldigt olika av olika aktörer och blev snart en ganska innehållslös term. DSDM [21] togs fram med ambitionen att bli en industristandard för RAD. Medan traditionella metoder utgår från att leverera en produkt som uppfyller fastställda krav, utgår DSDM från att leveransdatum och tillgängliga resurser är fastställda medan kraven tillåts variera. DSDM bygger på följande principer, som appliceras efter behov: Aktivt deltagande av användare. Systemets användare deltar aktivt genom hela utvecklingsprocessen. Teamet har auktoritet att fatta beslut. DSDM-team består av både utvecklare och användare. De ska kunna fatta beslut om förändringar av krav utan att blanda in högre ledning. 5

Iterativ och inkrementell utveckling med täta leveranser. Detta ger värdefull återkoppling från användarna. Dessutom kan levererade delsystem ge omedelbar affärsnytta. Arbetet sker utifrån prototyper, som utvecklas till det slutliga systemet. Produkten levereras inkrementellt med på förhand bestämda tidsintervall. Genom att hålla intervallen korta kan teamet lättare planera och prioritera aktiviteter. Fokuseringen på produkten snarare än aktiviteter leder till större flexibilitet. Odetaljerade baskrav. Kraven förfinas efter hand. Integrerad testning. Testning är inte en separat aktivitet. Under den inkrementella utvecklingen testas och granskas systemet fortlöpande av utvecklare och användare. Ett centralt begrepp i DSDM är tidslådor (eng. timeboxes). En tidslåda är motsvarigheten till traditionella metodikers aktiviteter. Här är den tillgängliga tiden fastställd och får inte överskridas. Istället är specifikationerna prioritetsordade, och man gör så mycket man hinner med. Projektets livscykel i DSDM är iterativ och inkrementell. Den består av fyra faser: Lämplighetsstudie och affärsstudie. Man undersöker om systemet passar för DSDM. Generella specifikationer tas fram. Iteration funktionsmodell. Kraven och specifikationerna förfinas. Iteration design och implementering. Prototyper utvecklas till leveransfärdiga delsystem. Leverans. Innefattar även utbildning av användare. Kommentarer DSDM handlar mer om projektstyrning än programmering. Det är en övergripande metod som kan komplettera till exempel XP. Grundprinciperna i DSDM är desamma som för LVM i allmänhet. DSDM beskriver en generell process för hur man implenterar dessa principer, som sedan anpassas till det specifika projektet. 3.4 Feature-Driven Development Centrala idéer I traditionella utvecklingmetodiker bryter man ner det planerade systemet i mindre delar för att kunna hantera komplexiteten. Det kan vara klasser, moduler eller funktionalitet som behövs i systemet. Dessa delar motsvarar inte nödvändigtvis direkt användarfunktionalitet. Resultatet blir att projektteamet riskerar att fokusera mer på systemets interna funktioner istället för de funktioner som är beställda av kunden. Ett annat problem är att kunden kan ha svårt att uppfatta projektets framåtskridande när hon inte kan relatera färdig funktionalitet till användarfunktionalitet. I Feature-Driven Development (FDD) [18, 19, 20] löser man detta problem genom att se till att nedbrytningen av problemet motsvarar användarfunktionalitet. Det resulterar i bibehållen fokus på resultatet, och bättre kommunikation med kunden. FDD är formulerat som fem stycken processer: 6

1. Ta fram en övergripande modell. Projektomfattande aktivetet där kund och utvecklare tillsammans tar fram en detaljerad modell över det kompletta systemet, uttryckt i till exempel klass- och sekvensdiagram. 2. Ta fram en lista över användarfunktionaliteter. Projektomfattande aktivetet där man identifierar all användarfunktionalitet som krävs för att uppfylla specifikationerna. Användarfunktionerna grupperas hierarkiskt och prioritetsordnas. Även här deltar kunden. 3. Planera utifrån användarfunktionalitet. Projektomfattande aktivitet där arbetet med olika användarfunktioner schemaläggs och planeras. Varje klass tilldelas en ägare. 4. Designa utifrån användarfunktionalitet. En aktivitet för varje användarfunktion, där man identifierar vilka klasser som berörs av varje funktion. Ägarna till dessa klasser bildar ett funktionsteam. Teamet tar fram en design för funktionen, och förfinar objektmodellen utifrån den. 5. Implementera utifrån användarfunktionalitet. En aktivitet för varje användarfunktion, där varje klassägare implementerar sina metoder och därtill hörande enhetstester. Efter kodinspektion levereras funktionen för integrering. Nödvändigheten med formella processer betonas i FDD. Stor vikt läggs vid att hålla dem okomplicerade och kort beskrivna, i motsats till vad som är fallet i många traditionella metodiker. För varje användarfunktion beskriver processerna 4 och 5 en iteration, som normalt inte är längre än två veckor. De korta iterationerna innebär att konkreta och för kunden användbara resultat levereras ofta. Detta tillsammans med de relativt enkla processerna gör att FDD kan betecknas som en lättviktsmetodik. Centrala metoder i FDD är Modellering av domänobjekt Konstruera klassdiagram som illustrerar de väsentliga objekten och deras realtioner inom en problemdomän. Utveckla baserat på användarfunktionalitet. Bryt ner problemet i enheter som relaterar direkt till användarfunktionalitet. Individer äger klasser och kod. I större projekt kan kollektivt ägande resultera i att det finns klasser som ingen tar ansvar för. Med individuellt ägande finns det en expert på varje klass. Funktionsteam. För att implementera en viss funktion måste de ägare vars klasser är berörda bilda team. Klassägare kan arbeta i mer än ett funktionsteam samtidigt. Kodgranskning. I FDD betonas vikten av formell kod- och designgranskning för att säkra kvaliteten. Regelbunden integrering. Regelbundna integreringar gör att man snabbare hittar fel. Dessutom finns det alltid en fungerade version att visa för kunden. integreringarna görs som regel ofta, varje dag eller varje vecka. 7

Konfigurationshantering. I FDD förordas en ganska omfattande konfigurationshantering. Rapportering och insyn. Formalismen och dokumentationen i FDD gör det relativt enkelt att ta fram olika slags mått på projektets status. Kommentarer Den enda principen som FDD har gemensamt med andra LVM är täta iterationer, men i övrigt verkar det vara hierarkiskt och formellt. FDD är inte bara en övergripande metodik för projektstyrning, utan innehåller också ett antal konkreta metoder. Tanken att man ska bryta ner problemet i delar som har direkt värde för användaren bör även kunna användas i andra sammanhang. Det är avsett för medelstora till stora projekt. 3.5 Lean Programming Centrala idéer Lean Programming (LP) [2] är inspirerat av Lean Manufacturing, som är en ledningsfilosofi med ursprung från Japansk bilindustri vid tiden efter andra världskriget. Det innebär kort uttryckt att allt som är överflödigt i tillverkningsprocessen ska elimineras. Först under 1980-talet fick Lean Manufacturing genomslag i västvärlden. LP har som syfte att överföra Lean Manufacturing på programvaruutveckling. Detta gör man med hjälp av tio grundregler: Eliminera överflöd. Eliminera det som inte har något direkt värde i slutprodukten. Här avses framför allt dokumentation, diagram och modeller som används under utvecklingen. Minimera artefakter i mellanleden. Även här tycks man avse överflödig dokumentation. Pressa ned utvecklingstiden. Använd iterativ utveckling med täta, små och fungerande delleveranser. Iterationer om ett par veckor till ett par månader föreslås. Fatta beslut sent. Var flexibel för förändringar. Fatta inte tidiga beslut baserade på prognoser. Delegera ansvar till utvecklarna. Genom att tala om för utvecklarna vad de ska göra istället för hur de ska göra uppmuntrar man dem att göra ett bra jobb. Lyssna på kunden. Genom iterativ utveckling får man kontinuerlig återkoppling från kunden. Gör rätt första gången. Genom täta kontakter med kunden vet man att man hela tiden har kundens krav aktuella. Enhetstestning ökar sannolikheten att leverera korrekt kod första gången. Undvik lokal optimering. Traditionella mått på projekts framåtskridande baseras ofta på lokala mätbara storheter som inte har något starkt samband med hela projektets framgång. Använd pålitliga underleverantörer. Skapa en kultur som uppmuntrar förbättringar. 8

Kommentarer I LP har man tagit ett befintligt ramverk ifrån tillverkningsindustrin och försökt överföra det på programvaruutveckling. Resultatet kan i vissa delar verka krystat och är som helhet ganska abstrakt. 3.6 Open Source Centrala idéer Open-Source (OS) är en rörelse med rötter i The Free Software Foundation (FSF) [11], som grundades av Richard Stallman i början av 1980-talet. Idag finns det flera olika grenar som framför allt skiljer sig i detaljer beträffande hur programvara ska licensieras. En av de viktigare är The Open Source Initiative (OSI) [12] som intar en pragmatisk hållning, i kontrast till Stallmans mer ideologiska rörelse. Grunder för OS-rörelsen är filosofin att programvara ska vara fri och distribueras med källkod. OS har framför allt attraherat enskilda programmerare runt om i världen, eftersom kommersiella aktörer har haft svårt att hitta affärsmodeller för att tjäna pengar på fri programvara. I OS finns ursprungligen ingen särskilt metodik formulerad. En metodik kan ändå sägas ha uppstått spontant ur förusättningarna. FSF formulerade filosofin bakom OS, medan den nuvarande formen för utveckling av OS-programvara initierades av Linus Thorvalds vid utvecklingen av operativsystemet Linux. Medan tidigare programvaruprojekt hade drivits som katedralbyggen, kan man likna Linus filosofi vid verksamheten i en basar. Katedralbygget kännetecknas av centralisering och toppstyrning, medan basaren bygger på distribuering och mångfald [10]. Kärnan i OS-metodiken ligger i observationen att om tillräckligt många betraktar ett problem så är lösningen uppenbar för åtminstone någon. Detta har formulerats som Linus lag: Given enough eyeballs, all bugs are shallow. Kommunikationen mellan deltagarna i ett OS-projekt sker nästan uteslutande över Internet. Utvecklingen och spridningen av Internet har varit en förutsättning för OS-rörelsen. Den som initierar ett projekt, börjar med att göra ett program som är tillräckligt bra för att intressera andra användare och utvecklare. Därefter publicerar hon det på webben och andra utvecklare och användare som är intresserade kan delta i projektet. Därefter intar hon rollen som koordinator. Den fortsatta utvecklingen bygger på att användare rapporterar buggar och önskade förbättringar, och att andra utvecklare förbättrar koden. Den nya koden integreras av koordinatorn. Tillvägagångssättet innebär att kraven inte är givna ifrån början utan tillkommer efter hand. Nya versioner publiceras ofta, för att göra den aktuella koden tillgänglig. Motivet för andra utvecklare att hjälpa till är kombinationen av intresse för problemet, och äran och stoltheten i att ha medverkat till att göra ett bra program. Viktiga egenskaper hos koordinatorn är att kunna lyssna till bra idéer, kommunicera med andra människor och att ge uppmuntran. OS-projekt har en enorm kompetenspool att hämta resurser från, eftersom vilken programmerare som helst i världen kan delta. Man kan betrakta OS-miljön som en marknad för individuella prestationer. Endast väl dokumenterade projekt med robust och enkel design kommer att dra till sig utvecklare och användare, och därmed överleva. OS-projekt bygger på frivilligt deltagande, och det är sannolikt att nyckelpersoner med tiden 9

kommer att lämna projektet. Dessa personer har då en outtalad skyldighet att lämna över sitt arbete till kompetenta efterföljare. I OS-projekt används som regel standardiserade gratisverktyg som GCC, GNU autotools, Python och Perl. Kommentarer OS kan betraktas som en lättviktsmetodik eftersom det inte bygger på formella processer. Det består av korta iterationer med täta utgåvor och stark återkoppling ifrån användarna. OS skiljer sig dock ifrån övriga LVM genom att utvecklare och användare sitter långt ifrån varandra, och att inslaget av direkt kommunikation är obefintligt. Det kan vara svårt att överföra OS-metodiken till kommersiella villkor, eftersom det inte finns några mekanismer för att garantera deadline, budgetföljning eller funktionalitet. OS-rörelsen genererar många program, stora såväl som små, och dåliga såväl som bra. Att en del program blir bra beror delvis på att OS attraherar många programmerare, varav åtminstone en del är väldigt duktiga. En aspekt av OS är att de bäst lämpade förmågorna vaskas fram ur en enorm världsomspännande programmerarpool. Detta går inte att åstadkomma inom ett företag. 3.7 Pragmatic Programming Pragmatic Programming (PP) [22] är inte en egentlig metodik, utan handlar mer om programmering som hantverk än administration av mjukvaruprojekt. PP beskriver en diger samling av diverse tips och metoder som kan hjälpa programmerare att producera bättre kod. Dessa kan naturligtvis användas tillsammans med många metodiker. Upphovsmännen bakom PP var med och formulerade manifestet för lättrörliga metodiker. 3.8 Rational Unified Processes Centrala idéer Rational Unified Processes (RUP) [26, 27] är ett generellt ramverk för processer för projektstyrning. Det är i princip en guide för hur man effektivt utnyttjar Unified Modeling Language (UML). Det är omfattande och flexibelt och kan anpassas till många olika typer av projekt. Man kan betrakta RUP som en metametodik, det vill säga en metodik för att skapa metodiker. Inom RUP är det möjligt att implementera såväl LVM som traditionella metodiker. Det har till exempel föreslagits som komplement till XP för att skala upp till större projekt. Vi behandlar inte RUP ingående här, eftersom det inte finns något som motiverar att man kallar det en lättviktsmetodik i sig. Kommentarer RUP har inte konstruerats i syfte att vara en lättviktsmetodik. I en del senare artiklar försöker man anpassa RUP till LVM. Man kan misstänka att det är ett försök att utnyttja uppmärksamheten kring LVM. 3.9 SCRUM Centrala idéer Scrum är en rugbyterm som betecknar en grupp spelare som ska plocka upp bollen och transportera den framåt. SCRUM [16, 17] är framför allt tänkt att användas till projekt som handlar om underhåll och 10

förbättringar av befintliga mjukvarusystem. Ett projekt i SCRUM handlar om att ta fram en ny utgåva. Bakom SCRUM ligger tanken att vissa faser i ett projekt inte går att beskriva som väldefinierade processer, eftersom de är utsatta för alltför stor osäkerhet. Detta gäller i synnerhet analys-, design- och utvecklingsfaserna. Till det befintliga systemet finns en prioritetsordnad lista över önskad ny funktionalitet och brister som ska rättas till. Arbetsgången är att man först genomgår en planeringsfas, där den nya utgåvan definieras utifrån listan. Därefter genomgår man en serie iterationer, kallade spurter (eng. sprints), som innehåller analys, design och utvecklingsfaser. Slutligen har man en avslutningsfas med integration, dokumentation och leverans av utgåvan. Varje spurt löper över ett fixerat tidsintervall på vanligen en till fyra veckor. Inför spurten definierar man vilken funktionalitet man ska implementera. Under spurten arbetar man inte efter någon definierad process, utan arbetet styrs mer eller mindre improviserat. Varje dag håller man ett kort möte där teamet kan rapportera problem, och projektledaren får ett grepp om vilka framsteg som gjorts. Efter spurten integrerar och testar man delar av den nya koden. Till sist uppdaterar man funktionalitetslistan. Kommentarer SCRUM fokuserar mest på iterativ planering och uppföljning, och föreskriver inte vilka metoder som ska användas under en iteration. SCRUM behandlar inte projektets hela livscykel, eftersom det är inriktat på att underhålla befintliga system. För att bedriva ett fullständigt projekt måste man komplettera det med andra metodiker. 3.10 Extreme Programming Centrala idéer Extreme Programming (XP) [1] är en metodik som vill lösa problemet med försenade och budgetöverskridande projekt. Metodiken vilar på fyra grundprinciper: Kommunikation. Bristande kommunikation ger ofta upphov till problem i projekt. Direkt och enkel kommunikation är en viktig del av XP. Enkelhet. Man ska enbart implementera sådant som är nödvändigt för stunden. Man ska inte skriva generell kod för eventuellt framtida bruk, eftersom förutsättningarna ofta förändras under projektets gång. Återkoppling. Konkret återkoppling tidigt och ofta från kollegor, kund och slutanvändare medför att fel och missförstånd upptäcks i tid. Kurage. Man måste ha kurage att ge och ta emot uppriktig kritik. Det är en förutsättning för de första tre principerna. Principerna konkretiseras i tolv praxisar som måste följas: Planeringsmöte. Huvudidén är att snabbt ta fram en översiktlig plan, som förfinas under projektets gång. Kund och utvecklare skriver informella beskrivningar av systemets specifikationer på lappar. Varje lapp beskriver en avgränsad önskad funktionalitet. Utvecklarna bedömer svårigheten i att implementera varje funktionalitet. Baserat på detta bestämmer sedan kunden vilka funktionaliteter som är viktigast att få med i nästföljande utgåva. 11

Parprogrammering. Innebär att all programmering sker i par. Fördelar med detta är att alla designbeslut fattas av två personer, minst två personer är bekant med varje del av koden, täta byten av partner ger kunskapsspridning och all kod granskas kontinuerligt. Testning. I XP använder man två slags tester: enhetstester och acceptanstester. Enhetstestning innebär att det till varje kodenhet ska finnas ett test. Testkoden skrivs först och används som specifikation. Efter varje integrering kontrollerar man att alla gamla enhetstester går igenom. Acceptanstester är tester på systemnivå, ofta ett test till varje funktionalitet, som skrivs av kunden tillsammans med programmerare. Omstrukturering. Förbättringar av koden som inte förändrar funktionaliteten. Enkel design. Implementera enbart det som är absolut nödvändigt för stunden. Om man försöker förbereda sin kod för framtida behov riskerar man att skriva kod som aldrig kommer att användas, eftersom kraven kan komma att förändras. Kollektivt ägande av kod. Vem som helst kan ändra vilken kod som helst. Då kan den som upptäcker brister i koden rätta till dem direkt. Fortlöpande integrering. Så snart någon kod passerar sitt enhetstest betraktas den som klar, och integreras med resten av systemet. På-platsen-kund. Det ska finnas en representant för kunden på plats hela tiden. Denna ska kunna ge snabb återkoppling, svara på frågor, och förklara specifikationer. Små utgåvor. All ny funktionalitet integreras så snart den är klar. På så sätt kan kunden tidigt tillgodogöras nyttiga funktioner och prova dem i dess rätta miljö. 40-timmarsvecka. Man ska inte trötta ut sin personal. Kodningsstandard. Blir nödvändigt eftersom alla äger koden tillsammans. XP föreskriver ingen speciell standard, utan bara att man följer någon. Systemmetafor. Underlättar att resonera om systemet. I traditionella metoder genomgår man i tur och ordning en analysfas, en designfas, en implementationsfas och en integrations- och testfas. Varje fas omfattar hela systemet. I XP genomgår man alla faserna samtidigt i varje iteration, men bara för en liten avgränsad del av systemet. Vilken funktionalitet som ska ingå i varje iteration bestäms av kunden. Kommentarer XP är en konkret metodik. Många av praxisarna i XP begränsar storleken på vilka projekt som kan genomdrivas. Omstrukturering av koden blir allt svårare när dess omfattning tilltar. I ett större projekt med många programmerare och omfattande kod är nyttan av kollektivt kodägande diskutabel man kan inte begära att vem som helst ska besitta kunskapen att rätta fel i vilken kod som helst. XP förordar täta integreringar med tillhörande enhetstestning av all kod efter varje integrering. XP nämner inte mycket om hur detta ska gå till när kodmassorna växer. Med anledning av ovanstående rekommenderas XP endast till små projekt om 10 20 programmerare. 12

4. Jämförelser En svårighet med att göra jämförelser mellan metodikerna är att de inte är likvärdiga. ASSD, CF, DSDM, FDD, SCRUM och XP är de metodiker som bäst kan karaktäriseras som LVM. Bland dessa intar XP en särställning genom att vara betydligt mer konkret och tydlig. LP är mer av en ledningsfilosofi än en metodik, OS är en ideologi utan någon explicit formulerad metodik, PP är en samling tips för programmerare, och RUP är ett ramverk som oftast används med traditionella metodiker. Generellt kan man säga att fullständiga metodiker för genomförande av projekt innehåller processer för uppstart, planering, utförande, styrning och övervakning, och avslut [29]. I vilken mån olika LVM behandlar dessa områden indikeras i tabell 1. I LVM tenderar planering, utförande och Uppstart Planering Styrning Utförande Avslut ASD + ++ + CF ++ ++ ++ DSDM + ++ ++ + + FDD ++ ++ ++ LP OS + + PP ++ RUP + + + + + SCRUM ++ ++ XP + ++ Tabell 1 Metodikernas omfattning. ( : behandlas ej; + : ingår; ++ : betonas) styrning att vara samlat i en integrerad process. LVM är ofta inte lika kompletta som traditionella metodiker eftersom de inte behandlar uppstart och avslut. De olika metodikerna lämpar sig för olika stora projekt. Detta visas i figur 1. Ett projekt kan anses vara stort när man ska ta fram ett omfattande och komplext system, eller när många människor är inblandade. I figuren avses med ett litet projekt färre än 20 utvecklare, och ett stort projekt fler än 80. Metodiker som är avsedda för större projekt innehåller mer inslag av planering, jämför med tabell 1. Även metodiker som betonar ett minimum av administration kommer därför med nödvändighet att bli tyngre med tilltagande projektstorlek [28]. Ett gemensam nämnare för ASD, DSDM, FDD, SCRUM och XP är hur man prioriterar i projektplanen. Medan traditionella metodiker prioriterar specifikationer högst och låter tidsplan och resurser variera, prioriterar dessa LVM tidsplanen och resurserna högst och låter specifikationerna variera. Konkret betyder det att man alltid håller sina leveransdatum, och levererar den funktionalitet som man har hunnit med att implementera. En metodik bygger på en modell av projektet, ofta uttryckt som projektets processer. För stora projekt blir modellen så stor och detaljrik att 13

ASD CF DSDM FDD LP OS PP RUP SCRUM XP små medelstora stora Figur 1 Metodikernas lämplighet för olika storlekar av projekt. den måste beskrivas på en högre abstraktionsnivå för att vara hanterbar. Metodiker för stora projekt måste bygga på abstrakta modeller, men de måste naturligtvis ändå konkretiseras när det kommer till det praktiska genomförandet. I figur 2 illustreras på vilken abstraktionsnivå projektets processer är beskrivna. Flera av de beskrivna metodikerna är endast över- abstrakt ramverk konkreta metoder ASD CF DSDM FDD LP OS PP RUP SCRUM XP Figur 2 Metodikernas abstraktionsnivå av projektets processer. gripande ramverk och måste alltså kompletteras med konkreta processer. I figuren betyder det att staplarna måste nå hela vägen ner till baslinjen som motsvarar det konkreta genomförandet. Från figuren framgår det att man måste komplettera de flesta metodikerna. Det har till exempel föreslagits att kombinera FDD eller CF med XP. När man söker information om LVM får man intrycket att XP har störst spridning. En anledning till det kan vara att XP är så konkret och lätt att komma igång med på egen hand. Flera av de andra metodikerna verkar kräva omfattande utbildning och kanske externa konsulter. De flesta ar- 14

tiklarna om ASD, CF, DSDM, FDD och SCRUM tycks vara skrivna av upphovsmännen bakom respektive metodik. Det är svårt att hitta oberoende material som beskriver praktiska erfarenheter av metodikerna. 5. Sammanfattning LVM för stora projekt är i flera fall beskrivna på en så abstrakt nivå att de ser enkla ut. En anledning till detta kan vara att man inte vill få metodiken att framstå som tung genom att lista de konkreta metoder som trots allt är nödvändiga. Att artiklar om LVM ofta på allmän nivå och innehåller otillräcklig information för att förstå metodikerna kan också bero på att man vill sälja böcker, kurser och konsulttjänster. Lättviktsmetodernas brist av övergripande projektstyrning gör att man i allmänhet måste kombinera dem med traditionella metodiker. Det är svårt att generellt säga vilken LVM man ska använda, men en viktig faktor för valet utöver projektets storlek, är hur erfarna och självgående utvecklarna är. Ju mer lättviktig en metod är, desto större ansvar vilar på utvecklarna. Kunskap som inte återfinns i dokumentation, förutsätts finnas implicit hos utvecklarna. Det innebär att de måste kunna inta flera roller som t.ex. systemarkitekter, programmerare och testare. Över huvud taget ställs större krav på utvecklarnas erfarenhet och skicklighet. Upphovsmännen bakom LVM beskriver gärna sina metodiker i fina och svåra ord. Ofta relaterar man till matematiska och systemteoretiska termer vilket kan ge ett kvasivetenskapligt intryck. Det får som effekt att det kan vara svårt att urskilja de goda idéerna som trots allt finns, och att allt kan låta lite löjligt. 6. Referenser [1] Ron Jeffries et. al. Extreme Programming Installed Addison Wesley, 2001. [2] Mary Poppendieck Lean Programming Part 1 & 2 Software Development Magazine, 2001. [3] Crystal Main Foyer http://crystalmethodologies.org/ [4] Alistair Cockburn. Characterizing People as Non-linear, First-order Components in Software Development. http://crystalmethodologies.org/articles/panlc/ peopleasnonlinearcomponents.html [5] Alistair Cockburn. Just-in-time Methology Construction. http://crystalmethodologies.org/articles/jmc/ justintimemethodologyconstruction.html [6] Alistair Cockburn. A Methodology Per Project. http://crystalmethodologies.org/articles/mpp/ methodologyperproject.html [7] Alistair Cockburn. Software Development as a Cooperative Game. http://members.aol.com/humansandt/papers/asgame/asgame.htm 15

[8] Alistair Cockburn. Surviving Object-Oriented Projects (The Agile Series for Software Developers). Addison-Wesley Pub Co. 1997. [9] Alistair Cockburn. Crystal Clear: Human-Powered Methodology for Small Teams., Addison Wesley, 2002 (to appear). [10] Eric Steven Raymond. The Cathedral and the Bazaar. 2000. http://tuxedo.org/~esr/writings/cathedral-bazaar [11] Richard Stallman. The GNU Manifesto. 2000. http://www.fsf.org [12] The Open Source Definition. 2000. http://www.opensource.org [13] Jim Highsmith. Retiring Lifecycle Dinosaurs http://www.adaptivesd.com/articles/retiring%20lc%20dinosaurs.pdf [14] James A. Highsmith III. Adaptive Software Development: A Collaborative Approach to Managing Complex Systems. Dorset House Publishing, 2000. [15] Dirk Riehle. A Comparison of the Value Systems of Adaptive Software Development and Extreme Programming: How Methodologies May Learn from Each Other http://www.riehle.org/computer-science-research/2000/xp-2000.html [16] Mike Beedle et. al. SCRUM: An extension pattern language for hyperproductive software development http://www.controlchaos.com/scrum.pdf [17] SCRUM Software Development Process, Building The Best Possible Software. http://www.controlchaos.com [18] Coad, De Luca, Lefebrve. Java Modeling in Color with UML. Prentice Hall 1999. [19] Feature Driven Development and Extreme Programming. the "Coad Letter", July 2000. http://www.togethercommunity.com/coad-letter/ Coad-Letter-0070.html [20] Palmer, Felsing. A Practical Guide to Feature-Driven Development Prentice Hall 2002. [21] DSDM Consortium, Dynamic Systems Development Method http://www.dsdm.org/ [22] Andrew Hunt and David Thomas. Pragmatic Programmer. Addison Wesley 1999. [23] The Pragmatic Programmers http://www.pragmaticprogrammer.com [24] Martin Fowler and Jim Highsmith. The Agile Manifesto. August 2001. http://www.sdmagazine.com/documents/s=844/sdm0108a/0108a.htm [25] Manifesto for Agile Software Development http://agilemanifesto.org 16

[26] Rational Unified Process White Paper: Best Practices for Software Development Teams. http://www.dthomas.co.uk/downloads/ Rational%20Unified%20Process.pdf [27] Using Rational Unified Process for Small Projects: Expanding Upon extreme Programming http://www.rational.com/products/whitepapers/tp183.jsp [28] Barry Boehm. Get Ready for Agile Methods, With Care. IEEE Computer, (35)1, January 2002. [29] William R. Duncan. PMBOK A Guide to the Project Management Body of Knowledge. PMI Standards Committee. 1996. A. The Manifesto for Agile Software Development Seventeen anarchists agree: We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: Individuals and interactions over processes and tools. Working software over comprehensive documentation. Customer collaboration over contract negotiation. Responding to change over following a plan. That is, while we value the items on the right, we value the items on the left more. We follow the following principles: Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. Welcome changing requirements, even late in development. Agile processes harness change for the customer s competitive advantage. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. Business people and developers work together daily throughout the project. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. Working software is the primary measure of progress. Agile processes promote sustainable development. The sponsors, developers and users should be able to maintain a constant pace indefinitely. Continuous attention to technical excellence and good design enhances agility. 17

Simplicity the art of maximizing the amount of work not done is essential. The best architectures, requirements and designs emerge from selforganizing teams. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland, Dave Thomas www.agilealliance.org 18