PROJEKTARBETE

SYSTEMUTVECKLINGSPROJEKT MED SCRUM OCH EXTREME PROGRAMMING

Det här dokumentet fokuserar på genomförandet av

projektet, processen under projektarbetet. För allmänt om
kursen, teamindelning osv., se studiehandledningen.
Innehåll
Hattmakarens nya affärssystem .............................................................................................................. 3
Genomförande ........................................................................................................................................ 4
Kundmöte ............................................................................................................................................ 4
Förberedelser .................................................................................................................................. 5
Uppföljning ...................................................................................................................................... 5
Sprintplanneringsmöten, 1-3 .............................................................................................................. 5
Förberedelser .................................................................................................................................. 5
Uppföljning ...................................................................................................................................... 5
Sprint retrospective ......................................................................................................................... 6
Sprint review (sprintplanning 2 och 3) ............................................................................................ 6
Redovisning ......................................................................................................................................... 6
Bedömning av projektarbetet (provkod: B002) ...................................................................................... 6
Betygsättning....................................................................................................................................... 7
3 Projektarbete - Systemutvecklingsprojekt med Scrum och Extreme Programming

Hattmakarens nya affärssystem

Det var en helt vanlig dag hos hattmakare Otto. Han satt i sin och sin kompanjon Judiths syateljé och
sydde på den senast beställda hatten av hans trogna kund Kurt Lupton. Han tänkte att vilken tur han
hade som hade så lojala kunder som alltid återkommer till honom så fort de behöver en ny hatt. Denna
gång skulle hatten vara till en promovering och det krävdes stor koncentration för att få till varenda
detalj med absolut högsta kvalitet.

Plötsligt far dörren till syateljén upp med ett brak och den lilla klockan på karmen som normalt sett
annonserar ut ett litet plingeling, för att göra honom uppmärksam på att en kund är på väg in, far nu i
stället ner i golvet av blotta förskräckelsen med både ett pling och ett donk. In kommer Ottos
barnbarn, märkbart exalterad!

- Morfar!

Otto tittar förskräckt upp och sticker sig nästan i fingret på synålen. Han skakar på huvudet.

- Vad du far fram! Har du inte lärt dig att ta det lugnt ännu? Du skrämmer ju nästan slag på mig.
- Ja, men jag har en helt otrolig nyhet, vänta, vänta tills du får höra detta!

Exalterat berättar Ottos barnbarn om sin senaste hobby, cosplay, och det konvent han nyligen besökt.
Hela sitt liv har han fått prova olika hattar och därmed utvecklat ett stort intresse för kostymering och
äntligen har han hittat sina likasinnade. Han berättar även att den hatt som han bar vid konventet
väckt stor uppmärksamhet.

- Vanligtvis beställer de flesta sina kostymer via ebay och liknande men det är alltid så dålig
kvalitet. Din hatt däremot… alla var så fascinerade.

Ottos barnbarn berättar att han har fått flera förfrågningar.

- Du måste tillverka de här nu!

- De frågade mig hur de beställer, men det går väl inte alls?

Ottos barnbarn pekar på Ottos gamla stationära dator som står i ett hörn i syateljén.

- Har du ens e-post morfar?

Otto har alltid endast tillverkat hattar åt sin trogna kundkrets och åt personer som kommer in i hans
ateljé. Detta är något helt nytt, en helt ny marknad. Hans barnbarn övertygar honom dock om att det
kommer att bli väldigt stort och att han måste satsa på detta. Otto ringer sin revisor för att höra sig för
vad denna nya marknad för med sig för bekymmer. Det visar sig att han behöver ett affärssystem för
att kunna spara information om lagerförda modeller, för att kunna plocka in förfrågningar på
specialtillverkningar, göra materialbeställningar, beräkna pris samt kunna göra utskrift av fraktsedel,
innehåll, värde, varukod för tulldeklaration mm. Eftersom hattarna nu skall kunna skickas behöver det
finnas ett system för att hålla reda på vilken hatt som skall till vem, vem som lagt vilken beställning etc.
Att bara anteckna i ett block inne i ateljén kommer inte längre att fungera.

