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

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

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

Anarchy Online 1996 - 2001

Drømmefall/Dreamfall 2001 - 2005

AOC 2002 - 2008

The Secret World 2004 – 2012?

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

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

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

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.

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

Struktur

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

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

Forenklet Tidslinje

Realistisk Tidslinje

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

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

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

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

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

Konseptfase Dokumentasjon Competetive analysis Vurdering av eksisterende og fremtidig konkurrerende produkter

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

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

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

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

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

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.

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

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

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

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

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

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

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!

Spørsmål?