Video og Database Marc Vinther Nanna Bak Eliassen Christian Bertelsen Sebastian Frank Andersen Mikkel Borg Svendsen
Indholdsfortegnelse Dokumentation af processen 4 Sprint Planning 4 Daily Scrum 5 Sprint Review 5 Sprint Retrospective 6 Burndown Charts 6 Backlogs 8 Attributtabeller 9 User Stories 10 Idé og koncept 11 Dramaturgi 12 Storyboard 13 Filmiske virkemidler 13! 3 af 17!
Dokumentation af processen Vi har valgt at opdele et stort Scrum Team, i to mindre Scrum teams til henholdsvis video og database. Da projektet blev udleveret, gik vi igang med at finde vores samlede Velocity. Ud fra antagelsen, at hvert gruppemedlem arbejder gennemsnitligt 2 timer om dagen på projektet, opnår vi en Velocity på 224 timer. I og med vi skulle levere to produkter, samt en rapport og en præsentation, skulle vi uddele varighed af de enkelte produkter og elementer den samlede aflevering skal indeholde. Vi kom frem til, at videoen fik tildelt 114 timer, databasedelen fik 75 timer, rapporten 34 timer og præsentationen har fået tildelt 5 timers arbejde. Ovenstående er absolut utopi, i og med, at 40% af arbejdsopgaverne i en Sprint, er blevet opdaget undervejs i Sprinten. Som tidligere påpeget, arbejder vi efter Scrum, og benytter os derfor også af de 5 events der finder sted under en Sprint; - Sprint Planning - Daily Scrum - Development Work - Sprint Review - Sprint Retrospective Hvorfor arbejder vi på denne måde? Det gør vi, for at opnå størst mulig effektivitet. Samtidigt, så ved at holde ovenstående events, udnytter vi de 3 grundsøjler for Scrum; Gennemsigtighed, Inspektion og Tilpasning. Sprint Planning Første event i Sprinten, er Sprint Planning. Her finder vi ud af hvad der skal laves og hvordan, og estimerer de netop definerede arbejdsopgaver, så de matcher den samlede Velocity for Sprinten. Sprint Planning er timeboxed til 8 timer, over en 30 dages Sprint. Det betyder, at den i vores tilfælde er timeboxed til 6 timer, da vores Sprint kører over 3 uger. Måden vi har estimeret arbejdsopgaverne på, er ved benyttelse af estimeringsmetoden Round Robin. En tidskrævende, men præcis estimeringsmetode. Her bliver en arbejdsopgave bragt på bordet, hvorefter første medlem fra Development Teamet giver! 4 af 17!
sit estimat på den givne arbejdsopgave. Når første medlem har gjort dette, videregives arbejdsopgaven til næste mand i rækken, der giver sit estimat på samme opgave. Er andet medlems estimat højere eller lavere, end første mands estimat, argumenteres der for de hidtil givne estimater. Når arbejdsopgaven har nået hele holdet rundt, er alle blevet enige om et endeligt, og ganske præcist, estimat. Vi har dog ikke estimeret arbejdsopgaverne tilfældigt. Vi har benyttet os af Fibonacci sekvensen, som går ud på, at vi får indarbejdet usikkerhed i forhold til arbejdsopgaverne. Selve sekvensen lyder på; 1, 2, 3, 5, 8, 13, 21, 34, 55 [ ]. Vi kan selvfølgelig ikke påbegynde en arbejdsopgave, der er estimeret til over en dags arbejde. En normal arbejdsdag er defineret til 8 timer, og hvis en arbejdsopgave bliver vurderet som værende mere end 8 timer, skal denne brydes ned i mindre arbejdsopgaver. Daily Scrum Ideelt set, ville Daily Scrum finde sted tidligst muligt på dagen, og have samme beliggenhed, hver eneste dag. På denne måde reduceres kompleksiteten ved at afholde daglige møder. Det har desværre ikke været en mulighed, i og med, at vi ikke har befundet os på en rigtig arbejdsplads. Derfor har vi valgt at holde møderne online, hvor hvert medlem har besvaret 3 spørgsmål; Hvad lavede jeg igår? Hvad skal jeg lave i dag? Samt, hvilke forhindringer har jeg i forhold til mine arbejdsopgaver; er jeg afhængig af, at nogle færdiggør deres arbejdsopgave, før jeg kan komme videre med min egen? Sprint Review Grundet projektets format, har det ikke været muligt at udnytte Scrum til punkt og prikke. Sprint Review er det afsluttende event, der vedrører de tekniske elementer af Sprinten. Vi skal skrive om vores brug af Scrum, og netop her, har disse to udmeldinger været modstridende. Når det er sagt, afholdte vi stadig Sprint Review. Selve eventet var timeboxed til 3 timer. Det blev grebet an, ved at demonstrere vores video og database strukturen; altså ved at vise de increments vi har lavet undervejs i Sprinten. Umiddelbart ville næste skridt i et Sprint Review være, at finde ud af hvad næste skridt skal være, men i og med at vi er! 5 af 17!
færdige med projektet, giver det ikke mening for os at bruge tid på dette aspekt af Sprint Reviewet. Sprint Retrospective Sidste event i Sprinten, er Sprint Retrospective. Dette event er timeboxed til halvanden time. Det er her, vi snakker om personlige forhold på teamet. Vi satte os ned sammen efter Sprint Review og gennemgik nogle spørgsmål i fællesskab; hvordan har samarbejdet været? Hvad har fungeret godt i denne Sprint? Hvad har fungeret mindre godt? Slutteligt, hvad kan vi gøre anderledes til en anden gang? Burndown Charts Vi har undervejs holdt styr på den samlede mængde arbejdsopgaver, der manglede at blive lavet. Her har vi brugt Burndown Charts, da disse viser de netop ovenstående; hvor mange timers arbejds venter, før vi kan kalde projektet for afsluttet. Grunden til at vores Burndown Charts ser ud som de gør, er at vores arbejdsopgaver ikke er blevet rykket over på sidste stadie og erklæret lukkede. Derudover har vi ikke brugt hele vores Velocity undervejs, som også kan ses på nogle af vores Burndown Charts. Som en sidenote, er vores Burndown Charts ikke lavet i Excel, da det ikke ville give mening for os, at sidde og indtaste vores tal manuelt, men i stedet benytte os af et værktøj der udfører arbejdet automatisk. På denne måde har vi kunne fokusere mere på andre elementer af projektet, og undgået at bruge unødvendig tid, ved at indtaste tallene manuelt. Alle fire diagrammer findes på næste side, hvor der medfølger en kort beskrivelse.! 6 af 17!
Rækkefølgen på vores Burndown Charts lyder således; først selve produktet. Næste Burndown Chart er for databasen. Tredje mand i rækken befinder sig nederst til venstre, og repræsenterer rapporten. Slutteligt, nederst til højre, befinder der sig en Burndown Chart for videoen.! 7 af 17!
Backlogs Vi har under Sprint Planningen fået stablet en Product Backlog på benene, der viser alle arbejdsopgaver og estimeringer af disse. Vi har valgt at opdele det yderligere, så vi har en backlog til hvert produkt og element; en til video, en til database, en til rapporten og en til det samlede produkt. Vi har brugt Trello til at sætte boards op, til de enkelte produkter og elementer. Her har vi 4 scenarier til arbejdsopgaver: - Backlog - Selve backloggen. Her ses alle estimerede arbejdsopgaver. Det giver os et overblik over hvad der mangler at blive lavet. - In Progress - Opgaver der bliver arbejdet på i øjeblikket, og er tildelt et gruppemedlem. - Review / QA - Er en arbejdsopgave rykket over på dette scenarie, betyder det at vedkommende der har arbejdet på den, har vurderet den som værende færdig. Derfor er den sende til review, for at et andet gruppemedlem kan kigge opgaven igennem. Grunden til at vi gør det på denne måde, er at man kan komme til at stirre sig blind på sit eget arbejde efter en vis tid, og derfor ved et uheld overse komplikationer. - Done - En arbejdsopgave der har været alle scenerierne igennem, og derved kan bedømmes som værende færdig.! 8 af 17!
Attributtabeller Client Attributes Type Null Default idclient (Primary) Int(11) No - Client_Name Varchar(45) No - Client_Address Varchar(45) Yes Null Client_Contact_Person Varchar(45) No - Client_Contact_Phone Varchar(45) Yes Null ZipCode_idZipcode Int(11) No - Project Attributes Type Null Default idproject (Primary) Int(11) No - Project_Name Varchar(45) Yes Null Start-date Datetime Yes Null End-date Datetime Yes Null Project_detail Longtext Yes Null Client_idClient (Primary) Int(11) No - Project_has_Resources Attributes Type Null Default Project_idProject (Primary) Int(11) No - Resource_idResource (Primary) Int(11) No - From_Date Datetime Yes Null To_Date Datetime Yes Null! 9 af 17!
Hourly_Usage_Rate Varchar(45) Yes Null Resource_Type Attributes Type Null Default idresource_type (Primary) Int(11) No - Resource_Type_Name Varchar(45) No - Resources Attributes Type Null Default idresources (Primary) Int(11) No - Resource_Name Varchar(45) Yes Null Resources-Detail Varchar(45) Yes Null Resource_Type_idResource_Type Int(11) No - Zipcode Attributes Type Null Default idzipcode (Primary) Int(11) No - City Varchar(45) No - User Stories For at skabe overblik over hvilke kriterier der er til databasen, har vi udarbejdet en række user stories, som er krav stillet fra brugeren til os, hvilket skal udforme databasen. - Som bruger, vil jeg gerne kunne indtaste mit navn. - Som bruger, vil jeg gerne kunne informere om min adresse. - Som bruger, vil jeg gerne kunne indtaste navn på en kontaktperson - Som bruger, vil jeg gerne kunne give information om kontaktpersonens telefonnummer.! 10 af 17!
- Som bruger, vil jeg gerne kunne give information om mit projekt. - Som bruger, vil jeg gerne kunne informere om hvilke ressourcer jeg bruger. Idé og koncept Selve projektet kan deles op i to dele. Videodelen og databasedelen. Videodelens hovedformål, var at beskrive den kommunikation der rent faktisk finder sted mellem browseren, web serveren og database serveren. Den kommunikation og den proces det er, har vi illustreret i vores film i form af en rejse gennem hverdagen og det danske land. Da målgruppen for denne film er andre multimediedesignstuderende, som måske ikke umiddelbart kender til databaser og den kommunikation der finder sted mellem databasen, browseren og web serveren, var det utrolig vigtigt for os, at målgruppen nemt kunne relatere og forholde sig til forklaringen. Vi vurderede, at det ville være klart nemmest at forstå, hvis vi tog udgangspunkt i hverdagen. Efter længere tids spekulationer, endte vi med at blive enige om, at noget af det som allerflest studerende kan nikke genkendende til, er den offentlige transport. Så det blev temaet for vores film.! 11 af 17!
Dramaturgi Filmens hovedperson står på en station, laver en HTML request (via P.O.V. interface), dørene åbner, og vi stiger ind og kører nu gennem PHP-land, hvor vi skifter sprog/tog til mysql, der leverer requesten videre til databasen, også kendt som endestationen. Vi kører herefter fra databasen, tilbage til mysql, tilbage til PHP og leverer en Succesfull request tilbage til clienten, som er vores hovedperson. Ovenstående er en kort beskrivelse af filmens handling - hvor vi som sagt vil forsøge at forklare den kommunikation der finder sted mellem browseren, web serveren og database serveren. For at sikre filmens dramaturgi har vi opbygget vores film efter berettermodellen, som gerne skal være med til at sikre at seerens opmærksomhed er fanget fra start til slut. Berettermodellen består af 7 faser, der hver har sin funktion i den samlede fortælling. Filmens første to faser er anslaget og præsentation og er her hvor seeren får en forsmag for filmens handling samt en præsentation af filmens hovedpersoner og location. Disse to faser, finder sted i filmens første scene hvor hovedpersonen og hans agenda bliver præsenteret. Filmens tredje fase er uddybningen og er her hvor seeren får mere af vide om filmens konflikter. Dette sker, da filmens hovedperson laver en såkaldt HTML request. Point of no return er filmens fjerde fase, og er der hvor der sker en afgørende begivenhed. Filmens hovedperson tager en afgørende beslutning, ved at hoppe ombord på toget. Der er derfor ingen vej tilbage. Konfliktoptrapningen er der hvor hovedpersonen bliver udfordret og det sker i en ret stor del af filmen, da hovedpersonen skal skifte tog en hel del gange. Filmens klimaks sker når konflikten løses og hovedpersonen når frem til databasen (endestationen) mens udtoningen finder sted, når hovedpersonen tager tilbage til udgangspunktet. Congratulations, you have succesfully signed up for the newsletter.! 12 af 17!
Storyboard Et storyboard er en god måde at forberede sig på, når man skal filme. Har man forberedt sig hjemmefra og lavet et storyboard kan man spare tid og kræfter på at skulle diskutere, hvordan handlingen skal være i næste scene, hvordan kameraindstillingen skal være, hvor langt klippet skal være, hvilken lyd der skal være og så videre. Vi har også lavet et storyboard, så vi netop var fri for at skulle tage stilling til om hvorvidt kameravinklen skulle være den ene, den anden eller den tredje. På vores storyboard kan man se, at filmens hovedperson starter med at stå på en togstation med ryggen til kameraet. Kameraet zoomer ind i hovedpersonens hoved, og ender med at blive hovedpersonens point of view hvor et interface dukker op. Hovedpersonen stiger på det første tog, og vi følger ham i toget. Hovedpersonen forlader toget, og vi ser en timelaps af stationen som hovedpersonen befinder sig på. Vi følger hovedpersonen ind i næste tog, til han forlader toget igen, inden han går ind i et nyt tog, som han også forlader. Hovedpersonen når frem til endestationen, og POV interfacet viser at databasen arbejder og går fra blå til grøn. Hovedpersonen skal nu tilbage til start. Dette gøres i form af timelapse i de tre toge som hovedpersonen skal igennem. Hovedpersonen stiger ud af det sidste tog, og POV interfacet viser at HTMLrequesten var succesfuld. Ud fra vores storyboard, havde vi derfor en god fornemmelse af, hvordan den endelige film ville gå hen og se ud. Dog med mulighed for enkelte ændringer, hvilket man også kan se i filmen. Det er jo tilladt at blive klogere og få nye kreative idéer. Filmiske virkemidler Vi har valgt at stille fremvise vores brug af filmiske virkemidler ved at opstille hver scene, og beskrive de enkelte virkemidler hertil; beskæring, synsvinkel, klipning, lyd og bevægelse.! 13 af 17!
Scene 1 Beskæring: Halvtotal Scene 2 Beskæring: Halvtotal Scene 3 Beskæring: Halvnær Bevægelse: Zoom Klipning: Kontinuitetsklipning Scene 4 Beskæring: Total / Point of view Bevægelse: Håndholdt Klipning: Kontinuitetsklipning! 14 af 17!
Scene 5 Beskæring: Total Scene 6 Beskæring: Total Synsvinkel: Fugleperspektiv Scene 7 Beskæring: Supertotal Bevægelse: Håndholdt Scene 8 Beskæring: Halvtotal! 15 af 17!
Scene 9 Beskæring: Supertotal Scene 10 Beskæring: Total Synsvinkel: Frøperspektiv Scene 11 Beskæring: Total Bevægelse: Håndholdt Scene 12 Beskæring: Halvtotal! 16 af 17!
Scene 13 Beskæring: Halvtotal Scene 14 Beskæring: Halvtotal Scene 15 Beskæring: Halvtotal Scene 16 Beskæring: Supertotal! 17 af 17!