Ottos barnbarn har googlat och rekommenderat att Otto ska ta kontakt med ett utvecklingsteam med
bra renommé för att få hjälp med sitt nya system.

- Du behöver bara berätta för dem om dina hattar så fixar de resten!

Otto överlägger med sin kollega Judith och tillsammans kommer de överens om att det är klart att de
ska satsa på detta. Det är dags att kontakta utvecklarna.
4 Projektarbete - Systemutvecklingsprojekt med Scrum och Extreme Programming

Genomförande
Projektuppgiften består av att genomföra ett systemutvecklingsprojekt enligt agila grundprinciper med
hjälp av Scrum och eXtreme Programming. Fokus i kursen ligger på att lära sig att arbeta utifrån ett
agilt arbetssätt och det är således processen som står i centrum – inte programmeringen – även om
programmeringen är ett verktyg för att kunna tillämpa processen. För att kunna följa en
systemutvecklingsprocess behöver ett system utvecklas, men det är inte det som i huvudsak
examineras, det är hur väl ni följer det som metoderna förespråkar. Processen ni kommer att följa
illustreras i nedanstående figur.

Mer information om kursträffar finns i studiehandledningen. I resterande delar av detta dokument

redovisas den process som skall följas under projektarbetet.

Kundmöte
Uppgiften som ni har fått är vagt specificerad. Ni kommer nämligen att samla in mer information om
funktionella och icke-funktionella krav via möten med kunden. Det första mötet är kundmötet, se
kursschema på Kronox för tidpunkt. Processen vid kundmötet är att ni skall agera som konsulter i ett
systemutvecklingsteam. Det är ert ansvar att få reda på så mycket som möjligt om verksamheten för
att kunna sammanställa kraven på systemet i en produktbacklog. För att få reda på detta behöver ni
ställa frågor till kunden. Förbered er i teamet innan! T ex står det i uppgiften att ni skall utveckla
”hattmakarens nya affärssystem”. Här gäller det att fundera på vad det innebär. Det står även att
systemet skall vara ett stöd för att kunna ta in förfrågningar. Hur ska detta ske? Uppgiftsbeskrivningen
är således inte tillräckligt tydlig för att räcka som underlag för utvecklingen. De frågor ni ställer och
svaren ni får på dem ger er en bättre förståelse. T ex är det inte en webbshop som skall utvecklas, utan
ett system som är ett stöd för hattmakaren att hantera förfrågningar som kommer in. Hur dessa
förfrågningar kommer in står inte, så det måste ni ta reda på.

Ett exempel på scenario vid kundmötet:

• Ni i teamet presenterar er, det behöver inte vara individuellt utan hitta på något, exempelvis:
”vi kommer från företag x, vår specialistkompetens är y…”.
5 Projektarbete - Systemutvecklingsprojekt med Scrum och Extreme Programming

• Be kunden att berätta om sin verksamhet.

• Kunden berättar, ni lyssnar och ställer frågor om något är otydligt.
• Ni ställer era förberedda frågor samt frågor som uppstått under tiden för att få en så bra bild
av det system som skall utvecklas som möjligt. När ni känner att ni fått veta allt ni behöver
tackar ni kunden och meddelar att ni kommer att återkomma med en lista över de krav som
ni har samlat in.

Förberedelser
Läs igenom systembeskrivningen noga. Diskutera i gruppen. Skriv frågor att ställa vid kundmötet.

Uppföljning
Samla alla insamlade krav i en produktbacklog i form av user stories. Samtliga user stories skall vara
tidsestimerade och prioriterade. Det är svårt att tidsestimera men gissningar är bättre än ingen
estimering alls. Är det någon user story som man absolut inte kan tidsestimera är det en spike och skall
hanteras som en spike. Det är dock inte godkänt att utnämna alla till spikes för att slippa estimera,
estimeringen är en del av processen, så detta skall bara användas i undantagsfall.

