Scrum + XP samt konsekvensanalys

Transkript

1 Scrum + XP samt konsekvensanalys Daniel Nimren dt05dn8 Douglas Frisk dt05df1 Dept. of Computer Science, Lunds Tekniska Högskola, Sweden {dt05dn8 dt05df1}@student.lth.se 1 mars 2010

2 Sammanfattning Denna rapport handlar om hur SCRUM kan integreras i XP med alla dess principer. Detta sker under kursen Programvaruutveckling i grupp samt Coaching för programvaruteam där målet är att arbeta fram en produkt som ska kunna användas för tidtagning vid tävlingar i enduro. Konsekvensanalys kommer till viss del vara en del av empirin under kursens gång. Kursen innebär sex långlabbar, sex veckomöten samt spiketid på fyra timmar varje vecka.

3 Innehåll 1 Studie Terminologi Introduktion SCRUM Vad är SCRUM? Djupgående terminologi Sprint Produkt backlog Sprint planering Burn down chart Sprint backlog Taskboard Daglig SCRUM Konsekvensanalys Vad innebär konsekvensanalys? Olika typer av konsekvensanalyser SCRUM + XP Bakgrund Empiri Slutsats Konsekvensanalys i agila projekt Bakgrund Empiri Slutsats Sammanfattning 14

4 Kapitel 1 Studie 1.1 Terminologi Iteration En återkommande process, i detta fallet en tidsperiod under vilken en långlabb, ett veckomöte och fyra timmars individuell spiketid ingår. Spike En lösning på något problem som man sedan kan använda sig utav i utvecklingen. I detta fall individuellt arbete som görs utanför schemalagd tid. SCRUM Ett arbetssätt inom agil utveckling, skrivs ofta med stora bokstäver beroende på att Ken Schwaber gjorde det i en av sina tidiga artiklar [1]. extreme Programming Ett arbetssätt inom agil utveckling [7]. Härmed känt som XP. EDA260 Kursen Programvaruutveckling i grupp på LTH. EDA270 Kursen Coaching för programvauteam på LTH. Konsekvensanalys Direktöversättning från termen impact analysis [5]. Story Beskrivning på ett krav ställt av kunden, används som term inom bl.a. XP. Artefakt (Inom konfigurationshantering) En del i ett projekt, kan vara en klass, ett dokument, en kompilator o.s.v.. Trac En wiki som har integrerad SVN, används i projektet. 2

5 1.2 Introduktion Våran djupstudie är baserad på kursen EDA260, i vilken en grupp med i vårt fall åtta studenter ska samarbeta under sex heldagar som var och en utgör en iteration i projektet. Kursen är obligatorisk för de som vill ta ut en examen som civilingenjör inom data. Det kan medföra en lägre motivation än det kanske hade varit på en valfri kurs eftersom alla inte har intresse för innehållet, dessutom slumpas teamen ihop så att en bra gemensamhet inom gruppen är inte självklar. Målet för projektet är att utveckla ett tidtagningssystem för motorcykelsporten Enduro. Detta med fokus på samtliga principer som XP medför, utöver detta har vi valt att skriva våran djupstudie om SCRUM och hur man kan integrera det i XP [3], utöver det har vi delar av SCRUM som fokus i projektgruppen. Kursen innefattar en långlabb, ett veckomöte och fyra timmars spiketid i veckan. Långlabben är ett moment då teamet samlas i en datorsal under en heldag för att utveckla produkten och brukar inledas med ett möte för att gå igenom dagens schema. Under veckomötet görs estimeringar och planeringar av de krav som kunden har kommit med sedan den senaste iterationen. På den individuella spiketiden ska utvecklarna arbeta hemma med något som kan gagna hela teamet och sedan presentera det på morgonmötet under nästa långlabb. Vi har även valt att ha konsekvensanalys [5] som ett fokus i projektet för att se om det är möjligt och givande i ett projekt med denna storleken och omfattningen. Det innebär att vårt team ska gradvis mer ingående analysera och spåra beroende mellan klasser och metoder i det pågående projektet för att på så sätt kunna estimera tidsåtgången för en story baserat på mer än bara just den storyns innehåll. Med gradvis syftar vi på att nivån på kraven av eftertänksamhet vid analysen blir större för varje iteration. Tanken med detta är att utvecklarna (som antas aldrig ha gjort en konsekvensanalys förr) inte ska behöva ta ett för stort steg direkt utan känna sig fram och märka tydliga skillnader under kursens gång. Med denna studien avser vi att undersöka om SCRUM går att kombinera med ett XP-projekt och framförallt i ett projekt inom kursen EDA260. Våran avsikt är att underlätta processen (eftersom det är just den som SCRUM inriktar sig på) under utveckling. Vi vill också undersöka om konsekvensanalys är vettigt att använda sig utav i agil utveckling eller om det medför en för stor belastning. I den här artikeln kommer vi beskriva SCRUM i kapitel 2 samt hur det kan integreras i XP i kapitel 4 samt beskriva konsekvensanalys i kapitel 3 och dess användande i agila projekt i kapitel 5. En sammanfattning finns i kapitel 6. Referenser är presenterade i slutet på artikeln, vissa av referenserna är andrahandsreferenser som har gett bakgrund men inte har blivit använda direkt i rapporten (och därav aldrig nämnda). 3

