1. No category

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
5
Burndown Charts
6
Backlogs
8
Attributtabeller
9
User Stories
11
Idé og koncept
12
Dramaturgi
12
Storyboard
13
Filmiske virkemidler
14
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 sit estimat på den givne
arbejdsopgave. Når første medlem har gjort dette, videregives arbejdsopgaven til næste mand i
4 af 17
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 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
5 af 17
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
-
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
-
9 af 17
Project
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
Hourly_Usage_Rate
Varchar(45)
Yes
Null
Attributes
Type
Null
Default
idResource_Type (Primary)
Int(11)
No
-
Resource_Type_Name
Varchar(45)
No
-
Project_has_Resources
Resource_Type
Resources
10 af 17
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
-
Attributes
Type
Null
Default
idZipcode (Primary)
Int(11)
No
-
City
Varchar(45)
No
-
Zipcode
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.
Som bruger, vil jeg gerne kunne give information om mit projekt.
11 af 17
- 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.
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
12 af 17
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”.
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.
13 af 17
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 HTML-requesten 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.
14 af 17
Scene 1
Beskæring: Halvtotal
Synsvinkel: Normalperspektiv
Klipning: Krydsklipning
Lyd: Asynkron lyd
Scene 2
Beskæring: Halvtotal
Synsvinkel: Normalperspektiv
Klipning: Krydsklipning
Lyd: Asynkron lyd
Scene 3
Beskæring: Halvnær
Synsvinkel: Normalperspektiv
Bevægelse: Zoom
Klipning: Kontinuitetsklipning
Lyd: Asynkron lyd
Scene 4
Beskæring: Total / Point of view
Synsvinkel: Normalperspektiv
Bevægelse: Håndholdt
Klipning: Kontinuitetsklipning
Lyd: Asynkron lyd
15 af 17
Scene 5
Beskæring: Total
Synsvinkel: Normalperspektiv
Klipning: Krydsklipning
Lyd: Asynkron lyd
Scene 6
Beskæring: Total
Synsvinkel: Fugleperspektiv
Klipning: Krydsklipning
Lyd: Asynkron lyd
Scene 7
Beskæring: Supertotal
Synsvinkel: Normalperspektiv
Bevægelse: Håndholdt
Klipning: Krydsklipning
Lyd: Asynkron lyd
Scene 8
Beskæring: Halvtotal
Synsvinkel: Normalperspektiv
Klipning: Krydsklipning
Lyd: Asynkron lyd
16 af 17
Scene 9
Beskæring: Supertotal
Synsvinkel: Normalperspektiv
Klipning: Krydsklipning
Lyd: Asynkron lyd
Scene 10
Beskæring: Total
Synsvinkel: Frøperspektiv
Klipning: Krydsklipning
Lyd: Asynkron lyd
Scene 11
Beskæring: Total
Synsvinkel: Normalperspektiv
Bevægelse: Håndholdt
Klipning: Krydsklipning
Lyd: Asynkron lyd
Scene 12
Beskæring: Halvtotal
Synsvinkel: Normalperspektiv
Klipning: Krydsklipning
Lyd: Asynkron lyd
17 af 17
Scene 13
Beskæring: Halvtotal
Synsvinkel: Normalperspektiv
Klipning: Krydsklipning
Lyd: Asynkron lyd
Scene 14
Beskæring: Halvtotal
Synsvinkel: Normalperspektiv
Klipning: Krydsklipning
Lyd: Asynkron lyd
Scene 15
Beskæring: Halvtotal
Synsvinkel: Normalperspektiv
Klipning: Krydsklipning
Lyd: Asynkron lyd
Scene 16
Beskæring: Supertotal
Synsvinkel: Normalperspektiv
Klipning: Krydsklipning
Lyd: Asynkron lyd
18 af 17