Issue- och Bug Trackers i X P-projekt

Transkript

1 Issue- och Bug Trackers i X P-projekt Snild Dolkow (dt06sd2@student.lth.se) Jon Sturk (dt06js3@student.lth.se) 24 februari 2009

2 A bst ract Denna djupstudie syftar till att undersöka nyttan av issue- och bug trackers i små programvaruprojekt som använder X P-metodiken. Det ta undersöktes genom att ge utvecklarna i ett litet X P-projekt möjligheten att använda Bugzilla. U tvecklarna fick sedan utvärdera Bugzilla med utgång i deras erfarenheter från projektet.

3 1 Inledning Denna djupstudie syftar till att undersöka nyttan av issue- och bug trackers i små programvaruprojekt. Studien behandlar issue / bug tracking med Bugzilla. Studien utfördes under P V G-projektet 1 på LT H, där denna studies författare var coacher för en grupp som utvecklade programvara för at t registrera tider och framställa resultat för olika sorters E nduro-tävlingar. Tanken var at t Bugzilla skulle användas kontinuerligt under projektets gång för att hålla reda på stories och upptäckta problem. Detta skulle hjälpa utvecklarna, kunden och coacherna at t få en bät tre överblick över hur utvecklingen framskrider. Som uppföljning fick utvecklarna fylla i ett formulär med frågor om hur de upplevt användningen av Bugzilla i projektet. Även projektets kund fick fylla i ett formulär. Studien indikerar at t användningen av Bugzilla passar dåligt i et t projekt av samma typ som Enduro-projektet. På grund av det dåliga underlaget är det dock inte möjligt att dra några konkreta slutsatser. Y tterligare studier i ämnet vore önskvärda. 2 B akgrund I ett projekt med många utvecklare finns ett behov av uppföljning av projektets utveckling och allmänna kodkvalitet. T ill en viss del går detta att åstadkomma med t.ex. wiki och vanliga (versionshanterade) textfiler. Det kan dock anses att det finns fördelar med att använda någon typ av automatiserat system för tracking. E t t issue / bug tracking-system ger utvecklare möjlighet at t diskutera, organisera och söka efter issues/ buggar. De har en databas av issues och ett grafiskt, ofta webbaserat, gränssnit t. Buggar och utökade krav kan läggas in i systemet efterhand. V issa trackers kan integreras med versionshanteringssystem som C VS och SV N. Dessa kan t.ex. göra det lättare att avgöra en applikations mognad[2] eller hjälpa teamet at t identifiera indirekta samband mellan olika delar av programmet[1]. Det finns ett stort antal verktyg för detta ändamål, med olika fördelar och nackdelar[3]. I denna rapport valdes Bugzilla, helt enkelt för at t förfat tarna kände till namnet sen tidigare. Bugzilla är dessutom väl ansedd och används i flera stora projekt, t.ex. Linux-kärnan och E clipse. P V G-projektet utförs i grupper på mellan åt ta och tolv utvecklare, två coacher och en kund. G ruppen arbetar enligt E xtreme Programming, X P. Varje iteration består av ett planeringsmöte i mitten av veckan samt en utvecklingsperiod 8:00-17:00 varje måndag under sex veckor. V idden av funktionalitet i projektet förändras ganska kraftigt under projektets gång när helt nya funktionalitetskrav dyker upp. Det ta kan ställas i kontrast till et t riktigt X P-projekt, där man får förmoda att man i alla fall har någon aning om vilken funktionalitet som kommer at t efterfrågas inom den närmsta framtiden. Därför kan det i P V G-projektet vara extra viktigt att kunna hålla reda på förändringar av önskad funktionalitet. 1 E D A 260, Programvaruut veckling i grupp E n kurs i X P-metodik för andraårsstudenter på civilingenjörsprogrammet, främst datateknik. 3