6 Kapitel 2 SCRUM 2.1 Vad är SCRUM? SCRUM är ett sätt att arbeta på, det är inte en metod utan snarare ett ramverk [1]. Vilket betyder att inget är satt i sten. Det är upp till varje team hur de vill implementera de delar som det talas om i SCRUM på det sätt som passar dem bäst i just deras situation. Situationen i fråga kan mycket väl förändras och likaså kommer principerna man talar om i SCRUM förandras med den. I stora drag är SCRUM en agil infallsvinkel på mjukvaruutveckling och har mycket gemensamt med andra metodiker som t.ex. XP. Men med den stora skillnaden att man inte lägger någon tyngd vid utvecklingsmetodik så som parprogrammering, enkel design o.s.v., utan koncentrerar sig enbart på processen, d.v.s. planering, upplägg o.s.v. [8]. Ett SCRUM-team ska vara självorganiserat i den mån att det inte finns någon direkt teamledare som styr. Alla medlemmar i teamet är med och tar gemensamma beslut angående vad som ska göras och hur det ska göras. Samt alla som behöver blandas in blir inblandade när ett beslut ska genomföras. Trots detta finns det roller i ett SCRUM-team [3], särskilt dessa: ScrumMaster Någon som agerar coach till teamet för att få dem att arbeta så smidigt som möjligt och på sin högsta nivå. Product owner En representant från rörelsen, kunderna och användarna som ser till att kraven följs och att det är rätt produkt som blir utvecklad. Utvecklare Programmerare, designers och folk med specialkunskaper. I SCRUM arbetar man i sprints, varje sprint börjar med att teamet levererar ett löfte om vad som ska vara klart efteråt. Efter varje sprint levereras de utlovade delarna, kodade, testade och integrerade i systemet som utvecklas. 2.2 Djupgående terminologi SCRUM liksom många andra metodologier och ramverk för att arbeta innehåller en hel del termer med en specifik innebörd, då SCRUM som tidigare nämnts bara är ett ramverk för utveckling i team så är inga av dessa termer exakta, utan snarare författarnas egna tolkningar. 4

