TaskIT. Cee Web Kirkegata 1-3 Oslo, OVERSIKT Presentasjon

Transkript

1 Cee Web Kirkegata 1-3 Oslo, TaskIT OVERSIKT Presentasjon Gruppen består av fire tredje-års studenter ved Høgskolen i Oslo og Akershus(HiOA), fakultetet for Teknologi, Kunst og Design(TKD). Det er to studenter fra Dataingeniør studiet og to studenter fra Informasjonsteknologi studiet. Gruppemedlemmene er: Elias A. Thøgersen, INFORMATIK14HA, s Fredrik A. Sigvartsen, HINGDATA14HA, s Jens B. Omfjord, INFORMATIK14HA, s Sander F. Sandøy, HINGDATA14HA, s Andre nøkkelpersoner inkluderer veileder fra HiOA Aiko Yamashita, Førsteamanuensis. Hector Rivas, administrerende direktør og kontaktperson hos oppdragsgiveren Cee Web AS. Oppdragsgiveren Cee Web AS driver til daglig med salg og utvikling av nettsideløsninger som skreddersys til kundens behov. Problemet som skal løses, går ut på å knytte mennesker som tilbyr og har behov for ulike tjenester via en webapplikasjon. Mer spesifikt utvikles det en plattform hvor brukere kan bestille hjelp innenfor kategorier som flytting, ærender og andre oppgaver som ikke trengs noen spesiell kompetanse for å utføre. Brukere skal også kunne tilby sin hjelp til å utføre de utlyste oppdragene innenfor kategorier som den gjeldende brukeren har satt som en jobb han eller hun selv er villig til å utføre. Dette skal løses på en mest mulig effektiv og sømløs måte.

2 Sammendrag Det skal utvikles en webapplikasjon som knytter kunder som trenger en tjeneste utført, sammen med kunder som utfører denne type tjenester. Applikasjonen skal utvikles i samarbeid med Cee Web AS. Det er lagt opp til at det skal utvikles en webapplikasjon for bruk i nettleser som frontend. Samt et API i backend slik at en i fremtiden lett kan lage en Dagens situasjon Cee Web driver per i dag med utvikling av nettløsninger for kunder på bestilling. Dette gjøres ved at det norske salgsteamet innhenter kunder, norske prosjektledere kommuniserer så kundenes ønsker til ExCel. ExCel er et Bangkok basert utvikler team som gjør den største delen av utviklingen for Cee Web AS. Prosjektet er i dag helt i startfasen og det har blitt lagt noen få retningslinjer for hvordan applikasjonen skal fungere og hva slags funksjonalitet som skal implementeres. Gruppen vil være med på planlegging og står for utvikling av applikasjonen. Det nye prosjektet som bachelorgruppen skal være med på skal derimot utvikles i Norge som en bacheloroppga ve. Oppdragsgiver sitt langsiktige mål for prosjektet er å skille det ut i et eget og selvstendig selskap. Problemet Hvis man i dag trenger hjelp med dagligdagse tjenester som å flytte, klippe gresset, løpe ærender eller måke snø må man som regel ut med en god sum penger. Dette fordi en som oftest må til firmaer som tilbyr disse tjenestene. Disse firmaene må betale ansatte, leie av lokale og andre utgifter de har. Ved å introdusere en plattform som knytter privatpersoner som trenger en tjeneste utført, med privatpersoner som tilbyr hjelp innenfor denne tjenesten, får man en mer effektiv løsning. Ved å knytte disse sammen kutter man bort utgiftene firmaene som tilbyr dette har, og en ender dermed opp med en mer lønnsom løsning for alle parter. Man får også muligheten til å få utført disse tjenestene på en mye mer effektiv måte enn man har om man går gjennom et firma. Målet med applikasjonen er å knytte oppdragstakere og oppdragsgivere sammen på en effektiv måte hvor tjenestene leveres når oppdragsgiver selv har tid og som gir arbeid til oppdragstakere når de har tid. Enten det er etter skole, eller ved siden av en annen jobb, eller som en fulltidsjobb. Det finnes konkurrenter der ute som har lignende løsninger. Finn.no Småjobber[1] er en av disse konkurrentene. Hos disse konkurrentene betales det meste i kontanter, og det er alltid en viss sikkerhet for at Finn.no ikke griper inn hvis arbeidsgiver ikke betaler deg. Vi tilbyr en

