NETTBUTIKK FOR HELSEPERSONELL

Transkript

1 NETTBUTIKK FOR HELSEPERSONELL Hovedprosjekt ved Høgskolen i Oslo og Akershus Våren 2015 Hanna Tekie Roza Moustafa Camilla Kaasi

2 Denne siden er blank med hensikt. 1-2

3 PROSJEKT NR. 14 Studieprogram: Informasjonsteknologi Postadresse: Postboks 4 St. Olavs plass, 0130 Oslo Besøksadresse: Holbergs plass, Oslo TILGJENGELIGHET OFFENTLIG Telefon: Telefaks: BACHELORPROSJEKT HOVEDPROSJEKTETS TITTEL DATO NETTBUTIKK FOR HELSEPERSONELL PROSJEKTDELTAKERE ANTALL SIDER / BILAG 100 INTERN VEILEDER ROZA MOUSTAFA CAMILLA KAASI HANNA TEKIE G. ANTHONY GIANNOUMIS OPPDRAGSGIVER KONTAKTPERSON DR. AKRAM ORG.NR.: MOHAMMED USMAN AKRAM TLF. NR.: SAMMENDRAG Nettbutikk hvor helsepersonell kan kjøpe artikler. 3 STIKKORD NETTBUTIKK HELSEPERSONELL.NET 1-3

4 Denne siden er blank med hensikt. 1-4

5 Forord Denne sluttrapporten er utarbeidet i forbindelse med hovedprosjektet ved Høgskolen i Oslo og Akershus våren Rapporten er utarbeidet av gruppemedlemmene Roza Moustafa, Hanna Tekie og Camilla Kaasi. Hovedprosjektet har basert seg på å utvikle en nettbutikk for helsepersonell, og ble tilbudt gruppen av oppdragsgiver Dr. Akram høsten Parallelt med utviklingen har vi utført en spørreundersøkelse for å kartlegge vaner hos helsepersonell i forbindelse med kjøp av medisinsk utstyr og uniformer på internett. Vi ønsker å takke alle som har medvirket i prosjektet. En spesiell takk rettes til veileder G. Anthony Giannoumis for hans støtte og ekspertise dette semesteret. I tillegg ønsker vi å takke Sindre Wigre for nyttige tilbakemeldinger på rapporten underveis. Sist men ikke minst ønsker vi å takke alle sykepleiestudentene ved høgskolen som tok seg tid til å besvare spørreundersøkelsen vi utførte i forbindelse med hovedprosjektet. Roza Moustafa Hanna Tekie Camilla Kaasi Oslo,

6 Denne siden er blank med hensikt. 1-6

7 Innholdsfortegnelse 1 Innledning Prosessrapport Spørreundersøkelsen Produktrapport Referanser Brukerveiledning Vedlegg

8 1 Innledning 1.1 Om gruppen Gruppen består av tre studenter ved Høgskolen i Oslo og Akershus som gjennomfører denne oppgaven som hovedprosjekt våren Vi ble kjent med hverandre gjennom første semester på høgskolen, og har samarbeidet ved flere anledninger i løpet av studieperioden. Ettersom vi kjente hverandre godt og tidligere samarbeid har fungert bra, var det naturlig å jobbe sammen på hovedprosjektet. Gruppen består av: Camilla Kaasi 25 år Student ved Ingeniørfag - data Fungerte som kontaktperson med intern veileder. Roza Moustafa 22 år Student ved Ingeniørfag - data Fungerte som Scrum-master og kontaktperson med oppdragsgiver. Hanna Tekie 24 år Student ved Ingeniørfag - data Fungerte som kontaktperson med prosjektansvarlig/faglærer. 1.2 Oppdragsgiver Oppdragsgiver er en lege som driver flere enkeltmannsforetak knyttet til profesjonen sin. Han jobber som turnuslege og er fra februar 2015 ansatt ved sykehuset i Telemark. Vi kom i kontakt med han ved å vise interesse for hans prosjektforslag Bestilling av vaksiner". Prosjektet handler om å oppgradere en utdatert informasjonsside for vaksinering til noe mer moderne og brukervennlig. Det viste seg at dette prosjektet var utdelt til noen andre, men han kunne tilby oss et annet prosjekt, Nettbutikk for helsepersonell. Oppgaven går ut på å utvikle en nettbutikk - med tilhørende administrerende verktøy - for salg av medisinsk utstyr og uniformer. 1-8

