Spårning av krav i agila projekt

Transkript

1 Spårning av krav i agila projekt Jonas Andersson D04, Lunds Tekniska Högskola d04jad@student.lth.se Jonas Andersson D04, Lunds Tekniska Högskola d04jan@student.lth.se Abstract Denna rapport behandlar ämnet spårning inom agila projekt, främst inom XP. Efter en genomgång av spårnings bakgrund tar vi upp motiveringar till spårning samt svårigheterna med det inom agila projekt. Vi provar ett självutvecklat verktyg för spårning på ett XP-team med sju medlemmar. Detta team plus ett annat som inte använt verktyget får sedan säga sin mening om spårning och behovet av det inom agila projekt.

2 Innehåll 1 Inledning 3 2 Bakgrund Problemen med XP Syfte Avgränsningar Ändringspåverkan 4 5 Kravspårning Vad avses med spårning av krav? Utbredning av kravspårning Befintliga möjligheter till kravspårning i agila metoder Möjliga problemområden Metod Verktygen XPlanner Eclipse Relaterat arbete 11 8 Resultat Frågeformulär Försöksgruppen Andra gruppen Användning av verktyget Användning per användare Användning per iteration Användning per funktion Diskussion Administrativt arbete Refaktoriseringar Slutsats Framåtblickar 16 A Frågeformulär till försöksgruppen som använt verktyget 18 B Frågeformulär till de som ej använt vårt verktyg 18

3 1 Inledning Den här djupstudien är gjord vid Lunds Tekniska Högskola under kursen EDA Coaching av programvaruteam. Studien behandlar spårning mellan kod och krav inom den agila utvecklingsmetodiken extreme Programming (XP). Detta är ett område som flera pionjärer inom XP helst inte pratar om, men som kanske är en nödvändighet för att metodiken ska kunna få fotfäste inom industrin. I studien har vi utvecklat ett verktyg för automatisk spårning genom att samköra information från programmen Eclipse och XPlanner. Detta verktyg prövas sedan på ett utvecklingsteam i kursen EDA Programvaruutveckling i grupp. Reflektioner om spårning tas även in från en grupp som inte har använt sig av verktyget. Efter detta så utvärderas verktyget och behovet av spårning inom ett XP-team. 2 Bakgrund Spårning av krav är något som återfinns i fler och fler standarder och praktiker för utveckling av mjukvara. Det har skett mycket forskning på området som har tagit praktiken framåt, men spårning av krav är fortfarande något som anses vara mycket problematiskt.(1) Inom agila metoder har man uppmärksammat problemet med att kraven förändras under arbetets gång. Kunden vet inte vad denne egentligen vill ha för produkt, den ändrar sig under arbetets gång och motsäger sig själv. Klassiska metoder som t.ex. vattenfalls-modellen försöker förutse och planera så mycket som möjligt, medan de agila metoderna istället koncentrerar sig på att anpassa utvecklingen för förändring. För att detta ska vara möjligt har man lämnat de klassiska kraven och använder istället stories som är mindre formella beskrivningar av kundens önskemål. Man kan se dessa som en liten del av ett användingsfall som skall vara affärs-orienterat, testbart och estimerbart.(2) 2.1 Problemen med XP I Essential XP: Documentation skriver Jeffries: XP is designed to use face to face human communication in place of written documentation wherever possible.... It is common for XP teams to have some pictures of the system s design on the wall for extended periods. I observe that these seem to serve more as decoration than as documentation: people don t look at them very often. They ask each other, or they pair program with someone who knows the answer. (3) En anledning till att XP ännu inte används i någon större utsträckning i industrin ligger förmodligen i bristen på dokumentation och design: XP s de-emphasis of design documentation is a concern in many environments, such as hard real-time systems, large systems, or virtual teams. In such environments, good designs are crucial to success, and using the refactoring strategy would be high-risk. (4) 3

