Arbetsplan och Problemsöknings nivåer

Idag valde jag att förändra min kursplan en aning, dels utifrån den feedback jag fick men också för att jag ville skifta fokuset ifrån metoder till hur informations insamling skulle förändra mitt arbete.

För att kunna utvärdera hur min arbetsprocess fungerar med hjälp utav ett automatiserat eller ett manuellt problem letnings verktyg så behöver jag veta hur jag arbetar med detta just nu och då passar den här arbetsboken alldeles utmärkt.

Idag har jag stött på en del problem som behövde undersökas men dessa var i någon form ganska traditionella programmerings problem som är en del utav att jag utvecklar något och alltså inte rör teamet eller någon annan än mig.

Madens jag utvecklar något gör jag ju själv en liten egen kvalitets säkring som i och för sig är så ytlig att jag ser att det som ska hända faktiskt händer.

Ett exempel var när kameran blev vänd upp och ner och eftersom jag fortfarande sitter och skriver och ändrar i mattematiken så rättade jag till det direkt och så behövde problemet inte komma ut till resten utav teamet utan kunde fixas direkt utav mig. Alltså en ytlig översikt som ser att det inte finns några uppenbara problem.

Om jag skulle summera vilka tydliga nivåer utav problemsökning vi har internt så skulle det se ut såhär:

  1. Jag skriver programkod och ser att jag får det önskade beteendet.
  2. Jag ser över mina ändringar genom att går in i spelet och testar alla funktioner jag la till
  3. Om de första två kollarna jag gjorde inte innehöll några uppenbara fel laddar jag upp dessa till resten utav teamet.
  4. Teamet utför här en ofrivillig test utav det jag förändrat eller lagt till i och med att de laddar ner mina uppdateringar får jag ganska omgående reda på om jag glömt lägga till filer eller andra saker som får själva spelmotorn att säga ifrån
  5. Om allt är prima med det kommer nästa problem check att bli under vårt nästa interna speltest där teamet är med och spelar och testar alla nya funktioner om något fel skulle upphittas under speltestet får jag snabbt reda på det utav mitt team som diskuterar problemet och om det är något som behövs fixas innan vi fortsätter med att lägga till mer funktionalitet eller låta vår community och utomstående testa det.

Jag skriver ofta ner buggar på papper där de svåraste eller största buggarna blir fixade innan jag fortsätter bygga ny funktionalitet men andra mindre buggar kan komma att bli kvar och glömmas bort vilket är något som jag kanske borde hitta en bra lösning på.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s