9 2 Prosessrapport 2.1 Innledning Organisering av arbeid Scrum Arbeidsflyten i Scrum Hvorfor Scrum Fremdriftsplan Risikoplan Utvikling av oppgaven Kravspesifikasjon Design Teknologi Back- end teknologi C#/ASP.NET Front end teknologi Arktitektur MVC Verktøy Visual Studio Git Trello Ansvar og samarbeid Arbeidsfordeling Møter og kommunikasjon Dokumentasjon Google Drive Scrum møter Dagbok Gjennomføringen av Scrum Scrum- møter Sprinter Hva vi ville gjort annerledes Kundehåndtering Forhold til oppdragsgiver Leveringer Ny teknologi Utfordringer med AngularJS

10 Utvikling av funksjonalitet Utfordringer Bruk av verktøy Kravspesifikasjonen og oppnåelse av mål Prioritert bort Mangler Fremgang Endringer i fremdriftsplan Avslutning Refleksjon Fremtiden

11 2.1 Innledning Vi var i dialog med vår oppdragsgiver fra og med oktober Alle i gruppen var godt kjent med oppgavebeskrivelsen da vi hadde vårt første møte i januar. Noen avgjørelser var tatt på forhånd - etter flere telefonsamtaler med oppdragsgiver: I oppgavebeskrivelsen foreslår vår oppdragsgiver en løsning med bruk av free template, med dette mente han en gratis programvare kalt Zen Cart 1 som har åpen kildekode tilpasset opprettelse og administrasjon av nettbutikker. Gruppen undersøkte hva Zen Cart var, samtidig som vi utpekte fordeler og ulemper ved å benytte nettbutikksystemet. Vi kom frem til at vi ville få mest læringsutbytte ved å utvikle nettbutikken fra bunnen av, ettersom Zen Cart ikke krever programmeringsferdigheter. Vi la frem dette til oppdragsgiver og han syns det var greit. Målet med dette var at oppgaven skulle bli mer tilpasset et bachelorprosjekt. 2.2 Organisering av arbeid Under forutsetning av at kvaliteten på produktet blir påvirket av både arbeidsmiljø og planlegging, bestemte vi oss for å bruke god tid på å sette oss inn i arbeidsmetoder - og benytte den tiden vi kan på planlegging. Ved semesterstart januar 2015 startet planleggingen for fullt. Noe av det første vi gjorde var å avtale møter med vår interne veileder og oppdragsgiver. Vi så på tidligere hovedprosjekter 2 løst av datastudenter ved Høgskolen i Oslo og Akershus, og ble inspirert av blant annet hvordan de estimerte tiden, løste oppgaven og skrev rapportene sine. 1 Zen Cart, 2 «Tidligere Prosjekter», Høgskolen i Oslo og Akershus,

12 2.3 Scrum Vi bestemte oss for å benytte Scrum 3 som rammeverk for organisering av arbeid i prosjektet. Etter å ha hatt emnet systemutvikling (DAFE2200, semester 3) fikk vi innblikk i ulike utviklingsmetoder, derav smidige prosesser som Scrum. Alle i gruppen visste altså hva Scrum innebar men ingen hadde brukt dette som utviklingsmetodikk før Arbeidsflyten i Scrum Scrum er en arbeidsmetode som fasiliterer samarbeid, kommunikasjon og framdrift mellom tre roller i et prosjekt: produkt-eier, Scrum-master og Scrum-team. Produkt-eier sitter med problemstillingen og er «stemmen» til brukergruppen. Scrum-master arrangerer daglige Scrum-møter og holder orden på arbeidsoppgaver. Et Scrum-team er utviklingsteamet. Planleggingen gjøres litt etter litt, og prosessen starter med at man har en visjon for produktet som skal utvikles. For å oppnå denne visjonen defineres et sett med arbeidsoppgaver, eller krav, som må gjennomføres. Utviklingen foregår gradvis med en serie iterasjoner 4, kalt sprinter i Scrum. Etter hver sprint leveres et inkrement 5 av produktet, og kunden kommer med tilbakemeldinger. Arbeidsoppgavene blir prioritert og estimert og lagt i en såkalt product backlog, det vil si en slags oppgaveliste med funksjonalitet som skal implementeres for en sprint av gangen. Under utviklingen holdes daglige Scrum-møter hvor hele teamet deltar og hver deltaker forteller om progresjon siden forrige møte, diskuterer problemer som har oppstått og hva de planlegger å utføre til neste dag. 3 «Prosessmodeller og smidig programvareutvikling», presentasjon fra Universitetet i Oslo, hentet , 4 Iterasjon - en syklus i utviklingen 5 Inkrement - et tillegg i funksjonaliteten som er implementert i et system 2-12