4 Design och dokumentation är alltså nödvändig i större projekt, med kritiska system eller när utvecklarna inte har samma geografiska placering. Det är en nödvändighet för att dels kunna förstå kod som man inte tidigare känner till och dels för att kunna göra korrekta bedömningar av en ändrings påverkan på resten av systemet. 3 Syfte Vårt syfte med denna djupstudie är att utveckla och utvärdera ett verktyg för att hantera spårning av krav i agila projekt. Vi vill undersöka om det är möjligt att koppla samman befintliga tekniker för att skapa en effektiv och enkel spårning mellan story och kod i båda riktningarna. Vi vill också undersöka om denna funktionalitet kommer till nytta i ett XP-projekt och om den kan användas för att få en överblick och förståelse för hur koden fungerar samt om den kan användas i samband med bedömningar av effekten av en eventuell ändring. 3.1 Avgränsningar Vi kommer i denna rapport inte att behandla den del av kravspårning som handlar om kravens uppkomst, utan endast att fokusera på länken mellan ett krav och dess implementation. Undersökningen kommer bara att göras för ett litet system med ett litet XPteam (sju utvecklare). Projektet syftar till nyutveckling och det är alltså inget befintligt system som kommer att vidareutvecklas. Ingen beskrivning av verktygen XPlanner, Eclipse samt CVS kommer ges i den här rapporten. Dessa är allmänt använda verktyg och vi anser att de flesta vet hur de fungerar. För mer information om XPlanner se 4 Ändringspåverkan Embrace change är Becks slagord (2) för att föra fram XP. Men i större projekt kan förändringar leda till stora komplikationer om man inte först gör en uppskattning av ändringens påverkan. Impact analysis definieras av Arnold och Bohner (5) som: identifying the potential consequences of a change, or estimating what needs to be modified to accomplish a change. Att ändra mjukvara utan att först ha bedömt ändringens påverkan på systemet kan enligt Arnold och Bohner bidra till bland annat Dåliga tidsuppskattningar Förseningar av releaser Försämrad mjukvarudesign Opålitlig mjukvara 4

5 Om man gör en ändring på ett ställe måste man också uppdatera all kod som har beroenden till den ändrade koden. Dessa beroenden kan härledas genom två tekniker; beroendeanalys och spårningsanalys. Beroendeanalys görs genom att låta ett verktyg söka igenom hela koden för att hitta alla vägar till det aktuella avsnittet och på så sätt ge en bild av vilka beroenden som finns. Spårningsanalys går i stället ut på att kunna spåra koden till andra artefakter (design, krav m.m.) som hör till implementationen, t.ex. genom kravspårning (5). I vår studie behandlas endast spårningsanalys. Att analysera en ändrings påverkan på systemet blir mer komplext ju större och mer komplexa projekten är. När ett projekt uppnår en viss storlek bildas en gräns mellan projektledare, kravhanterare och utvecklare som gör att helhetsbilden försvinner. De som har kunskap om kraven och visionerna har ingen insyn i designen och implementationen och vice versa. När utvecklarna får i uppgift att göra en förändring är det därför högst sannolikt att utvecklaren inte har insyn i vilka krav som föreligger för koden och de som tar beslut om ändringen har ingen insyn i vilka följder den kan få för övriga krav i systemet. Detta gör att den vanligaste orsaken till att mjukvaruprojekt misslyckas är en ineffektiv ändringshantering. (6) 5 Kravspårning 5.1 Vad avses med spårning av krav? Gotel och Finkelstein (1) definierar spårning av krav på följande vis (förkortningen RS syftar på Requirements Specification): Requirements traceability refers to the ability to describe and follow the life of a requirement, in both a forwards and backwards direction. Pre-RS traceability refers to those aspects of a requirement s life prior to inclusion in the RS. Post-RS traceability refers to those aspects of a requirement s life that result from inclusion in the RS. Som nämndes i syftet (se stycke 3) kommer vi endast att behandla Post-RS, alltså spårningen från krav till kod och tillbaka. Vi behandlar inte alls det som Gotel och Finkelstein kallar Pre-RS. 5.2 Utbredning av kravspårning Kravspårning i mjukvarusystem är i dag relativt ovanligt och bara vanligt inom industrier som kräver hög säkerhet, t.ex. livskritiska system inom medicin, flyg och kärnkraft. Då system blir större och mer komplexa försvåras också arbetet med att underhålla kravspårningen. (7) Inom de agila metoderna är kravspårning förstås ännu ovanligare och arbetet med att hålla denna typ av information aktuell gör ofta att man helt väljer bort spårningen: We don t think it s worth trying to trace requirements to classes in the system that implement the requirement. That s too much paperwork. 5