4 3 Inledande problem E tt antal problem stöttes på i början av projektet. Bugzilla installerades på Snilds hemdator. Därmed var den bara säkert tillgänglig under långlabbarna och, från iteration 3, även inför planeringsmötet på torsdagar. Det uppstod också problem med registrering av nya användare i systemet. När en ny användare registrerar sig på Bugzilla ska det skickas ut ett mail till dennes mailadress med et t automatiskt genererat lösenord. Dessa utskick fungerande inte som de skulle. Det ta innebar problem för nya användare, som behövde de utskickade lösenorden för at t kunna logga in. Därmed kunde P V G-teamet inte bekanta sig med Bugzilla inför första iterationen. 4 A nvändning 4.1 I tera t ion 1 Det var nyt t at t jobba enligt X P-metodiken, vilket gjorde stämningen småt t kaotisk. Det ta, i kombination med de tidigare nämnda problemen (avsnit t 3), bidrog till en låg användningsgrad under iteration 1. Alla stories hade lagts upp på Bugzillan i förväg, men färdiga stories markerades inte där och inga kommentarer skrevs in. F ärdiga stories markerades istället på en tavla i salen. De stories som slutfördes markerades som klara först senare i veckan, och då av teamets coacher. 4.2 I tera t ion 2 Även under den andra iterationen var användandet av Bugzilla lågt. E ftersom det fortfarande var relativt få stories föredrog teamet att använda tavlan för att hålla reda på vilka stories som var klara. Mycket tid gick åt för att få release 1 att fungera. Många av utvecklarna verkade stressade, vilket kan vara en orsak till att försöken att få utvecklarna at t använda Bugzillan möt tes av ointresse. 4.3 I tera t ion 3 Under iteration 3 visade sig Bugzilla-servern vara mer användbar. U tvecklarnas användande av denna var fortfarande lågt, även om vissa började visa et t visst intresse. Då det fanns flera stories kvar från iteration 2 visade det sig att Bugzilla hjälpte coacherna at t få en översiktsbild av projektet. Coacherna kunde därför avgöra vilka stories som var lämpliga at t arbeta på vid olika tidpunkter. Under iteration 3 markerades stories som klara parallellt på Bugzilla-servern och tavlan. 4

5 5 E nkä t till u t vecklarna 5.1 M otiva tion Fråga 1-3 ställdes för at t kunna identifiera utvecklarnas eventuella tidigare erfarenheter av issue / bug trackers. Resonemanget var at t tidigare erfarenhet kanske kunde ha ett samband med hur benägen en utvecklare var att använda Bugzillan i E nduro-projektet. U töver det skulle en utvecklare som uppskat tat Bugzilla i andra projekt men som inte använt Bugzilla i E nduro-projektet kunna indikera att issue / bug trackers inte är lika nyttig i X P-projekt. Fråga 4, 5 och 6 handlar om utvecklarnas upplevelse av Bugzilla under E nduro-projektet. Har de editerat i Bugzilla eller bara läst? Vad tyckte de? I fråga 7 och 8 var det tänkt att utvecklarna skulle få resonera fritt kring hur issue / bug trackers kan passa in i olika projektformer, och X P-projekt i synnerhet. 5.2 Svar Frågorna skickades ut på teamets mailinglista efter iteration Fr åga 1 Fråga: Har du använt Bugzilla förr? Se figur 1. F igur 1: Svar på fråga Fr åga 2 Fråga: Har du använt någon issue /bug tracker förr? V ilken? Fyra av tolv utvecklare hade använt andra issue / bug trackers. Nämnda exempel var Trac, Jira, Launchpad samt et t specialbygge för D-sektionens hemsida. 5

6 5.2.3 Fr åga 3 Fråga: Om du använt någon issue / bug tracker förr, hur tycker du att de har fungerat? Samtliga utvecklare som hade använt issue / bug trackers förr tyckte att de hade fungerat bra Fr åga 4 Fråga: Hur mycket har du använt Bugzilla under E nduro-projektet? Se figur 2. F igur 2: Svar på fråga Fr åga 5 Fråga: Hur tycker du att Bugzillas gränssnitt fungerar? Är det lätt att förstå och använda? En utvecklare tyckte att Bugzillas gränssnitt får ögon[en] att blöda jämfört med launchpad Fr åga 6 Fråga: Tycker du att Bugzilla varit användbart under E nduro-projektet? Varför /varför inte? Se figur 4. U tvecklarnas kommentarer: Nej, ty det har varit svårförståt t. Det är bra som verktyg att hålla reda på vilka stories som blivit klara eller ej. Dock, hade det ultimataste varit att alla stories efter hand som de kom in; blev inlagda som buggar som borde fixas på bugzillan. Därefter hade det par som skulle jobba med en viss story tagit åt sig den (då hade alla kunnat veta vem som jobbade med en viss story gentemot hur det är 6

7 F igur 3: Svar på fråga 5. nu när man ibland får gå och fråga vem som gör vilken) och därefter sätta den till klar när allting, texter, kodning osv är genomförd. W ikin hade varit bättre. Hade varit användbart om det hade använts av alla Det har inte uppståt t några problem som jag tror at t Bugzilla skulle kunnat hjälpa oss med. Hade man haft ett speciellt tst-team så hade det nog underlättat kommunikationenen mellan dem och utvecklarna. Nu i et t så här litet projekt känns det lite overkill. Nej, eftersom jag saknar kunskap om hur man använder Bugzilla ultimat vilket förmodligen även fler i projektet gör. Det bästa hade varit att man innan projektet började satte sig in i programmet och bestämde i vilken grad och för vilket ändamål man skulle använda Bugzilla. Å tkomsten försvårar även då servern inte alltid är uppe. Bugzilla har inte varit användbart ännu, eftersom projektet divideras upp i så många mindre delar, samt eftersom vi är så pass många i gruppen berät tar vi om varandras kods buggar. K anske skulle vara jätte användbart att hålla koll på buggar men tro man måste göra det till en vana att använda Fr åga 7 Fråga: F inns det någon funktionalitet du skulle vilja lägge till eller ta bort från Bugzilla för att göra den bättre anpassad till X P-projekt av den här sorten? Tror du att det finns något annat verktyg som hade passat bättre? 7