13 2.3.2 Hvorfor Scrum Det vi la vekt på da vi valgte Scrum var først og fremst at vi hadde en anelse om at rammeverket var mye brukt i IT-bransjen. Gjennom studiet har vi vært på flere bedriftspresentasjoner og fagdager, og vi har fått inntrykk av at Scrum er en populær metodikk i arbeidslivet. En annen viktig grunn til at vi valgte Scrum var for å optimalisere kundeverdien. Scrum innebærer at man hele tiden er i kontakt med kunden som gir tilbakemeldinger. Dette er verdifullt for å forbedre produktet, og samtidig levere et produkt som samsvarer forventningene til både kunden og brukerne. Dette gjør Scrum til en fleksibel modell. Vi mente også at gruppen ville ha større tilfredshet av å jobbe i et Scrum-team, hvor man jobber tett sammen, bør ha god kommunikasjon og hjelpe hverandre slik at man unngår flaskehalser og overlappende arbeidsinnsats. 2.4 Fremdriftsplan Vi satte av hele januar til planlegging. Utviklingen skulle starte i februar og pågå frem til april. Vi ble enige om å ferdigstille produktet den 23. april. For å tilpasse arbeidet i denne perioden for Scrum og definere antall sprinter, passet det å ha 5 sprinter; hver sprint på en 2 ukers tidsperiode. Resten av tiden frem til leveringsfristen 26.mai skulle brukes på å bearbeide og forbedre dokumentasjonen. Vi satte opp en arbeidsplan og en fremdriftsplan med milepæler. 2.5 Risikoplan Vi utformet også en risikoplan. Av erfaring fra andre prosjekter mener vi at det er nyttig å ha en risikoplan ettersom at ting kan gå galt, og da er det greit å vite hvordan man skal forholde seg hvis et problem skal oppstå - og forhindre at de oppstår. Risikohåndtering er spesielt viktig i ITprosjekter i tilfelle problemer med dårlig definerte krav og feil estimering av tid. En risikoplan inneholder forutsatt risiko et prosjekt kan komme over, sannsynlighet, konsekvens, tiltak for å forebygge og tiltak for å håndtere utfordringer dersom de bryter ut. Se Vedlegg 3 for hele risikoplanen. 2-13