6 Even if you have a tool, it s still too much effort to keep all the information consistent. (8) Keeping traceability and design documents up to date is very expensive and unreliable (particularly given the weakness of humans with regard to consistency). In most projects, it is not long before the documentation doesn t match the code. If keeping the two in sync were essential, project teams would not be able to continue through the maintenance phase. (9) XP används oftast i mindre projekt där bristen på ordentlig dokumentation och spårning kan överkommas genom att gruppen diskuterar och frågar varandra för att reda ut eventuella oklarheter. Vill man applicera metodiken på större projekt där utvecklare exempelvis kan sitta i olika länder med tidsskillnad är detta dock inte möjligt. Även med dagens möjlighet till kommunikation blir det inte effektivt. (7) En viktig del inom XP och agila metoder är aspekten att förändring är en naturlig del av processen. Eberlein et al (10) anser att detta är en viktig del i den typen av processer. Men lägger vikt vid att det inte finns någon riktig kravhantering i dessa processer. Att ha hantering av krav och ändringar ses som en grundläggande praktik inom mjukvaruutveckling. The CMM model states explicitly that an organization can only be considered level 2 if it has implemented the key area of requirements management. (10) CMM-modellen som nämns ovan är Capability Maturity Model som är en modell för att utvärdera och certifiera mognadsgraden hos mjukvaruorganisationer. Den går från nivå ett (lägst) till nivå fem (högst). Eberlein et al menar att de agila metoderna inte har råd att inte ha kravhantering och kravspårning. XP använder sig av stories men de används inte som en baseline för kravhantering. Det är inte tillräckligt för de agila metodikerna att förlita sig på konfigurationshantering på kodnivå. Metoder för kravhantering behöver anpassas för agila metoder för att ge en möjlighet till spårning mellan kundens intentioner och den faktiska implementationen.(10) 5.3 Befintliga möjligheter till kravspårning i agila metoder Bendix et al (11) menar att mycket av kravdelen inom konfigurationshantering fungerar om man följer XP-metodiken. Förändringshantering och förändringskontrollgrupper kan liknas vid när stories inom XP diskuteras, prioriteras, planeras och bestäms under det som kallas The Planning Game. Spårning av källkod till story, och på andra hållet, täcks dock inte av XP i sig. Om ett versionshanteringsvertyg används kan man enkelt i sina commit-comments ange vilken story som den versionen tillhör. Detta hjälper dock bara spårning från kod till story, men inte på andra hållet. Trace changes to stories: Definition: Each change set, typically each commit, should be traceable to the story and task it implements. Motivation: It further emphasizes the by XP proposed work model to implement only one specific task at a time. 6