Sprintplanneringsmöten, 1-3
Det är ni i teamet som ansvarar för sprintplanneringsmötena. Det är er Scrummaster som leder mötet.
Ni är utvecklarna och er lärare är er kund. Det är lätt att tro att läraren skall initiera mötet eftersom
det är er lärare men här handlar det om att ni skall lära er det agila arbetssättet och för det behövs
detta rollspel där det är ni som har taktpinnen. Det betyder att ni behöver ha kunskap innan mötet om
hur ett sprintplaneringsmöte skall gå till. I huvudsak ser dock processen ut enligt nedan:

Utifrån er tidsestimerade och prioriterade produktbacklog ska ni i teamet planera den första sprinten
tillsammans med kunden. För att kunna göra det behöver ni först i teamet ha diskuterat hur mycket
tid ni har tillgängligt under sprinten (se förberedelser). Ni skapar sprinten i Scrumwise vid mötet (ej i
förväg) genom att ange tiden som är tillgänglig för sprinten. Därefter kommer ni tillsammans med
kunden överens om ett mål för sprinten, t ex: att efter den här sprinten kommer vi att ha en
fungerande version av systemet med den allra mest grundläggande funktionaliteten. Därefter väljer ni
ut user stories från produktbackloggen utifrån det målet och i dialog med kunden. T ex:

- Vi föreslår att vi börjar med den här user storyn eftersom den är (högt prioriterad, för att den
lägger grunden för systemet, eller annat argument).

Ni föreslår user stories som skall ingå i den första sprinten men gör detta genom att ha en dialog med
kunden. Förklara hur ni tänker, fråga om kunden håller med. Ni driver processen men kunden ska
involveras. Ställ frågor till kunden. När ni har fyllt upp sprintens timmar med user stories motsvarande
dessa timmar är sprinten planerad. Fråga kunden om planeringen känns bra utifrån ett kundperspektiv.

Förberedelser
Beräkna tid för sprinten. Beräkna hur många dagar ni har. Bestäm hur många timmar per dag ni skall
arbeta med implementering, räkna bort tid för annat. Bestäm hur ni skall arbeta i par. Räkna ut er
totala tid för implementering under sprinten, ex:

X dagar, Y timmar per dag, Z par = X·Y·Z = XYZ timmar

Uppföljning
Er sprintbacklog skapas under mötet. Viktigt är dock att hålla sprintbacklogen levande under hela
sprinten. Medan ni arbetar på en user story uppdaterar ni dess status i Scrumwise. Om en user story
t ex är beräknad att ta 4 timmar och ni efter tre timmar är klara med den så anger ni detta. Ni kommer
6 Projektarbete - Systemutvecklingsprojekt med Scrum och Extreme Programming

då att se i den burndownchart som ni genererar efter sprintens slut att ni är snabbare än vad ni
estimerat. Är fallet tvärtom, att ni efter fyra timmar har kommit halvvägs så anger ni detta och när ni
är klara fyller ni i den faktiska tiden innan ni anger att user storyn är avklarad. Genom att uppdatera
sprintbacklogen med den faktiska tiden implementeringen tar får ni feedback på era estimeringar
vilket gör det lättare att tidsuppskatta framöver. I början blir det ofta fel men det är genom denna
process man lär sig.

Utöver detta skall ni även tillsammans i gruppen efter varje sprintplaneringsmöte genomföra ett sprint
retrospective.

Sprint retrospective
Sprint retrospective är ett möte som ni i gruppen har efter varje sprintplaneringsmöte där ni diskuterar
vad som gick bra i föregående sprint och vad som kan förbättras inför nästa.

Sprint review (sprintplanning 2 och 3)