14 2.6 Utvikling av oppgaven Etter at vi hadde satt oss inn i tidligere prosjekter, satt opp en hjemmeside for gruppen, valgt arbeidsmetode og skrevet noen prosjektdokumenter var vi klare for å definere oppgaven i mindre deler. 2.7 Kravspesifikasjon Oppgaveteksten inneholdt noen krav, men vi avtale med oppdragsgiver at han skulle sende oss en mail med utfyllende krav. Etter å ha fått denne mailen fra oppdragsgiver i midten av januar 2015, startet vi med å utarbeide kravspesifikasjonen - beskrivelse av hvilke brukerfunksjoner og generell ytelse et datamaskin - eller programsystem skal ha. Kravspesifikasjon utarbeides før en datamaskin anskaffes eller et programsystem utvikles, for å sikre at brukernes behov blir dekket når det gjelder funksjonalitet, ytelse og brukervennlighet. 6 Vi delte kravene inn i mindre punkter og skrev dem som brukerhistorier 7 - en eller flere setninger som beskriver hva brukeren av et system ønsker å få ut av systemet. Disse skrives på formen: Som en rolle ønsker jeg funksjon for å oppnå verdi. Vi delte inn brukerhistoriene i funksjonelle (hva et system skal gjøre) og ikke-funksjonelle krav (systemegenskaper og rammer) og førte opp dette i kravspesifikasjonen (se Vedlegg 1 for kravspesifikasjonen). Denne har vi brukt aktivt gjennom hele prosjektperioden. 2.8 Design Et av de høyeste kravene til produktet oppdragsgiver stilte var fint design - utseende på nettbutikken. Det ble nevnt på vårt første møte at han ville se skjelettet til nettbutikken i den første fasen av prosjektet. Vi startet derfor å diskutere designet tidlig. Oppdragsgiver viste oss forskjellige nettbutikker for helsepersonell til inspirasjon. Legebutikken 8 var den første nettbutikken han presenterte for oss. Oppdragsgiver ville ha en tilsvarende nettbutikk, men med andre fargetoner. Han viste oss også Gymo 9 og Vaktrommet Liseter, Ivar M.. (2009, 14. februar). Kravspesifikasjon: IT. I Store norske leksikon. Hentet 10. mai 2015 fra Legebutikken, 9 Gymo, 10 Vaktrommet,

15 Vi noterte oss linkene og ble kjent med nettbutikkenes oppbygging og design. Alle hadde mye til felles spesielt venstrestilt meny, søkefelt på toppen og en annonse med tilbud på forsiden. Vi ble enige om at vi skulle utvikle en nettbutikk som så mer moderne ut enn disse tre. Samtidig var det delte meninger om hvor mye vår nettbutikk skulle ligne på de som allerede eksisterer. For å få frem flere idéer skisserte hvert gruppemedlem et forslag som vi la frem for hverandre og diskuterte. Denne diskusjonen fikk frem hvor mye brukerne egentlig har å si for designet av en nettbutikk. Vi visste ingenting om brukergruppens handlemønster på nett: Når trenger de nye produkter? Hva foretrekker de at skal fremheves av produkter? Bryr de seg om reklame? Alle disse spørsmålene har noe å si for hvordan nettbutikken skal se ut til slutt. Derfor bestemte vi oss for å tilpasse nettbutikken så mye som mulig til brukergruppen. For at dette skulle skje, måtte vi bli bedre kjent med brukergruppen. Vi bestemte oss for at hvert gruppemedlem skulle snakke med bekjente leger og medisinstudenter - der vi tok opp en del punkter som var vanlig for dem når de handler på nett. Ved å ta utgangspunkt i dette, utviklet gruppen tre forskjellige designforslag. Se Vedlegg 5 for disse. Vi var ikke helt fornøyd med designforslagene, og følte ikke vi var klare for til å legge dem frem for oppdragiver. Vi ønsket å bruke mer tid på design, ettersom oppdragsgiver legger veldig stor vekt på dette. Vi innså at vi hadde behov for ytterligere informasjon om målgruppen, og ble enige om at en spørreundersøkelse ville gi oss god informasjon om hva de foretrekker. Vi bestemte oss for at utfallet skulle ha veldig mye å si for våre avgjørelser angående design. Se Spørreundersøkelsen for mer informasjon. 2.9 Teknologi Når det kommer til å utvikle en webapplikasjon, finnes det mange ulike språk, teknologier og rammeverk å velge mellom. Vår løsning er en todelt webapplikasjon som består av back-end og front-end. Back-end er en betegnelse brukt om server-siden av et program. Her skjer alt brukeren ikke ser. Back-end håndterer lagring, oppdatering og endring av data. 2-15