7 Supports: Continuous Integration, Collective Code Ownership. Requires: Use version control tool including functionality to manage meta-data, e.g. commit comments. (11) 5.4 Möjliga problemområden Att manuellt dokumentera spårning eller att använda krångliga verktyg går emot XP:s agila metoder. Även om dokumenteringen kan vara värd mycket är det svårt att motivera utvecklarna att faktiskt göra den, och göra den ordentligt. Det kan ofta krävas omfattande arbete och uppdatering av information, beroenden, manualer och liknande. Frågan blir inte bara längre om det är värt att utföra dokumentationen, utan även om den kommer göras ordentligt. Ett verktyg för spårning måste därför var enkelt att använda, och inte ivägen för utvecklarna. (10) In large agile projects, where traceability would be more beneficial, the task becomes increasingly difficult, and team members are often very reluctant to participate in the effort (10) Vid utveckling där all ändring i källkoden måste kopplas till en speciell story eller task möjliggörs spårning mellan dessa. Om man ser till så att ingen kod kan ändras utan att ange en relaterad task så uppstår risken att utvecklare till slut bara anger vilken task som helst. Då blir spårningen mycket mindre användbar. XP och andra agila metoder kräver att man tillåter aktiviteter såsom refaktorisering. Men om det hela sköts på ett bra sätt kan denna typ av utveckling ge många fördelar. (12) 6 Metod För att möjliggöra enkel spårning mellan stories och kod användes verktyget XPlanner, ett verktyg för planering och uppföljning, kombinerat med information från konfigurationshanteringssystemet CVS. Detta gjordes genom att användarna i XPlanner registrerade när de började arbeta med en story samt när de blev klara. Dessa tider jämförs sedan med samma användares commits i CVS-repositoryt. Resultatet av detta blev att vi från en given story eller task kunde ta fram kod som tillhörde denna, eller omvänt ta fram den eller de stories som hörde till ett stycke kod. För att automatisera denna process tog vi fram ett verktyg som gjorde det möjligt att i eclipse markera kod och sedan få en lista på vilka stories och task som koden hörde till. På varje story och task i XPlanner lades även till en länk som visar vilken kod som hörde till storyn. Detta verktyg provades sedan på en utvecklingsgrupp som gick kursen EDA260 - Programvaruutveckling i grupp under läsperiod ett våren Denna grupp informerades om och utbildades på verktyget. De uppmanades sedan till att använda det när behovet uppstod, exempelvis inför större refaktoriseringar. Enkelheten av verktyget gjorde att det inte var i vägen för utvecklarna och störde inte deras vanliga arbete. 7

8 Programming is a highly creative activity that requires full concentration by the developer; a concentration that may be disrupted by SCM operations. (13) All användning av verktyget loggades vilket gjorde att vi kunde sammanställa och analysera denna data. Detta gav oss möjlighet att se hur ofta det användes, om det var allmänt använt eller endast vissa personer som använde det samt om det fanns tider då användandet var mer intensivt. Vid studiens slut skickades frågeformulär ut till den grupp som använt verktyget, samt till ytterligare en grupp som inte använt verktyget. Detta formulär syftade till att ta reda på följande två huvudpunkter. Var verktyget till någon nytta för försöksgruppen? Hade verktyget underlättat arbetet hos gruppen som inte använde det. Från formuläret inkom även feedback om verktyget och förslag på eventuella förbättringar. Frågeformulären som skickades ut visas i appendix A och B. 6.1 Verktygen I detta stycke beskrivs hur verktygen fungerar samt hur de ändringar vi gjort ser ut rent grafiskt. De olika program som det ändrats i är enligt tidigare XPlanner samt Eclipse XPlanner Figur 1: XPlanner med den tillagda knappen Show Code 8

9 Figur 2: Visad kod efter att knappen Show Code tryckts Den enda skillnaden mot XPlanners vanliga funktionalitet är knappen Show Code som lades till under story- och tasksidorna. Knappen i XPlanner visas i figur 1. När denna knapp trycktes ned öppnades ett nytt fönster av webbläsaren, och den kod som producerats i samband med vald story/task visades. Samtlig kod i varje editerad klass visades, men den kod som ej hade ändrats var markerad med mörk bakgrund. Detta gav en bättre översikt än om det endast visats varje commitad rad av kod för sig. Ett exempel på hur det kunde se ut visas i figur 2. 9

10 6.1.2 Eclipse Figur 3: Eclipse med tillagt menyalternativ Find Story Till Eclipse hade vi utvecklat ett plugin som var lika enkelt att använda som knappen i XPlanner. Pluginet gjorde det möjligt att i en klass markera ett stycke kod sen högerklicka och i den menyn välja ett nytt alternativ kallat Find Story, se figur 3. När detta alternativ valts öppnades ett webbläsarfönster i vilken varje story och task som arbetats med i samband med den markerade koden visades. Stora kodstycken resulterade ofta i en lång lista med stories och tasks som hade behandlat koden. Detta eftersom koden i XP ändras mycket och ofta. Ville man veta mer specifikt vilken story en enkel rad kod tillhörde gick det också bra att endast markera den. Utseendet på det visade fönstret visas i figur 4. 10