7 Daglig sprint Sprint 1-4 veckor Produkt backlog Sprint backlog Aktuell release Figur 2.1: SCRUM process Sprint En sprint i SCRUM är en tidsperiod som brukar vara mellan en vecka och en månad. Undersökningar har visat att det är vanligast med två veckor. Under denna tiden är målet för teamet att klara av ett visst antal uppgifter som man kommer fram till i början av sprinten Produkt backlog En produkt backlog är en enkelt beskriven lista på vad kunden vill ha, med kundens terminologi. Det är med en sådan alla SCRUM projekt börjar. Den ska innehålla alla krav, stories, funktioner etc. Varje krav, story eller funktion bör vara beskriven med ett antal fält [3]: ID Ett vanligt automatiskt inkrementerat nummer som kan identifiera varje story. Namn Ett kort och beskrivande namn som lätt skiljer storyn från andra stories. Prioritet Ett nummer talar om hur viktig storyn är relativt alla andra stories. Kan bestämmas i vilket spann som helst bara man håller sig inom det under hela projektet. Inledande estimering Ett mått på hur lång tid man uppskattar att storyn kommer ta att implementera relativt alla andra stories. Även här ett nummer i vilket spann som helt så länge man är konsekvent. Demonstration En kort beskrivning på hur man kan demonstrera storyn när den är klar, D.v.s. hur den är tänkt att fungera. Anteckningar Annan information som inte passar i något av de andra fälten. Ibland uppkommer det beroende som kunden inte uttryckligen har ett krav på men som krävs för att implementera andra krav, dess kallas för tekniska stories. Vanligt är att dessa läggs till i listan på kundens krav för att underlätta logistiken i projektet. Men som sagt så är SCRUM endast ett ramverk och det är fullt möjligt att lägga till fler fält vid behov samt ta bort fält som känns överflödiga. 5

8 2.2.3 Sprint planering Inför varje sprint behövs det en bra och utförlig plan på vad som ska göras klart under sprinten [3]. ScrumMastern håller då ett möte för att klargöra kundens förväntningar och krav, samt komma fram till hur många man-timmar man har att jobba med, för att man ska veta hur många stories man räknar med att klara av. Det är under planeringsmötet som estimeringen av stories sker. Det finns många olika sätt att estimera och alla är förmodligen lika bra i den situation som den är anpassad för. Vilken man väljer är upp till ScrumMastern och ofta så experimenteras det för att komma fram till vilken det är. Kunden bör också närvara för att prioritera vilka stories som bör göras först och beroende på hur de estimerades även förändra prioriteringen om det behövs. Huvudmålet är att utvecklarna ska kunna jobba ostört under hela sprinten och på så vis uppnå maximal produktivitet. Det är därför viktigt att utvecklarna tänker igenom varje story tillräckligt för att komma på eventuella frågor redan då och på så vis spara den tid det tar att kontakta kunden senare under utvecklingen, även kundens tid är ju dyr. Under mötet bestäms även hur lång nästa sprint ska vara. Generellt sätt är en kortare sprint att föredra, dock inte så kort att ingenting hinns med för att man inte får upp farten. Kort sprint = kort feedback cykel = frekventare leveranser = frekventare kundfeedback = mindre tid spenderad i fel riktning = snabbare inlärning Normalt är att ha lika långa sprinter under hela projektet men ibland tar det en sprint eller två innan man har bestämt sig för vilken längd som passar bäst i just det projektet. Men liksom tidigare är det fritt fram att ändar uppfattning under projektets gång. Att ha ett kollektivt mål under en sprint gör så att hela gruppen arbetar mer tillsammans för att nå det. Ett mål är inte alltid så lätt att formulera och vid brist på ett är det bättre med ett halvdant mål än inget alls, det kan t.o.m. vara imponera på företagsledningen Burn down chart Ett burn down chart är en graf som utrycker t.ex. en iterations progress i antal estimerade poäng mot tiden [3]. I figur 2.2 visas ett exempel på ett burn down chart, på den horisontella axeln har vi enheten tid och på den vertikala axeln antal återstående estimerade poäng. Målet är att man ska veta om man ligger bra till i tiden genom att använda sig utav den raka linjen som går genom grafen. Efter iteration fyra kan man se att avståndet mellan följelinjen och den verkliga linjen blir allt för stor, det vill säga, det var för mycket att göra. Detta åtgärdades av att ScrumMastern tillsammans med kunden valde bort stories som var lågprioriterade och på så vis ledde linjen tillbaks där man ville se den. Likaså hade en omvänd situation krävt att nya stories skulle tillkomma. Det finns även alternativet att använda sig utav kalkylblad för att på ett enklare sätt kunna producera en graf med automatiskt ritad medianlinje (som används för att se när den riktiga linjen förväntas korsa x-axeln och på så vis ge ett estimat på hur man ligger till i förhållande till den planerade sluttiden). 6