16 Front-end er en betegnelse brukt om klient-siden av et program. Dette er brukergrensesnittet - den delen av programmet brukeren kommuniserer med Back-end teknologi Vi vurderte både C# og Java ved valg av back-end teknologi. I løpet av studiet har vi fått kjennskap til begge programmeringsspråkene. Java har vi brukt mest, vi har hatt undervisning i programmeringsspråket som enkeltemnet Programmering (DAPE1400) og benyttet det i et tidligere prosjekt gjennom emnet Programutvikling (DATS1600). C# har vi erfaring med fra emnet Webapplikasjoner (ITPE3200, semester 5), i forbindelse med en webapplikasjon - der vi brukte C# på serversiden. C#/ASP.NET Vi bestemte oss for å utvikle ved hjelp av C#, ettersom det er en fordel at vi har anvendt C# på tilsvarende måte som vi kommer til å gjøre under dette prosjektet. Videre ønsket vi å ta i bruk.net-rammeverket, som er tett integrert med C# Front end teknologi «Front end-løsningen» består av en kombinasjon av HTML, Javascript og CSS (stilark for HTML). HTML, formateringsspråk benyttet for å lage hypertekst-dokumenter på World Wide Web. Koder, kalt tagger (eng. tags), angir funksjonen til en tekst, det vil si om den er en overskrift, et vanlig tekstavsnitt, en tabell, en punktliste eller en lenke til annen tekst. 11 Vi ønsket å utvikle en «Single Page Application» 12 - en applikasjon som laster en enkel HTMLside, som oppdateres dynamisk etter brukerens interaksjoner. Det finnes flere ulike Javascriptrammeverk man kan benytte seg av under utviklingen av en «Single Page Application». Disse inneholder forhåndsdefinerte metoder som bidrar til å avlaste kodingen på klient-siden. AngularJS 11 Liseter, Ivar M. & Rossen, Eirik. (2009, 24. mars). Html. I Store norske leksikon. Hentet fra 12 Mike Wasson, MSDN Magazine, Single-Page Applications: Build Modern, Responsive Web Apps with ASP.NET,

17 I emnet Webapplikasjoner (ITPE3200) fikk vi en grunnleggende introduksjon til AngularJS 13 helt på slutten av semesteret. AngularJS er et Javascript-rammeverk utviklet av Google for å løse de utfordringene som oppstår under utvikling av Single Page Application. Vårt inntrykk var at AngularJS er et nytt og spennende rammeverk, men vi hadde ikke nok pensum med det, og fikk dermed aldri ordentlig grep om rammeverket. Likevel - for å få mest mulig læringsutbytte - bestemte vi oss for å bruke AngularJS til utvikling av front end-delen. I tillegg har vi fått et inntrykk av at AngularJS er veldig relevant for arbeidslivet. Bootstrap 3 Vi bestemte oss også for å bruke Bootstrap 3 14 som er et front-end rammeverk bestående av HTML, CSS og Javascript. Bootstrap er utviklet av Twitter, og inneholder ferdig CSS kode man kan legge til i et prosjekt for å designe utseende av applikasjoner. Noen fordeler med Bootstrap er: - Man slipper å bruke for mye tid på grunnleggende ting under utformingen - Automatisk tilpasset visning på mobiltelefoner - Bra for senere vedlikehold - Gir en ryddig struktur i HTML-koden - Responsivt design Arktitektur Ettersom AngularJS er et MVC-basert rammeverk, og våre erfaringer med MVC-modellen har vært gode tidligere, besluttet vi å bygge opp prosjektet etter denne modellen. AngularJS bruker en variasjon av MVC og MVVM. 13 Wikipedia contributors, "AngularJS," Wikipedia, The Free Encyclopedia, (besøkt Mai 23, 2015) 14 Chris-Håvard Berge, CHB Studios, Tre nettressurser til webutvikling, besøkt , 15 Responsiv design - kan vises på alle skjermstørrelser 2-17

18 MVC MVC 16 er et designmønster for utvikling av webapplikasjoner. Arkitekturen skiller mellom modell og brukergrensesnitt, og kan kort oppsummeres slik: Model - holder på data View - viser frem data Controller - flytter på data MVC er populært fordi den reduserer kompleksiteten i arkitekturen, øker fleksibilitet og sørger for enklere vedlikehold i koden. MVVM En nyere variant av MVC er MVVM 17 mønster. Denne består av: Model - holder på data ViewModel - en abstrakt representasjon av View View - viser, og sender data til, ViewModel 2.11 Verktøy Ettersom oppdragsgiver ikke satte noen krav til hvordan vi skal utvikle nettbutikken - i forbindelse med valg av verktøy og teknologi - er mange av valgene vi har tatt basert på hva vi lærte var best praksis gjennom studiet. De fleste verktøyene vi har tatt i bruk, har vi enten fått høre om i forelesninger eller gjennom bedriftspresentasjoner. I denne delen er en kort oversikt over hvilke verktøy som har blitt brukt. 16 Tutorials Point, AngularJS MVC Architecture, 17 Mike Wasson, MSDN Magazine, Single-Page Applications: Build Modern, Responsive Web Apps with ASP.NET,

