Dokumentasjon og Planlegging av større IT-prosjekter

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 1996 - 2001

5. Drømmefall/Dreamfall 2001 - 2005

6. AOC 2002 - 2008

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

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?