9 Poäng Tid Figur 2.2: Exempel på burn down chart Sprint backlog En sprint backlog börjar med att se ut precis som en produkt backlog fast innehåller endast de stories som teamet planerar att genomföra under kommande sprint. Efter hand har ScrumMastern i uppgift att bocka av de stories som är klara samt uppdatera estimeringarna efter hand för att på så vis få en klar bild över hur långt sprinten är gången. Dessa uppgifter överförs till en burn down chart. [3] Taskboard Under projektets gång brukar man använda sig av en tavla eller whiteboard för att illustrera vilka stories som finns att göra osv. Denna brukar kallas för taskboard [3], se figur 2.3 för ett exempel på hur det kan var strukturerat. Exemplet är uppdelat i fälten: icke påbörjade stories, påbörjade stories, klara stories, oplanerade stories (tekniska stories), burn down chart, nya stories (om de gamla tar slut). Den fungerar på det viset att en utvecklare plockar ett storykort från de icke påbörjade och flyttar det till påbörjat när han ska implementera den. När han är klar flyttar han den till klara stories och fyller i burn down charten så att den blir uppdaterad Daglig SCRUM Det dagliga SCRUMet är ett möte som, liksom termen antyder, hålls dagligen. När under dagen det hålls är upp till teamet och framför allt ScrumMastern. I stora drag är det antingen på morgonen innan utvecklarna har dragit igång med dagens arbete eller på eftermiddagen innan dagen tar slut. För- och nackdelar finns med båda och det är åter igen upp till teamet vad som passar bäst i den relevanta situationen. Termen stand up meeting är också vanlig och går helt enkelt ut på att den dagliga SCRUMen utförs stående för att alla ska vara så vakna på som möjligt och få mötet avklarat så snabbt som möjligt. Mötet är till för att prata om det som har gjorts sedan senaste mötet samt diskutera framtida händelser så som implementeringsförslag på stories eller förslag på förändringar. 7

10 Icke påbörjade stories Påbörjade stories Klara stories Burn down chart Oplannerade stories Nya stories Figur 2.3: Exempel på burn down chart 8

11 Kapitel 3 Konsekvensanalys 3.1 Vad innebär konsekvensanalys? Liksom ordet antyder så innebär konsekvensanalys en analys av konsekvenser vid förändring av t.ex. klasser eller metoder och ofta dokument som manualer o.s.v.. Med komplexiteten som de flesta av dagens projekt bär med sig är det väldigt nyttigt att se till så att man har en väl fungerande konsekvensanalys. Som på ett strukturerat sätt går igenom det som behöver förändras och på så vis ger en mer korrekt estimering av förändringen. Det som man vill uppnå efter en konsekvensanalys är att man vill veta vilken del av koden som måste testas om, vilken del av koden som måste skrivas om och få en bättre tidsestimering på det som ska implementeras [9]. På så vis minimeras antal fel i koden samt effektiviteten förbättras. 3.2 Olika typer av konsekvensanalyser När man pratar om konsekvensanalys för mjukvaruutveckling brukar man dela upp begreppen i två fack, det ena är statisk konsekvensanalys och det andra är dynamisk konsekvensanalys (som båda är en del utav vad som också brukar kallas beroendeanalys). Skillnaden är att man vid statisk konsekvensanalys analyserar källkoden för att på så vis kunna anta olika utfall vid körning av koden, när man istället analyserar utfallen vid en dynamisk konsekvensanalys. Fördelen med statisk konsekvensanalys är att den som analyserar får tänka igenom källkoden mer ingående och på så vis får en bättre förståelse, dock med nackdelen att det ofta slutar i en all för fingranulär analys. Den dynamiska ansatsen ger och andra sidan en mer precis analys men dock med nackdelen att koden i sig inte granskas i samband med analysen. 9