3 delingsøkonomi løsning, hvor all betaling skjer gjennom appen. Beløpet reserveres når man bestiller en tjeneste, og deles ut til oppdragstakere etter fullført oppdrag. For oppdragstaker er det derimot alltid en viss usikkerhet for at jobben ikke blir utført den dagen man ønsker. Vi ønsker å tilby en litt mer fleksibel modell hvor man kan bestille en tjeneste f.eks bare to timer i forveien, og tilbyr derfor en booking løsning av oppdragstakere. Oppdragsgiver velger dato, tjeneste og lokasjon, så får dem opp en oversikt over alle oppdragstakere som har muligheten til å ta dette arbeidet. Dette øker tryggheten for å få hjelp, hos oppdragsgivere. En annen fordel med Taskit, er muligheten for oppdragstakere å optimalisere sin timeplan. De trenger ikke å bruke utallige timer på å søke på oppdrag de uansett ikke får, Mål og rammebetingelser Målet er å tilby en tjeneste som er enkel å bruke, responsiv og innovativ. Tjenesten skal tilfredsstille følgende mål: Knytte oppdragstakere og oppdragsgivere sammen på en effektiv måte. Enkel registrering for brukere, både oppdragsgivere og oppdragstakere Holde all kommunikasjon mellom oppdragstaker og oppdragsgiver innad i appen, for eksempel meldingsutveksling og betaling Sette opp en solid og effektiv database. Denne skal være enkel å vedlikeholde og oppdatere. Brukervennlig frontend. Gjøre backend restful[2] slik at den lett kan integreres med andre enheter (Smart watch, mobil og andre applikasjoner) i fremtiden. Teknologier: Ruby on Rails. Heroku server. Waffle.io for prosjektstyring. Github for versjonskontroll. React.js i frontend. Invision for enkel visualisering av design utkast, og brukertesting. Rammebetingelser Prosjektet har ikke spesifikke rammebetingelser, men det er satt noen overordnede punkter. Kompatibelt med:

4 - Internet Explorer Google Chrome: Siste versjon - Mozilla Firefox: Siste versjon - Apple Safari: 7+ - Ovennevnte nettlesere på mobil, nettbrett og desktop. Krav til skalerbarhet - Lage et RESTful API som lar koble både web-applikasjon og en fremtidig app. Krav til brukervennlighet. Eksempler på flere testbare scenario: - En bruker med erfaring i bruk av webapper skal kunne registrere seg på under 3 minutter. - En bruker med erfaring i bruk av webapper skal kunne bestille hjelp under 3 minutter. - W3C standardene for tilgjengelighet ( accessibility ) skal følges. - Det skal påsees at applikasjonen er responsiv. Løsninger /alternativer Som på alle andre prosjekter er det mye å ta hensyn til når man begynner å snakke om hvilke teknologier man skal utnytte for å utføre oppgaven sin. Etter grundig diskusjon blant gruppemedlemmer har man kommet frem til valg av teknologier som gruppen mener er optimale. Gruppen har god kompetanse i en rekke teknologier, noe som gjorde valg av nettopp dette til en interessant diskusjon. Dette er første gang i skolesammenheng at gruppen får relativt frie tøyler når det kommer til valg av teknologi og utvikling. Webapplikasjon vs app I vår prosjektskisse skrev vi opprinnelig at målet var å lage en webapplikasjon samt en app for mobile enheter. Etter grundigere vurdering har vi bestemt oss for å kun fokusere på webapplikasjonen i vårt bachelorprosjekt. Dette fordi vi rett og slett tenker kvalitet før kvantitet. Å utvikle to stk. forskjellige plattformer i en periode på 5 måneder vil være alt for tidkrevende, og dermed setter vi fokuset på å utvikle en solid webapplikasjon. API Selv om vi kun skal fokusere på webapplikasjonen i selv bachelorprosjektet, så betyr ikke det at vi ikke tenker på muligheten for videreutvikling etter endt prosjekt. Dermed vil vi skape et API ved hjelp av Ruby on Rails som lett lar seg benytte både av vår webapplikasjon og en

