Dokumentasjon og Planlegging av større IT-prosjekter

Presentasjon om: "Dokumentasjon og Planlegging av større IT-prosjekter"— 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 2009+ 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 Struktur 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?