12 Kapitel 4 SCRUM + XP 4.1 Bakgrund Scrum är ett av de sätten att arbeta i team som blommat ut på senare år, det används flitigt ute i industrin. SCRUM är som tidigare nämnts ett ramverk (snarare än en arbetsmetod) med tyngdpunkt på den administrativa processen och med målet att maximera avkastning på investering. Med andra ord innebär det att i SCRUM finns det principer för att hantera utvecklingen medan de principer som vi använder oss av från XP ska garantera oss en hög standard. Ken Schwaber (som tillsammans med Jeff Sutherland formulerade den första versionen av SCRUM) och Kane Mar har tidigare gjort ett försök i att sammansvetsa SCRUM med XP i ett mjukvaruprojekt [8]. Vi har som mål att försöka applicera deras metodik på kursen EDA Empiri Eftersom varje sprint inte var längre än en dag kändes det överflödigt att försöka integrera dagliga sprintar i detta projektet. Det innebär att den dagliga SCRUMen i vårt fall reflekterar en hel iteration/sprint och inte riktigt är så som en daglig SCRUM är tänkt. Utan i stället tog upp delar av det som bör tas upp under en sprint planering. För att till så stor del som möjligt imitera en Burn down chart använde vi det inbyggda verktyget i Trac (se fig 4.1 för en skärmdump från iteration två) för att lägga in varje story och task, vilken ger oss en procent på hur långt vi har kommit under varje iteration. Vi kan gissa på den återstående tiden men inte få en så klar tid som det är meningen att man ska få. Våra veckomöten och andra sidan reflekterar i större drag det som i SCRUM kallas för sprint planering eftersom det är då vi estimerar stories och planerar inför nästkommande iteration/sprint. Under varje iteration/sprint fanns det stories uppsata på väggen under rubrikerna klara, prio 1 och prio 2. För att försöka imitera en taskboard. 10

13 Figur 4.1: Skärmdump från Tracen över en implementation av burn down chart 4.3 Slutsats Eftersom det börjas på flera stories sammtidigt så kommer det medföra att, enligt ett Burn down chart, det inte blir gjort något alls förrän efter ett par timmar. Vilket gör att tidsestimeringen som Burn down chart tillhandahåller blir väldigt labil och näst intill omöjlig att använda. Detta hade kunnat åtgärdas med längre iterationer, precis som det är meningen att det ska vara på en arbetsplats. Tillsammans med en Sprint backlog fann vi dock att detta gav en tillräckligt överskådlig process med tanke på den korta tiden som det skulle täcka. Vi anser att det var tillräckligt med att sätta upp stories på väggen för att efterlikna ett taskboard, eftersom vi ändå inte hade möjligheten att rita ett burn down chart som gav någon vettig information. Hade våran taskboard använts som det var tänkt tror vi att en bra överblick över aktuell iteration/sprint hade varit tydlig, men eftersom eleverna allt som oftast glömde bort att flytta stories till klara delen så fallerade detta till viss del. Detta tror vi kan bero till stor del på att vi som coacher misslyckdes med att definiera story done på ett tydligt sätt. Vi tog för mycket för givet och inser att det är viktigt att vara övertydlig på alla punkter eftersom man inte kan anta att alla ligger på samma nivå i ett team som inte är handplockat. 11