5 eventuell app. Vil vil benytte oss av et RESTful API hvor målet er at skalerbarhet og integrasjon skal stå sterkt. Ruby on Rails Ruby on Rails er et rammeverk som er bygget oppå programmeringsspråket Ruby. En fordel med Rails er at mye av konfigureringen gjøres av seg selv, noe de selv markedsfører med slagordet convention over configuration [3]. Dermed blir det ingen unødvendige komplikasjoner når man skal sette opp prosjektet og man trenger ikke bruke lang tid på dette, slik det ofte kan bli når man for eksempel setter opp et Java-prosjekt En viktig fordel med å programmere i Ruby er såkalte RubyGems. RubyGems er et pakkehåndtering verktøy som er et standard format for å distribuere Ruby biblioteker. Dette er et verktøy designet for å enkelt håndtere installering av diverse gems som gjør utviklingen mye enklere. Gems er altså biblioteker som gir økt funksjonalitet. En annen fordel med Rails er at det har meget god dokumentasjon. REACT React er et JavaScript-bibliotek for utvikling av dynamiske brukergrensesnitt på web. Der hvor flere andre rammeverk prøver å løse hele stacken, tilbyr React i stedet en solid abstraksjon for utvikling av V-en i MVC, viewet. I motsetning til omtrent alle lignende teknologier søker React å gi deg en mulighet til å programmere brukergrensesnittet uten at du må forholde deg til DOM-en. Dette gjør React ved å fokusere på komponenter og trær av disse komponentene. En beskriver hvordan komponent treet ser ut gitt en gjeldende tilstand, og React finner den mest effektive måten å endre DOM-en. Det viser seg at React sin modell konseptuelt er mye lettere å forholde seg til enn en av de andre tilstands tunge DOM-sentriske løsningene. React legger også til rette for svært god ytelse. Analyse av virkninger Når vi velger å lage webapplikasjonen med Ruby on rails og React så velger teknologier som kommer til å forbli relevante i lang tid fremover, dette er selvfølgelig viktig. En av tingene som gjør at React går så fint sammen med Rails er at React ikke har noen eksterne avhengigheter, noe som gjør at den lett kan kobles opp mot andre JS biblioteker. På grunn av dette kan man enkelt implementere React inn i Rails stacken, og man vil sitte igjen

6 med Rails sånn man kjenner det, bare med et mye bedre og mer slagkraftig front-end javascript bibliotek. Risikovurdering Risikoanalyse og risikohåndtering er to veldige viktige fokusområder når en driver med prosjektplanlegging. Gruppen har identifisert overordnede risikoer for prosjektet, og vil jobbe iterativt med risikoidentifisering under hver sprint. Risikoanalysen fungerer slik at man setter opp sannsynlighet og konsekvens for en risiko, multipliserer disse og får ut en risikofaktor. Høy risikofaktor vil si at dette må prioriteres. Sannsynlighet og konsekvens vurderes med scores fra 1-5, hvor høy score vil si høy sannsynlighet/konsekvens. Referanser [1] Finn. (2016) Finn Småjobber [online]. Available: [2] Oracle. (2013) The Java EE 6 Tutorial [online]. Available: [3] Wikipedia contributors. (2016, November 3). Convention over configuration [online]. Available:

7 Framdriftsplan Prosjektmetodikk og gjennomføring Scrum 1 Som prosjektmetodikk bruker vi Scrum. For prosjektets framdrift vil dette si at det ikke vil være noen milepæler, men sprinter med 2 ukers varighet. Totalt vil det være 9 sprinter. Sprinter Hver sprint varer i 2 uker. Sprint planlegging Ansvarlig: Scrum Master Før hver sprint skal sprinten planlegges. Gruppen ser på brukerhistoriene øverst i Backlogen, og estimerer cirka hvor mye hver enkelt får gjort i løpet av den kommende sprinten. Denne estimeringen er basert på hva man fikk til i forrige sprint. Scrum Master og gruppen skal alltid forsøke å øke utført arbeid. I dette møtet er det mulig å sørge for at alle forstår hvorfor disse brukerhistoriene er så 1 Scrum (Desember 2016). Hentet fra:

8 relevante. Det er ikke lov å endre det forpliktelsene man har gjort i dette møtet under Sprinten. Sprint Vurdering / Sprint Demo Forberedelse ansvarlig: Dette rulleres hver sprint. Når: Siste fredag i Sprinten. Dette møtet viser gruppen hvor mye man har fått til i løpet av Sprinten. Alle interessenter kan komme, ikke bare produkteier, Scrum Master og gruppen, men også interessenter som vår veileder ved HiOA, og andre som kan ha interesse i det vi utvikler som brukere og andre i administrasjonen i Cee Web. Møtet er åpent, og teamet demonstrerer hva de har flyttet til kolonnen Done i løpet av Sprinten. Det er viktig at dette møter Definition of Done, se definisjonen lenger ned. Etter demonstrasjonen kan interessentene komme med tilbakemelding på hva gruppen har fullført i løpet av Sprinten. Sprint Retrospektiv Ansvarlig: Scrum Master Her ser man tilbake på arbeidet man har gjort. Hva var bra, hva kunne ha blitt gjort bedre og hva kan man gjøre fra og med neste Sprint for å forbedre arbeidet? Dette krever disiplin og fokus, da det kan være vanskelig å diskutere slike ting uten å peke fingre. Det er ikke meningen her å peke fingre. I slutten av dette møtet skal Scrum master og gruppen bli enige om hva som kan forbedres til neste Sprint. Definition of Done En oppgave møter Definition of Done når: - Koden består en enhetstest. - Funksjonaliteten møter kravet som er beskrevet i Scrum-kortet. - Code Review er utført, og godkjent av vedkommende som skal utføre dette. Alle har en Code Review partner, som skal godkjenne koden. Roller Product Owner (Produkteier) Ansvarlig: Hector Rivas Produkt eieren har visjonen bak alt gruppen skal gjøre, lage og utføre. Vedkommende vet hva som er viktigst for applikasjonens helhet, og er derfor den beste til å prioritere Backlogen. Scrum Master Ansvarlig: Fredrik A. Sigvartsen

9 Dette er personen som skal veilede gruppen gjennom Scrum rammeverket, og hjelpe dem med å eliminere alt som hindrer dem i å jobbe raskere. Interessenter HiOA Vår veileder ved Høgskolen i Oslo og Akershus, Aiko Yamashita, er en av hovedinteressentene i prosjektet. Hennes interesse av webapplikasjonen er at alt er faglig relevant i forhold til studiene gruppemedlemmene går på. Cee Web Interessentene i Cee Web er eiere og administrasjon i selskapet. Dette inkluderer også vår kontaktperson, Hector Rivas. Interessen til eierne i Cee Web er først og fremst ROI(Return on Investment), altså hva får de igjen for å investere ressurser i dette prosjektet? Gruppen jobber i dag med dette som en bacheloroppgave, og Cee Web har ytret et ønske om øke omfanget av prosjektet på et senere tidspunkt. Interessen deres blir da også at webapplikasjonen er skalerbar. Testing Ansvarlig: Jens Omfjord. Teamet Utvikler teamet: Elias A. Thøgersen, Jens B. Omfjord, Sander F. Sandøy og Fredrik A. Sigvartsen. Gjør arbeidet synlig En av de viktige elementene er synliggjøring av arbeid. Her bruker man tradisjonelt et Scrum Board hvor det benyttes ulike kolonner To do, Ready, In progress og Done. Burndown Chart er en annen måte å gjøre arbeid synlig. Her ser man hvor mye hvert medlem har utført og Scrum Master viser daglig frem dette diagrammet. Jira har et slikt Scrum Board, og det er denne applikasjonen vi bruker til å gjøre dette prosjektets arbeid synlig. Backlog Backlogen er alt det gruppen skal utføre av arbeid. Dette er en prioritert liste av 2 overordnede brukerhistorier, som beskriver funksjonaliteten på en ikke-teknisk måte. Webapplikasjonen som skal bygges, kan brytes ned i utallige brukerhistorier. Backlogen er alt gruppen kan gjøre hvis de har uendelig med tid. Produkteier sin oppgave er å sørge for at denne listen til alle tider er prioritert, basert på diskusjoner han har hatt med interessentene. 2 User stories (2015). Hentet fra:

10 Leveranser Prosjekter er ofte lagt opp til at man skal ha milepæler, og spesifikke faser for når man skal jobbe med hvilken del. I Scrum ser man at dette ikke fungerer, da estimeringen av tid oftest er urealistisk. Derfor finnes det ingen milepæler i dette prosjektet. På en annen side, så skal det leveres ferdig funksjonalitet i slutten av hver sprint. Det vil si at istedenfor å levere 3-4 større versjoner av programmet, så sikter vi oss inn på å levere ny funksjonalitet annenhver uke fra og med Sprint 3. Faser Produkt Visjon: Knytte oppdragsgivere som ønsker å kjøpe seg mer tid, og trenger hjelp med dagligdagse tjenester med oppdragstakere som ønsker å tjene ekstra penger ved siden av skole, jobb og kan til og med gjøre dette fulltid. Dette løses på en tidseffektiv og stedsbasert måte. Planlegging Sprint 1 Når: Mandag 16. Januar Mandag 30. Januar Sprint Review: Fredag 27. Januar 15:00 Implementasjon Sprint 2 Når: Mandag 30. Januar Mandag 13. Februar Sprint Review: Fredag 10. Februar 15:00 Sprint 3 Når: Mandag 13 Februar Mandag 27. Februar Sprint Review(Demo): Fredag 24. Februar 15:00 Sprint 4 Når: Mandag 27. Februar Mandag 13. Mars Sprint Review(Demo): Fredag 10. Mars 15:00 Sprint 5 Når: Mandag 13. Mars Mandag 27. Mars Sprint Review(Demo): Fredag 24. Mars 15:00

11 Sprint 6 Når: Mandag 27. Mars Mandag. 10. April Sprint Review(Demo): Fredag 7. April 15:00 System Testing Sprint 7 Når: Mandag 10. April Mandag 24. April Sprint Review(Demo): Fredag 21. April 15:00 Sprint 8 Når: Mandag 24. April Mandag 8. Mai Sprint Review(Demo): Fredag 5. Mai 15:00 Sprint 9 Når: Mandag 8. Mai Mandag 22. Mai Sprint Review: Fredag 19. Mai 15:00 Alle leveranser og faser er hypotetiske. Dette vil mest sannsynlig bli endret underveis, da man etter 2-3 sprinter vil se hvor mye man faktisk får gjort hver sprint.

12 Overordnede milepæler Arbeidsplan Brukerhistorier Brukerhistorier brukes i smidig utvikling, og gir en måte for kunden å beskrive bruksområder av et system som skal lages med sitt eget språk, uten noen form for teknologisk syntaks. Kunden setter også prioritering på de forskjellige brukerhistoriene, slik at han/hun er sikre på at den viktigste funksjonaliteten blir prioritert. I vårt tilfelle har vi delt inn alle brukerhistoriene i backlogen inn i fire forskjellige prioriteringsgrupper; Will have, Should have, Could have og Won t have. Ved å få kunden til å sette en sånn prioritering på alle brukerhistoriene gjør det det enkelt for oss når vi skal bestemme hvilke brukerhistorier vi skal jobbe med i neste sprint. Registrering av bruker Registrering av bruker via e-post. Som en ny bruker, ønsker jeg å kunne registrere meg med min e-postadresse fordi jeg ikke ønsker å bruke Facebook, LinkedIn eller Google. Registrering av bruker via Facebook. Som en ny bruker, ønsker jeg å kunne registrere meg med min Facebook-profil fordi dette går raskere. Registrering av bruker via LinkedIn. Som en ny bruker, ønsker jeg å kunne registrere meg med min LinkedIn-profil fordi dette går raskere. Registrering av bruker via Google. Som en ny bruker, ønsker jeg å kunne registrere meg med min Google-profil fordi dette går raskere. Bekreftelse av mobiltelefonnummer. Som systemansvarlig, ønsker jeg å få bekreftet legitimiteten til brukere ved å få bekreftet mobiltelefonnummer