8 F igur 4: Svar på fråga 6. Åtta utvecklare svarade Vet ej. Bugzilla passar inte så bra till så här små projekt Att prata med teamet funkar bättre. För oss som inte har någon direkt testning utan utvecklar mer kanske det hade varit mer användbart att ha något som beskriver koden, som man kan uppdatera när man gör förändringar. Jag vet inte om det finns nåt vettigt sätt eller verktyg att göra det med dock. Bugzilla är nästan för avancerat för ett projekt av denna storlek. T O D O notisar, eller gula lappar hade räckt Fr åga 8 Fråga: Om inte, tror du att issue /bug trackers kan vara mer användbara i någon annan projektform? Svaren har tolkats ut ur fritext, och en utvecklare kan alltså ha bidragit till en eller flera kolumner i figur Fr åga 9 Fråga: Övrigt? Av de svar som inkom på fråga 9 var det bara en som hade med bug/ issue trackers at t göra: Hade till och med glömt bort [Bugzilla] fram till dess at t [Snild] nämnde det idag. 6 E nkä t till kunden 6.1 Frågor 1. På vilket sätt har du använt dig av Bugzillan under projektet? Hur myc- 8

9 F igur 5: Svar på fråga 8. ket? 2. Har Bugzillan underlät tat för dig som kund? Hur? 3. K unde Bugzillan ha använts på ett bättre sätt under projektet? 4. K änner du att Bugzilla passar i ett X P-projekt av den här sorten? Varför / varför inte? 5. F inns det någon funktionalitet du skulle vilja lägge till eller ta bort från Bugzilla för att göra den bättre anpassad till X P-projekt av den här sorten? Tror du att det något annat verktyg som hade passat bättre? 6. Ö vriga synpunkter. 6.2 Svar Nedan följer en sammanfattning av svaren. Svaren i sin helhet kan läsas i bilaga A. K unden har inför planeringsmötena gått in på Bugzillan för att få en överblick. Under måndagarnas långlabbar har han dock föredragit at t prata direkt med teamet och kolla på tavlan. Han tycker att Bugzilla har funkat lika bra som en wikisida med en storytabell för honom, och tycker att om det underlättar för teamet är det bra. K unden har tidigare använt Trac kopplat till versionshanteringssystemet Subversion med goda erfarenheter. E n funktion han uppskat tar är at t man i Trac enkelt kan koppla tickets (motsvarande Bugzillas buggar) till commitkommentarer. V idare anser kunden at t det hade varit bra om Bugzillan varit tillgänglig även under torsdagarna, inför planeringsmötet. Det ta önskemål har tagits i beaktning, och Bugzillan kommer at t vara tillgänglig varje torsdag från och med planeringsmöte 4. 9