14 Kapitel 5 Konsekvensanalys i agila projekt 5.1 Bakgrund Med kursen konfigurationshantering (EDAN10) i ryggen kändes det naturligt att införa begreppet konsekvensanalys i denna kursen också, eftersom det gång på gång visat sig vara ett väldigt kraftfullt verktyg inte minst inom mjukvarubranchen. Tanken bakom detta var att vi skulle uppnå en bättre kodkvalitet samt färre refaktoriseringar. Vi förväntade oss att det inte skulle bli några speciellt svåra konsekvensanalyser eftersom detta projektet är väldigt linjärt och inför speciellt många tänkbara fällor. 5.2 Empiri Från och med andra veckomötet använde vi oss utav konsekvensanalys i samband med estimeringen av stories. Gruppen delades upp i två mindre grupper som var för sig satt och diskuterade konsekvensanalysen för att komma fram till något som sen kunde jämföras med resultatet från den andra gruppen. Om de två gruppernas konekvensanalys inte överensstämde så gick gruppen igenom det tillsammans och redde ut och diskuterade eventuella oklarheter som kan ha orsakat avvikningen. Eftersom konsekvensanalys mer eller mindre kan göras hur ingående som helst valde vi att lägga det på vad vi ansåg vara en ytlig nivå som borde klaras av utan att ha läst om ämnet i fråga. Tillvägagångssättet som vi ville att vårt team skulle använda var i stil med [9]: Identifiera artefakter som kommer behöva modifieras. Spåra andra artefakter som korrelerar med den aktuella artefakten. Spåra vidare på samma sätt tills inga fler vägar i en tänkt graf hittas. Gå igenom alla spårade artefakter och undersök om de behöver förändras. 12

15 5.3 Slutsats Dock visade det sig att det var en aning för svårt att följa arbetsflödet som vi hade valt. Konsekvensanalysen blev allt som oftast ganska misslyckad och kunde sluta med resultat som: Det här påverkar alla klasser Vilket självklart inte är en speciellt bra och utförlig analys. Detta visade sig dessutom genom fruktansvärda refaktoriseringsproblem som antagligen uppkom till stor del på grund av en undermålig konsekvensanalys. Vid eftertanke tror vi att det hade varit bättre att inte vänta tills iteration två innan man introducerar konsekvensanalys samt att börja i små steg, kanske med enbart punkt ett i listan. 13

16 Kapitel 6 Sammanfattning Eftersom skillnaderna på SCRUM och XP ofta behandlar olika delar av utvecklingen är det en ganska naturlig process att kombinera de båda. Den relativt korta period som denna kursen varar känns dock som lite för kort för att detta ska kunna implementeras på ett smidigt sätt. Men vi är båda övertygade om att idéen är bra och att den förmodligen skulle fungera smärtfritt i ett projekt av den större magnituden. Projekt ute på arbetsplatser använder redan konsekvensanalys och det av en anledning, hade det gjorts grundligt och på rätt sätt i vårat projekt är vi säkra på att det hade gett oss ett annat resultat, ett bättre resultat. En av våra frågor innan projektet började var om konsekvensanalys var värt den extra tiden det tar i ett agilt projekt. Med facit i hand så; nej, det var det inte, vi misslyckades med största sannolikhet av två skäl. För det första så fanns det inte nog med tid på veckomötena för att hinna göra en djupgående analys av varje story och för den andra så saknades kompetensen för att göra en. 14

17 Litteraturförteckning [1] SCRUM development process, Advanced development methods, Ken Schwaber [2] Best Practices in Scrum Project Management and XP Agile Software Development, 2004, Object Mentor, Inc. and Advanced Development Methods [3] Scrum and XP from the Trenches, Henrik Kniberg 2007 C4Media Inc. [4] Agile project management with Scrum, Microsoft Press, Ken Schwaber 2004 [5] Change Impact Analysis for Object-Oriented Programs, Barbara G. Ryder 2001 [6] XP Pocket Guide, Shane Warden 2003 [7] Embracing Change with XP, Kent Beck, IEEE 1999 [8] Scrum with XP, Kane Mar & Ken Schwaber, 22 mars 2002, Prentice Hall [9] Change Impact Analysis, Martin Ward, Software Technology Research Lab De Montfort University 15