13 Logg inn med epost. Som bruker ønsker jeg å logge inn med e-postadressen og passordet mitt fordi jeg allerede har en bruker. Logg inn med Facebook. Som bruker ønsker jeg å logge inn med Facebook profilen min fordi jeg allerede har en bruker. Logg inn med LinkedIn. Som bruker ønsker jeg å logge inn med LinkedIn profilen min fordi jeg allerede har en bruker. Logg inn med Google. Som bruker ønsker jeg å logge inn med Google profilen min fordi jeg allerede har en bruker. Opprettelse av oppdrag Chat. Som bruker ønsker jeg å kommunisere med den andre parten etter en oppdragsavtale er inngått for lettere å koordinere oppdraget. Velge type tjeneste. Som bruker ønsker jeg å spesifisere hvilken tjeneste jeg ønsker å få utført for å være sikker på at jeg får hjelp med den tjenesten jeg ønsker hjelp til. Valg om bruk av kjøretøy. Som bruker ønsker jeg å spesifisere om oppdragstaker trenger å benytte seg av en bil/lastebil for å fullføre oppdraget, slik at jeg kan spesifisere tjenesten nærmere. Velge antall oppdragstakere. Som en oppdragsgiver vil jeg ha mulighet til å velge hvor mange oppdragstakere jeg trenger for at jobben skal utføres så effektivt som mulig. Estimere antall timer. Som en oppdragsgiver vil jeg ha mulighet til å estimere hvor mange timer arbeidet tar fordi dette er informasjon oppdragstaker trenger for å vite om han kan ta jobben eller ikke. Spesifisere dato og tidspunkt. Som en oppdragsgiver vil jeg ha mulighet til å spesifisere hvilken dato og tidspunkt jeg trenger hjelp for å kunne se hvem som er tilgjengelige den datoen. Definer tjenestespesifikk informasjon. Som oppdragsgiver ønsker jeg å skrive en kort beskrivelse av oppdraget slik at oppdragstaker vet hva oppdraget går ut på. Se tilgjengelighet. Som oppdragsgiver ønsker jeg å se hvem som er tilgjengelige datoen jeg valgte tidligere slik at jeg er sikker på at personen jeg får hjelp på er ledig.

14 Oppdragstaker timeplan. Som oppdragstaker ønsker jeg å sette opp en timeplan på når jeg har lyst å jobbe, slik at jeg ikke blir forstyrret når jeg er utilgjengelig. Se aktivitet. Som en potensiell oppdragstaker, ønsker jeg å se all aktivitet i nærheten for å se hva applikasjonen har å tilby. Filtrere på pris. Som oppdragsgiver ønsker jeg å kunne filtrere prisen på tjenesten slik at den kan være innenfor mitt budsjett, når jeg velger ut personen som skal utføre jobben for meg. Generelt Se dashboard. Som bruker ønsker å ha all funksjonalitet samlet i et administrasjonspanel, slik at jeg enkelt vet hvor jeg skal navigere for å finne frem til det jeg ønsker å gjøre. Se en oversikt over fremtidige jobber. Som oppdragstaker vil jeg ha muligheten til å se en oversikt over kommende oppdrag jeg har takket ja til, og datoen på disse som en slags timeplan for å enkelt ha en oversikt over når jeg skal gjøre hva. Se en oversikt over utførte jobber. Som oppdragstaker ønsker jeg å ha en oversikt over utførte jobber, slik at jeg har dokumentasjon og referanser på jobber jeg har utført, samt oversikt over utbetalingene mine. Se kontooversikt. Som bruker ønsker jeg å kunne se oversikt over kontoen min, slik at jeg enkelt kan holde oversikt over den. Endre på kontoinnstillinger. Som bruker av applikasjonen ønsker jeg å kunne endre på kontoopplysningene mine i tilfelle faktaopplysningene mine endres mens jeg er bruker hos dere. Avbestille tjeneste. Som bruker ønsker jeg å ha mulighet til å kunne avbestille en tjeneste fordi det kan oppstå uforutsette hendelser som gjør at tidspunktet ikke passer. (Her bør det spesifiseres hvor kort tid i forkant man kan avbestille) Vurdere oppdragstaker etter utført tjeneste. Som bruker ønsker jeg å ha mulighet til å kunne vurdere oppdragstaker etter utført tjeneste, slik at andre brukere kan få nytte av min erfaring med denne oppdragstakeren.