10 F igur 6: Korrelation mellan tidigare användning av issue / bug trackers och användning av Bugzilla i E nduro-projektet. 7 D isk ussion U tvecklarna tvingades inte at t använda Bugzilla under E nduro-projektet. Under iteration 1-3 användes datorsalens tavla som tracker. Tanken bakom det ta var att det var att arbetssättet i Enduro-projektet var nytt för de flesta utvecklarna, och coachernas förhoppning var at t utvecklarna själva skulle bli intresserade av Bugzilla och kanske se en nytta i dess användning. Från och med iteration 4 kommer utvecklarna tvingas at t använda Bugzilla, eftersom utvecklarna vid det här laget bör vara invanda med projektets arbetsprocess. Hypotesen är att utvecklarna kommer att bli mer positiva till användningen av Bugzilla i projektet. Risken är dock att tvång kommer att göra dem negativa. E ftersom data från iteration 4 och 5 inte kommer at t kunna inkluderas i den slutliga studien kommer de att bifogas som bilagor till densamma. 7.1 A nvändning E tt fåtal av utvecklarna hade använt Bugzilla eller någon annan issue / bug tracker förr, och hade goda erfarenheter från det. Det är rimligt att anta att dessa utvecklare skulle vara mer benägna at t använda Bugzilla-servern i E nduroprojektet, och datan från enkäten indikerar också det ta (se figur 6). Svaret lite spänner ganska stort över flera olika sätt att använda Bugzilla. Detta, i kombination med at t urvalet för enkäten är ganska litet, innebär at t inga säkra slutsatser om et t eventuellt samband kan dras. 10

11 7.2 A nvändar vänlighet och ny t t a U tvecklarnas åsikter om Bugzillas användarvänlighet gick isär. Några tyckte at t gränssnit tet var ganska krångligt. Projektets coacher håller med. E ndast två utvecklare tyckte at t Bugzilla hade varit användbart under projektet. För kundens del hade det gåt t lika bra med en tabell på en wiki. De flesta utvecklarna trodde dock at t issue / bug trackers skulle vara mer användbara i andra sorters projekt. Den allmänna åsikten verkar vara at t Bugzilla kändes onödigt. 7.3 Slu tsa ts Studien indikerar at t användningen av Bugzilla passar dåligt i et t projekt av samma typ som E nduro-projektet. Det ta står i kontrast till studier som visat att större projekt kan ha stor nytta av issue / bug tracking[4]. På grund av det dåliga underlaget är det tyvärr inte möjligt att dra några konkreta slutsatser. Y t terligare studier i ämnet vore önskvärda. 11

12 R eferenser [1] Michael F ischer, Martin Pinzger och Harald G all. Analyzing and Relating Bug Report D ata for Feature Tracking [2] Steve Mc Connell. G auging Software Readiness with Defect Tracking [3] Nicolás Serrano och Ismael C iordia. Bugzilla, I Tracker, and O ther Bug Trackers [4] Luis Villa. Large Free Software Projects and Bugzilla. Ur Proceedings of the L inux symposium

13 A K undens enkä tsvar 1. Jag har gått in inför planeringsmötena för att få en överblick. På måndagarna har jag tyckt det var smidigast att snacka med er i salen och kolla på tavlan. 2. G enom at t lista alla buggar och kolla vilka som är F I X E, N E W, AS- SI får jag den information som jag vill ha för at t kunna följa hur det går. För mig är det lika bra som om ni hade haft en sida på wiki med en tracker (se t ex era syskonteam ht tp:/ / torvalds.cs.lth.se / E D A / TeamPages/ Team08/Stories och / torvalds.cs.lth.se / E D A / TeamPages/ Team09/ Tracker). Så om ni dessutom får yt terligare stöd ifrån bugzilla så är det ju en fördel framför mer manuellt jobb. 3. Inte som jag vet. Jag har knappt använt bugzilla själv (men vet i stora drag hur det fungerar). 4. Ja, det tror jag. Det är ju viktigt att det är lättviktigt och går enkelt att ändra status och innehåll på buggar etc, men det tror jag att det är. 5. E t t system som vi har börjat använda i vårt forskningsprojekt är Trac, kopplat till subversion. Se ht tp:/ / palcom-trac. Det känns smidigt tycker jag och lät tviktigt, tar inte energi från övriga arbetet. Där har man en direkt koppling till changesets i subversion, och enkelt att göra länkar mellan commit-kommentarer och tickets (motsvarande buggar i bugzilla). Jag vet inte hur det är i bugzilla med C VS-koppling, men det kanske hade varit bra med en koppling till C VS-loggen i bugzilla och möjlighet at t browsa koden som i Trac. Fast i kursprojektet kanske det hade ställt till med mer förvirring än vad det hjälpt till. 6. Jag hade ju inte avtalat med er när jag tänkte försöka gå in, och inte tänkt igenom det så noga. Det hade varit bra om bugzillan varit uppe på torsdagarna också - eller gärna 24/7 förstås om möjligt. 13