19 Visual Studio Visual Studio 18 er et integrert utviklingsmiljø levert av Microsoft. Utviklingsmiljøet brukes ofte for å utvikle programmer for Windows, men er også ofte brukt for å utvikle websider og webapplikasjoner. Alle på gruppen hadde erfaring med Visual Studio fra tidligere. Siden Visual Studio er levert av Microsoft, og en del av.net rammeverket, passer det godt til teknologien vi har valgt Git For håndtering av versjonskontroll tok vi i bruk noe vi kjenner fra før - Git. NTNU 19 beskriver tjenesten slik: Git er et verktøy for versjonskontroll og kodedeling. Det vil blant annet si at du kan lagre hele historikken til hvordan kode har utviklet seg, og gå tilbake til et hvilket som helst punkt Trello Vi ble kjent med Trello 20 da vi hadde en gjeste-foreleser fra Bekk i emnet Webapplikasjoner (ITPE3200). Han presenterte et Scrum-prosjekt der teamet brukte Trello. Etter dette undersøkte vi hvordan tjenesten fungerte og kom frem til at det ville være et nyttig verktøy for prosjektstyring. Trello er et web-basert prosjektstyringsverktøy levert av Fog Creek Software. I Trello er prosjekter representert som ulike brett, som inneholder forskjellige lister. Listene inneholder kort som kan flyttes mellom dem. 21 I vårt prosjekt inneholdt hvert kort en brukerhistorie fra «product backlogen» som ble tilknyttet eierskap. Oppgavene er sortert og ordnet i den rekkefølgen vi forventer å utvikle dem, og flyttet gjennom listene Må gjøres, Pågående, Under Testing og Ferdig. 18 Wikipedia contributors, "Microsoft Visual Studio," Wikipedia, The Free Encyclopedia, (besøkt Mai 23, 2015). 19 «Git versjonskontroll», NTNU, 20 Trello, 21 Wikipedia contributors, "Trello," Wikipedia, The Free Encyclopedia, (besøkt Mai 23, 2015). 2-19

20 2.12 Ansvar og samarbeid Ettersom gruppen har samarbeidet tidligere, visste vi at fordeling av oppgaver er nøkkelen til et godt samarbeid. Vi hadde den fordelen at vi kjente til gruppemedlemmenes sterke og svake sider, noe som gjorde det enklere å fordele oppgaver - både slik at alle løser noe de mestrer og utfordres Arbeidsfordeling Når det gjelder utviklingen av nettbutikken, jobbet alle medlemmene med back-end, front-end, design og dokumentasjon. Vi ønsket at alle skulle få mest mulig læringsutbytte, og delte ikke ansvar slik at én satt med back-end; det hadde resultert i at dette medlemmet hadde blitt veldig god i C# men ikke mestret front-end teknologien AngularJS i like stor grad. Vi forsøkte å dele brukerhistoriene likt mellom oss. Brukerhistoriene er likevel så forskjellige og krever ulike ferdigheter, at vi ofte har hjulpet hverandre og byttet på oppgavene. Dette har ført til at vi har delt mye kunnskap - og praktisert tettere samarbeid enn om vi hadde jobbet mer individuelt Møter og kommunikasjon Vi hadde flere møter med både intern veileder og oppdragsgiver. I tillegg ble det utvekslet mail kontinuerlig. Vi bestemte at de kun skulle forholde seg til en kontaktperson fra gruppen for utveksling av mail, og eventuelle telefonsamtaler. Gruppen har hatt jevnlig kontakt med veileder gjennom hele prosjektperioden. Under disse møtene fikk vi veiledning om hvordan vi skal lage spørreundersøkelse og analysere resultatet, og hvor viktig det er å behandle kunder riktig. Gruppen er veldig fornøyd med å ha han som veileder. Grunnet en travel tidsplan hos oppdragsgiver har vi ikke hatt så mange møter med han som vi hadde planlagt. For det meste holdt vi kontakten via e-post. Hittil har vi hatt møte med han to ganger i planleggingsfasen og en gang under utviklingen av produktet. 2-20