11 Figur 4: Visad kod efter att knappen Find Story tryckts 7 Relaterat arbete Vid Depaul University, Chicago, IL, har en studie av liknande slag genomförts av Christopher Lee och Luigi Guadagno i ett projekt kallat FLUID: Echo (7). De utvecklar ett verktyg som sköter spårning genom att spara alla ändringar och alla diskussioner om krav och andra dokument. By providing a means to gather requirements in an informal manner and later restructure the information to suit formal requirements specifications, FLUID: Echo hopes to alleviate many of the pains in requirements engineering. FLUID: Echo also attempts to address issues in traceability management, by including conversations about requirements in the information model. (7) I FLUID: Echo tas även upp hur stories skapas och hur de utvecklas genom konversationer. De arbetar alltså även på den nivå som Gotel och Finkelstein (1) kallar Pre-RS. De talar i studien om hur utvecklare ofta använde sig av källkod som sin främsta informationskälla. Detta eftersom den alltid var av sin egen senaste version. Dokumentation däremot ansågs oftast som abstrakt och utdaterad. Som slutsats drar dom att spårning är positivt för mjukvaruutveckling, men på grund av sin svårighet och komplexitet så genomförs det sällan. En modell som är enkel att använda och inte stör utvecklingen skulle kunna göra så att spårning görs oftare. 8 Resultat 8.1 Frågeformulär De svar som kom in från frågeformulären visas nedan Försöksgruppen Av sju stycken utvecklare svarade fem stycken på frågorna. Svaren följer nedan. 11

12 Fråga 1: Har ni använt verktyget? De flesta har endast använt verktyget ett fåtal gånger. Några endast vid installationen för att testa det. Fråga 2: Har det varit till någon hjälp? De flesta har inte sett någon nytta i verktyget. En person anger att det varit till nytta för att reda ut oklarheter med vem som har skrivit vad. Fråga 3: Hur hade ni gjort om ni velat spåra kod till story, eller tvärtom, om ni inte haft tillgång till verktyget? De flesta föreslår att helt enkelt fråga sina medarbetare. Detta är möjligt då alla sitter nära varandra. Det nämns dock svårigheter såsom att ens medarbetare kan vara upptagna med annat och inte ha tid. Andra förslag är att själv försöka lista ut till vilken story en kodbit hör till genom att köra programmet och se när koden körs. Fråga 4: Hade det tagit längre eller kortare tid att spåra kod till story/task utan verktyget? Flertalet av svaren anser att verktyget är snabbare än att söka manuellt. Åsikter om att behov av att få förklaring av eventuella bitar kod som berörs kommer även fram. Detta ger ju inte verktyget så i liknande fall kan den manuella versionen vara bra. Fråga 5: Har ni fått tillräcklig utbildning på verktyget? Ja på alla svaren. Fråga 6: Var verktyget lätt att använda? Ja på alla svaren. Fråga 7: Var det något som ni önskar vore annorlunda med verktyget? Enda saken som kommer upp här är önskan om att det skulle fungera med Eclipse 3.2. Fråga 8: Spårning mellan kod och krav genomförs i regel inte inom XP eftersom det inte anses vara värt mödan. Hur tycker ni att ett verktyg som ger automatisk spårning kan hjälpa under ett XP-projekt? De flesta tror att sådana verktyg hade varit bra vid större projekt. Men vissa ser även nyttan inom små XP-projekt. Det är ju ofta man inom XP hittar kod som man inte vet exakt vad den gör. Om man då enkelt kan få en lista på berörda stories kan man få en uppfattning om vad det hela handlar om. Fråga 9: Spårning används bland annat för att kunna bevisa för kunden att en viss story är implementerad. Hur tror ni att detta fungerar i ett XP-projekt? Många tycker det känns onödigt att bevisa implementation genom att visa koden för kunden. De som svarat detta tycker istället att man kan visa att programmet i sig uppfyller kraven i storyn. En annan åsikt är att det är acceptanstesterna som bevisar funktionaliteten. Fråga 10: Tror ni att det finns en större nytta av verktyget i större projekt 12

