Your SlideShare is downloading. ×
0
Kth Nov 09
Kth Nov 09
Kth Nov 09
Kth Nov 09
Kth Nov 09
Kth Nov 09
Kth Nov 09
Kth Nov 09
Kth Nov 09
Kth Nov 09
Kth Nov 09
Kth Nov 09
Kth Nov 09
Kth Nov 09
Kth Nov 09
Kth Nov 09
Kth Nov 09
Kth Nov 09
Kth Nov 09
Kth Nov 09
Kth Nov 09
Kth Nov 09
Kth Nov 09
Kth Nov 09
Kth Nov 09
Kth Nov 09
Kth Nov 09
Kth Nov 09
Kth Nov 09
Kth Nov 09
Kth Nov 09
Kth Nov 09
Kth Nov 09
Kth Nov 09
Kth Nov 09
Kth Nov 09
Kth Nov 09
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Kth Nov 09

349

Published on

Föreläsning om Game Design på KTH.

Föreläsning om Game Design på KTH.

0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
349
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
3
Comments
0
Likes
1
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Skapa Värde <ul><li>KTH - November 2009 </li></ul>
  • 2. Varför detta är viktigt för tekniker <ul><li>- Fet bredsida från en Designer </li></ul><ul><li>Nästan alla projekt misslyckas </li></ul><ul><li>Alla i teamet är involverade </li></ul><ul><li>Alla måste vara beredda att agera </li></ul>
  • 3. Nu börjar vi
  • 4. Vad som händer när man börjar <ul><li>Skapa och underhåll ett Team </li></ul><ul><ul><li>Träna på kommunikation med varandra </li></ul></ul><ul><ul><li>Detta kräver tid i början och fortgår genom projektet </li></ul></ul><ul><li>Förtydliga och revidera en idé om en produkt </li></ul><ul><ul><li>Samlar ihop och tolkar den information som har stor relevans för produkten </li></ul></ul><ul><ul><li>Hanterar informationen tillsammans för att nå gemensamt perspektiv </li></ul></ul><ul><ul><li>Fokuserar på, tränar upp och nyttja teamets tid och engagemeng </li></ul></ul><ul><li>Skapa, underhåll och förändra en produkt </li></ul><ul><ul><li>Baserad på teamets gemensamma lärdommar, förmågor och insikter </li></ul></ul><ul><ul><li>Uppnå mål </li></ul></ul><ul><ul><li>I tät kontakt med marknaden </li></ul></ul>
  • 5. Sträva efter förbättring <ul><li>Varför bry sig om Lean och Agile? </li></ul><ul><ul><li>Marknadstypen är avgörande för processen </li></ul></ul><ul><li>Börja sakta </li></ul><ul><ul><li>Agil utveckling ökar i hastighet över tid </li></ul></ul><ul><ul><li>Att börja för fort är sällan önskvärt </li></ul></ul><ul><ul><li>Detta är svårt </li></ul></ul><ul><li>Hela teamet tränar på snabbhet under hela projektet </li></ul><ul><ul><li>Scrum ”sprint retrospectives” </li></ul></ul><ul><ul><li>Lean ”kaizen” </li></ul></ul><ul><ul><li>Generellt ”feedbackloopar” </li></ul></ul>
  • 6. Gör en del antaganden om marknaden Old Market Old Product New Market Old Product Old Market New Product New Market New Product Resegmented Existing New niche cheap Olika delar av idén har olika utmaningar. Hur ser denna marknad ut för mig? Typ av risk Teknik Efterfrågan website kraftverk (fusion) mmorpg
  • 7. Speldesign
  • 8. <ul><li>Symbolik för terminologi och funktion </li></ul><ul><li>Metafor matchar användarens mål </li></ul>Konceptuellt om Spel
  • 9. Vad spel gör <ul><li>Roligt = ”Learning in a safe environment” </li></ul><ul><li>Nervsystem &amp; dopamin </li></ul><ul><li>Spel konstrueras för att säkra effekten </li></ul><ul><li>Vad som fungerar är oftast okänt </li></ul>
  • 10. STARS - En modell för analys Cred till modellens uppfinnare: Daniel Cook (www.lostgarden.com) Skill GOAL Tools &amp; Action Rules Stimuli
  • 11. Engagemeng i allmänhet Casual Hardcore Interested Engaged Dedicated <ul><ul><li>Vanliga </li></ul></ul><ul><ul><li>Betalar Inget </li></ul></ul><ul><ul><li>Sällsynta </li></ul></ul><ul><ul><li>Betalar Mycket </li></ul></ul>GOAL Skill Tools &amp; Action Stimuli Rules
  • 12. Hur man säkrar att lyckas <ul><li>Iteration </li></ul><ul><ul><li>Vad betyder detta för produktion </li></ul></ul><ul><li>Varje ”STARS” loop kan och behöver testas </li></ul><ul><ul><li>Fel måste lagas för att addera fler loopar framgångsrikt </li></ul></ul><ul><ul><li>Vad som är ”rätt” är ofta okänt </li></ul></ul><ul><li>Detta är problematiskt för estimering </li></ul><ul><ul><li>Chablonestimat av # iterationer i produktion </li></ul></ul><ul><ul><li>Agila metoder vänder på problemet och blickar bakåt i stället </li></ul></ul>
  • 13. Vad som händer när det går bra Google Analytics från ett av våra experiment. ?
  • 14. Spel är okända problem <ul><li>Vad som är ”rätt” är okänt </li></ul><ul><ul><li>Pskologi använder ”black box” metafor för användarens psyke </li></ul></ul><ul><ul><li>Spel använder samma trick </li></ul></ul><ul><ul><li>Speldesign har några teoretiska modeller för standardmönster </li></ul></ul><ul><li>Hur vi vet vad som blev rätt </li></ul><ul><ul><li>KBT Psykologi använder ”beteendeförändring” </li></ul></ul><ul><ul><li>Spel använder samma trick </li></ul></ul><ul><ul><li>Speldesign har många teoretiska modeller för att göra antaganden </li></ul></ul><ul><li>Hur vi vet att vi är färdiga </li></ul><ul><ul><li>Alla mål uppnås </li></ul></ul><ul><ul><li>Pengarna tar slut </li></ul></ul><ul><ul><li>Information tar slut </li></ul></ul><ul><ul><li>Tiden tar slut </li></ul></ul>
  • 15. Sammanfattning Speldesign <ul><li>Speldesign är ett verktyg som gör produkter engagerande </li></ul><ul><li>Innovativ speldesign måste testas grundligt </li></ul><ul><li>För att få ett bra resultat testar man ofta </li></ul><ul><li>Ett bra resultat är en ”hockey stick” på marknaden </li></ul>
  • 16. Produktion av värde
  • 17. Saker att sträva mot över tid <ul><li>Produktivitet </li></ul><ul><ul><li>Mätbara beteendeförändringar orsakade av produkt i användarens händer </li></ul></ul><ul><ul><li>Det finns många vanliga felaktiga mätmetoder som skapar ”waste” </li></ul></ul><ul><li>Några Trick </li></ul><ul><ul><li>Optimera hela systemet för biologiska informationsnätverk </li></ul></ul><ul><ul><li>Säkra mätbarhet av alla tänkbara relevanta beteendeförändringar </li></ul></ul><ul><ul><li>Identifiera potential till ökad produktivitet </li></ul></ul><ul><li>Skapa förutsättningar </li></ul><ul><ul><li>Teamet startar i okänt territorium </li></ul></ul><ul><ul><li>Tid och utrymme för att driva OODA loop </li></ul></ul>
  • 18. Praktisk innebär <ul><li>Optimera utveckling för snabb testning </li></ul><ul><ul><li>Ta bort det som inte snabbar upp </li></ul></ul><ul><ul><li>Säkra att feedback från test är användbar </li></ul></ul>idé 110101001011110110101
  • 19. Två olika sätt att jobba på Snabbt Långsamt
  • 20. Kvalitet
  • 21. Att betrakta Kvalitet objektivt <ul><li>Alla är sällan överens om vad det innebär </li></ul><ul><ul><li>Prislapp </li></ul></ul><ul><ul><li>Lycka </li></ul></ul><ul><ul><li>Glädje </li></ul></ul><ul><ul><li>Mercedes </li></ul></ul><ul><ul><li>Upplevelse </li></ul></ul><ul><ul><li>Perfektion </li></ul></ul><ul><ul><li>Felfrihet </li></ul></ul><ul><ul><li>Funktionalitet </li></ul></ul><ul><ul><li>Konvention </li></ul></ul><ul><ul><li>... </li></ul></ul><ul><ul><li>? </li></ul></ul>
  • 22. Kvalitet är Felfrihet <ul><li>Kvalitet är inbyggd i processen </li></ul><ul><ul><li>Defekt </li></ul></ul><ul><ul><ul><li>~ Svaghet som orsakar misslyckande </li></ul></ul></ul><ul><ul><li>Förebyggande arbete </li></ul></ul><ul><ul><ul><li>i stället för reaktivt arbete </li></ul></ul></ul><ul><ul><ul><li>Continuous Deployment ftw </li></ul></ul></ul>
  • 23. Abstrakt Motiv <ul><li>Några begrepp ett team kommer pyssla med </li></ul><ul><ul><li>Produkt ~ system av noder och länkar </li></ul></ul><ul><ul><li>Metcalfe’s Law ~ Network Effect </li></ul></ul><ul><ul><li>Erlang ~ nytta av levande länk </li></ul></ul><ul><ul><li>Defekt ~ antinytta av levande länk </li></ul></ul><ul><li>Detta har några konsekvenser </li></ul><ul><ul><li>Små produkter tål större defekter </li></ul></ul><ul><ul><li>Antinytta växer lavinartat med #noder * defekter/nod </li></ul></ul><ul><ul><li>Tekniskt misslyckande smyger sig på produkten </li></ul></ul>
  • 24. Praktiska Strategiska Åtgärder <ul><li>Bryt ner produkten i lagom celler </li></ul><ul><ul><li>Speldesign matchar cellerna mot ”chunkbarhet” </li></ul></ul><ul><ul><li>Arbeta med en länk i taget </li></ul></ul><ul><ul><li>Säkra befintligt värde före skapande av nytt </li></ul></ul><ul><ul><li>I förväg betrakta länkar som inte når 1 Erlang som negativt värde </li></ul></ul><ul><ul><li>Klustra lämpliga noder </li></ul></ul><ul><ul><ul><li>Infodesigners kallar ofta detta för ”Gruppera Information” </li></ul></ul></ul><ul><li>Alternativ man kan välja i stället </li></ul><ul><ul><li>Börja om: ”Redesign” | ”Complete Rewrite” | ”Konkurs” </li></ul></ul><ul><ul><li>Sälj verksamheten till ny ägare </li></ul></ul><ul><ul><li>Byt Marknad </li></ul></ul><ul><ul><li>Investera i andra produkter </li></ul></ul>
  • 25. Praktiska Taktiska Åtgärder <ul><li>Implementera QA i arbetsprocessen </li></ul><ul><ul><li>De fem varför </li></ul></ul><ul><ul><li>Investera proportionellt mot skadans kostnad i varje steg </li></ul></ul><ul><ul><li>Automatisera detektion av defekter </li></ul></ul><ul><ul><li>Stoppa defekter från att komma igenom processen </li></ul></ul><ul><ul><li>Börja litet och träna på att växa </li></ul></ul><ul><li>Alternativa ”taktiska” åtgärder </li></ul><ul><ul><li>Skyll på något annat </li></ul></ul><ul><ul><li>Låtsas att det inte finns defekter </li></ul></ul><ul><ul><li>Fokusera på karriären </li></ul></ul><ul><ul><li>Ge bort problemet till en testavdelning </li></ul></ul>
  • 26. Åtgärder inbyggda i Agila metoder <ul><li>Definiera vad länkens Erlang är i Backlog </li></ul><ul><ul><li>Iterera samma PBI tills 1 Erlang uppnås </li></ul></ul><ul><ul><li>Investera i löpande inspektion av byggda länkar och dess noder </li></ul></ul><ul><ul><li>Delegera ägarskap av helheten till ”PO” </li></ul></ul><ul><ul><li>Delegera ägarskap av process till Teamet </li></ul></ul><ul><ul><li>Automatisera prioritering av problem ~ ”impediment” </li></ul></ul><ul><li>Alternativa processer </li></ul><ul><ul><li>Maximera antalet features (noder) </li></ul></ul><ul><ul><li>Anställ QA avdelning </li></ul></ul><ul><ul><li>osv.. </li></ul></ul>
  • 27. Kvalitet i praktiken <ul><ul><li>Hög </li></ul></ul><ul><ul><li>Hög kostnad </li></ul></ul><ul><ul><li>Stort värde </li></ul></ul><ul><ul><li>Mycket testning </li></ul></ul><ul><ul><li>Vanlig </li></ul></ul><ul><ul><li>Vanlig kostnad </li></ul></ul><ul><ul><li>Vanligt värde </li></ul></ul><ul><ul><li>Lite testning </li></ul></ul><ul><ul><li>Låg </li></ul></ul><ul><ul><li>Vanlig kostnad </li></ul></ul><ul><ul><li>Lågt värde </li></ul></ul><ul><ul><li>Gissa = testa </li></ul></ul>
  • 28. <ul><li>Hög kvalitet är logiskt simpel </li></ul>I processen onUpdate() if userCatPleasure &gt;= qualityAmbition then backlog else iterate end
  • 29. Hur detta brukar se ut #iterationer userCatPleasure qualityAmbition #!&amp;% Mjau? *Purr* = Done! Mjau? = Iterate Deadline!
  • 30. Sammanfattning Kvalitet <ul><li>Bli van att hantera defekter tillsammans </li></ul><ul><li>Långsiktig hållbarhet kostar i början </li></ul><ul><li>Livsviktigt i längden </li></ul><ul><li>I grunden är detta en fråga om testning av värde </li></ul><ul><li>&amp; Testning av teknik </li></ul>
  • 31. Konceptutveckling &amp; Scrum
  • 32. Konceptutveckling i allmänhet <ul><li>Formulerande av hypoteser så de kan valideras eller invalideras av ett utvecklingsteam </li></ul><ul><li>Scrum kallar dessa hypoteser för Backlog </li></ul>
  • 33. Antagandet om värde finns i Backlog <ul><li>Värdet i systemet är länkarna mellan noderna </li></ul><ul><ul><li>Interaktionen mellan noder har värde </li></ul></ul><ul><ul><ul><li>Features är Noder </li></ul></ul></ul><ul><ul><ul><li>Erlang dyker upp igen </li></ul></ul></ul><ul><ul><ul><li>Produkten definieras som länkar </li></ul></ul></ul><ul><ul><ul><ul><li>Dvs: Vad som händer och hur detta har ett värde </li></ul></ul></ul></ul>
  • 34. Konceptet ämnar belysa värdet <ul><li>Huvudsakligen är detta kommunikation </li></ul><ul><ul><li>Det uppstår även vissa anteckningar </li></ul></ul><ul><ul><li>Vad kommunikationen inehåller lär vi oss under resan </li></ul></ul><ul><ul><li>Verkningsgrad av kommunikation, 3 nivåer </li></ul></ul><ul><ul><li>#1: Dialog, gemensamt skissande, gemensam analys etc </li></ul></ul><ul><ul><li>#2: Tele-pressence, conf call, irc chat, google talk, msn, telefon </li></ul></ul><ul><ul><li>#3: Dokumentation </li></ul></ul>
  • 35. Dokumentation blir Backlog <ul><li>Hypoteser om värdet samlas i Backlog </li></ul><ul><ul><li>Produktägaren väljer vilket experiment teamet gör först </li></ul></ul><ul><ul><li>Teamet gör ett experiment i taget </li></ul></ul><ul><ul><li>Backlog skrivs således så det inte uppstår interna beroenden </li></ul></ul><ul><ul><ul><li>Detta är lite klurigt </li></ul></ul></ul><ul><ul><li>Experiment brukar misslyckas </li></ul></ul><ul><ul><li>Konceptet rör sig fortare än visionen, långsammare än backloggen </li></ul></ul>
  • 36. Koncept blir testbart <ul><li>Testning styr arbetet </li></ul><ul><ul><li>Vad kan testas? </li></ul></ul><ul><ul><li>När, mot vem, hur? </li></ul></ul><ul><ul><li>=============== </li></ul></ul><ul><ul><li>Hur gick testerna? </li></ul></ul><ul><ul><li>Vilket testresultat vill vi uppnå nästa gång? </li></ul></ul>
  • 37. Frågor?

×