21 2.14 Dokumentasjon Google Drive Vi brukte Google Drive 22 som verktøy for å holde orden på alle filene vi har hatt gjennom prosjektet. Google Drive er en fillagrings- og synkroniseringstjeneste utviklet av Google. Tjenesten tillater brukere å lagre alle slags filer på en 15 GB gratis lagringsplass - som kan deles med andre brukere. Google Drive gir god støtte for samarbeid. Alle på gruppen kunne opprette, se, redigere og kommentere dokumenter. Hver dokument har også en tilhørende logg over alle endringer slik at man hele tiden har en oversikt over hvem som har endret hva og når. Vi lagret alle salgs dokumenter knyttet til prosjektet i Google Drive, men også for eksempel back-up filer og nyttige videoer Scrum møter Vi utnevnte et gruppemedlem til å fungere som Scrum-master gjennom prosjektperioden. Gruppen opprettet en mal som Scrum-master benyttet etter hvert møte for å skrive et kort referat. Disse referatene ble brukt som en slags logg over hva som var gjort og hvilke problemer vi støtte på underveis Dagbok Gjennom prosjektperioden har vi skrevet dagbokinnlegg på gruppesiden vår. Denne inneholder punkter fra møtene med veileder og oppdragsgiver, samt alle avgjørelser vi har tatt som ikke har noe med koding å gjøre - samt ting som ikke kommer frem ved Scrum-møter. 22 Wikipedia contributors, "Google Drive," Wikipedia, The Free Encyclopedia, (besøkt Mai 23, 2015). 2-21

22 2.15 Gjennomføringen av Scrum Tiden vi hadde satt av for utvikling i fremdriftsplanen var fem sprinter; hver sprint på en to-ukers tidsperiode. Disse sprintene startet med at vi plukket ut de høyst prioriterte brukerhistoriene fra kravspesifikasjonen, og fordelte de på gruppemedlemmene. Arbeid tilknyttet brukerhistoriene ble tidsestimert og lagt i product backlog. Ved estimering benyttet vi oss av planning poker som vi også ble kjent med gjennom emnet systemutvikling (DAFE2200, semester 3). Planning poker fungerer slik at hvert gruppemedlem har en kortstokk med tall som representerer estimater. Alle velger det estimatet de mener oppgaven trenger, og snur kortene på bordet for å avsløre svaret. Dersom det er noen store avvik skal valget begrunnes og gruppen estimerer på nytt. Vi brukte PlanningPoker, en applikasjon som kan lastes ned fra App Store Scrum-møter Hver dag møttes gruppen til et daglig Scrum-møte der hvert medlem svarte på følgende spørsmål: 1) Hva har du gjort siden i går? 2) Hva skal du gjøre i løpet av dagen? 3) Har det oppstått noen problemer eller hindringer? Disse møtene skulle være korte; hensikten er å få en kjapp oversikt og motivasjon på starten av dagen. Vi planla å bruke rundt minutter på hvert møte, men de ble ofte mer tidkrevende enn forventet. Grunnen til dette var at vi gjorde referat av alle møtene, og at vi tok opp diskusjoner og andre problemstillinger i løpet tiden også. Scrum-møtene ble vanligvis holdt, men en gang i blant kunne gruppen sitte hver for seg og jobbe, og da ble det litt mer utfordrende å få til disse møtene Sprinter Vi forsøkte å følge sprintene og gjøre alt som måtte implementeres innenfor hver sprint så langt det strakk til. 2-22