13 med fler utvecklare och större kodbas? Alla svar är eniga om att det kan vara nyttigt i större projekt. Någon lägger dessutom stor vikt vid att skriva lättbegriplig kod men inser även att det är svårt att skriva så att alla förstår Andra gruppen Av åtta stycken utvecklare svarade sex stycken på frågorna. Svaren följer nedan. Fråga 1: Har ni någon gång upplevt att ni velat veta vilken story eller task som en bit kod hörde till? Här finns både ja- och nej-svar. Önskemål om att kunna hitta beroenden mellan kod och stories som är under utveckling kom även fram. Fråga 2: Har ni någon gång upplevt att ni velat veta vilken kod som producerats till en viss story eller task? De flesta svarar nej på den här frågan. Men vissa svar tyder på att om möjligheten att göra det funnits, så hade de använt den. Fråga 3: Om någon av föregående två frågor inträffat: Lyckades ni ta reda på det? Alla som svarar här har angett att de lyckats lösa problemet. Fråga 4: Hur gjorde ni/skulle ni göra för att spåra kod till story? De som svarat här anger att de lyckats lösa det genom att vända sig om och fråga gruppen. Andra alternativ var att kontrollera commit -loggen i CVS. Fråga 5: Hade ett verktyg som automatiskt spårar kod till story/task varit till någon hjälp för er? De flesta svarar med ett tveksamt ja. Behovet av det har inte upplevts under projektet. Några anser att det räcker med att fråga teamet. Fråga 6: Spårning mellan kod och krav genomförs i regel inte inom XP eftersom det inte anses vara värt mödan. Hur tycker ni att ett verktyg som ger automatisk spårning kan hjälpa under ett XP-projekt? Åsikten att det inte behövs i ett XP-projekt är gemensam i alla svar. De anger dock vissa saker som det kan användas till. Exempelvis under spike-tid när man inte har andra team-medlemmar nära och kan fråga. Även vid ändring i gammal kod anses det kunna hjälpa att förstå vad som görs. Fråga 7: Spårning används bland annat för att kunna bevisa för kunden att en viss story är implementerad. Hur tror ni att detta fungerar i ett XP-projekt? Acceptanstester framkommer även här som en lösning. Ett annat förslag är att låta kunden sköta trackingen och på så sätt se hur varje story blir implementerad. Även att visa kunden den färdigimplementerade funktionen i programmet tas upp. Fråga 8: Tror ni att det finns en större nytta av verktyget i större projekt med fler utvecklare och större kodbas? 13

14 Många svarar lite osäkert på den här frågan. En är väldigt positiv då det i stora projekt finns många klasser och det blir lättare att se vilka beroenden som finns mellan en story och klasserna. En är negativ och anser att verktyget skulle ta fokus från de mer viktiga delteknikerna i XP. Det är lite farligt att ha ett sådant verktyg då det till stor del kan utnyttjas för att smutskasta utvecklare. 8.2 Användning av verktyget Verktyget användes under fyra iterationer och fick totalt 34 anrop/förfrågningar Användning per användare Användandet avser inloggad användare. Den utvecklare i paret som inte var inloggad när anropet gjordes finns ej med i statistiken. Användare Antal anrop A 4 B 4 C 10 D 13 E 3 F 0 G Användning per iteration Verktyget introducerades först under iteration två. Iteration Antal anrop Användning per funktion Funktionen Story till kod innebär att användaren i XPlanner klickat på knappen Show code för en task eller story (figur 1). Kod till story innebär att användaren markerat ett stycke kod i Eclipse och valt Find story (figur 3). Funktion Antal anrop Story till kod 11 Kod till story 23 9 Diskussion Som vi kan se av resultatet så var användningen och nyttan av verktyget låg under detta projekt. Det stora antalet användningar under första iterationen beror sannolikt främst på att verktyget var nytt och att utvecklarna ville testa om det fungerade. 14

