Mobilt säljstöd utvecklat med scrum
Tim Cifuentes Vargas
Handledare, Elias Nordström Examinator, Anders Fröberg
Upphovsrätt
Detta dokument hålls tillgängligt på Internet – eller dess framtida ersättare – under 25 år från publiceringsdatum under förutsättning att inga extraordinära omständigheter uppstår. Tillgång till dokumentet innebär tillstånd för var och en att läsa, ladda ner, skriva ut enstaka kopior för enskilt bruk och att använda det oförändrat för ickekommersiell forskning och för undervisning. Överföring av upphovsrätten vid en senare tidpunkt kan inte upphäva detta tillstånd. All annan användning av dokumentet kräver upphovsmannens medgivande. För att garantera äktheten, säkerheten och tillgängligheten finns lösningar av teknisk och administrativ art. Upphovsmannens ideella rätt innefattar rätt att bli nämnd som upphovsman i den omfattning som god sed kräver vid användning av dokumentet på ovan beskrivna sätt samt skydd mot att dokumentet ändras eller presenteras i sådan form eller i sådant sammanhang som är kränkande för upphovsmannens litterära eller konstnärliga anseende eller egenart. För ytterligare information om Linköping University Electronic Press se förlagets hemsida http://www.ep.liu.se/.Copyright
The publishers will keep this document online on the Internet – or its possible replacement – for a period of 25 years starting from the date of publication barring exceptional circumstances. The online availability of the document implies permanent permission for anyone to read, to download, or to print out single copies for his/hers own use and to use it unchanged for non-commercial research and educational purpose. Subsequent transfers of copyright cannot revoke this permission. All other uses of the document are conditional upon the consent of the copyright owner. The publisher has taken technical and administrative measures to assure authenticity, security and accessibility. According to intellectual property law the author has the right to be mentioned when his/her work is accessed as described above and to be protected against infringement. For additional information about the Linköping University Electronic Press and its procedures for publication and for assurance of document integrity, please refer to its www home page: http://www.ep.liu.se/. © Tim Cifuentes VargasFörord
Först och främst vill jag tacka Elias Norström VD på Gastrogate för idén till själva projektet och kontinuerlig guidning i projektet.
Sedan vill jag tacka Anders Fröberg för utmärkt handledning. Sist men inte minst vill jag
Sammanfattning
Det här är ett examensarbete gjort på uppdrag av Gastrogate AB. Målet med examensarbetet är att utvärdera projektmetodiken Scrum i en grupp med endast en utvecklare. För att undersöka detta applicerades metoden genom att utveckla ett mobilt säljstöd i from av en mobilapplikation. Under projektet förarbete beslutades det att applikationen skulle byggas för iPad i Objective-C. Projektmetodiken anpassades för en projektgrupp med endast en utvecklare. Tillexempel hölls inga dagliga möten och rollen Scrum master tilldelades utvecklaren. Arbetet delades upp i tre sprintar. I början av varje sprint hölls ett möte där implementerad funktionalitet visades upp och reflekterades över. Under mötet planerades även den efterföljande sprinten. Resultatet av studien visar att det är möjligt att genomföra projekt med metodiken Scrum även om projektgruppen är väldigt liten. Flera av Scrums fördelar kan ändock tillgodoräknas. En grupp bestående av endast en utvecklare är dock i minsta laget och fördelarna med Scrum blir sannolikt fler om gruppen består av åtminstone två utvecklare.
Innehållsförteckning
1Inledning ... 6
1.1
Syfte ... 6
1.2
Frågeställning ... 6
1.3
Avgränsning ... 6
2
Bakgrund ... 7
2.1
Beskrivning av scrum ... 7
3
Metod ... 10
3.1
Triangulering ... 10
4
Resultat ... 11
4.1
Anpassning av Scrum ... 11
4.2
Tekniskt förarbete ... 11
4.3
Första sprinten ... 12
4.4
Andra sprinten ... 14
4.5
Tredje sprinten ... 16
4.6
Triangulering ... 17
5
Diskussion ... 20
5.1
Scrum för mindre projekt ... 20
5.2
Tidsestimeringar ... 21
5.3
Uppstartstid ... 21
5.4
Hantering av stora datamängder ... 21
6
Konklusion ... 22
7
Referenser ... 23
Figurförteckning
Figur 1 Autentisering, användarnamn och lösenord ... 18Figur 2 Autentisering, pinkod ... 18
Figur 3 Huvudmeny ... 19
Figur 4 Kundlista ... 19
Figur 5 Kundmeny ... 19
Figur 6 Kundinformation ... 19
Figur 7 Kundnoteringar ... 19
Sida 6
1
Inledning
Idag finns det flera projektmetodiker för mjukvaruutveckling. Det här examensarbetet är utfört i samarbete med företaget Gastrogate AB. Företaget tillhandahåller idag en restaurangguide där restaurangbesökare kan söka bland restauranger och deras menyer. I dagsläget har företaget fem till tio säljare ute i fält som arbetar med att värva nya kunder. Säljarna har tillgång till intern information om kunderna i företagets intranät. För att undersöka om en agil projektmetodik passar företaget har företaget valt att utvärdera detta genom att utveckla en applikation för mobilt säljstöd. Företaget har i nuläget endast en webbutvecklare. Därför kommer scrum i detta examensarbete att anpassas till en mindre projektgrupp. Idag behöver säljaren tillgång till en dator för att mata in information från kundmöten, vilket är komplicerat att göra ute i fält. Säljaren behöver även kunna hitta restauranger i närheten för att använda sin tid mer effektivt och spontanboka möten med restauranger där hen befinner sig för tillfället. Genom att utveckla en applikation för detta kan säljarens vardag effektiviseras.1.1 Syfte
Huvudsyftet med projektet är att undersöka hur väl projektmetodiken scrum fungerar i ett enmansprojekt. Detta innebär tillexempel att studera om fördelarna med scrum erhålls i ett projekt med endast en utvecklare. Tanken är att anpassa scrum för en mindre projektgrupp och hitta en projektmetodik som företaget kan använda i andra projekt. Efter sökning i databasen Google Scholar och IEEE har undertecknad ej funnit några tidigare studier på hur man kan anpassa scrum till ett projekt med endast en utvecklare. Det här examensarbetet syftar därför till att undersöka detta. Det finns studier som undersökt appliceringen av Scrum i mindre grupper, där mindre grupper definierats som upptill tio projektmedlemmar [1] eller tre till fem personer [2]. Således saknas forskning inom området och examensarbetet syftar till att utreda detta.1.2 Frågeställning
För att kunna besvara syftet har undertecknad valt nedanstående frågeställning. Med välfungerande avses huruvida projektmetodiken är applicerbar på mindre projekt. Är Scrum en välfungerande projektmetodik för enmans projekt?1.3 Avgränsning
Att utveckla en applikation är endast ett medel för att nå syftet med examensarbetet. Därför finns avgränsningen att applikationen ej behöver vara färdigutvecklad vid examensarbetsavslut. Konsensus med företaget är att endast en grund för framtida utveckling ligger inom examensarbetets omfattning.Sida 7
2
Bakgrund
Det finns flera olika slags projektmetodiker som syftar till att organisera IT-projekt samt förbättra arbetet och utfallet. En tidigare väl använd projektmetodik heter Vattenfallsmetoden, enlig den metoden drivs projektet utifrån ett linjärt flöde med fokus på förarbete och dokumentation. [1] Ett nyare angreppssätt är att använda agil projektmetodik vilket istället bygger på frekvent kommunikation och fortlöpande återkoppling. Vid agil utveckling ligger fokus på att reflektera över det som implementeras och att beställaren involveras i projektet. [2] I denna studie har den agila utvecklingsmetoden Scrum valts, detta utifrån företagets önskemål. Det finns flera studier om projektmetodiker, Dybå and Dingsøyr systematiska review [3] har undersökt resultatet från trettiosex empiriska studier för att utreda om agila metoder har någon fördel jämfört med enkelriktade metoder. I en enkelriktad metod genomgår utvecklingsprocessen stegvis, utan återkoppling till föregående steg i processen. Resultatet från studien var att det ej finns något tydligt svar på frågan. Evidensen bedömdes därutöver vara låg då de ingående studierna hade ingående brister i studiedesignerna. Olika studier har även fått olika resultat i de olika angreppssätten. Huruvida en projektmetodik påverkar resultatet kan antas bero på många olika faktorer. Till exempel kan implementeringen av agil utveckling försvåras om resterande del av företaget använder en linjärmetod. Detta resultat stämmer väl överens med Senapathi och Srinivasans studie som identifierat flera nyckelfaktorer som anses påverka utfallet av vald projektmetodik [4]. Ytterligare en faktor som påverkar utfallet är projektgruppens storlek. Det finns indikationer som visar att fler projektmedlemmar inte nödvändigtvis ökar produktiviteten, utan snarare minskar den. Konsensus inom mjukvaruutveckling är att mindre grupper är mer produktiva inom mjukvaruprojekt. Detta då behovet av kommunikation inom gruppen växer med ökad projektgruppsstorlek. [5] Scrum Guides rekommenderar en projektgruppsstorlek på tre till nio utvecklare [2].2.1 Beskrivning av scrum
Scrum är en agil projektmetodik som bygger på kommunikation och inkrementella projektmål. Nedan följer en kort beskrivning av hur Scrum tillämpas. Detta baseras på information från upphovsmännen till Scrum, Jeff Sutherland och Ken Schwaber. [2]2.1.1 Roller
I Scrum finns det tre olika roller. Dessa är Produkt ägare, Scrum master och Utvecklare. Dessa roller bör innehas av olika personer för bästa resultat.2.1.1.1 Produkt ägare
Ansvarar för Product backlog samt sköter kommunikation mot kunden. Produkt ägaren är den enda projekt medlemmen som får lägga till delmål till backlogen. En Produktägare kan ansvara för flera projekt.2.1.1.2 Scrum master
Den här rollen har till uppgift att coacha gruppen och att se till att de följer Scrums som arbetsmetodik. En Scrum master kan ansvara för flera projekt.Sida 8
2.1.1.3 Utvecklare
En självorganiserande grupp som består av maximalt tio personer. Utvecklarna tillsammans med produktägaren planerar arbetet. En viktig del i Scrum är att utvecklarna bör ha överlappande färdigheter för att kunna arbeta tvärfunktionellt.2.1.2 Product backlog
En lista med alla uppgifter i projektet innehållandes en kort beskrivning och prioritering. Sköts och ägs av produkt ägaren. Product backlog kan fyllas på och ändras under projektets gång, dock endast av produkt ägaren.2.1.3 Sprint
En sprint motsvarar ett delmål i projektet. Sprinten skall ha en deadline satt som ej får flyttas fram. Vanligtvis är en sprint mellan en vecka och en månad lång. Målet med varje sprint är att leverera ett fungerande förbättring av projektet.2.1.3.1 Sprint planning
Varje sprint inleds med att projektmedlemmarna väljer uppgifter från product backlog. I det här mötet närvara samtliga projektdeltagare. Under det här mötet skapas en sprint backlog som består av de uppgifter från product backlog som utvecklarna har åtagit sig att färdigställa under sprinten.2.1.3.2 Scrumboard
För att visualisera arbetet brukar man kunna använda en Scrumboard som kan visualiseras både digitalt och analogt. I analogt utförande kan man använda en tavla med följande kolumner: • To do • In progress • Test • Done Under sprint planning fyller man To do kolumnen med lappar som symboliserar de uppgifter som projekt gruppen har åtagit sig att utför under sprinten. När en utvecklare börjar arbeta med en uppgift flyttas en lapp från To Do till In progress. När utvecklaren är klar med uppgiften flyttas uppgiften till Test där en annan utvecklare kan ta testa funktionaliteten. Om resultatet fungerar flyttas lappen till Done. På så vis kan en projektledare enkelt se visuellt hur projektet fortlöper.2.1.3.3 Daily scrum
Detta är en av de viktigaste delarna i Scrum. Det här delmomentet hjälper till att uppnå transparens i projektet. Tanken med de dagliga mötena är att tidigt identifiera hinder och problem i projektet. En Daily Scrum bör ej vara längre än 15 minuter. Under en Daily Scrum får endast dessa tre frågor besvaras och diskuteras. • Vad har jag gjort sedan igår? • Vad ska jag åstadkomma till imorgon? • Vad hindrar mig?Sida 9
2.1.3.4 Sprint review
Ett möte tillsammans med produktägaren och kunden där status för den aktuella sprintens delmoment redovisas. Därefter demonstreras färdigställd funktionalitet. Mötets deltagare består av utvecklaren och kunden och skall hållas i slutet av varje sprint.2.1.3.5 Sprint retrospective
Under det här mötet är vanligtvis endast Utvecklarna och Scrum master närvarande. Syftet med mötet är att diskutera hur arbetet fortlöpt och vad man kan förbättra i nästa sprint.Sida 10
3
Metod
Detta projekt syftar till att undersöka hur väl Scrum kan tillämpas i ett projekt med en utvecklare. Med anledning av detta följer projektet Scrums regelverk med modifieringar som återfinns under kapitlet Resultat.3.1 Triangulering
För att möjliggöra att undersöka hur väl scrum fungerar, som projektmetodik med endast en utvecklare, valde undertecknad att triangulera resultatet. Triangulering valdes som utvärderingsmetod eftersom det ger möjlighet att belysa frågan ur olika perspektiv. Triangulering ger därför ett mer objektivt resultat samt ökad validitet. Denna studie är kvalitativ i och med att den syftar till att mäta hur väl en projektmetodik fungerar. Då detta är ett abstrakt mått har undertecknad valt att mäta resultatet genom att triangulera mellan de olika projektdeltagarnas perspektiv samt projektets utfall. Att både beställare samt utvecklare är tillfredsställda med projektmetodiken är därför mått på hur väl projektmetodiken fungerar. Ytterligare ett viktigt mått är hur slutprodukten ser ut. Följande tre perspektiv valdes: • Utvecklarens erfarenhet och upplevelse av arbetsmetodiken • Beställarens erfarenhet och upplevelse av arbetsmetodiken • Projektets slutprodukt3.1.1 Utvecklarens erfarenhet och upplevelse av arbetsmetodiken
En av de viktigaste egenskaperna med en projektmetodik för mjukvaruutveckling är att den ger projektmedlemmarna stöd under projektets gång. Det här perspektivet ger utvecklaren möjlighet att uttrycka sina åsikter om hur väl det har fungerat att arbeta som ensam utvecklare i projektet.3.1.2 Beställarens erfarenhet och upplevelse av arbetsmetodiken
Målet med ett projekt är att nå ett fördefinierat resultat, som är satta utifrån en beställares önskemål. I ett agilt projekt, vilket det här examensarbetet har som syfte att undersöka, är beställaren djupt involverad i projektet fortgång. Beställarens erfarenhet och upplevelse av arbetsmetodiken är således vital.3.1.3 Projektets slutprodukt
I det här projektet kommer en mjukvaruprodukt att utvecklas, dock ryms det ej inom projektet ramar att slutföra mjukvaran. Således är det intressant att undersöka hur långt utvecklingen har produkten ha kommit vid projektets avslut.Sida 11
4
Resultat
Utvecklingen av applikationen organiserades enligt den egna versionen av scrum, vilken har presenterats under kapitlet metod. För att få en överblick över projektets omfattning inleddes projektet med en initial planering där övergripande funktionella önskemål togs upp.4.1 Anpassning av Scrum
Då detta examensarbete syftar till att undersöka hur väl scrum fungerar i enmans projekt har följande justeringar av projektmetodiken antagits.4.1.1 Roller
Elias Nordström på Gastrogate AB fick rollen som produktägare samt beställare, och skötte därmed prioriteringen av product backlog och de affärsmässiga besluten. Som tidigare nämnts bestod projektgruppen endast av en utvecklare, Tim Cifuentes Vargas. Enligt Scrums regelverk bör Scrum master ej vara samma person som utvecklaren eller produktägaren. I och med projektets ringa storlek tillämpas ej rollen som scrummaster.4.1.2 Sprint
Sprintarnas längd sattes till fem arbetsdagar för att hinna med totalt tre stycken iterationer. Vid planeringen av en sprint valdes uppgifter från product backlog och bröts sedan ner i mindre delar innan de placerades i sprintens egen backlog. Daily scrum hanterades genom att varje dag notera svaren på de tre frågorna, nämnda i 2.1.3.3. Varje sprint avslutades med ett möte där implementerad funktionalitet demonstrerades, arbetets fortskridande reflekterades över och nästa sprint planerades. I vanliga fall deltar ej produktägaren på Sprint retrospective. Dock valde vi ändå att Elias Nordström skulle delta för att möjliggöra diskussion av förbättringsmöjligheter i arbetet. Visualisering av planeringen hanterades med online-verktyget ScrumDo. Detta gav oss en digital Scrumboard som fungerar i enlighet med 2.1.3.2.4.2 Tekniskt förarbete
För att undersöka omfattningen av implementationsdelen tillverkades skisser med förslag på hur de olika vyerna skulle implementeras. Det diskuterades fram en överskådlig plan angående applikationens utförande och önskad funktionalitet. Vi bestämde även vilken plattform applikationen skulle byggas för.4.2.1 Säkerhet
För att inte utomstående individer skulle få tillgång till Gastrogates interna system har vi lagt fokus på säkerhet. Första gången applikationen startas efterfrågar den användarens namn och lösenord. Det skickas sedan krypterat till Gastrogate där servern autentiserar användare mot det befintliga systemet och returnerar en cookie, vilken är giltig i tjugofyra timmar. För att använda den lagrade cookien kommer säljaren att behöva använda en 4-siffrig kod, vilket möjliggör säker hämtning och uppladdning av interndata. All kommunikation sker krypterat över HTTPS.4.2.2 Val av plattform
Att välja plattform är ett viktigt beslut som kan få stora konsekvenser längre fram i produktens livscykel. I dagsläget finns det en mängd olika plattformar som lämpar sig för tablet applikationer. Till exempel iOS, Android och webbteknik. iOS valdes tidigt eftersom säljarna redan har iPhone och handledaren önskade att applikationen skulle kunna köras native på iPad och iPhone.Sida 12 Trots detta granskade vi möjligheterna att göra applikationen med webbteknik så som HTML5, JavaScript och CSS. För att jämförelsen ska bli rättvis undersöktes ramverket jQuery Mobile som är väl utbyggt med stöd för övergångar, tabellvyer och diverse grafiska element vilket gör att en webbsida beter sig mer som en native- applikation. Ramverket har stöd för det flesta mobila plattformar som används idag. Vi valde dock att bygga applikationen i Objective C för iOS. En bidragande orsak till detta var undertecknads erfarenhet av just detta. En annan anledning var att en applikation som implementeras med webbteknik skapar ett extra lager mellan hårdvaran och applikationen eftersom den körs i en webbläsare. På grund av detta blir en applikation som skrivs direkt för plattformen snabbare och har färre begränsningar.
4.2.3 Önskad funktionalitet
För att applikationen skulle kunna effektivisera säljarnas vardag behövdes en stor mängd funktionalitet implementeras. Vi var dock väldigt medvetna om att all funktionalitet inte kommer att kunna levereras inom ramen för det här examensarbetet. Följande funktionalitet var önskad: • Säker kommunikation och autentisering. • Sökbar vy där alla restauranger i systemet listas. • Restaurang-vy med detaljerad information som till exempel noteringar, fakturor, besöksstatistik och säljmöten. • Kart-vy där alla anslutna restauranger visas. Icke anslutna restauranger skall även de visas med hjälp av externdata. • Planerings-vy för säljmöten. Säljaren skall kunna se tidigare och kommande möten. Alla vyerna skall inhämta information från Gastrogates interna system och i stor utsträckning lagras lokalt.4.2.4 Product backlog
Den initiala planeringen resulterade i en välfylld product backlog och ett antal designskisser över applikationens vyer. Sedan prioriterades vyernas implementation efter beställarens önskemål. Tanken med projektet var att bygga grundstommen i en applikation vars omfattning sträcker sig utanför examensarbetets ramar. De vyer och den funktionalitet som placerades i product backlog: • Användarautentisering mot server • Applikationens huvudmeny • Lista över alla restauranger i systemet med sökfunktion • Vy med allmän information om vald restaurang • Vy med noteringar gjorda om vald restaurang • Vy med säljnoteringar gjorda om vald restaurang • Vy med besöksstatistik från restaurangens hemsida • Vy med faktureringshistorik för vald restaurang • Kartvy som kan användas för att hitta restauranger i närheten All data skall hämtas via ett API som producerades under projektets gång i samband med implementationen av respektive vy.4.3 Första sprinten
Målet med sprinten var att starta igång projektet, sätta upp arbetsmiljön och bygga grundenSida 13 till applikationen som t.ex. användarautentiseringen och applikationens huvudmeny.
4.3.1 Planering
Under planeringen av den här sprinten valdes följande två uppgifter från product backlog: • Användarautentisering mot server. • Applikationens huvudmeny.4.3.1.1 Säkerhet
Autentiseringen skulle bestå av ett API dit klienten skickar användarnamn, lösenord och udid. APIet svarar då med en token som är giltig i 24 timmar. Både servern och klienten validerar att token fortfarande är giltig. Om användaren har en giltig token kan denne autentisera sig lokalt med hjälp av en pinkod som hanteras av klienten. Anger användaren rätt pinkod skickas token till servern för kontroll ifall den är giltig. Om användaren stänger applikationen och öppnar den inom 5 minuter krävs ingen pinkod. Är applikationen inaktiv i mer än fem minuter eller mindre än 24 timmar kan användaren använda pinkoden för att autentisera sig. Efter 24 timmar kräver applikationen att användaren autentiserar sig med användarnamn och lösenord. För att få en bättre bild av autentiseringsprocessen skapades ett flödesdiagram, se ”Bilaga 1 – Autentiseringsprocessen”. För att realisera detta skapades ett API som autentiserar användare mot företagets befintliga användardatabas. På klienten behövdes en klass för hantering av autentiseringens logik som öppnar pinkod eller login dialogen vid behov.4.3.1.2 Huvudmenyn
Applikationen var tänkt att bestå av en huvudmeny där man kan välja mellan en restauranglista och en kart-vy. Tanken var att det i efterhand ska vara enkelt att lägga till fler huvud vyer. Som utgångspunkt bestämdes att detta skulle lösas med en av de inbyggda vy-kontrollerna. I det här fallet bestående av två kolumner där högerkolumnen var tänkt att användas som meny och vänsterkolumnen för innehåll.4.3.2 Implementering
Utvecklingsmiljön kördes lokalt på min dator vid testning och applikationen klarade av att validera användare mot den befintliga användardatabasen. Det fanns tyvärr inte tid till att påbörja byggandet av huvudmenyn. För att generera pinkodsdialogen användes ett bibliotek vid namn PinCode. Biblioteket ger samma utseende och beteende som iOS egna pinkodsdialog. Autentiseringen fick även möjligheten att köra ett block med kod ifall den går igenom.4.3.3 Reflektioner
Tyvärr fanns det inte tid till att implementera alla delmoment som hade planerats för den första sprinten. Detta berodde på att det tog längre tid än väntat att sätta upp en lokal utvecklingsmiljö bestående av PHP-ramverket Buzzmix. En utav anledningarna till att det tog väldigt lång tid är att Buzzmix helt saknar dokumentation. Dessutom kräver utvecklingsmiljön en rad andra komponenter som till exempel fulltext sökmotorn Sphinx, vilken inte var helt smärtfritt att installera. Vid implementationen av användarautentiseringen stötte undertecknad inte på några större hinder. Dock fanns det ej tid till implementationen av huvudmenyn på grund utav att sprinten tog slut. Implementationen av huvudmenyn flyttades därför tillbaka till product backlog.Sida 14
4.4 Andra sprinten
Under den här sprinten skulle en sökbar lista över alla restauranger byggas. All data som listan använder skall lagras lokalt. Eftersom huvudmenyn inte byggdes under den föregående sprinten lades den uppgiften in i den här sprinten.Sida 15
4.4.1 Planering
Följande uppgifter valdes från product backlog: • Huvudmenyn • Restauranglistan med sökbarhet och lokal lagring av data. • Visa alla restauranger eller endast kunder i restauranglistan. • ”Pull to refresh” i restauranglistan.4.4.1.1 Huvudmenyn
Huvudmenyn planerades, precis som i föregående iteration att implementeras med en vy bestående av två kolumner där högerkolumnen var tänkt att användas som meny och vänsterkolumnen till innehåll.4.4.1.2 Restauranglistan
Restauranglistan skulle implementeras med en standard tabellvy. Som datakälla används Core Data vilket är Apples egen ORM-databas för iOS. Sökbarhet i tabellen skulle implementeras med en sökruta högst upp i tabellvyn. I Tabellvyns UINavigationController placeras en UISegmentedControl för att välja mellan att visa alla restauranger i systemet eller endast kunder. Restauranglistan skulle även förses med ”Pull to refresh” funktionalitet vilket återfinns i många populära applikationer, till exempel Facebooks iOS-applikation. ”Pull to refresh” innebär att när man är högst upp i en vy går den att fortsätta dra och om man drar den tillräckligt långt visas en snurrboll som indikerar att vyns innehåll laddas om.4.4.2 Implementering
Huvudmenyn var från början tänkt att implementeras med en två kolumns-vy- kontroller. Istället användes ett externt bibliotek, FRLayeredNavigationController (FRLNC). Detta på grund av att navigeringen inte var möjlig att lösa på ett smidigt sätt med en UISplitViewController då denna endast kan ha en huvudmeny med detaljerade vyer. FRLNC efterliknar beteendet hos flera kända iPad-applikationer. När en ny vy öppnas glider den in över den föregående vyn med en offset. Det hela resulterar i att man kan skapa en intuitiv och dynamisk navigering i hierarkin av vy- kontroller. Restauranglistan implementerades precis som planerat med en UITableViewController. Även sökningen implementerades som planerat. Listan hämtar data från en lokal Core Data databas. För att fylla den lokala databasen skapades ett API för hämtning av restaurangernas grunddata till restauranglistan. Det fanns tyvärr inte tillräckligt med tid att implementera ”Pull to refresh” och möjligheten att välja mellan att endast visa befintliga kunder eller alla restauranger i systemet.4.4.3 Reflektioner
Under byggandet av huvudmenyn skrotades idén att använda en UISplitViewController för navigeringen. Detta berodde på att navigeringen inte gick att få till på ett bra sätt i en menyhierarki med flera nivåer. Istället ägnades tid åt att hitta ett externt bibliotek för att uppnå lagerbaserad navigering likt Twitters iPadapp. Tre bibliotek valdes ut för noggrannare undersökning och testning. Dessa var FRLayeredNavigationControllerxi, PSStackedView xii och StackScrollViewxiii. Efter att ha testat demonstrationsapplikationer från de tre biblioteken valdes FRLayeredNavigationController eftersom funktionaliteten i deras demo var exakt de som eftersöktes. Dokumentationen av biblioteket upplevdes även väldigt komplett. Detta gjorde att det var simpelt att påbörja användandet av biblioteket.Sida 16 Något annat som tog betydligt längre tid att implementera än planerat var uppdaterandet av Core Data med data från APIet. Tanken var att applikationen skulle lagra stora delar av företagets data lokalt då säljarna ofta befinner sig på platser med bristfällig internetuppkoppling. Totalt innehåller registret 10 000 restauranger, där ungefär en tiondel är aktiva kunder. Resterande restauranger består av gamla kunder och restauranger företaget har kontaktat tidigare. För att lösa problemet gjordes först ett försök med att radera alla poster i databasen och lägga in de nya. Det gjordes även försök med att uppdatera alla befintliga poster i databasen, likt ”ON UPDATE” skulle ha använts i en SQL databas. Tyvärr hjälpte inget av dessa och för att lösa problemet gjordes tester för att hitta flaskhalsen i importen av data. Det som upptäcktes var att tog väldigt lång tid att söka fram objekt med Core Data. Att radera objekt blev därför väldigt tidsödande eftersom man måste göra det per objekt. Att uppdatera objekt var ännu sämre ur prestanda synpunkt eftersom man måste plocka fram ett objekt i taget och kolla om något har ändrats. Slutsatserna av detta blev att i framtiden bygga ett API som endast skickar de poster som ändrats och uppdatera de befintliga posterna. Detta bör fungera tillfredställande eftersom de över 10 000 posterna inte ändras särskilt ofta. I samråd med min handledare på företaget beslutade vi att det skall göras utanför exjobbet.
4.5 Tredje sprinten
Under den föregående sprinten implementerades en listvy innehållandes alla restauranger i systemet. Under den här sprinten byggdes listvyn ut med en detaljerad vy för varje restaurang i listan.4.5.1 Planering
Följande uppgifter flyttades fram från förra sprinten: • Visa alla restauranger eller endast kunder i restauranglistan. • ”Pull to refresh” i restauranglistan. Följande uppgifter valdes från product backlogen: • Detaljerad meny för enskilda restauranger • Vy, API och lagring för allmän information om vald restaurang • Vy, API och lagring för noteringar gjorda om vald restaurang • Vy, API och lagring för säljnoteringar gjorda om vald restaurang Tanken är att den detaljerade menyn skall nås genom att klicka på en restaurang i restauranglistan. I den menyn ska man kunna välja mellan de tre nedersta punkterna.4.5.2 Implementering
Att lägga till möjligheten att endast visa aktiva kunder i restauranglistan var inte svårt och implementerades snabbt. Möjlighet att filtrera sökresultaten var inte heller något problem då de implementeras med standardkomponenter. Dock var det inte lika enkelt att få dessa två att fungera tillsammans. För att implementera ”Pull to Refresh” i restauranglistan användes standardkomponenter vilket gjorde det väldigt smärtfritt. Den detaljerade menyn tillsammans med den allmänna informationsmenyn och noterings-vyn implementerades även de utan större svårigheter. Det byggdes även ett API för att hämta information från servern och lagra informationen lokalt.Sida 17 Tyvärr fanns det inte tid till att implementera vyn med säljnoteringar.
4.5.3 Reflektioner
Den tredje och sista sprinten var den som nästan gick enligt plan. Efter två veckors arbetande med iOS blev det mycket lättare att planera och uppskatta hur mycket arbeta som skulle hinnas med. Detta ledde till att nästan allt hans med under sprinten. Allting kunde lösas med standardkomponenter som undertecknad redan arbetat med vilket gjorde att väldigt lite tid ägnades åt efterforskning och onödigt krångel. Tyvärr medför användandet av iOS standardkomponent för ”Pull to refresh” att applikationen inte kan köras med iOS version under 6.0. Detta kommer dock inte att bli något problem eftersom vi kommer ha full kontroll över de enheter som skall köra applikationen. Att bygga APIer och spara dess data till Core Data för att sedan hämta ut informationen och sedan skapa en tabellvy gick väldigt smidigt för den allmäna informations-vyn och noterings-vyn. Detta beror till största del på att hela applikationen bygger på det förfarandet.4.6 Triangulering
För att kunna ge svar på projektets frågeställning belystes ämnet utifrån tre olika perspektiv med så kallad triangulering.4.6.1 Erfarenheter och upplevelser
Varken utvecklaren eller beställaren hade tidigare erfarenhet av att arbeta med scrum eller annan agil projektmetodik. Både utvecklaren och beställaren var i överlag nöjda med vald projektmetodik. Båda två ansåg att det var lämpligt och fördelaktigt att dela upp arbetet i sprintar. Beställaren menade att det var bra eftersom det belyste vilka uppgifter som skulle göras, när dessa skulle utföras och vad som ej blev gjort. På så sätt förtydligades projektets planering och framskridande. Utvecklaren upplevde att scrum var en gynnsam projektmetodik då det var bestämt vad som skulle utföras under den aktuella sprinten. Det innebar således ett tydligt fokus i arbetet och eftersom omfattningen i varje sprint var ganska liten blev varje delmoment överskådligt. För utvecklaren var det smidigt att lägga in nya idéer i product backlog och låta sprinten fortgå som planerat. På så sätt fanns möjlighet att göra klart de planerade uppgifterna och sedan ta diskussionen om prioritering av de nya idéerna under den kommande sprintplaneringen. Både utvecklaren och beställaren upplevde det positivt att alla nya idéer och önskemål hanterades i product backlog. Vid nästkommande sprintplanering upplevdes det värdefullt att uppgifterna i product backlog var prioriterade och estimerade. För beställaren var det ovant och delvis prövande att sprintarna skulle utföras oavbrutet från början till slut. I och med att projektet saknade scrummaster, då det endast bestod av två personer, fick utvecklaren ta diskussioner kring backlogen vilket annars ej hade skett. Detta medförde att utvecklaren behövde ta tid från det faktiska arbetat för att utföra dessa uppgifter. Något varken utvecklaren eller beställaren upplevde positivt var felaktiga estimat. Utvecklaren ansåg att det var svårt att bedöma i förväg hur lång tid en uppgift skulle ta samtidigt som beställaren önskade att uppgifterna blev klara enligt estimaten. Att arbeta ensam som utvecklare upplevdes som en stor nackdelen då det innebar att denne ej kunde diskutera estimat samt tekniska lösningar med annan utvecklare. Detta medförde att utvecklaren stundtals erfor att det blev svårare att uppnå bra resultat.Sida 18 Vid slutet av projektet fanns en testbar produkt, den var dock ej så fullständig som planerad. Tekniska svårigheter gjorde att alla estimat ej kunde hållas, dessa tekniska svårigheter berodde i sin tur på att utvecklaren saknade kompetens inom området.
4.6.2 Projektets slutprodukt
Efter de tre sprintarna var en stor del av applikationens grund implementerad. De punkter från den ursprungliga backlogen, som blev implementerade, var: • Användarautentisering mot server • Applikationens huvudmeny • Lista över alla restauranger i systemet med sökfunktion • Vy med allmän information om vald restaurang • Vy med noteringar gjorda om vald restaurang Det medförde att fem av de nio uppgifterna i den ursprungliga backlogen implementerades under projektet. Scrum bygger på kontinuerliga körbara leveranser vilket innebär att de uppgifter som genomfördes var kompletta och redo att visas för beställaren.4.6.2.1 Autentisering
För att undvika informationsläckage implementerades autentisering mot företagets befintliga användardatabas. Interaktionen med användaren sker genom två vyer. Den ena kräver både användarnamn och lösenord (Figur 1) och den andra kräver endast en fyrsiffrig pinkod (Figur 2). Vyerna används i enlighet med beskrivningen i kapitel ”4.3.1.1 Säkerhet” och ”Bilaga A – Autentiseringsprocessen”. Figur 1 Autentisering, användarnamn och lösenord4.6.2.2 Navigering
Applikationen har en huvudmeny, Figur 3 Huvudmeny, där det alternativet som är implementerat heter ”Restaurang info”. ”Restaurang info”-vyn, Figur 4 Kundlista, består av en lista över alla företagets tidigare kontaktade kunder. Listan kan filtreras med fritextsökning på kundnamn. Det går även att filtrera bort icke kunder vilket går att kombinera med fritextsökningen. Navigationen är lagerbaserad vilket innebär att alla nya vyer som öppnas lägger sig ovanpå de tidigare vyerna med en offset. Klickar man på den Figur 2 Autentisering, pinkodSida 19 synliga delen av en undermeny stänger man den aktuella vyn. Figur 3 Huvudmeny Figur 4 Kundlista
4.6.2.3 Kundinformation
Om man väljer en kund i kundlistan visas en meny, Figur 5, där man kan välja olika typer av information angående den valda kunden. Väljer man ”Allmänt” visas en vy, Figur 6, med kundens basinformation vilket är bland annat adress, telefonnummer och epost. Under meny valet ”Noteringar”, Figur 7, visas en lista över alla tidigare loggade kontakter med den aktuella kunden. Listan innehåller datum, rubrik och information om huruvida det aktuella ärendet är öppet eller stängt. Figur 5 Kundmeny Figur 6 Kundinformation Figur 7 KundnoteringarSida 20
5
Diskussion
Det finns flera projektmetodiker som syftar till att förbättra och effektivisera arbetet, varav Scrum är en av dessa. En fördel med Scrum är den kontinuerliga återkopplingen och diskussionen med beställaren. Jämför med exempelvis Vattenfallsmetoden där all planering görs i början av projektet. Det finns många studier som styrker att Scrum är en bra projektmetodik, men dessa studier baseras på alltifrån tre till tio personer i gruppen [6] [7]. Tidigare studier har ej undersökt hur Scrum fungerar i projekt med endast en utvecklare. Detta är således ett nytt forskningsfält med stora kunskapsluckor. Genom att anpassa Scrum till ett enmansprojekt undersöktes om fördelarna med Scrum ändock fanns kvar och om det således var en välfungerande projektmetodik.5.1 Scrum för mindre projekt
För att kunna använda Scrum med endast en utvecklare behövde metoden förändras, exempelvis hölls ej de dagliga mötena och rollen Scrum master tilldelades utvecklaren. Trots de mindre förändringarna fungerade det bra att arbeta med Scrum under projektets gång. Både utvecklare och beställare upplevde flera fördelar med projektmetodiken. Normalt sett hålls ett dagligt möte där utvecklarna diskuterar projektstatus. Detta valdes dock bort eftersom projektgruppen endast bestod av en utvecklare. Istället var tanken att utvecklaren enskilt skulle ge svaren på de tre frågorna, nämnda under avsnitt 2.1.3.3. Att som ensam utvecklare endast skriva ned svaren tillförde dock ej någon vinst varför denna del togs bort under projektets gång. Hade det varit fler involverade i projektet hade svaren på de frågorna varit viktigare att kommunicera i gruppen. Ett annat frånsteg som gjordes var att ej tillämpa rollen Scrum master. Detta berodde till största del på att projektgruppen bestod av endast två personer. Konsekvensen av beslutet blev i praktiken att produktägaren och utvecklaren delade på rollen och fick således ta större ansvar. Problematiken i detta är att Scrum mastern skall verka som en coach för utvecklaren och ett stöd till produktägaren. Rimligt att anta är att utvecklaren kan lägga större fokus på arbetet om en annan person agerar Scrum master, vars roll delvis består i att skydda utvecklaren från distraktioner. Något som däremot ej ändrades var grunden i Scrum med löpande kommunikation mellan beställare och leverantör i den iterativa processen. Att planera arbetet i sprintar och hämta uppgifter från en backlog var en klar fördel. När man planerar projektets olika delar under projektets gång blir det till exempel lättare att hantera ändrade önskemål från kund. Dessutom kan man hela tiden ta med sig lärdomar från föregående sprinter för att förbättra den resterande implementationen. En möjlig nackdel med detta är att om man jobbar mot en extern kund kan det bli problem om man till exempel jobbar efter en fast prismodell. Det är nämligen lätt att projektet drar ut på tiden eftersom man vid slutet av varje sprint skall reflektera över vad som gjordes och gå tillbaka och rätta till saker. Dock kommer det självklart alltid att uppstå problem och buggar vid mjukvaruutveckling, men med Scrum är det möjligt att ta tag i problem tidigare under projektets gång. Detta eftersom man kanske inte märker av problem i arkitekturen förrän man ska börja implementationsfasen om man arbetar med exempelvis Vattenfallsmetoden. Med tanke på att denna studie endast har undersökt scrum som projektmetodik och dessutom i en högst ovanlig form är det svårt att dra slutsatser angående huruvida utfallet av projektmetodiken Scrum är mer fördelaktig än någon annan projektmetodik i mindre projekt. Tidigare studier har, som tidigare nämnts, kommit fram till att det behövs mer forskning inom området och att det nuvarande kunskapsläget är bristfälligt [3].Sida 21
5.2 Tidsestimeringar
En svårighet under projektets gång vara att estimera tidsåtgång för olika delar av projektet. Detta är ej ett unikt problem för just Scrum eller denna studie utan ett generellt problem. I slutet av projektet blev det dock betydligt enklare att förutse tidsåtgången. När varje del av projektet består av att planera och implementera ett nytt koncept blir det svårt att estimera tidsåtgången på grund av bristen på tidigare erfarenhet att relatera till. Å andra sidan kan man även fundera kring om det resultatet kunnat uppnås ifall projektgruppen bestått av fler utvecklare. Svårigheten med tidsestimeringar innebar att allt som planerats in under sprintarna ej hanns med. I det här projektet gjorde det inte särskilt mycket eftersom målet var att bygga en stabil grund att fortsätta utveckla utanför examensarbetets omfattning. Problemet med tidestimeringarna i projektet beror sannolikt på att undertecknad ej hade särskild stor erfarenhet av ramverken och språken som användes. Med mer erfarenhet hade det blivit mycket enklare att estimera arbetstiden för projektets olika delar.5.3 Uppstartstid
Vid uppstarten av den första delen av projektet, implementationen av autentisering, tillkom oväntade problem. Företaget använder ett egenutvecklat PHP- ramverk som helt saknar dokumentation. För att köra ramverket lokalt behöver man ha en LAMP stack tillsammans med Sphinx. Utöver detta arbetar miljön mot två olika databaser där man behöver plocka ner rätt tabeller lokalt för att miljön skall fungera. Detta är typexemplet på varför den bör finnas en grundläggande dokumentation av komplexa system. Det visar även på fördelarna med att använda allmänt accepterade ramverk. Detta eftersom man kan spara tid då det oftast finns dokumentation tillgänglig.5.4 Hantering av stora datamängder
En viktig del av applikationen var att den skulle fungera med grundläggande data även utan tillgång till internet. Därför skall all grunddata för Gastrogates totalt strax över femtontusen kontaktade restauranger lagras lokalt. Ett förslag var att tömma databasen och fylla den med ny information inför varje uppdatering. Med femtontusen rader i databasen fungerade inte det angreppssättet då det tog mycket lång tid att importera data i databasen. Dessutom är det orimligt att ladda ned cirka 1mb data allt för ofta över en mobil internetuppkoppling. Tyvärr var det inte möjligt att lösa det här problemet i praktiken inom exjobbets ramar. Om möjligt hade en lösning varit att lagra en kopia av databasen lokalt i applikationen från början. För att hålla den lokala databasen uppdaterad hade datum och tidsangivelse lagts in för den senaste synkroniseringen för att på så sätt endast behöva hämta den data som ändrats. Detta borde gå mycket fortare än att ladda in alla femtontusen raderna varje gång.Sida 22
6
Konklusion
Att genomföra mjukvaruprojekt på utsatt tid med önskad funktionalitet är svårt, därför finns olika projektmetodiker för att förbättra förutsättningarna. Resultatet av denna studie visar att en fortgående dialog mellan beställare och leverantör är en grundförutsättning för ett lyckat resultat. Genom att sammanfatta den funktionalitet som skall implementeras och ta ett steg i taget blev det enklare att greppa omfattningen av implementationen. Detta eftersom den fortgående dialogen mellan utvecklaren och beställaren skapar större insikt och förståelse sinsemellan. Möjligheten att under projektet prioritera vilka delar som skulle implementeras var en annan fördel. Vid slutet av varje sprint fick beställaren en demonstration av produktens status. Detta gav beställaren en större kännedom och möjlighet att tidigt i projektet få en bild av hur applikationen kommer att fungera. En lärdom från studien är att agila projekt bör drivas med en lös tidsram eller möjlighet att plocka bort uppgifter, detta för att kunna hålla deadline. Eftersom projektgruppen endast bestod av en utvecklare och en beställare kunde dock inte alla fördelar med Scrum upplevas. Sannolikt skulle det ha varit bättre att ha två utvecklare i projektgruppen. Detta med anledning av att det är lätt att fastna i samma tankemönster och att det blir enklare att lösa komplexa problem vid samarbete mellan flera utvecklare. De dagliga mötena som normalt ingår i Scrum är ett viktigt delmoment eftersom de samlar gruppen och ger utvecklarna möjlighet att flagga för eventuella problem. Utvecklingsprocessen blir helt enkelt mer transparent. Dagliga möten förekom ej i denna studie då projektgruppen bestod av endast en utvecklare. Sammanfattningsvis visar denna studie att Scrum är ett välfungerande arbetssätt vid enmansprojekt. Flera av projektmetodikens fördelar kommer till gagn, dock ej alla.Sida 23