23 Utfordringer med sprinter Vår største utfordring under sprintene var å fullføre alle oppgavene i product backlog. Dette skyldtes oftest at det dukket opp problemer som stoppet fremgang i utviklingen. Vi opplevde også ved enkelttilfeller at vår estimering ikke stemte overens med tiden vi faktisk brukte på en brukerhistorie. I starten av utviklingsperioden fokuserte vi på å løse problemene når de dukket opp, og dette ble en slags flaskehals for enkeltpersoner; man ble sittende over tid med underordnede problemer, noe som hindret framgang i arbeidet. En annen utfordring med sprinter vi ikke var forberedt på, var at strukturen kunne bli verre etterhvert som funksjonalitet ble lagt til. Vi måtte derfor også bruke tid på å restrukturere systemet underveis i utviklingen Hva vi ville gjort annerledes Vi skulle gjerne omdefinert brukerhistoriene i product backlog, slik at den heller hadde bestått av en liste med arbeidsoppgaver som beskriver hva som må implementeres for å lage produktet basert på brukerhistorien, heller enn en beskrivelse av selve brukerhistorien. På den måten ville arbeidet med å utarbeide hvilke funksjonaliteter hver brukerhistorie etterlyser, og dessuten hvordan det skulle løses teknisk flyttes frem i tid og bli en del av planleggingen. Dette hadde gitt en mye bedre oversikt over hva som skulle gjøres, ettersom vi synes brukerhistoriene ofte var for vage og inneholdt for mye funksjonalitet som måtte implementeres. Basert på erfaringer gjennom utviklingen, tror vi at vi kunne satt av kortere sprinter med en tidsperiode på for eksempel en uke. Da kunne vi fordelt færre arbeidsoppgaver i hver sprint, og det ville vært enklere å se hvordan vi ligger an. Det hadde også vært en idé å rangere arbeidsoppgavene fra lett til vanskelig. Det tar vanligvis litt tid før en får forståelse og grep på teknikken og logikken bak et språk. Starter man med å kode funksjonalitet som ikke er så utfordrende i starten, vender man seg til språket man skriver i - dette kan hjelpe veldig når man nærmer seg de vanskelige oppgavene. 2-23

24 Å starte med store og utfordrende funksjonaliteter for å få på plass de grunnleggende delene med en gang, var som sagt med på å skape flaskehalser i vårt prosjekt. Men etterhvert i prosjektet satte vi store problemene litt på vent før vi senere tok tak i dem igjen, og løste de senere. Dette tror vi skyldes at vi i mellomtiden fikk enda mer grep på logikken Kundehåndtering Kundehåndtering er noe intern veileder oppfordret oss til å ta veldig seriøst. I de fleste bransjer så vel som IT-bransjen er det fornøyde kunder som gir bra omdømme. Ettersom Scrum gir god mulighet for å inkludere og samarbeide var planen å vektlegge dette for å skape et så godt forhold til oppdragsgiver som mulig Forhold til oppdragsgiver Helt fra starten var forholdet til oppdragsgiver veldig bra. Praten gikk godt for seg. Vi passet på å være høflige både på møter og e-post. Oppdragsgiver kom med forslag og innspill så vel som vi også presenterte idéer og løsningsmetoder. I tillegg fikk han hele tiden oppfølging på e-post angående hva vi hadde pratet om, og hva vi lurte på videre Leveringer Gruppen hadde to store møter med oppdragsgiver før utviklingen, og planen videre etter det var å møte oppdragsgiver for å levere inkrement etter hver sprint. Oppdragsgiver informerte om at disse møtene kunne bare holdes i helgene - ettersom han er turnuslege og gjennomfører turnustjenester i andre byer på arbeidsdagene. Vi syns dette var greit og prøvde å være så fleksible som mulig. Arbeidsplanen til oppdragsgiver forandret seg gjennom prosjektperioden, og det ble mer og mer utfordrende med leveringer. Til slutt fikk vi kun levert ett inkrement etter den første sprinten, og dette var gjennom et Skypemøte. Oppdragsgiver var lite tilgjengelig resten av prosjektperioden, og vi prøvde å respektere hans hektiske timeplan og forholdt oss til å sende e-post. Dette gjorde at det ble mindre tilbakemeldinger fra legen enn det vi forventet, men vi fikk veldig positive tilbakemeldinger etter første levering, noe som var betryggende for resten av utviklingen. 2-24