15 Verktyget har vid några tillfällen använts för att ta reda på vem som skrivit en viss kod. Denna funktionalitet erbjuds redan av de flesta verktyg för konfigurationshantering genom funktionen annotate. Denna typ av användning var inte syftet med verktyget. Om utvecklarna skulle hamna i en situation där de skulle behöva den typ av spårning som verktyget erbjuder så skulle verktyget enligt svaren göra detta på snabbaste sätt. Alternativet är att fråga de andra i teamet och eftersom de sitter precis bredvid så har man direkt möjlighet att kunna diskutera koden och vad den är till för, vilket är en fördel gentemot att använda verktyget. Detta är något som Lee et al (7) också tar upp (se stycke 5.2). De menar att behovet uppstår först när projektet blir större och utvecklarna inte sitter nära varandra. Även Jeffries (3) anser att kommunikation mellan utvecklarna används då man vill ha information om något (se stycke 2.1). Det mesta pekar alltså på att verktyget inte gör någon nytta i den storlek på projekt som vi har utvärderat verktyget i och den storlek på projekt som Beck m.fl. avser när de pratar om XP (ca 10 personer). Det intressanta ligger snarare i hur nyttan skulle se ut i större projekt, där utvecklarna är fler och därför inte sitter i samma rum eller ens i samma land. XP har inte någon större utbredning i denna storlek på projekt, sannolikt för att informationen finns hos utvecklarna och inte är dokumenterad. Vi, och större delen av de som tillfrågats i formulären, tror att nyttan av verktyget skulle vara större i ett större projekt. Kanske kan metodiken även bli intressant för säkerhetskritiska system (se stycke 2.1 och 5.2) om man kan erbjuda möjlighet till kravspårning. På svaren från frågeformulären verkar det som att vår försöksgrupp var mer positivt inställd till spårning än den andra gruppen. Båda två har genomgått ett XP-projekt med mål att utveckla precis samma program, och därmed borde båda grupperna upplevt behovet av spårning på samma sätt. Vår försöksgrupp har dock blivit mer medvetna om fenomenet spårning i sig och har därmed kunnat fundera mer över hur det påverkar en större process. Den andra gruppen fick frågorna utan att ha varit medveten om möjligheten och behovet av spårning. Detta kan förklara varför de inte är lika positivt inställda mot spårning inom XP. 9.1 Administrativt arbete Anledningen till att man idag inte har något stöd för spårning mellan krav och kod i agila metoder är enligt Beck, Fowler (8) och Cockburn (9) att det är för mycket pappersarbete (se stycke 5.2). De anser att det är för jobbigt även om man har ett verktyg. Eberlein et al (10) och Cowham (12) har också tagit upp problem som kan uppkomma om det administrativa arbetet blir för jobbigt (se 5.4). Detta är något som vi inte har upplevt under projektet och tanken med verktyget var att det inte skulle ge för mycket merarbete. Det enda som krävs för att hålla spårningen fungerande är att utvecklarna anger när de börjar och när de slutar jobba med en story, vilket på samma gång ger oss möjlighet till tracking genom XPlanner. 15

16 9.2 Refaktoriseringar Det som ställer till det för verktyget är refaktoriseringar. Refaktoriseringar är en naturlig del av XP och utvecklarna måste tillåtas att fritt göra refaktoriseringar. Vårt verktyg är i dag inte speciellt robust och det räcker att man gör ändringar av whitespace på en rad för att raden ska associeras med en ny ändring. Detta skulle enkelt kunna lösas genom att verktyget bortser från denna typ av ändringar. Värre blir det om man verkligen designar om koden, bryter ut kod i metoder och skapar nya klasser. Om refaktoriseringen görs då man inte är inloggad i XPlanner kan verktyget dra slutsatsen att ändringen hör till en refaktorisering. Om refaktoriseringen innebär att man ändrat på en rad skulle verktyget kunna undersöka en tidigare version och se om den tidigare versionen kan associeras med en story/task. Om spårningen ändå inte kan göras kan verktyget titta på den kod som ligger före och efter en refaktorisering för att avgöra vilken story/task den hör till. 10 Slutsats Av vår studie kan vi dra slutsatsen att kravspårning inte gör någon nytta i XPprojekt med ca 10 personer, eftersom man istället kommunicerar med resten av teamet för att få information. Utifrån våra källor har vi kunnat dra slutsatsen att agila metoder inte används i större eller säkerhetskritiska projekt p.g.a. bristande dokumentation och dålig ändringshantering. Verktyget kan sannolikt ha ett större värde i denna typ av projekt och kan vara en av de delar som behövs för att göra agila metoder intressanta för stora och säkerhetskritiska projekt. För att verktyget ska bli användbart behöver stödet för refaktoriseringar utvidgats så att spårningen blir mer robust. 11 Framåtblickar Det finns mycket som talar för att möjliggöra spårning inom XP och agila metodiker. När detta steg är övervunnit kanske dessa utvecklingsmetoder kan slå igenom även på större skala. Men inom de projekt som kräver hård toppstyrning med exakt vad som får ändras, samt hur det ska ändras, kommer det ta lång tid innan utvecklingsprocessen ändras. 16

