Presentasjon lastes. Vennligst vent

Presentasjon lastes. Vennligst vent

Dokumentasjon og Planlegging av større IT-prosjekter Fra en spillutviklers perspektiv.

Liknende presentasjoner


Presentasjon om: "Dokumentasjon og Planlegging av større IT-prosjekter Fra en spillutviklers perspektiv."— Utskrift av presentasjonen:

1 Dokumentasjon og Planlegging av større IT-prosjekter Fra en spillutviklers perspektiv

2  Jarl Schjerverud  1994 – 2007 Funcom, Lead Game Designer/Producer  Foreleser i spilldesign ved HIOF og NITH  Jobber til daglig som rådgiver i ODIN MEDIA

3 Om Foredraget  Dokumenter og dokumentasjon  Gjennomføring  Planlegging  Prosess, fra ide til produkt  Kort introduksjon av spill-industri og prosjekter

4 Anarchy Online

5 Drømmefall/Dreamfall

6 AOC

7 The Secret World 2004 – 2012?

8 Spillutvikling da...  Enkle produkter  Små team  Små budsjetter  Utviklingstid i uker

9 ...og nå  Team: 200+  Budsjett: $50 mill. +  Tid: 2 – 5 år

10  13 millioner abonennter ...betaler USD 13 per mnd.  USD 169mill per mnd!

11 Utfordringer  Store team, mange unge og uerfarne  Høy risiko, lange prosjekter  Svært komplekse oppgaver i mange disipliner  Programmering  Prosjektledelse  Grafikk  Animasjon  Lyd  Musikk  Dramaturgi  Etc.

12  Store krav til kvalitet  Levering på tid  Holde tritt med teknologi  Utvikling over flere platformer  Forutsi marked flere år frem i tid  Endring av spesifikasjon underveis

13 Struktur

14  Prosjektleder – overordnet ansvar for tid, budsjett, bemanning  Game Director – overordnet kreativt ansvar  Team Leads – ansvar for avdeling

15 Typiske Faser  (Kravspesifikasjon/Analyse)  Konsept  Innsalg, oppstart  Design og spesifikasjon  Implementasjon  Verifikasjon/Testing  Release  Vedlikehold

16 Forenklet Tidslinje

17 Realistisk Tidslinje

18 Prosjektplan  Ta høyde for at endringer (alltid) vil skje  Men aldri ta lett på endringer  Sørge for at alle endringer går igjennom alle faser:  Konsept  Spesifikasjon  Implementasjon  Test  Prøve å identifisere tidlig hvor en vil få flere iterasjoner  Iterativ prosjekt-modell

19  Interne milestones slik at en får testet at alle systemer og ressurser fungerer sammen.  Timeboxing  Tilpasse ambisjon på system/feature nivå  Distribuere tilgjengelig tid – slik at vanskelige eller kritiske systemer får ”mest” tid

20 Dokumentasjon  Konseptfase  Ideutvikling  Definere hva som skal lages  Vurdere om prosjektet skal startes

21 Konseptfase Dokumentasjon  High Concept  Overordnet beskrivelse av forslag til hva som skal lages  Kortfattet – intern bruk  Concept  Detaljering av hva som skal lages  Kortfattet beskrivelse av alle elementer

22 Konseptfase Dokumentasjon  Risk assessment  Risikovurdering spesifik for prosjektet  Hvilke risker finnes  Sannsynlighet  Plan om risiko inntreffer

23 Konseptfase Dokumentasjon  Competetive analysis  Vurdering av eksisterende og fremtidig konkurrerende produkter

24 Konseptfase Dokumentasjon  Pitch  Salgsfremmende dokument til ekstern bruk  Baseres på konsept

25 Konseptfase Dokumentasjon  Preliminary project plan  Første utkast til mulig prosjektplan  ”Deliverables”  Definisjon av videre faser  Preliminary staffing plan  Kompetanse  Når  Hvor mange

26 Dokumentasjon  Designfase  Detaljering og spesifikasjon av alle elementer  Svært nøyaktig beskrivelse av ”alt”  Er det ikke dokumentert – er det ikke i spillet  100% innsats gir 80% dokumentasjon

27 Designfase Dokumentasjon  System designs  Spesifikasjon av funksjonalitet, mekanismer, regler, etc.  Mange dokumenter  ”Tusenvis” av sider – presisjon og detaljenivå avgjørende for videre arbeide  Alle moduler brytes ned i mindre og mindre biter til de er ”håndterbare” – for så å bli spesifisert  Gjør det mulig å jobbe parallelt

28 Designfase Dokumentasjon  Content designs  Spesifikasjon av alt innhold (som systemene bruker)  Text  Personer (NPC, PC)  Lyd  Musikk  Brett (level design)  Etc.

29 Designfase Dokumentasjon  Teknisk spesifikasjon  Teknisk spesifikasjon basert på system og content design  Typen spesifikasjon er avhengig av område; • Programmering • Grafikk (2d/3d) • Lyd • Animasjon • Etc.  Kan føre til nødvendig endring av design pga. Tid, budsjett, teknologi, etc.

30 Dokumentasjon  Implementasjonsfase  Alle tekniske spesifikasjoner brytes ned i minste mulige, praktiske arbeidsoppgave – ”Tasks”  Hver task estimeres med: • Minste tid • Største tid • Sannsynlig tid  Estimasjonen må gjøres av den som skal utføre oppgaven

31

32 Dokumentasjon  Implementasjonsfase  Risiko dokumentasjon oppdateres  Prosjekt plan oppdateres  Design dokumenter oppdateres/vedlikeholdes løpende

33 Dokumentasjon  Verifikasjon/Test-fase  All testing gjøres mot eksisterende dokumentasjon  ”Test cases” lages og dokumenteres for typiske brukerscenarioer ...men også for de mest atypiske  Platform spesifik kompabilitetstesting

34 Dokumentasjon  Verifikasjon/Test-fase  Alle feil og mangler rapporteres tilbake som arbeidsoppgaver (tasks)  Spesifikasjoner/Design dokumentasjon er utgangspunkt

35 Verktøy  Prosjekt plan (MS Project)  Design/Spesifikasjon (Wiki)  Tasks (Bugzilla, Basecamp)  Bug-rapportering (Bugzilla)

36 Guidelines  Enighet om hva som skal lages  Detaljert spesifikasjon av ”alt”  Bryt ned spesifikasjon i minste mulige arbeidsoppgaver  Bruk god tid på å få gode tidsestimater på alle arbeidsoppgaver  La de som skal utføre oppgavene estimere og planlegge sine egne oppgaver

37 Guidelines  Tilrettelegge for endringer  Bruke nok tid på planlegging før en starter implementasjon  Dokumentasjon skal være så kortfattet som mulig – men samtdig så detaljert som mulig  Dokumentasjon skal fungere som referanser – ikke romaner!  Dokumentasjonen skal tjene utviklerne – ikke omvendt!

38 Spørsmål?


Laste ned ppt "Dokumentasjon og Planlegging av større IT-prosjekter Fra en spillutviklers perspektiv."

Liknende presentasjoner


Annonser fra Google