En skillnad mellan sprintplanneringsmöte 1 och de efterföljande, 2 och 3, är att vid
sprintplanneringsmöte 2 och 3 förväntas mötet inledas med en sprint review. Under sprint review
redovisas föregående veckas arbete genom demonstration av det som utvecklats hittills så att kunden
kan komma med reflektioner. Detta är ett sätt att säkerställa att ni och kunden har en gemensam bild
av systemet som skall utvecklas. Utöver det skall ni reflektera över måluppfyllelse och
tidsuppskattningar under föregående sprint. Här visas även föregående veckas burndownchart. För att
detta skall fungera är det viktigt att ni regelbundet statusuppdaterar era user stories medan ni arbetar
med dem (se uppföljning).

Redovisning
Under projektredovisningen inleder teamet med att visa upp produktbackloggen. Teamet skall även
reflektera över måluppfyllelse, tidsuppskattning etc. från förgående sprint. Här visas även den aktuella
burndowncharten upp med jämförelse till den första. Då detta är projektavslutet ska teamet diskutera
hur väl de har lyckats planera in genomförandet av projektet under de sprintar som funnits tillgängliga.
En kort demonstration av det utvecklade systemet avslutar redovisningen. Det är viktigt att teamet
redovisar både processen och systemet och att det tydligt framgår hur planeringen och
implementationen av prioriterade krav utfördes. Skulle det vara så att teamet inte har lyckats med att
implementera prioriterade krav behövs en reflektion kring detta, vad som hände, anledningar, vad
teamet lärt sig och tar med sig för erfarenheter etc. Varje team har cirka 20 minuter för sin redovisning.

Bedömning av projektarbetet (provkod: B002)

Hur ni agerar och dokumenterar under processen bedöms. När det gäller bedömningen handlar det
om hur väl processen följs, att kundmötet, sprintmötena samt redovisningen genomförs enligt
metoderna (och exemplen i det här dokumentet). När det gäller bedömningen av artefakterna handlar
det inte om hur korrekta tidsestimeringar som görs, för tanken är att ni ska lära er att tidsestimera
genom att praktisera. Här handlar det istället om att artefakterna ska ha framställts enligt anvisningar
i metoderna. T ex att user stories är formulerade som user stories, att de är korta och oberoende, att
de är tidsuppskattade och att de är prioriterade. Det handlar även om att sprintbacklogen hålls
uppdaterad med status under sprinten så att det i slutet av sprinten är möjligt att generera en
burndownchart. För att detta skall lyckas måste ni ha en dialog inom teamet.

Provkod B002
Möte/artefakt Bedömning (+/-/ok)
Kundmöte
Product backlog (PB)
7 Projektarbete - Systemutvecklingsprojekt med Scrum och Extreme Programming

Sprintmöte 1/Sprintbacklog 1 (SB1)

Sprintmöte 2/Sprintbacklog 2 (SB2)
Sprintmöte 3/Sprintbacklog 3 (SB3)
Burndownchart 1 (BC1)
Burndownchart 2 (BC2)
Burndownchart 3 (BC3)
Redovisning av systemet
Implementation av prioriterade krav

Bedömning av möten:
+ : Väl förberedda, följer processen väl, agerar självständigt och professionellt. Har dialog med kunden
och driver processen.
ok : Studenterna har i huvudsak koll på processen och mötet kan genomföras utan att kunden behöver
agera lärare (i alltför stor utsträckning).
- : Studenterna har inte koll på processen och är inte förberedda, läraren måste agera lärare och kan
inte fokusera på att vara kund.

Bedömning av artefakter:
+ : Följer det som föreskrivs enligt metoderna exemplariskt
ok : Följer i huvudsak det som föreskrivs enligt metoderna med något enstaka undantag
- : Följer inte det som föreskrivs enligt metoderna

Betygsättning
Högsta utfall på projektet är 10 +, lägsta är 10 -. Minus kommer dock endast att sättas i fall där ni
som studenter inte alls är förberedda, alternativt inte alls har förstått metoderna/arbetssättet.
Bedömningen av mötena/artefakterna ger betyget på provkoden enligt nedanstående:

U: Mer än tre minus

G: Maximalt tre minus, övriga möten/artefakter ska ha bedömts med ok eller +
VG: Inga minus samt minst 7 av 10 möten/artefakter ska ha bedömts med +