17 Referenser [1] Orlena Gotel, Anthony Finkelstein: An analysis of the requirements traceability problem, Requirements Engineering, 1994., Proceedings of the First International Conference on, [2] Kent Beck: Embracing change with extreme programming, Computer, nummer 10, Oct [3] Ron Jeffries: Essential XP: Documentation, XP Magazine, [4] Mark C. Paulk: Extreme Programming from a CMM Perspective, IEEE SOFT- WARE, November/December, [5] Robert S. Arnold: Software Change Impact Analysis, IEEE Computer Society Press, [6] Krzysztof Kowalczykiewicz, Dawid Weiss: Traceability: Taming uncontrolled change in software development, Poznan University of Technology, [7] Christopher Lee, Luigi Guadagno: FLUID: Echo - Agile Requirements Authoring and Traceability, Lehrstuhl für Angewandte Softwaretechnik, [8] Kent Beck, Martin Fowler: Planning Extreme Programming, Addison Wesley, [9] Alistair Cockburn: Agile Software Development, Addison-Wesley, [10] Armin Eberlein, Julio Cesar Sampaio do Prado Leite: Agile Requirements Definition: A View from Requirements Engineering, International Workshop on Time-Constrained Requirements Engineering, [11] Ulf Asklund, Lars Bendix, Torbjörn Ekman: Software Configuration Management Practices for extreme Programming Teams, Department of Computer Science, Lund Institute of Technology. [12] Robert Cowham: Requirements Based Development- Yes Please! (But How?!), [13] Henrik B. Christensen: Tracking Change in Rapid and extreme Development: A Challenge to SCM-tools?, Centre for Experimental Computer Science, University of Aarhus. 17

18 A Frågeformulär till försöksgruppen som använt verktyget 1. Har ni använt verktyget? 2. Har det varit till någon hjälp? 3. Hur hade ni gjort om ni velat spåra kod till story, eller tvärtom, om ni inte haft tillgång till verktyget? 4. Hade det tagit längre eller kortare tid att spåra kod till story/task utan verktyget? 5. Har ni fått tillräcklig utbildning på verktyget? 6. Var verktyget lätt att använda? 7. Var det något som ni önskar vore annorlunda med verktyget? 8. Spårning mellan kod och krav genomförs i regel inte inom XP eftersom det inte anses vara värt mödan. Hur tycker ni att ett verktyg som ger automatisk spårning kan hjälpa under ett XP-projekt? 9. Spårning används bland annat för att kunna bevisa för kunden att en viss story är implementerad. Hur tror ni att detta fungerar i ett XP-projekt? 10. Tror ni att det finns en större nytta av verktyget i större projekt med fler utvecklare och större kodbas? B Frågeformulär till de som ej använt vårt verktyg 1. Har ni någon gång upplevt att ni velat veta vilken story eller task som en bit kod hörde till? 2. Har ni någon gång upplevt att ni velat veta vilken kod som producerats till en viss story eller task? 3. Om någon av föregående två frågor inträffat: Lyckades ni ta reda på det? 4. Hur gjorde ni/skulle ni göra för att spåra kod till story? 5. Hade ett verktyg som automatiskt spårar kod till story/task varit till någon hjälp för er? 6. Spårning mellan kod och krav genomförs i regel inte inom XP eftersom det inte anses vara värt mödan. Hur tycker ni att ett verktyg som ger automatisk spårning kan hjälpa under ett XP-projekt? 7. Spårning används bland annat för att kunna bevisa för kunden att en viss story är implementerad. Hur tror ni att detta fungerar i ett XP-projekt? 8. Tror ni att det finns en större nytta av verktyget i större projekt med fler utvecklare och större kodbas? 18